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 is a killer app for IBE (Identity Based Encryption)  Primary benefit: eliminate key distribution We analyze IBE for and argue that:  IBE brings significant risks to security Stronger trust assumptions Unnecessarily complex cryptosystem  Can easily be replaced by other cryptosystems; e.g., RSA

Secure with RSA (SMIME) SMIME: {m} PK R PK R Domain ADomain B CA A (SK A, PK A ) CA B (SK B, PK B ) Sender (ID S ) Receiver (ID R ) {PK R } SK B

IBE: {m} PK R PK R = f(PK PKG B, ID R, policy) Secure with IBE Domain ADomain B PKG A (SK A, PK A ) PKG B (SK B, PK B ) Sender (ID S ) Receiver (ID R ) PK PKG B SK R

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 IBEvs.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 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,  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 (SK PKG ) Sender (ID S ) Receiver (ID R ) (PK R,SK R ) = f(SK PKG,ID R ) SK R {m} PK R PK R ID R

IB-mRSA (Ding and Tsudik, 2003) Recipient Domain Sender (ID S ) Receiver (ID R ) Cert Org SEMCA SK R,U SK R,SEM {m} PK R PK R = f(Cert Org,ID R ) {m} PK R {{m} PK R } SK R,SEM

Secure with IB-MKD (Identity Based - Message Key Distribution) PK KDC Recipient Domain KDC (SK, PK) Sender (ID S ) Receiver (ID R ) KDC = Key Distribution Center {m} k denotes symmetric encryption {x} PK denotes asymmetric encryption {k||ID R ||policy} PK KDC k E(m) E(m) = {{m} k,{k||ID R ||policy} PK KDC }

Object-Based Key Distribution (Ford and Wiener, 1994) PK KRA Recipient Domain Key Release Agent (SK, PK) Sender (ID S ) Receiver (ID R ) {k||policy} PK KRA k E(m) E(m) = {{m} k,{k||policy} PK KRA }

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/MIMEIBEIB-mRSACallasIB-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 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. RevocationOCSP/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. 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 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?  