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? hkhurana@ncsa.uiuc.edu jbasney@ncsa.uiuc.edu