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
(thats not what I meant by this policy!)
Certificates
Certificates
Introduced in 1978
[Kohnfelders Bachelors 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 3
rd
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 cards 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 owners 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
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
Indirect CRL
Combines CRLs of many CAs
Potentially a for fee service by T3
rd
P
Certificate Revocation Trees
Valicert [Kocher]
Based on Merkles 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? Whats the
difference between assumes and expects?
X trusts a CA = X assumes CA will
establish and maintain accurate binding of
attributes and PKs
Maintain? Includes secure the binding, CAs
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 CAs
Etc
Parent certifies children
Leaves are non-CA (end-) entities
Typically CA either certifies other CAs 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
Whats 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 CA1s PK in its browser
CA1s 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 Bobs 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