PKI by Gene Itkis

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