This document discusses public key infrastructures (PKI) and their components. It describes how PKI can enable secure communication, notarization, time-stamping, non-repudiation, and privilege management through the use of certificates, digital signatures, and trusted third parties. It also outlines some of the pitfalls of PKI, such as key compromises, difficulties with revocation, and human errors in certificate validation. Finally, it examines the technical details of how certificates, certification authorities, certificate paths, and trust models function within a PKI.

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

60. Multiple Certificates per
Entity