On the Risks of IBE Himanshu Khurana and Jim Basney NCSA, University of Illinois International...
-
Upload
paul-willis -
Category
Documents
-
view
216 -
download
0
Transcript of On the Risks of IBE Himanshu Khurana and Jim Basney NCSA, University of Illinois International...
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)
SMIME: {m}PKR
PK R
Domain A Domain B
CAA
(SKA, PKA)CAB
(SKB, PKB)
Sender(IDS)
Receiver(IDR)
{PKR}SKB
IBE: {m}PKR
PKR = f(PKPKGB
, IDR, policy)
Secure Email with IBE
Domain A Domain B
PKGA
(SKA, PKA)PKGB
(SKB, PKB)
Sender(IDS)
Receiver(IDR)
PK PKG B
SKR
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 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
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
PKG(SKPKG)
Sender(IDS)
Receiver(IDR)
(PKR,SKR) = f(SKPKG,IDR)
SKR
{m}PKR
PKR
IDR
IB-mRSA(Ding and Tsudik, 2003)
Recipient Domain
Sender(IDS)
Receiver(IDR)
CertOrg
SEMCA
SKR,U
SKR,SEM
{m}PKR
PKR = f(CertOrg,IDR)
{m}PKR
{{m}PKR } SKR,SEM
-1
Secure Email with IB-MKD(Identity Based - Message Key Distribution)
PKKDC
Recipient Domain
KDC(SK, PK)
Sender(IDS)
Receiver(IDR)
• KDC = Key Distribution Center • {m}k denotes symmetric encryption• {x}PK denotes asymmetric encryption
{k||IDR||policy}PKKDC
k
E(m)
E(m) = {{m}k,{k||IDR||policy}PKKDC}
Object-Based Key Distribution(Ford and Wiener, 1994)
PKKRA
Recipient Domain
Key Release Agent(SK, PK)
Sender(IDS)
Receiver(IDR)
{k||policy}PKKRA
k
E(m)
E(m) = {{m}k,{k||policy}PKKRA}
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 ComparisonS/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]