Transcript On the Risks of IBE*

On the Risks of IBE
Himanshu Khurana and Jim Basney
NCSA, University of Illinois
International Workshop on Applied PKC (IWAP),
Dalian, China, Nov 2006
Introduction
• Identity based cryptography flourishing
 Initial work by Cocks, Boneh and Franklin
• Encrypted email is a killer app for IBE
(Identity Based Encryption)
 Primary benefit: eliminate key distribution
• We analyze IBE for Email and argue that:
 IBE brings significant risks to email security
• Stronger trust assumptions
• Unnecessarily complex cryptosystem
 Can easily be replaced by other cryptosystems; e.g., RSA
Secure Email with RSA (SMIME)
Domain A
Domain B
CAA
(SKA, PKA)
CAB
(SKB, PKB)
{PKR}SKB
Sender
(IDS)
SMIME: {m}PKR
Receiver
(IDR)
Secure Email with IBE
Domain A
Domain B
PKGA
(SKA, PKA)
PKGB
(SKB, PKB)
SKR
Sender
(IDS)
PKR =
f(PKPKGB, IDR, policy)
IBE: {m}PKR
Receiver
(IDR)
Benefits of IBE
• Eliminate User Key Distribution
 One key fetch per domain (PKG)
 Sender generates public keys of domain users
• Policy-based encryption
 E.g., “open after Monday”
• Implicit user mobility
 Recipient can get private key from any location onto
any device
Trust Assumptions
IBE
vs.
RSA
• Fully trusted PKG
 Generates private keys
• Online PKG
 Revocation via shortlived keys
• Weaker end-to-end
encryption
 PKG can decrypt
messages
• Partially trusted CA
 Users generate keys
• Offline CA
 Revocation via CRLs,
OCSP
• Strong end-to-end
encryption
 Only recipient can
decrypt messages
IBE Revocation
• Goal: Minimize extent of compromise
• IBE time-based sender policy [Boneh03]
 How does sender determine appropriate policy?
 Requires policy standardization
• Update domain parameters [Smetters03]
• Revoke the identity?
RSA-based IBE
• Can we implement IBE for email using RSA?
• Prior work:
 J. Callas. Identity-Based Encryption with Conventional
Public-Key Infrastructure. In 4th Annual PKI R&D
Workshop, number 7224 in Interagency Reports, pages
102–115. NIST, 2005.
 X. Ding and G. Tsudik. Simple Identity-Based
Cryptography with Mediated RSA. In CT-RSA, Lecture
Notes in Computer Science 2612, Springer, pages 193–
210, 2003.
IBE with Conventional PKI
(Callas, 2005)
Recipient Domain
(PKR,SKR) = f(SKPKG,IDR)
PKG
(SKPKG)
SKR
Sender
(IDS)
Receiver
(IDR)
IB-mRSA
(Ding and Tsudik, 2003)
Recipient Domain
CA
SKR,SEM
SEM
SKR,U
-1
SKR,SEM
Sender
(IDS)
PKR = f(CertOrg,IDR)
Receiver
(IDR)
Secure Email with IB-MKD
(Identity Based - Message Key Distribution)
• KDC = Key Distribution Center
• {m}k denotes symmetric encryption
• {x}PK denotes asymmetric encryption
Recipient Domain
KDC
(SK, PK)
{k||IDR||policy}PKKDC
k
Sender
(IDS)
E(m) = {{m}k,{k||IDR||policy}PKKDC}
Receiver
(IDR)
Object-Based Key Distribution
(Ford and Wiener, 1994)
Recipient Domain
Key Release Agent
(SK, PK)
{k||policy}PKKRA
k
Sender
(IDS)
E(m) = {{m}k,{k||policy}PKKRA}
Receiver
(IDR)
Analysis
• IB-MKD achieves IBE benefits, same trust assumptions
 Using widely-accepted RSA cryptosystem
 Previous RSA-based IBE work fails to do so
• Protocol differences in IB-MKD
 User encrypts with domain public key
• Highlights weaker notion of end-to-end encryption
• Does not change security properties
 Policy itself is encrypted
• Additional feature not provided in IBE
 Recipient must contact KDC for every message
• More overhead than IBE but comparable to POP over SSL
• Provides timely policy evaluation and immediate revocation
System Comparison
S/MIME
IBE
IB-mRSA
Callas
IB-MKD
Trusted
Entities
CA is partially
trusted for public
key distribution.
PKG is fully trusted.
CA and SEM are
fully trusted.
PKG is fully
trusted.
KDC is fully
trusted.
End-to-end
Encryption
CA can’t decrypt
messages.
PKG can decrypt
messages.
CA can decrypt
messages but
SEM cannot.
PKG can decrypt
messages.
KDC can decrypt
messages.
Encryption
Key Fetch
One key fetch per
recipient.
One key fetch per
domain.
One key fetch
per domain.
One key fetch per
recipient.
One key fetch
per domain.
Decryption
Key Fetch
Offline. Recipient
generates the
private key.
One key fetch per
policy.
Contact SEM for
partial decryption
of each message.
One key fetch
per policy.
Obtain symmetric
key from KDC
for each message.
Revocation
OCSP/CRLs.
Short-lived keys.
Immediate
revocation via
SEM.
Could support
short-lived keys.
Immediate
revocation via
KDC.
Policy-based
Encryption
No direct support.
Policy included in
key generation.
No direct support.
Could be
extended to
support.
Policy associated
with message
key.
Recipient
Mobility
Requires smartcard
or key repository.
Implicit. Recipient
fetches key from
PKG.
Requires
smartcard or key
repository.
Implicit.
Recipient fetches
key from PKG.
Implicit.
Recipient fetches
key from KDC.
Encryption
Key/Target
Recipient key.
Recipient key.
Recipient key.
Recipient key.
KDC public key.
Online versus Offline
• RSA-based IBE approaches assume online
operation
 Contact SEM/KDC for every message
 Contact PKG for every recipient [Callas05]
• IBE’s strength may be offline environments
 Pre-distribute PKG parameters and secret keys
 If timely revocation is not a strong requirement
• Can RSA simulate offline IBE?
Conclusions
• Secure Email with IBE has strong trust assumptions
 Need to be evaluated carefully before deployment
• IBE’s complex cryptography may be unnecessary
 IB-MKD achieves goals with RSA
• Questions?
 [email protected]
 [email protected]