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
• 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
▫ PublicKey1 is not escrowed, used for the
services prohibiting key escrow
▫ PublicKey2 is escrowed in the PKG, used
for other services requiring key escrow
Certificate
IDU
PublicKey1
Period of validity,
CA signature, ...
Hash
As the "identity"
IBE
PublicKey2
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 <linjq@lois.cn>