Public Key Infrastructures

1. Public Key Infrastructures Gene Itkis itkis@bu.edu Based on “Understanding PKI” by Adams & Lloyd

2. What and How?

3. Services • Secure communication • Notarization • Time-Stamping • Non-Repudiation • Privilege Management • Authorization & Authentication • Authorization & Policy Authorities • Delegation • Blind vs. Auditable

4. PKI and the Services • CLAIM: PKI can help in all • Question(subjective – GI) • Where is the source of trust in all these? • Suggestion (subjective – GI) • Try to do the same without PKI, using only symmetric techniques (usually possible!); find the problem; see how this problem is manifested and addressed in the PKI solution. • Easier to “cheat” (including yourself!) with PKI. Symmetric techniques are more explicit. • Make all the security & trust assumptions explicit!

5. Mechanisms • Crypto • Signatures, hash, MAC, ciphers • Infrastructure • Tickets • Certificates • Authorities (Trusted Third Parties) • Ticket Granting, Key Distribution • Certificate, Policy, Authorization,Time, Notary, etc. • Archives

6. Pitfalls • Security breaches • Key compromises • Inherent difficulties • Revocation • Negligence • Certificates are routinely not checked or some of the attributes ignored • Alarms and warnings ignored (“certificate not valid. Press OK to proceed.”) • Inconsistencies & human factors(“that’s not what I meant by this policy!”)

7. Certificates

8. Certificates • Introduced in 1978[Kohnfelder’s Bachelor’s thesis] • X.509 – “the standard standard” today • v.1 (1988) – not extendable • v.2 – not much better • v.3 (1997) is much better – optional extensionsToday, X.509=v.3 • Many other standards extend X.509 • Others • PGP, SPKI, etc.

9. Certificates • Certificates  Signature • Certificates are implemented using Signatures • Certificates  Authentication • Authentication can be implementedusing Certificates • Same for Authorization, etc. • Certificates are static • Change => Re-Issue • *This could be challenged, but not in standard x509

10. X.509 Certificate Format • See [AL] pg.76

11. Certificate Validation • Integrity: signature is valid • Signed by atrusted CA • or certification path is rooted in a trusted CA • Certificate is valid now: • We are between Not Valid Before and Not Valid After time points in the certificate • Not Revoked • Use is consistent with the policy

12. Alternatives to X.509 Brief detour

13. SPKI – A Simple PKI • Authorization certificates • Delegation • SDSI – a Simple Distributed Security Infrastructure • Question #1: it may be very nice, butwill it ever be used by anyone?

14. PGP – Pretty Good Privacy • Tendencies • Email • Incompatibilities between PGP and S/MIME • OpenPGP v6.5 supports x509 certs, but still… • Personal (rather than corporate)

15. SET – Secure Electronic Transaction • Credit card payment protocol • Adopts and extends X.509 • See [AL] pg.84

16. Back to X.509 End detour

17. Infrastructure:Policies and Authorities

18. Certificate Policies • Certificate Policy • “high level what is supported” document • CPS – Certification Practice Statement • “detailed, comprehensive, technical how policy is supported” document • No agreement on the roles and meanings of the above • Might be not public; hard to enforce

19. Certificate Policies • Distinguished by OIDs (Object ID) • “form letters” • Equivalences • Policy Mapping ext. declare policies equivalent • Established & registered byPolicy [Management] Authorities • Internal – e.g. corporate • External – community

20. CA – Certification Authority • Issuer/Signer of the certificate • Binds public key w/ identity+attributes • Enterprise CA • Individual as CA (PGP) • Web of trust • “Global” or “Universal” CAs • VeriSign, Equifax, Entrust, CyberTrust, Identrus, … • Trust is the key word

21. RA – Registration Authority • Also called LRA – Local RA • Goal: Off-load some work of CA to LRAs • Support all or some of: • Identification • User key generation/distribution • passwords/shared secrets and/or public/private keys • Interface to CA • Key/certificate management • Revocation initiation • Key recovery

22. PKI management

23. Key & Certificate Management Key/Certificate Life Cycle Management • Identity  Key. Focus on Key! Stages • Initialization • Issued (active) • Cancellation • Generation • Issuance • [Usage] • Cancellation

24. Initialization • Registration • Via RA • Identity verification • According to CP/CPS docs • If on-line, should be protected+authenticated(?) • Secret shared by user and CA • New or pre-existing relationship • Key pair generation • Certificate creation & delivery • [Key backup]

25. Key pair generation • Where? (by who?) • CA • RA • Owner (e.g. within browser) • Other Trusted 3rd Party • What for? • Non-repudiation  owner generation • Dual key pair model • Separate key pairs for authentication, confidentiality, etc.

26. Key pair generation • Performance • Laptop, smart cards – used to be too slow • Today – many smart cards can generate own keys • Centralized generation • Scalability: bottleneck for performance & security • Assurance • “Is the smart card’s random number generator good enough?” • Minimal security requirements guarantees • Legal/Liabilities • Who to sue? Who backs up above assurances?

27. Certificate Creation+Distribution • Creation – CA only • Distribution (to the owner) • Certificate only • Certificate + private key • Deliver key securely! • X509 rfc2510 • Direct to owner • To depository • Both

28. Certificate dissemination • Out-of-band • Public repositories • LDAP-like directories • Used mostly for confidentiality • In-band • E.g. signed e-mail usually carries certificate Issues: • Privacy, scalability, etc.

29. Key backup • Backup  Escrow • Backup= only owner can retrieve the (lost) key • Escrow= organization/government can retrieve the key even against owner’s wish • Non-repudiation conflicts with Backup • Where & how to backup securely???

30. Issued Phase • Certificate retrieval • To encrypt msg or verify signature • Certificate validation • Verify certificate integrity+validity • Key recovery • Key backup – automate as much as possible • Key update • When keys expire: new certificate [+new keys]

31. Certificate Cancellation • Certificate Expiration • Natural “peaceful” end of life • Certificate Revocation • Untimely death, possibly dangerous causes • Key history • For owner: eg to read old encrypted msgs • Key archive • “For public”: audit, old sigs, disputes, etc.

32. Certificate Expiration • No action • Certificate renewal • Same keys, same cert, but new dates • Preferably automatic • but watch for attributes change! • Certificate update • New keys, new certificate

33. Certificate Revocation

34. Certificate Revocation • Requested by • Owner, employer, arbiter, TTP, ???, … • Request sent to • RA/CA • Mechanisms for Revocation checks • Certificate Revocation Lists (CRLs) • On-line Certificate Status Protocol (OCSP) • Will it live? (SCVP) • Revocation delay • According to Certificate Policy

35. Publication Mechanisms • Complete CRLs • Authority Revocation Lists (ARLs) • CRL distribution points (partition CRLs) • Delta CRLs • Indirect CRLs • Enhanced CRL distribution points & Redirect CRLs • Certificate Revocation Trees (CRTs) White lists vs Black lists

36. CRL versions • Version 1 (from x509 v1) • Flaws: • Scalability • Not extendable • Can replace one CRL with another • Version 2 (similar to x509 v3) • Extensions • critical and non-critical • Per-CRL and per-entry • Format: see [AL] pg.112

37. Complete CRLs • Advantage: • Self-contained, simple, complete • Problems: • Scalability • CRL may grow too big • Timeliness • Also results from CRL size • Conclusion: appropriate for some domains

38. Authority Revocation Lists • ARL = CRL for Cas • Revokes certificates of Cas • Rarely needed/used • Decommissioned • Compromised

39. CRL Distribution Points • Partition CRL into smaller chunks • Static partitions: • Certificate points to its CRL distribution point • Dynamic partitions • Enhanced/Redirect CRL DPs • Certificate points to a Redirect CRL • Redirect CRL directs to the proper CRL partition

40. Delta CRL • Incremental change • From Complete or Partition CRL • CRLnew=BaseCompleteCRLold + DeltaCRL • Possibly many DeltaCRLs from same BaseCRL • E.g. complete CRL issued once a week, and a new DeltaCRL (containing the previous DeltaCRLs) issued every day

41. Indirect CRL • Combines CRLs of many CAs • Potentially a “for fee” service by T3rdP

42. Certificate Revocation Trees • Valicert [Kocher] • Based on Merkle’s hash trees • Similar/Relevant work: [Micali; Naor&Nissim] • Construct hash-tree; leaves – certificates • Sign root • To verify a certificate in the tree: path from the certificate to root + the siblings • Certificate Owner can offer proof of not being revoked as of the current CRT date!

43. Trust models

44. Trust model issues • Who to trust? • Which certificates can be trusted • Source of Trust • How it is established? • Limiting/controlling trust in a given environment

45. Common Trust Models • CA Hierarchy • Distributed • Web • User-centric Tool • Cross-certification

46. Trust – definition(??) • “A trusts B = A assumes B will behave exactly as A expects” • Problem 1: A expects B to try every way of cheating A that B can find, and A assumes B will do exactly that == A trusts B? • Problem 2: Is it a tautology? What’s the difference between “assumes” and “expects”? • X trusts a CA = X assumes CA will establish and maintain accurate binding of attributes and PK’s • Maintain? Includes secure the binding, CA’s keys binding, security, etc…

47. Trusted Public Key • PK is trusted by X when X is convinced the PK corresponds to SK which legitimately and validly belongs only to a specific named entity

48. CA Hierarchy • Tree architecture • Single Root CA • Number of subordinate CA’s • Etc… • Parent certifies children • Leaves are non-CA (end-) entities • Typically CA either certifies other CA’s or end-entities, but not both • Everyone has Root CA PK

49. Context is important • Privacy Enhanced Mail (PEM) adopted strict hierarchy of CAs approach and failed • DoD could use hierarchy fine

50. Distributed Trust Architecture • A set of independent hierarchies • May evolve as independent historically • Cross-certification or PKI networking • Connect the hierarchies • Fully-meshed – all CAs are cross-certified • Hub & spokes or bridge CA • Not= Hierarchy • No root CA: every end-entity holds its CA PK