Public Key Infrastructures
Gene Itkis
itkis@bu.edu
Based on “Understanding PKI” by Adams & Lloyd
What and How?
Services
 Secure communication
 Notarization
 Time-Stamping
 Non-Repudiation
 Privilege Management
– Authorization & Authentication
– Authorization & Policy Authorities
– Delegation
• Blind vs. Auditable
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!
Mechanisms
 Crypto
– Signatures, hash, MAC, ciphers
 Infrastructure
– Tickets
– Certificates
– Authorities (Trusted Third Parties)
• Ticket Granting, Key Distribution
• Certificate, Policy, Authorization,Time, Notary, etc.
• Archives
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!”)
Certificates
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.
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
X.509 Certificate Format
 See [AL] pg.76
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
Alternatives to X.509
Brief detour
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?
PGP – Pretty Good Privacy
 Tendencies
– Email
• Incompatibilities between PGP and S/MIME
• OpenPGP v6.5 supports x509 certs, but still…
– Personal (rather than corporate)
SET – Secure Electronic Transaction
 Credit card payment protocol
 Adopts and extends X.509
– See [AL] pg.84
Back to X.509
End detour
Infrastructure:
Policies and Authorities
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
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
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
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
PKI management
Key & Certificate Management
Key/Certificate Life Cycle Management
– Identity  Key. Focus on Key!
Stages
 Initialization
 Issued (active)
 Cancellation
• Generation
• Issuance
• [Usage]
• Cancellation
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]
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.
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?
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
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.
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???
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]
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.
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
Certificate Revocation
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
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
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
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
Authority Revocation Lists
 ARL = CRL for Cas
– Revokes certificates of Cas
– Rarely needed/used
• Decommissioned
• Compromised
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
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
Indirect CRL
 Combines CRLs of many CAs
– Potentially a “for fee” service by T3rdP
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!
Trust models
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
Common Trust Models
 CA Hierarchy
 Distributed
 Web
 User-centric
Tool
 Cross-certification
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…
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
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
Context is important
 Privacy Enhanced Mail (PEM) adopted
strict hierarchy of CAs approach and failed
 DoD could use hierarchy fine
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
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
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
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
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
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
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
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
Certificate Path Processing
 Path construction
– Aggregation of necessary certificates
 Path validation
– Checking the certificates and the keys
• Includes all steps of certificate validation
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
Multiple Certificates per
Entity