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.  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 extensions Today, 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 implemented using 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 a trusted 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, but will 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 by Policy [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 3 rd 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+validityintegrity+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.  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 –CRL new =BaseCompleteCRL old + 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 T3 rd P

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

51. Web Model  A bunch of root CAs pre-installed in browsers  The set of root CAs can be modified –But will it be?  Root CAs are unrelated (no cross- certification) –Except by “CA powers” of browser manufacturer –Browser manufacturer = (implicit) Root CA

52. User-Centric  PGP  User = her own Root CA –Webs of trust  Good –User fully responsible for trust  Bad –User fully responsible for trust –Corporate/gov/etc. like to have central control User-centric not friendly to centralized trust policies

53. Cross-Certification  Mechanism: –Certificates for CAs (not end-entities)  Intra- vs. Inter- domain  One or two directions –CA1 certifies CA2 and/or CA2 certifies CA1  Control –Cross-certificate limits trust Name, policy, path length, etc. constraints

54. Entity Naming  What’s the identity? (the one bound by certificate to the PK [+sk]) –If a certificate is issued to “GeoTrust ”, rather than “Geotrust”, you may be talking to a different entity than what you think

55. Name Uniqueness  X.500 Distinguished Name (DN) –Tree of naming authorities –X.509 Subject is a DN; –IP addresses, email, etc. are similar  Problems –Not too user-friendly –Central naming authority not always there => lots of cooperation required from participating entities

56. Names (continued)  So, how useful are names? –SDSI, SPKI, etc – not very –X.509 allows alternative names Extensions subjectAltName If this extension is used Subject name (DN) is not required –Global uniqueness – not always crucial –Piggy-back on existing naming/identity infrastructures

57. Certificate Path  Alice “trusts” CA1 –Alice has CA1’s PK in its browser CA1’s PK = “trust anchor” –“trust anchor” depends on the model  CA1 certifies CA2; CA2 certifies CA3  CA3 certifies Bob  => Alice “trusts” Bob –Alice associates PK in Bob’s certificate with Bob

58. Certificate Path Processing  Path construction –Aggregation of necessary certificates  Path validation –Checking the certificates and the keys Includes all steps of certificate validationcertificate validation

59. Path Construction  “Just a [Shortest] Path graph algorithm”  Not so simple – graph is not known –Edges (certificates) need to be queeried  Once Path Construction is done Path Validation is straight-forward

60. Multiple Certificates per Entity