CMSC 414
Computer and Network Security
Lecture 16
Jonathan Katz
PKI and certificate authorities
“Public-key infrastructure” (PKI)
 In our discussion of public-key crypto, we have
assumed users know each others’ public keys
 But how can public keys be reliably distributed?
– Download from web page: insecure against man-in-themiddle attack
– Can be obtained from CD-ROM or in person, but this is
impractical in general
 One solution: bootstrap new public keys from
public keys you already know!
– Certificates vouch for binding of public keys to names
PKI components
 Certificates
– (Means for obtaining/retrieving certificates)
– (Trust model/method for using certificates)
 “Trust anchors”/CAs
– (Naming conventions; authentication policy)
 Revocation
Certificates
 One party can vouch for the public key of another
 Cert(AB) = SignSKA(“B”, PKB, info)
– “info” can include expiration time, restrictions, etc.
 Can view this as a directed edge in a graph:
A/PKA
B/PKB
 If you know A’s public key (and trust its
certification), you can learn B’s public key
Transitivity/“certificate chains”
 Can learn keys via multiple hops:
PKA
Cert(AB)
PKB
PKC
Cert(BC)
 Semantics are slightly different here: you may
trust A to certify B, but do you trust A to certify
that B can certify others?
Transitivity
 Can also infer trust from multiple (disjoint?) paths
to the same public key for the same identity
– Edges may also have weights indicating level of trust
– A difficult problem in general
PKA
PKB
PKD
PKE
Public keys already known
PKC
Obtaining certificates
 How does B get a certificate on its public key?
 For best security, done in some out-of-band
manner
– E.g., B shows a physical ID along with a USB stick
containing its public key
 Other mechanisms possible
– E.g., via email (under certain assumptions on reliability
of email)
Retrieving certificates
 How does A retrieve certificates for B?
– “Trust anchors” = set of public keys already known to A
(and trusted to certify others)
 Some possibilities:
– B “collects” certificate(s) for itself, sends them all when
starting a connection
– A finds certificates/certificate chains beginning at its
own trust anchors and terminating at B
– A tells B its trust anchors; B (finds and) sends
certificates or certificate chains beginning at those trust
anchors and terminating at itself
Trust anchors?
 Who are A’s trust anchors?
 Two main possibilities:
– Certificate authorities
– “Web of trust”
CAs and certificates
 A certificate authority (CA) is a widely used trust
anchor
 CA authentication policy determines the level of
authentication needed to identify the principal
before the certificate is issued
 CA issuance policy describes the principals to
whom the CA will issue certificates
 A single entity can “act” as multiple CAs, each
with their own policies…
– Use distinct public keys (with different security)
Example: Verisign
 Multiple levels of authentication
– Verification of valid email address
– Verification of name/address
– Background check
 Different authentication policies with the same
issuance policy (i.e., individuals)
 Another issuance policy for issuing certificates to
corporations
Trust
 How much to trust a particular certificate?
 Based on:
– CA authentication policy
– Rigor with which policy is followed
– Security of CA’s secret key
– …
 In practice (for most people), all CAs trusted
equally
Naming
 Identifiers correspond to principals
– Must uniquely identify the principal
– (Real) names alone are not enough!
• Need disambiguation
 A principal may have multiple identifiers
– Depending on that principal’s roles
– E.g., work/personal
Monopoly model
 A single CA certifies everyone
 Drawbacks
– Single point of failure
– Not very convenient
– Complete monopoly…
 Monopoly model does not scale to the Internet,
but may be used within a single organization
Monopoly + RAs…
 The CA can appoint registration authorities (RAs)
 RAs check identities and vouch for keys, but the
CA does all actual signing
– More convenient
– Not necessarily more secure (possibly less)
 RAs can be integrated into other models as well
Monopoly + delegated CAs
 CA can issue certificates to other CAs
– Vouch for their key and their trustworthiness as a CA
– Delegated CA can sign certificates itself
 Users must now obtain a certificate chain
 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:
– Security can reduce to least secure trust anchor
– Who says the user trusts the trust anchors?
– Can users be tricked into using “bad” trust anchors?
– Can public keys of “good” trust anchors be changed in
the software?
“Web of trust” model
 Users responsible for defining the trust anchors
they want to use
– E.g., their friends; people they met in person (“keysigning parties”)
 Drawbacks
– Scalability/usability?
– How much trust to place in a certificate chain
PKI in the real world
 PKI is implemented in modern web browsers
– Firefox: Tools →Options→Advanced →Encryption
– IE/Chrome (via Windows):
• Windows XP: Start →Run →”certmgr.msc”
• Windows Vista and later: Start →”certmgr.msc”
– “Trust” is only as good as your trust anchors
• Do you know who your trust anchors are?
 “Web of trust” model
– PGP keyserver (http://pgp.mit.edu)
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
 Why use expiration dates at all?
– Expiration dates improve efficiency
– Revocation may not be implemented
Cert. revocation lists (CRLs)
 CA issues signed list of (un-expired) revoked
certificates
– Must be updated and released periodically
– Must include timestamp
– Verifier must obtain most recent CRL before verifying a
certificate
 Using “delta CRLs” improves efficiency
OLRS (“On-line revocation server”)
 Also known as OCSP (“Online Certificate Status
Protocol”)
 Verifier queries an OLRS to find out if a
certificate is still valid
– OLRS somewhat mitigates advantages of having a
public-key model in the first place
– But OLRS is not as security sensitive as a KDC/CA,
and certs can be used even if OLRS is unavailable
 If OLRS has its own key, it can certify for a user
that the user’s certificate is valid at a certain time
Self revocation
 Sign a message revoking your own public key;
send to the CA who issued your certificate
 This is how revocation is done in the web-of-trust
model
– Deposit revocation into keyserver
Revocation in practice (2011)
 Browsers (or users) tend to ignore a failure to
obtain a current CRL/connect to an OLRS
http://www.imperialviolet.org/2011/03/18/revocation.html
 Google Chrome disabling revocation checks
http://www.imperialviolet.org/2012/02/05/crlsets.html
– Instead, pushing CRLs into software updates
Midterm review
 A: 79-100
 B: 65-78
 C: 50-65
 D/F: < 50
 Re-grade policy:
– Submit brief write-up of what question(s) should be regraded, and why
– I will re-grade the entire exam