CMSC 414
Computer (and Network) Security
Lecture 17
Jonathan Katz
More on PKI
(Chapter 15, KPS)
PKI components
 CAs…
 Repository for retrieving certificates
 Revocation method
 Method for evaluating a chain based on
known “trust anchors”
 (Orthogonal issue: how are the keys of the
trust anchors distributed?)
Some terminology
 If A signs a certificate for B’s name/key, then A is
the issuer and B is the subject
 If A wants to find a path to B’s key, then B is the
target and A is the verifier
 A trust anchor is a public key that the verifier
trusts to sign certificates (typically known to the
verifier through some out-of-band mechanism)
Trust models
 Define how a verifier chooses trust anchors,
and what certification paths create a legal
chain from trust anchor to target
Monopoly model
 A single CA certifies everyone
 Drawbacks
– Single point of failure
– Not very convenient
– Complete monopoly…
 Pure monopoly not used in practice
Monopoly + RAs…
 The CA can appoint RAs
 RAs check identities and vouch for keys,
but the CA does all actual signing
– Certainly more convenient
– Not necessarily more secure
 (Note: RAs can be integrated into other
models as well)
Monopoly + delegated CAs
 As seen in class last time…
 CA can issue certificates to other CAs
– Vouch for their key and also their
trustworthiness as a CA
– Delegated CA can sign certificates itself
 (Note: delegation can be incorporated into
other models as well)
Oligarchy
 Multiple trust anchors
– E.g., multiple keys pre-configured in software
– User can add/remove trust anchors
 Issues:
– Less resistant to compromise!
– Who says the user trusts the trust anchors?
– Can user be tricked into adding or using a
“bad” anchor?
Anarchy model
 Users responsible for defining the trust
anchors they want to use
 Drawbacks
– Scalability?
– How much trust to place in a certificate chain
“Top down” w/ name constraints
 Like monopoly model with delegated CAs
– But delegated CAs are only allowed to certify
their portions of the namespace
– This makes it easier to find a certificate chain,
and also is more likely to be trustworthy
Revocation
 Revocation is a key component of a PKI
– Secret keys stolen/compromised, user leaves
organization, etc.
 This is in addition to expiration dates
included in certificates
– Certificate might need to be revoked before
expiration date
– Expiration dates improve efficiency
Cert. revocation lists (CRLs)
 CA issues signed list of (un-expired)
revoked keys
– Must be updated and released periodically
– Must include timestamp
– Verifier must obtain most recent CRLs before
verifying a certificate
 Using “delta CRLs” improves efficiency
OLRS
 “On-line revocation server”
 Verifier queries an OLRS to find out if a
certificate is still valid
 If OLRS has its own key, it can certify that
a certificate is valid at a certain time
“Good lists”
 The previous approaches basically use lists
of “bad” certificates
 Also possible to use a list containing only
“good” certificates
– Likely to be less efficient
Directories
 PKIs do not require directories
– Users can store and present their own certificate
chains to a trust anchor
 Directories can make things easier, and
enable non-interactive setup
Finding certificate chains
 Two approaches: work “forward” from
target toward a trust anchor, or “backward”
from trust anchor to target
 The better approach depends on
implementation details
– For example, in system with name constraints,
easier to work “backward”
Final notes: PKI in practice
 PKIs are implemented in web browsers!
 Security notes:
– A certificate is meaningless without verifying
the name in the certificate
– A certificate from an unknown CA is useless
– “Trust” is only as good as your trust anchors
• Do you know who your trust anchors are?