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

Identity-Based Encryption
Technology Overview
Public Key Cryptography Without Certificates
Mark J. Schertler
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


2
IBE mathematics is being standardized in IEEE 1363.3
IETF S/MIME Informational RFC
IBE Public Keys
… Introduce This Elegance
Public-key Encryption where Identities are used as Public Keys

IBE Public Key:
[email protected]

RSA Public Key:
Public exponent=0x10001
Modulus=13506641086599522334960321627880596993888147
560566702752448514385152651060485953383394028715
057190944179820728216447155137368041970396419174
304649658927425623934102086438320211037295872576
235850964311056407350150818751067659462920556368
552947521350085287941637732853390610975054433499
9811150056977236890927563
3
How IBE works in practice
Alice sends a Message to Bob
Key Server
• Master Secret
• Public Parameters
2
Receives
Private Key
3
for [email protected]
Requests
private key,
authenticates
[email protected]
[email protected]
[email protected]
1
Alice encrypts with
[email protected]
4
Bob decrypts with 4
Private Key
How IBE works in practice
Alice sends a Message to Bob
Key Server
Fully off-line - no connection to server required
[email protected]
[email protected]
[email protected]
1
Charlie encrypts
with [email protected]
5
Bob decrypts with 2
Private Key
IBE Public Key Composition
v2 ||
public key definition version
ibe-server.acme.com#1234 ||
server location and public parameter version
week = 252 ||
key validity period
[email protected]
e-mail address
6
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
7
Public Key Infrastructure
Certificate Server binds Identity to Public Key
Certification
Authority
Certificate
Server
Store
Certificate
CA Signing Key
CA Public Key
Look up
Bob’s Certificate,
Check revocation
Send
Public Key,
Authenticate
Receive
Certificate
Recovery
Server
Store Bob’s
Private Key
8
CA Public Key
Bob’s Private Key
Bob’s Public Key
[email protected]
[email protected]
Identity Based Encryption
Binding of Identity to Key is implicit
IBE Key Server
Certificate
Server
X
Look up
Bob’s Certificate,
Check revocation
Store
Certificate
Master Secret
Public
Parameters
Send
Identity,
Authenticate
Receive
Private Key
Recovery
Server
X
Store Bob’s
Private Key
Public Parameters
[email protected]
9
Bob’s Private Key
[email protected]
Adding IBE to CMSv3

Define OtherRecipientInfo Type for RecipientInfo
in Enveloped Data


Add IBE per RFC 3370 – CMS Algorithms

Create IBE algorithm Informational RFC similar to
RFC 2313 - PKCS #1: RSA Encryption Version
1.5

10
Based on CMSv3 - RFC 3852
Could be IEEE 1363.3 spec
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
•
•

11
Validity Period
Identity (RFC822)
Public Parameters
12
IBE Public Keys - Revocation and Expiration
IBE Public Key: [email protected] || week = 252
e-mail address


13
key validity
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
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






14
PKI Smart Cards
RSA SecurID
LDAP, Active Directory
Login/Password
Email Answerback
Username and password
Voltage
VSPS
Auth.
Service
The IBE Key Server
Master Secret
s = 1872361923616378
Voltage Server
Request for Private Key
for Identity [email protected]

Key Server has “Master Secret” to generate
keys



15
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 Security Model
Master 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
16
IBE Key
Server
Master Secret
1238715613581
Public
Parameters
Public
Parameters
Public
Parameters
[email protected]
[email protected]
Voltage Enables Perimeter Content Scanning
Filtering Spam and Viruses with End-to-End Encryption
INTERNET
DMZ
LAN
Voltage IBE
Gateway Server
Encrypted
email arrives

17
1
Email is
scanned
GW
Archive
Audit
Virus
GW
Exchange,
Domino, etc.
2
User receives 3
encrypted email
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
IBE: Setting A New Standard In Security
Current Efforts
IBCS-1 Standard
Other IBE
Technology
Study Group
Post IEEE
Standards
IEEE Working Group
IEEE Study Group
• Set structure of standard
• Write PoA
Feb/2005
• PBC/IBE Standard
• Submit for ratification
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


18
Working Group
No other cryptographic algorithms have begun this process so quickly
Voltage IBE Toolkit FIPS 140-2 certified
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.”
19
Voltage: “Stateless” Architecture

Keys and messages are never stored on Voltage server


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

20
Mail delivered using existing infrastructure
Easily meet message retention policies
Voltage: “Stateless” Architecture

Highly scalable





Strongest integration with network edge content
scanning

21
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
Only solution with end-to-end encryption with anti-virus, antispam, archiving
Voltage: Lowest Overhead

Leverages existing mail infrastructure




Self-provisioning authentication


Same messages can be viewed with client or Zero
Download Messenger
No additional headcount required

22
No IT/administrative action required to enroll new users
No need to select delivery methods


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
Voltage customers report 0.1 FTE required
Identity-Based Encryption (IBE)

IBE is an old idea


First practical implementation





Over 200 scientific publications on IBE/Pairings
Dan Boneh awarded 2005 RSA Conference Award for Mathematics
Standardization Efforts


23
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


Originally proposed by Adi Shamir, co-inventor of the RSA
Algorithm, in 1984
IBE being standardized by NIST and IEEE 1363.3
IETF S/MIME?
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

24
Server scalability not limited by number of messages
25
IBE and PKI
26
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
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?

27
Yes, IBE solves many of the issues of PKI
Public Key Infrastructure
Certificate Server binds Identity to Public Key
Certification
Authority
Certificate
Server
Store
Certificate
CA Signing Key
CA Public Key
Look up
Bob’s Certificate,
Check revocation
Send
Public Key,
Authenticate
Receive
Certificate
Recovery
Server
Store Bob’s
Private Key
28
CA Public Key
Bob’s Private Key
Bob’s Public Key
[email protected]
[email protected]
Identity Based Encryption
Binding of Identity to Key is implicit
IBE Key Server
Certificate
Server
X
Look up
Bob’s Certificate,
Check revocation
Store
Certificate
Master Secret
Public
Parameters
Send
Identity,
Authenticate
Receive
Private Key
Recovery
Server
X
Store Bob’s
Private Key
Public Parameters
[email protected]
29
Bob’s Private Key
[email protected]
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.
•

PKI requires pre-enrollment



Instead, IBE uses short-lived keys. PKI can’t do this because this would
compound lookup problem
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
30
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



Powerful for encryption



31
requires no pre-enrollment
software only
no key-lookup
revocation is easy
Content scanning easy
Where to use PKI
 Inside the
organization
 For maximum
security/high cost
deployments
 Mainly authentication
and signing
Where to use IBE
 Inside or outside the
organization
 For any level of
security
 Where encryption/
privacy is important
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?
32
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


33
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 [email protected]
• Encrypt all ePHI (lexicon)
• Encrypt if subject contains
“confidential”
-OR•Encrypt all unless opt-out