RIKE: Using Revocable Identities to Support Key Escrow in PKIs

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 protected]
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
 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
▫ 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
• 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
• Basic idea
▫ Each user has only one certificate, not
 The certificate is used for non-repudiation
• Basic idea
▫ Each user has only one certificate, not
▫ 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
• 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
Period of validity,
CA signature, ...
As the "identity"
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 highlycompatible 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
Any questions or comments?
Jingqiang Lin <[email protected]>

similar documents