Presentation on theme: "RIKE Using Revocable Identities to Support Key Escrow in PKIs Nan Zhang, Jingqiang Lin, Jiwu Jing, Neng Gao State Key Laboratory of Information Security,"— Presentation transcript:
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 email@example.com
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.
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
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.
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.
Current solutions Two-certificate solutions ▫Each user has two certificates (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.
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
Our Solution - RIKE RIKE ▫Using Revocable Identities of IBE to support Key Escrow in PKIs ▫Integrating IBE and PKIs
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
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
RIKE Basic idea ▫Each user has only one certificate, not escrowed The certificate is used for non-repudiation
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
RIKE Only one certificate ▫PublicKey 1 is not escrowed, used for the services prohibiting key escrow ▫PublicKey 2 is escrowed in the PKG, used for other services requiring key escrow
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
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
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.
Other issues Integrate hierarchical IBE and hierarchical PKIs to build hierarchical RIKE Hierarchical RIKE with cross certificates Refer to the paper for details