1 / 18

RIKE Using Revocable Identities to Support Key Escrow in PKIs

RIKE Using Revocable Identities to Support Key Escrow in PKIs. Nan Zhang, Jingqiang Lin , Jiwu Jing, Neng Gao State Key Laboratory of Information Security, Chinese Academy of Sciences linjq@lois.cn. Public Key Infrastructure - PKI.

primo
Download Presentation

RIKE Using Revocable Identities to Support Key Escrow in PKIs

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. RIKEUsing Revocable Identities to Support Key Escrow in PKIs Nan Zhang, Jingqiang Lin, Jiwu Jing, Neng Gao State Key Laboratory of Information Security, Chinese Academy of Sciences linjq@lois.cn

  2. Public Key Infrastructure - PKI • A PKI certificate binds a public key and the identity of a user U. • Signed by a certification authority (CA). • The public key (or certificate) can be used to verify signatures and encrypt messages, by another user U’. • U’ shall firstly validate/verify the certificate.

  3. Conflicting Requirement – Key Escrow • Non-repudiation: prohibit key escrow • Key escrow is prohibited, if the certificate (or public key) is used for non-repudiation. • E.g., verify signatures

  4. Conflicting Requirement – Key Escrow • Non-repudiation: prohibit key escrow • Confidentiality: require key escrow • Key escrow (or key recovery) is usually required, if the certificate is used for confidentiality; e.g., encrypt messages. • A corporation backs up all private keys of its employees. • To decrypt the messages, in the case that the private key is unavailable.

  5. Conflicting Requirements in One User • These conflicting requirements can exist in one user. • U signs messages, sent to everybody. • Other users sends encrypted messages to U.

  6. Current solutions • Two-certificate solutions • Each userhas twocertificates (i.e., two key pairs). • One is for non-repudiation, not escrowed. • The other is for confidentiality, escrowed. • Key escrow authority (KEA) • The component is responsible for storing the backups of escrowed private keys.

  7. Drawback of the current Solution • PKI system/CA • The number of certificates is doubled • Relying party, who uses the certificate to encrypt/verify messages • Validate or maintain two certificates for each contact • Key escrow authority • As certificates expire and more users • Backup more and more private keys

  8. Our Solution - RIKE • RIKE • Using Revocable Identities of IBE to support Key Escrow in PKIs • Integrating IBE and PKIs

  9. IBE: Identity-based encryption • A special type of public key algorithm • Private key generator (PKG) • Initializes a secret master key and the pubic parameters • A user's public key is calculated from its identity and the pubic parameters • by anybody • The user asks the PKG to generate the private key corresponding to its identity. • When receiving encrypted messages

  10. Inherent key escrow of IBE • Features • Any bit-string can be used to derive a public key • Inherent key escrow • The PKG generates private keys for all IBE users

  11. RIKE • Basic idea • Each user has only one certificate, not escrowed • The certificate is used for non-repudiation

  12. RIKE • Basic idea • Each user has only one certificate, not escrowed • The hash value of the certificate is inputted to IBE as the “identity” to derive the second public key • This key pair is used for confidentiality • This IBE private key is inherently escrowed

  13. RIKE • Only one certificate • PublicKey1 is not escrowed, used for the services prohibiting key escrow • PublicKey2 is escrowed in the PKG, used for other services requiring key escrow

  14. Benefits – from PKI • The conflicting requirements of key escrow is satisfied • Each user holds only one certificate • Relying parties manage only one certificate for each contact • Compared with two-certificate solutions, the number of certificates is half • The PKG only keeps the IBE master key • On the contrary, the KEA in the current solutions back up all private keys

  15. Benefit – from IBE • In IBE, revocation is difficult, because users don’t want to change their identities • In RIKE, the certificate can be revoked by lots of existing PKI revocation mechanisms • The certificate is used as a “revocable identity” for IBE • If the PKI certificate is revoked, the “identity” and the IBE key pair is also revoked • It helps to the application of IBE algorithms

  16. Benefit – Compatibility • RIKE integrates PKIs and IBE, in a highly-compatible way. • It is highly-compatible with the popular X.509 PKIs. • A certificate extension is designed to carry the IBE algorithm parameters • If a user doesn’t support this extension, the certificate is used a common X.509 certificate. • If the user support the extension, the IBE public key is derived.

  17. Other issues • Integrate hierarchical IBE and hierarchical PKIs to build hierarchical RIKE • Hierarchical RIKE with cross certificates • Refer to the paper for details

  18. Thanks Any questions or comments? Jingqiang Lin <linjq@lois.cn>

More Related