1 / 18

Identity-based cryptography for GRID security

Kenny Paterson Information Security Group Royal Holloway, University of London Joint work with Hoon Wei Lim. Identity-based cryptography for GRID security. Outline. Introduction to GRID computing GRID security An identity-based approach to GRID security A hybrid approach Future work.

jersey
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. Kenny Paterson Information Security Group Royal Holloway, University of London Joint work with Hoon Wei Lim Identity-based cryptography for GRID security

  2. Outline • Introduction to GRID computing • GRID security • An identity-based approach to GRID security • A hybrid approach • Future work

  3. 1. What is GRID computing? A technology that enables coordinated resource sharing in dynamic and multi-institutional virtual organisations (VOs). Example GRIDs: UK e-Science GRID; European DataGRID.

  4. What Is GRID Computing? • Globus Toolkit (GT) • The de facto standard open source software toolkit. • GT3 in wide use, GT4 (web-services enabled) released in late 2004. • GRAM • GRID Resource and Allocation Management. • Users request job execution on remote resource. • GRAM defines interface for job request and control. • Globus Security Infrastructure (GSI) • Defines a security infrastructure to provide general purpose security services for GRIDs. • PKI-based, using X.509 certificates.

  5. 2. GRID Security • Standard security requirements • Authentication, authorisation and access control. • Particularly for job execution and data access on remote resources. • Data confidentiality and integrity. • For data in transit between local host and remote resources. • GRID-specific requirements • Support for single sign-on (SSO). • User need only enter password once per session • Support for delegation of capabilities (proxying). • Both for SSO and for delegation of job execution from one resource to another. • Interoperability with local security solutions (e.g. Kerberos).

  6. 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 short-term key pair (proxy key pair). • Proxy certificate for proxy key pair signed using long-term private key. • Long-term private key now deleted; proxy private key protected by local file system permissions. • User now uses proxy key pair (and certificate) to authenticate, establish secure sessions etc. • No password re-entry needed and long-term private key protected. • SSL/TLS used for secure communications.

  7. Delegation • Delegation of capabilities from one party to another. • For example, a resource may need to access additional resources on behalf of user, without user intervention. • Resource creates proxy key pair. • Proxy request signed using resource’s long-term private key and delivered to user along with proxy public key. • User checks request and signature, then creates proxy certificate on resource’s proxy public key and proxy request. • Signature created using user’s proxy private key. • Proxy certificate forwarded to resource. • 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 for clients. • CRLs as proposed revocation mechanism for long-term keys. • Scalability and timeliness of information. • Is further support for revocation of proxy credentials needed? • How does the architecture scale to production level GRIDs?

  9. 3. An ID-based Approach • In a GRID environment: • Users and resources have well-defined identities. • Membership, access rights and trust relationships fairly static over time. • Key escrow not of great concern. • May change with advent of commercial GRIDs. • These are all indicators that an ID-based approach to GRID security may bring some benefits. • Main ideas: • Replace GRID CA by GRID TA or hierarchy of GRID TA and local TAs (one per organisation in GRID). • Use hierarchical ID-PKC to manage proxying. • Exploit identifiers to specify policies and validity periods. • Use carefully selected parameters to minimise computation and bandwidth requirements.

  10. ID-based Architecture • Hard-code root TA’s params into GRID software. • One-time registration of local TAs with root TA. • Local TAs responsible for registration of their users and resources. • Use Gentry-Silverberg HIBE and HIBS. • Identity at level t formed as ID1||ID2||…||IDt • Entity at level t-1 in hierarchy has secret st-1 and issues private keys to entities at level t for which it is responsible. • Any entity can encrypt for (or verify signatures of) any other entity in the hierarchy, provided their identity string is known.

  11. Single Sign-On Level 0 Root TA Level 1 Local TA Local TA Level 2 User Resource User 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. • And, for example, a subset of user’s privileges. • Level 3 identifiers can be parsed by resources when checking proxy signatures and making access control decisions.

  12. Delegation – 1 Level 0 Root TA Level 1 Local TA Local TA Level 2 User Resource User Proxy Level 3 Delegated Resource Level 4

  13. Delegation – 2 • User proxy combines user proxy identifier, resource identifier, validity period and delegated privileges to create identifier for delegated resource (level 4). • User proxy transports private key matching identifier to resource using HIBE. • Resource can now use private key to vouch that it has received delegated capability from user proxy. • Apparently such key transport is a not acceptable in the GRID community. • So regard private key as a BLS-style signature on a set of privileges requested by a resource. • Key transport becomes certificate delivery! • When exercising proxy, resource should show this certificate and prove knowledge of level 3 private key matching identifier in certificate.

  14. Secure Communications • User proxy and resource can engage in SSL/TLS-like protocol to authenticate and establish secure communications channel. • Needs support for new ID-based ciphersuites. • Replace RSA/DSA signatures by HIBS. • Replace RSA encryption by HIBE (key transport version of protocol). • Or DHKE mod p by elliptic curve DH (DH version). • Replace ClientCert and ServerCert messages by null strings!

  15. Benefits • Benefits of the ID-based approach include: • Automatic revocation via expiry of time-limited identifiers. • Reduced round trips if user can predict delegation requests. • Reduced bandwidth. • Bulky certificate chains eliminated, shorter keys. • Similar computational costs. • Trivial computation of proxy key pairs (RSA key pair generation replaced by elliptic curve multiplication). • Replication of existing GRID security capabilities. • Easy integration with SSL/TLS.

  16. Drawbacks • Some drawbacks: • Inherent escrow may be a problem in commercially-oriented GRID environments. • Management of distribution of private keys to users/resources. • Handle at time of registration. • Optional inclusion of expiry information in user identifiers. • Finer grained revocation requires a separate mechanism. • But comparable in effectiveness to use of CRLs in conventional GRID.

  17. 4. A Hybrid Approach • Use PKI at levels 0-2 combined with ID-PKC at the user level (level 2) and below. • Users become TAs for a shallow hierarchical ID-based system. • Solves key escrow problem for users. • Now only rightful users can know private keys of proxies. • Retains many benefits of fully ID-based approach. • Simple support for SSO and delegation. • Lightweight proxy key pair generation. • Exploit IDs as identifier to encode delegation policies, privileges, validity periods. • But now (short) certificate chains needed. • Architecture explored in more detail in paper by Lim and Robshaw.

  18. 5. Future Work • Detailed comparison of computation and bandwidth requirements. • Pure ID-PKC verus hybrid approach versus pure PKI. • Can certificateless PKC offer something extra? • Can we exploit aggregate signatures to make multiple delegations easier? • Efficient ID-based aggregate signature scheme? • Mixed scheme allowing aggregation of ID-based and short signatures? • Can we exploit Boneh-Boyen HIBE with constant-sized ciphertexts? • Can we exploit ID-based non-interactive key agreement to reduce round trips in establishment of secure channels? • Not if forward secrecy/key freshness is desired. • Can we tune group size/parameters to different levels in a HIBE/HIBS scheme? • c.f. use of 512-bit and 1024-bit keys at different levels in GSI. • GT4 allows use of web services. • Suggests an ID-PKC approach to web services might be interesting?

More Related