Identity-Based Encryption Technology Overview

1. Identity-Based EncryptionTechnology 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 1363.3 • 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: alice@gmail.com • RSA Public Key: Public exponent=0x10001 Modulus=13506641086599522334960321627880596993888147 560566702752448514385152651060485953383394028715 057190944179820728216447155137368041970396419174 304649658927425623934102086438320211037295872576 235850964311056407350150818751067659462920556368 552947521350085287941637732853390610975054433499 9811150056977236890927563 X

4. ReceivesPrivate Keyfor bob@b.com 3 2 Requests private key, authenticates 1 4 Bob decrypts withPrivate Key Alice encrypts with bob@b.com How IBE works in practiceAlice sends a Message to Bob • Key Server • Master Secret • Public Parameters bob@b.com bob@b.com alice@a.com

5. Fully off-line - no connection to server required 1 2 Bob decrypts withPrivate Key Charlie encrypts with bob@b.com How IBE works in practiceAlice sends a Message to Bob Key Server bob@b.com charlie@c.com bob@b.com

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

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. Certification Authority Certificate Server StoreCertificate CA Signing Key CA Public Key RecoveryServer Send Public Key, Authenticate ReceiveCertificate Look up Bob’s Certificate, Check revocation Store Bob’s Private Key Public Key InfrastructureCertificate Server binds Identity to Public Key CA Public Key Bob’s Private Key Bob’s Public Key alice@a.com bob@b.com

9. X Certificate Server StoreCertificate X RecoveryServer Look up Bob’s Certificate, Check revocation Store Bob’s Private Key Identity Based EncryptionBinding of Identity to Key is implicit IBE Key Server Master Secret Public Parameters SendIdentity, Authenticate ReceivePrivate Key Public Parameters Bob’s Private Key alice@a.com bob@b.com

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 2313 - PKCS #1: RSA Encryption Version 1.5 • Could be IEEE 1363.3 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

13. || week = 252 key validity 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 IBE Public Key: bob@wellsfargo.com e-mail address

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 Authentication Adapters • PKI Smart Cards • RSA SecurID • LDAP, Active Directory • Login/Password • Email Answerback • Username and password Auth. Service Voltage VSPS

15. 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 The IBE Key Server Master Secret s = 1872361923616378 1872361923616378 Voltage Server Request for Private Key for Identity bob@b.com bob@b.com

16. The IBE Security ModelMaster Secret and 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 IBE KeyServer Master Secret1238715613581 PublicParameters PublicParameters PublicParameters alice@a.com bob@b.com

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

18. IBE: Setting A New Standard In Security Post IEEE Standards Current Efforts Study Group Working Group • IEEE Study Group • Set structure of standard • Write PoA • IEEE Working Group • PBC/IBE Standard • Submit for ratification IBCS-1 Standard Other IBETechnology Feb/2005 Mid 2005 > 2007 • 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 140-2 certified

19. Voltage: Proven Ease of Use • The easiest-to-use secure email: • 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 email encrypted based on my email 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 1363.3 • 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

26. IBE and PKI • Voltage Security • Identity-Based Encryption • IBE and PKI • Comparing IBE and PKI • Combining the Two • The future of IBE • 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. Certification Authority Certificate Server StoreCertificate CA Signing Key CA Public Key RecoveryServer Send Public Key, Authenticate ReceiveCertificate Look up Bob’s Certificate, Check revocation Store Bob’s Private Key Public Key InfrastructureCertificate Server binds Identity to Public Key CA Public Key Bob’s Private Key Bob’s Public Key alice@a.com bob@b.com

29. X Certificate Server StoreCertificate X RecoveryServer Look up Bob’s Certificate, Check revocation Store Bob’s Private Key Identity Based EncryptionBinding of Identity to Key is implicit IBE Key Server Master Secret Public Parameters SendIdentity, Authenticate ReceivePrivate Key Public Parameters Bob’s Private Key alice@a.com bob@b.com

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. IBE and PKI – Strengths and Weaknesses Where to use PKI • Inside the organization • For maximum security/high cost deployments • Mainly authenticationand signing 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 Where to use IBE • Inside or outside the organization • For any level of security • Where encryption/ privacy is important

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

33. Sample Policies • Encrypt all traffic to xyz.com • Encrypt from john@co.com • Encrypt all ePHI (lexicon) • Encrypt if subject contains “confidential” • -OR- • Encrypt all unless opt-out 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