On the Risks of IBE

1
On the Risks of IBE

• Himanshu Khurana and Jim Basney
• NCSA, University of Illinois
• International Workshop on Applied PKC (IWAP),
  Dalian, China, Nov 2006

2
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

3
Secure Email with RSA (SMIME)
4
Secure Email with IBE
5
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

6
Trust AssumptionsIBE vs. RSA

• Fully trusted PKG
• Generates private keys
• Online PKG
• Revocation via short-lived 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

7
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?

8
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 RD Workshop, number 7224 in
  Interagency Reports, pages 102115. 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 193210, 2003.

9
IBE with Conventional PKI(Callas, 2005)
Recipient Domain
(PKR,SKR) f(SKPKG,IDR)
PKG (SKPKG)
Sender (IDS)
Receiver (IDR)
10
IB-mRSA(Ding and Tsudik, 2003)
Recipient Domain
SEM
CA
Sender (IDS)
Receiver (IDR)
11
Secure Email with IB-MKD(Identity Based -
Message Key Distribution)
12
Object-Based Key Distribution(Ford and Wiener,
1994)
Recipient Domain
Key Release Agent (SK, PK)
PKKRA
kpolicyPKKRA
k
Sender (IDS)
Receiver (IDR)
E(m)
E(m) mk,kpolicyPKKRA
13
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

14
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 cant 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.
15
Online versus Offline

• RSA-based IBE approaches assume online operation
• Contact SEM/KDC for every message
• Contact PKG for every recipient Callas05
• IBEs 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?

16
Conclusions

• Secure Email with IBE has strong trust
  assumptions
• Need to be evaluated carefully before deployment
• IBEs complex cryptography may be unnecessary
• IB-MKD achieves goals with RSA
• Questions?
• hkhurana_at_ncsa.uiuc.edu
• jbasney_at_ncsa.uiuc.edu