The State of the PKI

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

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

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

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

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

6. 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…)

7. I thought we had a standard... Certificate Formats

8. Certificate Usage • Identity and authenticity • Owner and key • Authorization • Access control • Permissions • Non-repudiation

9. The Venerable X.509 Certificate • X.509v3 Certificate

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

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

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

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

14. Certificate Authorities and the PKI

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

16. 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 Concepts

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

18. 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!

19. 1. CertXX Company X Certificate Authority Company Y Certificate Authority 2. CertXY 2. CertYX 1. CertYY User A User B User C User D User E User F CertXA CertYD Certificate Authority Interoperability • Cross certification: For D to communicate to A: D sends CertYD CertYY A validates CertYD using CertXY

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

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

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

23. 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?

24. 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 X.509 Certificate Revocation List • X.509v2 CRL format Extensions: Reason for Revocation Delta Update

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

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

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

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

29. Security Degree of “freshness” Replay attack for cached certificates Performance Database search time Signed responses RSA too slow ECDSA/DSA to enhance performance Online Certificate Status Protocol

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

31. 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 CRD N2,0 N2,1 N3,0 N3,0 CA Sig

32. 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 Merkle Hash Trees

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

34. 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?

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

36. 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?

37. What 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 CA Evaluation Checklist

38. PKI Development Directions • Directories • Short certificates • Traditional • Bullet • Certified time

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

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

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

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

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

44. Client and Certifier cooperate on creation of a bullet Client Certifier 1. Temporary PK pair (x,X) 2. Create permanent PK pair and bullet f( Sig values, x, X) = (a, A, BulletA) 3. Publish Ia ,BulletA Permanent PK pair (c,) (name, X) 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 Bullet Creation

45. The user of the wireless device wishes to retrieve his/her account information and therefore, needs to authenticate the bank. 1. Requests Server’s Bullet Wireless Network 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. Bullet Application

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

47. 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 ???

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

49. PKI Products & Services

50. 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 Product & Service Listing