1 / 31

Identity-Based Cryptography for Grid Security

Hoon Wei Lim Information Security Group Royal Holloway, University of London (Joint work with Kenny Paterson). Identity-Based Cryptography for Grid Security. Outline. Grid security Identity-based cryptography An identity-based alternative to GSI Performance analysis

tallulah-lynch
Download Presentation

Identity-Based Cryptography for Grid Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hoon Wei Lim Information Security Group Royal Holloway, University of London (Joint work with Kenny Paterson) Identity-Based Cryptography for Grid Security

  2. Outline • Grid security • Identity-based cryptography • An identity-based alternative to GSI • Performance analysis • Benefits and drawbacks • Conclusions

  3. 1. Grid Security • Grid security requirements: • Entity authentication • E.g. individual users, resource/service providers. • Single sign-on • Logon once but authenticate to multiple resources. • Delegation • Achieve unattended authentication, allowing an intermediate party to act on user’s behalf. • Credential life-span and renewal • Short-term (proxy) credentials are used to limit the exposure of long-term credentials (private keys) • Authorization and access control • Others: integration and inter-operability, policy management, trust relationships, user privacy, etc.

  4. GSI: Single sign-on • User’s long-term private key encrypted using key derived from password. • Public key certified by X.509 certificate that is issued by Grid CA. • At logon: • Password unlocks long-term private key. • User’s machine generates proxy/short-term key pair. • Proxy certificate for short-term public key signed using long-term private key. • Proxy private key protected by local file system permissions. • User now uses proxy credential to authenticate, establish secure sessions, etc. • No password re-entry needed and long-term private key protected.

  5. GSI: Authentication • Mutual authentication performed as part of a TLS handshake protocol. • Needed during job submission and before delegation. • Make uses of standard and proxy certificates in ClientCert and ServerCert. • Proxy private keys are used for signing handshake flows. • Involves transmission and verification of certificate chains.

  6. GSI: Secure communications • Authenticated session key establishment also as part of the TLS handshake protocol. • Uses RSA encryption to transport keying material securely from client (user) to server (resource). • Proxy keys are used for RSA encryption. • Keying material used to derive keys for TLS secure channel.

  7. GSI: Delegation • Delegation of rights from one party to another. • For example, a resource X may need to access additional resources on behalf of user A, without user intervention. • Resource X creates proxy key pair. • Proxy request signed using X’s newly created proxy private key and delivered to user A along with proxy public key. • A’s proxy checks request and signature, then creates proxy certificate on resource’s proxy public key and proxy request. • Signature created using A’s proxy private key. • Proxy certificate forwarded to resource X. • A certificate from user (proxy) delegating certain rights to resource.

  8. Some problems • Large number of signature and certificate chain verifications are needed. • Even for execution of a simple job request. • SSO and delegation require frequent generation of proxy credentials. • Each new credential requiring moderately intensive key generation (typically use 512 and 1024 bit RSA keys). • Several protocol messages and round trips involved in delegation. • High computational and communication overheads. • CRLs as proposed revocation mechanism for long-term keys. • Scalability and timeliness of information. • Does the security architecture scale to production level grids?

  9. 2. Identity-Based Cryptography Original idea due to Shamir (1984): • Public keys derived directly from system identities (e.g. an e-mail address or IP address). • Private keys generated and distributed to users in by a trusted authority (TA) who has a master key. • As long as: • Bob is sure of Alice’s identity and • The TA has given the private key to the right entity, then Bob can safely encrypt to Alice without consulting a directory and without checking a certificate.

  10. Basic idea of IBC TA Private Key Alice’s ID Public Key

  11. Reality of IBC TA Authentic public parameters Secure channel Alice’s ID

  12. IBC: A short history • Shamir devised only an ID-based signature scheme. • Construction of trulypractical and secure ID-based encryption scheme an open problem until 2001. • Sakai, Ohgishi and Kasahara (SCIS, Jan. 2001). • Boneh and Franklin (CRYPTO, Aug. 2001). • Practical and provably secure. • Uses elliptic curve cryptography and pairings on elliptic curves. • Cocks’ scheme (IMA C&C, Dec. 2001). • Scheme based on quadratic residuosity, not bandwidth efficient. • Research done in mid 1990’s at UK government agency.

  13. Some benefits of IBC • Certificate-free. • No processing, management or distribution of certificates. • Directory-less. • Bob can encrypt for Alice without looking-up Alice’s public key first. • Indeed, Alice need not have her private key when she receives Bob’s encryption. • Automatic revocation. • Simply extend identifier to include a validity period. • Alice’s private key becomes useless at end of each period, because Bob will start to update identifier. • So Alice needs to obtain private key for current period from TA in order to decrypt.

  14. Hierarchical IBC • Hierarchical identity-based cryptography (HIBC). • Gentry and Silverberg (2002) • Eases the private key distribution problem and improves scalability of the Boneh-Franklin IBE scheme. • Mimics the hierarchy of CA’s often seen in PKI. • HIBE and HIBS schemes. • Architecture: • A root TA at level 0 with a master secret s0. • Entity at level t-1 in hierarchy has secret st-1 and issues private keys St to entities at level t for which it is responsible. • So each entity acts as TA for lower-level entities. • Any entity can encrypt for (or verify signatures of) any other entity in the hierarchy, provided their identity string is known.

  15. 3. An ID-based Alternative • Main ideas: • Replace Grid CA by Grid TA (or hierarchy of TAs depending on the scale). • Apply the Gentry-Silverberg HIBE and HIBS schemes for encryption/decryption and signature generation/verification. • Eliminate certificates and certificate chains. • Simplify proxy generation and dissemination. • Use automatic revocation feature of HIBC to limit proxy credential lifetimes and to set proxy policies. • Use carefully selected cryptographic parameters to minimise computation and bandwidth requirements.

  16. ID-based architecture • Bootstrap root TA’s parameters into grid software. • One-time registration of local TAs with root TA. • Local TAs responsible for: • Registration of local users and resources. • Distribution of long-term private keys to local users and resources. • Users and resources in turn act as TAs for their proxies. • Distribution of short-term (proxy) private keys within user machine/resource.

  17. ID-based architecture Level 0 Root TA Level 1 Local TA Local TA Level 2 User Resource User Proxy Resource Proxy Level 3

  18. Single sign-on Level 0 Root TA Level 1 Local TA Local TA Level 2 User Resource User Proxy Resource Proxy Level 3 Single Sign On: • Password unlocks user (level 2) private key. • User (level 2) can then create private key for user proxy (level 3). • Level 3 identifier encodes validity period for proxy. • Level 3 identifiers can be parsed by resources when checking proxy signatures and making access control decisions.

  19. Delegation • User proxy combines user proxy identifier, resource identifier, validity period and delegated privileges to create identifier for delegated resource (level 4). • Identifier acts as a form of delegation token. • User proxy transports private key matching identifier to resource, e.g. using a shared session key. • Resource can now use private key to vouch that it has received delegated rights from user proxy. • Exploits dynamic nature of HIBC: • User proxy creates a new level below it in hierarchy. • Delegated resource effectively becomes subordinate to user proxy in hierarchy.

  20. Delegation Level 0 Root TA Level 1 Local TA Local TA Level 2 User Resource User Proxy Resource Proxy Level 3 Secure private key transport Delegated Resource Level 4

  21. Delegation: Alternative • A one-pass non-interactive delegation protocol. • When user wants to delegate her credential to resource: • User creates identifier (delegation token) as before. • User signs the identifier (using HIBS) and forwards it to resource. • Resource’s status as the delegation target can be confirmed by a third party by: • Verifying the signed delegation token using user’s ID. • Challenging resource to prove possession of the identity-based private key matching delegation token.

  22. Delegation: Alternative Level 0 Root TA Level 1 Local TA Local TA Level 2 User Resource User Proxy Resource Proxy Delegated Resource Level 3 Signature on token Level 4

  23. Authentication and secure communications • Use identity-based version of TLS. • Gives mutual authentication and establishment of secure communications channel. • Replace RSA signatures by HIBS. • Replace RSA encryption for key transport by HIBE. • Replace ClientCert and ServerCert with ClientIdentifer and ServerIdentifier. • E.g.ClientIdentifier = IDA , LTA • Needs support in TLS for new ID-based ciphersuites.

  24. Key update and revocation • User long-term keys can be updated on a yearly basis. • Encode year as part of user identifier. • /C=UK/O=eScience/OU=RHUL/CN=Alice/Y=2006 • Update requires secure channel from TA to user. • Can use existing user public key to encrypt new private key. • We can use finer-grained identifiers for more regular automated revocation: • /C=UK/O=eScience/OU=RHUL/CN=Alice/Y=2006/M=May • However, if this is still not sufficient, existing PKI revocation mechanisms such as CRLs, OCSP, can be used. • Default lifetime for short-term keys in GSI is 12 hours. • Mimic this by including expiry periods in all proxy identifiers.

  25. 4. Performance Analysis • Assumptions: • CA’s certificates and TA’s system parameters are pre-distributed. • Size of standard certificate = 1.5 kilobytes (RSA public key, modulus, signature, excluding subject, issuer, validity period). • Size of proxy certificate = 0.8 kilobytes. • Selection of ID-based components to give roughly same security as 1024-bit RSA. • Dominant computational costs: • GSI – RSA key generation. • ID-based GSI – pairing computation. • Dominant communication costs: • GSI – certificates, RSA encryption (512 bits) and signature (512 bits). • ID-based GSI – HIBE encryption (1056 bits) and HIBS signature (816 bits).

  26. Communication costs • GSI: • Authenticated key agreement: 4 certificates (2 proxy), 1 encryption, 1 signature. • Delegation: 1 proxy certificate, 1 signature, 1 public key. • ID-based GSI: • Authenticated key agreement: 1 encryption, 1 signature. • Delegation: 1 signature.

  27. Computational costs • GSI: • Single sign-on:1 key generation • Authenticated key agreement (TLS): 6 modular exponentiations (encryption), 2 modular exponentiations (decryption) • Delegation: 1 key generation, 1 modular exponentiation (encryption), 2 modular exponentiations (decryption) • ID-based GSI: • Single sign-on: 1 key generation (1 point multiplication and 1 point addition) • Authenticated key agreement (TLS): 3 point multiplications, 4pairing computations, 1 point addition. • Delegation: 1 key generation, 1 point multiplication.

  28. Computational costs • Timings obtained through implementation of RSA and HIBE/HIBS schemes based on the MIRACL library (with C/C++). • Using a Pentium IV 2.4 GHz processor. • Known optimisation techniques were used, e.g. small RSA public exponent, faster RSA decryption (CRT method) and eta pairing. • The two approaches have comparable costs.

  29. 5. Benefits and Drawbacks Benefits: • Identity-based replication of existing grid security features. • Certificate-free • Reduced bandwidth and comparable computational costs. • More efficient delegation mechanisms. • Automated revocation of keys. • Trivial computation of proxy key pairs.

  30. Benefits and drawbacks Drawbacks: • Inherent escrow may be a problem in commercially-oriented grid environments. • But MyProxy already in wide-spread use! • Distribution of private keys to users/resources. • Fine-grained revocation requires an additional mechanism. • Current lack of support for and standardization of IBC.

  31. 6. Conclusions • We have used ID-based techniques to propose an alternative grid security infrastructure. • ID-based techniques seem well-matched to the grid environments. • Our ID-based proposal has significant benefits, but also some drawbacks. • Future work: • Prototyping? • Impact on web services security? • Use of certificateless public key cryptography?

More Related