The State of the PKI Technologies Directions

The State of the PKI Technologies, Directions & Products William Lattin Director, Security Infrastructure Marketing 510/780 -5423 wlattin@certicom. com CACR June 1999

Presentation Objectives The nature of trust Current certificate technologies PKI issues: n CA operation & security n Trust policy n Policy management Implementation considerations PKI directions Products & services

Definitions Certificate u Set of information signed by a Certificate Authority (CA) u Binds a public key to the identity of its owner n u Person or machine Can also bind policy and attributes to the identity of its owner

Definitions - cont’d Public Key Infrastructure (PKI) u Trust model (CPS) u Certificate format u Certificate management n Creation, Storage, Revocation, Updating n Policies & Attributes m n Cross-certification, non-repudiation Associated protocols m PKIX, SET, etc

The Need to Create Trust Distributed information u Intranets, extranets, access control, VPN Electronic commerce How to do? u Most difficult to quantify and implement n u Name > Person > Characteristics > Identity? Trusted Third Parties (TTP) n Central to dispute resolution

Trust in the Digital Age Some trust issues are: u How do I know you are you? u How can I trust “your” public key? u How do I know you are authorized to do that? u How can I prove you did that? u How can I prove when you did that? u Liability (How can I sue you? Let me count the ways…)

Certificate Formats I thought we had a standard. . .

Certificate Usage Identity and authenticity u Owner and key Authorization u Access control u Permissions Non-repudiation

The Venerable X. 509 Certificate X. 509 v 3 Certificate

X. 509 Standards ANSI X 9. 57 Certificate Management ANSI X 9. 55 Certificate Extensions IETF PEM & PKIX (RFC 2459) ISO ITU-T X. 509 SECG

Issues with X. 509 Format ASN. 1 Distinguished names u Global name spaces difficult n u Overlapping common names Names cannot be confidential Certificate size u Constrained devices n SET Certificates: 1580 - 2600 Bytes

Other Certificate Formats PGP u email addresses, human names, PK fingerprints n u DNS names are useful! Bottom-up approach via “web of trust” SPKI/SDSI (Rivest, Ellison, Lampson) u Principals are public keys with “human” names n Globally distinct; locally known

Certificate Formats Which is appropriate? u Application Specific n Open / closed network n Bandwidth limited m u Cryptographic signature method n u WAP; FLEX CAs support many; apps only one Certificate Size

Certificate Authorities and the PKI

Certificate Authority Concepts Certificate Authority/Registration Authority structure CA RA RA Directory • CA/RA could be single unit

Certificate Authority Concepts CA Functions u Key pair generation* u Key recovery* u Key backup u RA Functions Authenticate cert generation requests u Create/revoke u Authenticate requestor u Send cert request to CA u Distribute cert from CA to requestor certificates u Store certificates u Cross-certification * Application Dependent

Certificate Authority Hierarchy Bank of the World CAHQ US Branch CERTHQUS CERTUS Alice CAUS Japan Branch CAJP Dave CERTHQJP Bob CERTJP Bob s For Alice to validate CERTJP Bob, she needs: s s CERTJP Bob, CERTHQJP, CERTHQHQ Ultimately depends on trust model Applications may not support!

Architectural Trust? Different risks associated with PKI architectures u CA/RA or CA/CA? u RA security as critical as that of CA n u Rogue certificates Root key compromise n Disastrous in any event!

Certificate Authority Interoperability Cross certification: 1. Cert. XX 2. Cert. XY Company X Certificate Authority Company Y Certificate Authority 1. Cert. YY User A User B User C Cert. XA User D Cert. YD For D to communicate to A: D sends Cert. YD Cert. YY A validates Cert. YD using Cert. XY User E User F 2. Cert. YX

Certificate Authority Interoperability Cross-certification issues: u How do they communicate? u Assignment of risk u Is their trust model as good as yours? Reality u Implement on an exception basis u Technically simple; legally impossible

The Interoperability Myth The nice thing about standards… u X. 509 does not guarantee it! Different vendor’s CAs typically don’t interoperate u Cross-certification and trust models u Directory/Database schema u CRLs PKIX provides some interoperability

Certificate Validation Methods PKI is incomplete without validation Two models: u Assume OK unless told otherwise u Assume invalid unless explicitly told OK

Certificate Validation Methods Signature chain validation - complex u Must traverse and verify each CA to root u Browsers really don’t support! Certificate Revocation Lists On-line Certificate Validation Merkle Hash Tree Which to Use?

X. 509 Certificate Revocation List X. 509 v 2 CRL format Signature Algorithm Issuer Name this Update Date next Update Date Revoked Certificates Serial Number A Revoked on Date. . Serial Number X Revoked on Date Extension CA Signature Extensions: Reason for Revocation Delta Update

Certificate Revocation Lists Cert Bob ? Alice Certificate Exchange CRL ? CRL Distribution Secure CRL Server CA CRL Bob

Certificate Revocation Lists ISSUE: Update frequency General CRLs impractical u Long lists; network overhead Delta CRLs u Changes since the original Distribution Points u Parse the CRL and distribute portions of list to appropriate local servers

Online Certificate Status Protocol IETF PKIX proposed standard u draft-ietf-pkix-ocsp-05. txt Determine current certificate status without CRL u Risk mitigation via “real-time” checks Protocol independent

Online Certificate Status Protocol Cert Bob ? Cert Alice Certificate Exchange ? Alice Bob Secure OCSP Server CA CRL

Online Certificate Status Protocol Security u Degree of “freshness” u Replay attack for cached certificates Performance u Database search time u Signed responses n RSA too slow n 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 -R 0 -----> N 0, 0 R 0 -R 1 -----> N 0, 1 N 1, 0 CRD N 2, 0 R 1 -R 2 -----> N 0, 2 N 1, 1 R 2 -R 3 -----> N 0, 3 N 3, 0 R 3 -R 4 -----> N 0, 4 CA Sig N 1, 2 R 4 -R 5 -----> N 0, 5 N 2, 1 R 5 -R 6 -----> N 0, 6 R 6 -Inf -----> N 0, 7 N 1, 3 N 3, 0

Merkle Hash Trees Commercialized by Vali. Cert for certificate revocation u Vali. Cert proof of validity (TTP) CRLs limited to approx 1000 Bytes (log 2 N reduction) u Still too large for certain applications

Real World Implementations A single global hierarchy will never occur Communities of Interest u Mutual agreement on trust & risk levels Overlapping “distinguished names”?

Implementation Issues What are your security policy, certificate usage policies, and application(s)? u Signature lifetime; CRL update criteria; physical security; need for non-repudiation; frequency of certificate issuance; smart card support Liability Issues u Whose fault is it really? ? ? u Why blame the CA for all?

Implementation Issues cont’d Outsourcing CA Operations: u Does their CA security meet your requirements? n Audit trails, physical security, operator access controls u Do they adequately vet the requestor? n RA structure vs direct application

Implementation Issues cont’d In-house CA issues: u Physical security for CA, operator roles and access controls, personnel needs for operation General issues: u Must a directory be used? n u Are you prepared to be limited to a schema? Acquisition and recurring costs m Per certificate fees / maintenance fees

CA Evaluation Checklist What cryptographic algorithms are supported (ECDSA, DSS, RSA)? What is the format of the certificate request? Support RA functionality? Field/modulus lengths? RNG? Does CA only generate client key pairs; Supported cert formats (X. 509, SET, SSL, accept etc) Is a CRL maintained? How distributed? What cryptographic hardware is supported for When? secure signature generation? pub key from client; or both? Multiple operator roles? Distinct operator How is the CA private key backed-up? login What computing platform is the CA based Completeness of audit trail. Signed by CA? upon? IDs and passwords? Permanently stored? Use a special O/S? CA actions when a cert is about to expire? What databases are supported (flat file, SQL, Does CA support smart cards? RDMS)? How is cross-certification performed? What directories are supported? ANSI, IETF PKIX support What directory access protocol is used? FIPS 140 -1 certification Must a directory be used? Acquisition Price / Annual Fees

PKI Development Directions Directories Short certificates u Traditional u Bullet Certified time

Directories - the enabling technology u LDAPv 2 protocol & schema proposed IETF stds u Directory Enabled Networks initiative n u LDAP & standard schema! True enterprise & global scalability n Replace full function CAs; attribute certificates? u The mechanism for security policy u ISSUE: Directories must be trusted

Short Certificates X. 509 certificates are too long u Shortest ECDSA X. 509 cert approx 350 bytes Unsuitable for embedded devices u Storage u Bandwidth Complex management issues u Revocation lists

Shortening X. 509 ANSI X 9. 68 draft u Allow use of Packed Encoding Rules u Eliminate “redundant” or “inefficient” fields n Serial number is implicit - hash of certificate n Date encoding minimized n Names can be simplified m SDSI concept of hash of public key & local name

Bullet Certificates Introduced in 1998 by Certicom Basic Concepts: u X. 509 certificates explicitly bind user information and public key u Bullets implicitly bind user information and public key n Public key can be derived from the signature if public key of the CA is available

Bullet Certificates - cont’d Advantages: u Bandwidth Savings: Public key of user and the signature of the CA are combined in a single element n u 21 Bytes versus 350 Bytes (X. 509 ECDSA cert) Computational Savings: Bullets can be verified in half the time of an ECDSA-signed certificate u Bullet certificates can live within current CA certificate infrastructures n For example, a bullet certificate could be placed in an X 509 certificate extension

Bullet Creation Client and Certifier cooperate on creation of a bullet Client Certifier 1. Temporary PK pair (x, X) Permanent PK pair (c, ) (name, X) 2. Create permanent PK pair and bullet f( Sig values, x, X) = (a, A, Bullet. A) 1. Create unique name, Ia 2. Compute implicit signature (Ia, Sig values) 3. Publish Ia , Bullet. A Public f(X, Ia, , c )= (Sig values) 3. Send unique name and special sig values

Bullet Application The user of the wireless device wishes to retrieve his/her account information and therefore, needs to authenticate the bank. Wireless Network 1. Requests Server’s Bullet Bank Server Wireless Client 2. Sends Bullet and data signed under server’s private key - this information is sent over the air link 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. Considering the bandwidth limitations over the air link, bullets are an efficient choice for this application.

Certified Time The business need: u Determining “when” an event occurred u Imprecise in our paper world u Applications: arbitrage, patent filing, ebusiness PKI can deliver: u Authentic, traceable time (UTC to NIST) u Non-repudiation

Certified Time - or is it? Timestamps to withstand the test of time u What modulus length is appropriate? n n u 512 - 15, 000 RSA bits 113 - 512 ECC bits What hash is appropriate? n SHA-1 at 80 bits of security n SHA-2 at ? ? ?

Certified Time - cont’d Two IETF tracks: u Secure distribution of time via NTP n n u S/Time Working Group draft-mills-ntp-auth-coexist-01. txt Document time stamping n PKIX Time Stamp Protocols n draft-ietf-pkix-time-stamp-01. txt n Many CAs will support

PKI Products & Services

Product & Service Listing Products: Services: Baltimore Technologies* Digital Signature Trust Co. * Diversinet* GTE Cyber. Trust Entegrity Solutions Global. Sign Entrust Technologies Inter. Clear GTE Cyber. Trust Thawte Microsoft Veri. Sign Motorola* Netscape Xcert International* * Supports ECC

Summary The PKI is ready for business u Products/services abound n u Select to match application Implementation as much a business decision as a technology decision n business re-architecting, risk management, economics Have we got it right? u Evolution (revolution? ) continues

A closing observation: in The PKI technology issues pale comparison with its legal challenges