Identity-Based Encryption Technology Overview Public Key Cryptography Without Certificates Mark J. Schertler

2 Identity-Based Encryption (IBE)  IBE is an old idea  Originally proposed by Adi Shamir, S in RSA, in 1984  Not possible to build an IBE system based on RSA  First practical implementation  Boneh-Franklin Algorithm published at Crypto 2001  Bilinear Maps (Pairings) on Elliptic Curves Based on well-tested mathematical building blocks  Public Key Algorithm used for Key Transport  The IBE breakthrough is having major impact  Now over 400 scientific publications on IBE and Pairing Based Cryptography  Major deployments in industry  Standardization Efforts  IBE mathematics is being standardized in IEEE  IETF S/MIME Informational RFC

3 IBE Public Keys … Introduce This Elegance Public-key Encryption where Identities are used as Public Keys  IBE Public Key:  RSA Public Key: Public exponent=0x10001 Modulus= X

4 How IBE works in practice Alice sends a Message to Bob Key Server Master Secret Public Parameters Alice encrypts with 1 Requests private key, authenticates 2 Receives Private Key for 3 Bob decrypts with Private Key 4

5 How IBE works in practice Alice sends a Message to Bob Key Server Charlie encrypts with 1 Bob decrypts with Private Key 2 Fully off-line - no connection to server required

6 IBE Public Key Composition address key validity period week = 252 || server location and public parameter version ibe-server.acme.com#1234 || public key definition version v2 ||

7 IBE Benefits Dynamic “As Needed” Public and Private Key Generation  No pre-generation or distribution of certificates  Built-in Key Recovery – No ADKs  Allows content, SPAM, and virus scanning at enterprise boundary  Facilitates archiving in the clear per SEC regulations Policy in the Public Key  e.g. Key Validity Period  No CRLs Dynamic Groups  Identities can be groups and roles; no re-issuing keys when group or role changes Minimal System State  Master Secret / Public Parameters (~50KB) all you need for disaster recovery  End user keys and message not stored on server  Server scalability not limited by number of messages Benefits lead to: High system usability Highly scalable architecture Low operational impact Fully stateless operation

8 Public Key Infrastructure Certificate Server binds Identity to Public Key Send Public Key, Authenticate Receive Certificate CA Signing Key Certification Authority CA Public Key Certificate Server Store Certificate Look up Bob’s Certificate, Check revocation CA Public Key Bob’s Private Key Bob’s Public Key Recovery Server Store Bob’s Private Key

9 Identity Based Encryption Binding of Identity to Key is implicit IBE Key Server Master Secret Send Identity, Authenticate Receive Private Key Public Parameters Bob’s Private Key Certificate Server Store Certificate Look up Bob’s Certificate, Check revocation X Recovery Server Store Bob’s Private Key X

10 Adding IBE to CMSv3  Define OtherRecipientInfo Type for RecipientInfo in Enveloped Data  Based on CMSv3 - RFC 3852  Add IBE per RFC 3370 – CMS Algorithms  Create IBE algorithm Informational RFC similar to RFC PKCS #1: RSA Encryption Version 1.5  Could be IEEE spec

11 CMSv3 RecipientInfo ::= CHOICE { ktri KeyTransRecipientInfo, … ori [4] OtherRecipientInfo } OtherRecipientInfo ::= SEQUENCE { oriType OBJECT IDENTIFIER, oriValue ANY DEFINED BY oriType } oriValue ANY DEFINED BY oriType  Version  Domain and Parameter Version (Server Location)  Schema Validity Period Identity (RFC822)  Public Parameters

12

13 IBE Public Keys - Revocation and Expiration  IBE Systems use short lived keys  Public key contains key validity  Every week public key changes, so every week a new private key must be retrieved by the client  Refresh period is configurable  This simplifies key revocation  Users removed from the directory, no longer get keys  Above system is identical to a weekly CRL address key validity || week = 252 IBE Public Key:

14 User authentication Voltage can support any type of authentication Authentication needs differs by Application  More sensitive data, requires stronger authentication  Identity-Based Encryption scales across all levels Voltage VSPS Auth. Service Authentication Adapters  PKI Smart Cards  RSA SecurID  LDAP, Active Directory  Login/Password  Answerback  Username and password

15 The IBE Key Server  Key Server has “Master Secret” to generate keys  A random secret is picked when the server is set up  Each organization has a different Master Secret  Private key is generated from Master Secret and Identity Voltage Server Master Secret s = Request for Private Key for Identity

16 The IBE Security Model Master Secret and Public Parameters IBE Key Server Master Secret Public Parameters When the key server is set up:  Generate a random Master Secret  Derive Public Parameters from the master secret  Distribute Public Parameters to all clients (one time setup only)  Public Parameters are similar to a CA root certificate (long lived, bundled with software) During Operation:  Client uses Public Parameters in the encryption operation  Server uses Master Secret to generate private keys for users Public Parameters Public Parameters

17 Voltage Enables Perimeter Content Scanning Filtering Spam and Viruses with End-to-End Encryption DMZLANINTERNET Voltage IBE Gateway Server Exchange, Domino, etc. User receives encrypted 3  IBE’s on-the-fly key generation capability enables end-to-end encryption with content scanning  Filter for Viruses, Trojans, Spam, etc.  Allows archiving for compliance, audit GW Virus Audit Archive is scanned 2 Encrypted arrives 1 GW

18 IBE: Setting A New Standard In Security Current EffortsStudy GroupWorking Group Post IEEE Standards Feb/2005Mid 2005 > 2007 IEEE Study Group Set structure of standard Write PoA IEEE Working Group PBC/IBE Standard Submit for ratification Other IBE Technology IBCS-1 Standard  Current efforts are supported by Bell Canada, CESG, Gemplus, HP Labs, Microsoft, NTT DoCoMo, NoreTech, NSA, Siemens, STMicroelectronics  IEEE and NIST fast-tracking IBE for standardization  No other cryptographic algorithms have begun this process so quickly  Voltage IBE Toolkit FIPS certified

19 Voltage: Proven Ease of Use  The easiest-to-use secure  Seamless integration with leading mail clients  No-download send/receive through Zero Download Messenger No JavaScript, ActiveX, or browser plugins  Policy-based encryption at network edge  No change in user behavior  Only secure messaging solution rated “Excellent” in usability by eWeek Labs “During my test of the system, it worked great. All a provider needed to do was send me an encrypted based on my address… It was simple and easy to operate.”

20 Voltage: “Stateless” Architecture  Keys and messages are never stored on Voltage server  Mail delivered using existing infrastructure  Only one backup required for life of system  Entire system can be recovered from single piece of data in minutes, whether 20 users or 20 million  Messages can never be lost  No separate message store to backup  Administrator can decrypt messages at any point in future  No ADKs required  Full support for cleartext or encrypted archiving  Easily meet message retention policies

21 Voltage: “Stateless” Architecture  Highly scalable  New servers can be replicated from single backup  Servers never need to be synchronized  Can be load balanced using DNS  Built for enterprise- and carrier-class environments  Strongest integration with network edge content scanning  Only solution with end-to-end encryption with anti-virus, anti- spam, archiving

22 Voltage: Lowest Overhead  Leverages existing mail infrastructure  Messages delivered using normal mail flow  No new webmail/parallel mail infrastructure to manage, scale  Other solutions are equivalent to running an entirely new Exchange/Notes system  Self-provisioning authentication  No IT/administrative action required to enroll new users  No need to select delivery methods  Same messages can be viewed with client or Zero Download Messenger  No additional headcount required  Voltage customers report 0.1 FTE required

23 Identity-Based Encryption (IBE)  IBE is an old idea  Originally proposed by Adi Shamir, co-inventor of the RSA Algorithm, in 1984  First practical implementation  Research funded by DARPA  Boneh-Franklin Algorithm published at Crypto 2001  Based on well-tested building blocks for encryption: PKCS #7, S/MIME(CMS), 3DES, AES, SHA-256, DSS, SSL  Industry acceptance  Over 200 scientific publications on IBE/Pairings  Dan Boneh awarded 2005 RSA Conference Award for Mathematics  Standardization Efforts  IBE being standardized by NIST and IEEE  IETF S/MIME?

24 Voltage IBE breakthrough Highest system usability  No certificates – no CRLs: ease of use for administrators and end users Lowest operational impact  No new directories or resources required to manage system Fully stateless operation  Keys dynamically generated – no storage required - simplifies disaster recovery, retention and backup Most flexible mobility architecture  Architected for “occasionally-connected” users: full online and offline usage Most scalable architecture  Server scalability not limited by number of messages

25

26 IBE and PKI 1. Voltage Security 2. Identity-Based Encryption 3. IBE and PKI 1. Comparing IBE and PKI 2. Combining the Two 4. The future of IBE 5. Voltage and the DoD/DHS

27 Public Key Infrastructure  Working client side PKI Deployments are few  Mainly government and defense  A few large companies  These deployments have major issues  Deployment Cost  Certificate Revocation  Content scanning is still an unsolved issue (e.g. for filtering mail for viruses, spam or audits)  Difficult to use  Can IBE help?  Yes, IBE solves many of the issues of PKI

28 Public Key Infrastructure Certificate Server binds Identity to Public Key Send Public Key, Authenticate Receive Certificate CA Signing Key Certification Authority CA Public Key Certificate Server Store Certificate Look up Bob’s Certificate, Check revocation CA Public Key Bob’s Private Key Bob’s Public Key Recovery Server Store Bob’s Private Key

29 Identity Based Encryption Binding of Identity to Key is implicit IBE Key Server Master Secret Send Identity, Authenticate Receive Private Key Public Parameters Bob’s Private Key Certificate Server Store Certificate Look up Bob’s Certificate, Check revocation X Recovery Server Store Bob’s Private Key X

30 IBE vs. PKI – Practical Implications  IBE has no Certificates and Certificate management  No certificate server  No certificate lookups for the client  No certificate (or key) revocation, CRLs, OCSP etc. Instead, IBE uses short-lived keys. PKI can’t do this because this would compound lookup problem  PKI requires pre-enrollment  In PKI, recipient must generate key pair before sender can encrypt message  IBE is Ad-Hoc capable, a sender can send message at any time  IBE eliminates encryption key recovery/escrow server  Most PKI applications require access to private keys (e.g. Lost keys, Financial Audit, Virus Filtering etc.)  Key server can generate any key on the fly

31 Where to use IBE  Inside or outside the organization  For any level of security  Where encryption/ privacy is important Where to use PKI  Inside the organization  For maximum security/high cost deployments  Mainly authentication and signing IBE and PKI – Strengths and Weaknesses Public Key Infrastructure (PKI)  Expensive to deploy and run  Requires pre-enrollment  Issuing certificates  Works well for authentication  Can be made highly secure through smart cards Identity-Based Encryption  Ad-hoc capable  requires no pre-enrollment  software only  Powerful for encryption  no key-lookup  revocation is easy  Content scanning easy

32 Policy-Driven Encryption Does the sender want to encrypt? What does it say? Who is it from? Who is it to? What company is it to?

33 Policy-Based Encryption  Policy-based encryption  Controlled by administrators  Automatically enforced based on message flow and/or content  Can also allow users to opt-in, or opt-out based on keywords (no client s/w)  At the network edge  Encryption decision occurs at the boundary to minimize exposure and maximize transparency  A powerful tool for compliance Sample Policies Encrypt all traffic to xyz.com Encrypt from Encrypt all ePHI (lexicon) Encrypt if subject contains “confidential” -OR- Encrypt all unless opt-out