Slides - Pairings In Cryptography

innocentsickΤεχνίτη Νοημοσύνη και Ρομποτική

21 Νοε 2013 (πριν από 3 χρόνια και 6 μήνες)

67 εμφανίσεις

Identity
-
based cryptography for
GRID security

Kenny Paterson

Information Security Group

Royal Holloway, University of London

Joint work with Hoon Wei Lim



Pairings in Cryptography, Dublin, June 12
-
15 2005

2

Outline

1.
Introduction to GRID computing

2.
GRID security

3.
An identity
-
based approach to GRID security

4.
A hybrid approach

5.
Future work

Pairings in Cryptography, Dublin, June 12
-
15 2005

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.

Pairings in Cryptography, Dublin, June 12
-
15 2005

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.

Pairings in Cryptography, Dublin, June 12
-
15 2005

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


Pairings in Cryptography, Dublin, June 12
-
15 2005

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.



Pairings in Cryptography, Dublin, June 12
-
15 2005

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.

Pairings in Cryptography, Dublin, June 12
-
15 2005

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?




Pairings in Cryptography, Dublin, June 12
-
15 2005

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.



Pairings in Cryptography, Dublin, June 12
-
15 2005

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
ID
1
||ID
2
||…||ID
t


Entity at level
t
-
1

in hierarchy has secret
s
t
-
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.






Pairings in Cryptography, Dublin, June 12
-
15 2005

11

Single Sign
-
On




Root TA

Local TA

User

User Proxy

Local TA

Resource

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.


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.

Pairings in Cryptography, Dublin, June 12
-
15 2005

12

Delegation


1




Root TA

Local TA

User

User Proxy

Local TA

Resource

Delegated
Resource

Level 0

Level 1

Level 3

Level 2

Level 4

Pairings in Cryptography, Dublin, June 12
-
15 2005

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.

Pairings in Cryptography, Dublin, June 12
-
15 2005

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!

Pairings in Cryptography, Dublin, June 12
-
15 2005

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.


Pairings in Cryptography, Dublin, June 12
-
15 2005

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.

Pairings in Cryptography, Dublin, June 12
-
15 2005

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.



Pairings in Cryptography, Dublin, June 12
-
15 2005

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?