Identity-Based Cryptography for Grid Security

Identity-Based Cryptography for Grid Security

Hoon Wei Lim

Information Security Group

Royal Holloway, University of London

(Joint work with Kenny Paterson)

2The 17th Global Grid Forum, May 10-12, Tokyo

Outline

1. Grid security

2. Identity-based cryptography

3. An identity-based alternative to GSI

4. Performance analysis

5. Benefits and drawbacks

6. Conclusions


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.


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.


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.


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.


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.


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?


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.


Basic idea of IBC

TA

Private Key

Alice’s ID

Public Key


Reality of IBC

TA

Secure channel

Authentic public parameters

Alice’s ID


IBC: A short history

Shamir devised only an ID-based signature scheme. Construction of truly practical 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.


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.


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.


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.


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.


ID-based architecture

Root TA

Local TA

User

User Proxy

Local TA

Resource

Level 0

Level 1

Level 3

Level 2

Resource Proxy


Single sign-on

Root TA

Local TA

User

User Proxy

Local TA

Level 0

Level 1

Level 3

Level 2

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.

Resource

Resource Proxy


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.


Delegation

Root TA

Local TA

User

User Proxy

Local TA

Delegated Resource

Level 0

Level 1

Level 3

Level 2

Level 4Secure private key transport

Resource

Resource Proxy


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.


Resource Proxy

Delegation: Alternative

Root TA

Local TA

User

User Proxy

Local TA

Resource

Delegated Resource

Level 0

Level 1

Level 3

Level 2

Level 4 Signature on token


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.


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.


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).


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.

Operation GSI (kbits)ID-based

(kbits)

Authenticated Key agreement (TLS) 37.8 1.9

Delegation 7.8 0.8


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, 4

pairing computations, 1 point addition. Delegation: 1 key generation, 1 point multiplication.


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.

Operation GSI (ms)ID-based

(ms)

Long-term key generation 149.90 1.69

Proxy key generation 34.85 1.74

Authenticated Key agreement (TLS) 5.34 28.95

Delegation 37.49 5.09


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.


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.


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?

Documents

Identity-Based Cryptography for Grid Security