interoperation between a conventional pki and an id based infrastructure n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Interoperation Between a Conventional PKI and an ID-Based Infrastructure PowerPoint Presentation
Download Presentation
Interoperation Between a Conventional PKI and an ID-Based Infrastructure

Loading in 2 Seconds...

play fullscreen
1 / 15

Interoperation Between a Conventional PKI and an ID-Based Infrastructure - PowerPoint PPT Presentation


  • 80 Views
  • Uploaded on

Interoperation Between a Conventional PKI and an ID-Based Infrastructure. Geraint Price Royal Holloway University of London joint work with Chris Mitchell. Overview. Introduction Technical Background A Simple Certificate-Based Solution Extending Our Analysis Lessons Learnt and Future Work

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Interoperation Between a Conventional PKI and an ID-Based Infrastructure' - iola


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
interoperation between a conventional pki and an id based infrastructure

Interoperation Between a Conventional PKI and an ID-Based Infrastructure

Geraint Price

Royal Holloway University of London

joint work with Chris Mitchell

overview
Overview
  • Introduction
  • Technical Background
  • A Simple Certificate-Based Solution
  • Extending Our Analysis
  • Lessons Learnt and Future Work
  • Conclusions

EuroPKI 2005

introduction
Introduction
  • Our analysis focuses on the following scenario:
    • Domain A uses a certificate-based PKI
    • Domain B uses an ID-based PKI
    • Users in domains A & B wish to interact securely
  • We consider issues such as:
    • What are the specific issues arising for interoperation in either direction?
    • What are the security implications of interoperation?
    • What lessons can we learn, and where do we go from here?

EuroPKI 2005

technical background
Technical Background
  • Certificate management in a conventional PKI adds a significant overhead
  • In 1984 Shamir proposed Identity-based cryptography, where the public-private key pair is generated from public information
  • Until Boneh and Franklin’s work in 2001, no efficient encryption mechanism existed
  • Sender can encrypt a message to a recipient without having to retrieve the recipient’s public key

EuroPKI 2005

technical background ii
Technical Background (II)
  • Main operational differences:
    • Trusted Authority (analogous to the CA) generates all private keys using a domain secret
    • Private decryption keys only need to be generated when they are required for decryption
    • There is no explicit means of revocation, but there are similar associated problems
  • Very little prior work that studies the interaction:
    • Chen et al [2002] and Smetters and Durfee [2003] propose a tiered approach

EuroPKI 2005

a simple certificate based solution
A Simple Certificate-Based Solution
  • We consider the “obvious” solution:
    • Cross-certification between the two domains
  • How does cross-certification work natively?
    • In the certificate-based world, there is already plenty of work done in this area
    • In the ID-based world, no prior work uses ID-based cryptography to secure inter-domain communication
  • It appears that ID-based cryptography is not suitable for supporting inter-domain credentials

EuroPKI 2005

the certificate based user
The Certificate-Based User
  • How the scheme would work:
    • CA for domain A generates a cross-certificate for the TA in domain B
    • The cross-certificate could contain policy information for domain B that is of relevance to domain A
    • The user in domain A validates the cross-certificate and checks the policy for acceptability
    • There will typically be a need for a certificate status check, and possibly some additional path validation

EuroPKI 2005

the certificate based user ii
The Certificate-Based User (II)
  • We now note some potential difficulties
  • Certificate content and type:
    • Identity certificate or attribute certificate?
    • We believe that an identity certificate would be preferable in practice
  • CP and CPS:
    • Cert-based PKIs rely heavily on CPs and CPSs
    • ID-Based environments allow the offloading of policy creation onto the user

EuroPKI 2005

the certificate based user iii
The Certificate-Based User (III)
  • How does the cert-based user assure themselves that the private keys in domain B conform to the desired policy?
  • Two possible solutions:
    • The TA in domain B could release a set of policy statements in an similar manner to a CP
    • The sender in domain A generates a new identity-based key with a reference to the appropriate policy

EuroPKI 2005

the id based user
The ID-Based User
  • How the scheme would work:
    • The TA for domain B generates a cross-certificate for the public key of the CA in domain A
    • This cross-certificate could contain policy information for domain A of relevance to a user in domain B
    • The user in domain B validates the cross-certificate and checks the policy for acceptability
    • There will typically be a need for a certificate status check and possibly some additional path validation
  • While this gives the functionality we require, it is a rather inelegant solution

EuroPKI 2005

the id based user ii
The ID-Based User (II)
  • An alternative would be to have the TA in domain B issue an identity-based signing key to the CA within domain A
  • This approach is unlikely to be used in practice
  • CP and CPS – two candidate approaches:
    • Users in domain B would be required to parse the certificate policies of domain A
    • The TA within domain B could identify suitable CPs from domain A
  • The second option provides for a cleaner approach

EuroPKI 2005

the id based user iii
The ID-Based User (III)
  • Revocation: A “pure” identity-based implementation relies on key re-issuance
  • Three candidate mechanisms for users in domain B to validate domain A certificates:
    • The CA could issue new certificates at the same rate as the TA would issue identity-based keys
    • The TA could act as a filter for user requests
    • The user could be required to interrogate the CRL and OCSP servers directly
  • Application level considerations are likely to impact on this design decision

EuroPKI 2005

extending our analysis
Extending Our Analysis
  • Potential Alternative Solutions:
    • Reversal of the burden of work onto the recipient using an identity-based key
    • Using a trusted intermediary to decrypt and re-encrypt the flow of messages
    • Less complexity in signature based solution
  • Additional Technologies:
    • Certificateless Public Key Cryptography (Al-Riyami and Paterson [2003])
    • Certificate Chaining

EuroPKI 2005

lessons learnt and future work
Lessons Learnt and Future Work
  • What are the main differences that impact on interoperation?
    • How the policy setting and validation is performed
    • Where and how the policy matching takes place
    • The difference in what is being certified and what is the content of the identifier
  • What additional work is needed?
    • An assessment of policy handling in light of actual security requirements
    • Potential for attribute certificates in cross-certification

EuroPKI 2005

conclusions
Conclusions
  • Existing technical solutions are far from ideal for the users in an identity-based environment
  • Candidate solutions either force identity-based clients to make use of certificates, or they require the use of trusted intermediaries
  • Building mechanisms to limit the impact at the user level is likely to require additional intermediary services

EuroPKI 2005