The State of the PKITechnologies, Directions & Products

William LattinDirector, Security Infrastructure Marketing

510/780-5423 wlattin@certicom.com

CACR June 1999

Presentation Objectives

The nature of trust

Current certificate technologies

PKI issues:

CA operation & security

Trust policy

Policy management

Implementation considerations

PKI directions

Products & services

Definitions

Certificate

Set of information signed by a Certificate

Authority (CA)

Binds a public key to the identity of its

owner

Person or machine

Can also bind policy and attributes to

the identity of its owner

Definitions - cont’d

Public Key Infrastructure (PKI)

Trust model (CPS)

Certificate format

Certificate management

Creation, Storage, Revocation, Updating

Policies & Attributes

Cross-certification, non-repudiation

Associated protocols

PKIX, SET, etc

The Need to Create Trust

Distributed information

Intranets, extranets, access control, VPN

Electronic commerce

How to do?

Most difficult to quantify and implement

Name > Person > Characteristics > Identity?

Trusted Third Parties (TTP)

Central to dispute resolution

Trust in the Digital Age

Some trust issues are:

How do I know you are you?

How can I trust “your” public key?

How do I know you are authorized to do that?

How can I prove you did that?

How can I prove when you did that?

Liability (How can I sue you? Let me count

the ways…)

Certificate Formats

I thought we had a

standard...

Certificate Usage

Identity and

authenticity

Owner and key

Authorization

Access control

Permissions

Non-repudiation

The Venerable X.509 Certificate

X.509v3 Certificate

version (v3)

serial number

signature algorithm ID

issuer name

validity period

subject name

subject public key info

issuer unique identifier

subject unique identifier

extensions

signed by issuer (CA)

X.509 Standards

ANSI X9.57 Certificate

Management

ANSI X9.55 Certificate Extensions

IETF PEM & PKIX (RFC 2459)

ISO

ITU-T X.509

SECG

Issues with X.509 Format

ASN.1

Distinguished names

Global name spaces difficult

Overlapping common names

Names cannot be confidential

Certificate size

Constrained devices

SET Certificates: 1580 - 2600 Bytes

Other Certificate Formats

PGP

email addresses, human names, PK fingerprints

DNS names are useful!

Bottom-up approach via “web of trust”

SPKI/SDSI (Rivest, Ellison, Lampson)

Principals are public keys with “human” names

Globally distinct; locally known

Primary purpose: authorize some action, grant

permission

Certificate Formats

Which is appropriate?

Application Specific

Open / closed network

Bandwidth limited

WAP; FLEX

Cryptographic signature method

CAs support many; apps only one

Certificate Size

Certificate Authorities and the PKI

RA

Certificate Authority Concepts

Certificate Authority/Registration

Authority structure

RA

CA

• CA/RA could be single unit

Directory

Certificate Authority Concepts

CA Functions

Key pair generation*

Key recovery*

Key backup

Authenticate cert

generation requests

Create/revoke

certificates

Store certificates

Cross-certification

RA Functions

Authenticate requestor

Send cert request to CA

Distribute cert from CA

to requestor

* Application Dependent

Certificate Authority Hierarchy

For Alice to validate CERTJP Bob, she needs: CERTJP Bob, CERTHQJP, CERTHQHQ Ultimately depends on trust model Applications may not support!

Bank of the World

CAHQ

CAUS CAJP

Alice

Dave

Bob

CERTHQJP

CERTJP Bob

CERTHQUS

CERTUS Alice

Japan BranchUS Branch

Architectural Trust?

Different risks associated with PKI

architectures

CA/RA or CA/CA?

RA security as critical as that of CA

Rogue certificates

Root key compromise

Disastrous in any event!

Certificate Authority Interoperability

Cross certification:

Company XCertificate Authority

User A User B User C

CertXA

Company YCertificate Authority

User D User E User F

CertYD

1. CertXX

1. CertYY

2. CertXY 2. CertYX

For D to communicate to A:

D sends CertYD CertYYA validates CertYD using CertXY

Certificate Authority Interoperability

Cross-certification issues:

How do they communicate?

Assignment of risk

Is their trust model as good as yours?

Reality

Implement on an exception basis

Technically simple; legally impossible

The Interoperability Myth

The nice thing about standards…

X.509 does not guarantee it!

Different vendor’s CAs typically don’t

interoperate

Cross-certification and trust models

Directory/Database schema

CRLs

PKIX provides some interoperability

Certificate Validation Methods

PKI is incomplete without validation

Two models:

Assume OK unless told otherwise

Assume invalid unless explicitly told OK

Certificate Validation Methods

Signature chain validation - complex

Must traverse and verify each CA to root

Browsers really don’t support!

Certificate Revocation Lists

On-line Certificate Validation

Merkle Hash Tree

Which to Use?

X.509 Certificate Revocation List

X.509v2 CRL format

Signature AlgorithmIssuer Namethis Update Datenext Update DateRevoked Certificates Serial Number A Revoked on Date

.

. Serial Number X Revoked on DateExtension

CA Signature

Extensions: Reason for Revocation Delta Update

Certificate Revocation Lists

CASecureCRL

Server

??

CRL

CRL

Cert Bob

Cert Alice

CRL

Certificate Exchange

Alice Bob

CRL Distribution

Certificate Revocation Lists

ISSUE: Update frequency

General CRLs impractical

Long lists; network overhead

Delta CRLs

Changes since the original

Distribution Points

Parse the CRL and distribute portions of list

to appropriate local servers

Online Certificate Status Protocol

IETF PKIX proposed standard

draft-ietf-pkix-ocsp-05.txt

Determine current certificate status

without CRL

Risk mitigation via “real-time” checks

Protocol independent

Online Certificate Status Protocol

CASecureOCSPServer

??Cert Bob

Cert Alice

CRL

Certificate Exchange

Alice Bob

Online Certificate Status Protocol

Security

Degree of “freshness”

Replay attack for cached certificates

Performance

Database search time

Signed responses

RSA too slow

ECDSA/DSA to enhance performance

Merkle Hash Trees

Developed by Ralph Merkle

Each message to be signed

corresponds to a node in a tree

Each node consists of a hash of the

prior nodes

Number of messages that can be

signed is limited by depth of tree

Merkle Hash Trees

0-R0 -----> N0,0

R0-R1 -----> N0,1

R1-R2 -----> N0,2

R2-R3 -----> N0,3

R3-R4 -----> N0,4

R4-R5 -----> N0,5

R5-R6 -----> N0,6

R6-Inf -----> N0,7

N1,0

N1,1

N1,2

N1,3

N2,0

N2,1

N3,0

CA Sig

N3,0

CRD

Merkle Hash Trees

Commercialized by ValiCert for

certificate revocation

ValiCert proof of validity (TTP)

CRLs limited to approx 1000 Bytes

(log2N reduction)

Still too large for certain applications

Real World Implementations

A single global hierarchy will never

occur

Communities of Interest

Mutual agreement on trust & risk levels

Overlapping “distinguished names”?

Implementation Issues

What are your security policy, certificate

usage policies, and application(s)?

Signature lifetime; CRL update criteria;

physical security; need for non-repudiation;

frequency of certificate issuance; smart card

support

Liability Issues

Whose fault is it really???

Why blame the CA for all?

Implementation Issues - cont’d

Outsourcing CA Operations:

Does their CA security meet your

requirements?

Audit trails, physical security, operator

access controls

Do they adequately vet the requestor?

RA structure vs direct application

Implementation Issues - cont’d

In-house CA issues:

Physical security for CA, operator roles and

access controls, personnel needs for operation

General issues:

Must a directory be used?

Are you prepared to be limited to a schema?

Acquisition and recurring costs Per certificate fees / maintenance fees

Per certificate fees prohibit policy management?

CA Evaluation ChecklistWhat cryptographic algorithms are supported

(ECDSA, DSS, RSA)?

Field/modulus lengths? RNG?

Supported cert formats (X.509, SET, SSL, etc)

What cryptographic hardware is supported for

secure signature generation?

How is the CA private key backed-up?

What computing platform is the CA based upon?

Use a special O/S?

What databases are supported (flat file, SQL,

RDMS)?

What directories are supported?

What directory access protocol is used?

Must a directory be used?

Is special client S/W required to access CA?

What is the format of the certificate request?

Support RA functionality?

Does CA only generate client key pairs; accept

pub key from client; or both?

Is a CRL maintained? How distributed? When?

Multiple operator roles? Distinct operator login

IDs and passwords?

Completeness of audit trail. Signed by CA?

Permanently stored?

CA actions when a cert is about to expire?

Does CA support smart cards?

How is cross-certification performed?

ANSI, IETF PKIX support

FIPS 140-1 certification

Acquisition Price / Annual Fees

PKI Development Directions

Directories

Short certificates

Traditional

Bullet

Certified time

Directories

Directories - the enabling technology

LDAPv2 protocol & schema proposed IETF

stds

Directory Enabled Networks initiative

LDAP & standard schema!

True enterprise & global scalability

Replace full function CAs; attribute certificates?

The mechanism for security policy

ISSUE: Directories must be trusted

Short Certificates

X.509 certificates are too long

Shortest ECDSA X.509 cert approx 350 bytes

Unsuitable for embedded devices

Storage

Bandwidth

Complex management issues

Revocation lists

Distinguished names

Shortening X.509

ANSI X9.68 draft

Allow use of Packed Encoding Rules

Eliminate “redundant” or “inefficient”

fields

Serial number is implicit - hash of certificate

Date encoding minimized

Names can be simplified

SDSI concept of hash of public key & local

name

Bullet Certificates

Introduced in1998 by Certicom

Basic Concepts:

X.509 certificates explicitly bind user

information and public key

Bullets implicitly bind user information

and public key

Public key can be derived from the signature if

public key of the CA is available

Bullet Certificates - cont’d

Advantages:

Bandwidth Savings: Public key of user and the

signature of the CA are combined in a single

element

21 Bytes versus 350 Bytes (X.509 ECDSA cert)

Computational Savings: Bullets can be verified in

half the time of an ECDSA-signed certificate

Bullet certificates can live within current CA

certificate infrastructures

For example, a bullet certificate could be placed in an

X509 certificate extension

Bullet Creation

Client Certifier1. Temporary PK pair (x,X)

2. Create permanent PK pair and bullet

f( Sig values, x, X) = (a, A, BulletA)

3. Publish Ia ,BulletA

(name, X)Permanent PK pair (c,)

1. Create unique name, Ia

2. Compute implicit signature

f(X, Ia,,c )= (Sig values)

3. Send unique name and special sig values

(Ia, Sig values)

Public

Client and Certifier cooperate on creation of a bullet

Bullet Application

Wireless

Network

Wireless Client

1. Requests Server’s Bullet

3. Client “derives” the server public key from the bullet, using CA’s public key.

4. Client completes authentication of the server by verifying the data signed under server’s private key, using the public key of the server derived in step 3.

2. Sends Bullet and data signed under server’s private key - this information is sent over the air link

The user of the wireless device wishes to retrieve his/her account information and therefore, needs to authenticate the bank.

Bank Server

Considering the bandwidth limitations over the air link, bullets are an efficient choice for this application.

Certified Time

The business need:

Determining “when” an event occurred

Imprecise in our paper world

Applications: arbitrage, patent filing, e-

business

PKI can deliver:

Authentic, traceable time (UTC to NIST)

Non-repudiation

Certified Time - or is it?

Timestamps to withstand the test of

time

What modulus length is appropriate?

512 - 15,000 RSA bits

113 - 512 ECC bits

What hash is appropriate?

SHA-1 at 80 bits of security

SHA-2 at ???

Certified Time - cont’d

Two IETF tracks:

Secure distribution of time via NTP

S/Time Working Group

draft-mills-ntp-auth-coexist-01.txt

Document time stamping

PKIX Time Stamp Protocols

draft-ietf-pkix-time-stamp-01.txt

Many CAs will support

PKI Products & Services

Product & Service Listing

Products:

Baltimore Technologies*

Diversinet*

Entegrity Solutions

Entrust Technologies

GTE CyberTrust

Microsoft

Motorola*

Netscape

Xcert International*

Services:

Digital Signature Trust Co.*

GTE CyberTrust

GlobalSign

InterClear

Thawte

VeriSign

* Supports ECC

Summary

The PKI is ready for business

Products/services abound

Select to match application

Implementation as much a business

decision as a technology decision

business re-architecting, risk management,

economics

Have we got it right?

Evolution (revolution?) continues

A closing observation:

The PKI technology issues pale in comparison with its legal challenges