Public Key Infrastructures

1. Public Key
Infrastructures

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

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