identity based encryption technology overview l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Identity-Based Encryption Technology Overview PowerPoint Presentation
Download Presentation
Identity-Based Encryption Technology Overview

Loading in 2 Seconds...

play fullscreen
1 / 33

Identity-Based Encryption Technology Overview - PowerPoint PPT Presentation


  • 691 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Identity-Based Encryption Technology Overview' - garth


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
identity based encryption technology overview

Identity-Based EncryptionTechnology Overview

Public Key Cryptography Without Certificates

Mark J. Schertler

identity based encryption ibe
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
ibe public keys introduce this elegance
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

how ibe works in practice alice sends a message to bob

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

how ibe works in practice alice sends a message to bob5

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

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

bob@acme.com

e-mail address

IBE Public Key Composition
ibe benefits
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

public key infrastructure certificate server binds identity to public key

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

identity based encryption binding of identity to key is implicit

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

adding ibe to cmsv3
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
cmsv3
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
ibe public keys revocation and expiration

|| 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

user authentication
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

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

The IBE Key Server

Master Secret

s =

1872361923616378

1872361923616378

Voltage Server

Request for Private Key for Identity bob@b.com

bob@b.com

the ibe security model master secret and public parameters
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

voltage enables perimeter content scanning filtering spam and viruses with end to end encryption

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
ibe setting a new standard in security
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
voltage proven ease of use
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.”

voltage stateless architecture
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
voltage stateless architecture21
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
voltage lowest overhead
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
identity based encryption ibe23
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?
voltage ibe breakthrough
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
ibe and pki
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
public key infrastructure
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
public key infrastructure certificate server binds identity to public key28

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

identity based encryption binding of identity to key is implicit29

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

ibe vs pki practical implications
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
ibe and pki strengths and weaknesses
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
policy driven encryption
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?

policy based encryption

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