CMSC 414
Computer and Network Security
Lecture 25
Jonathan Katz
Certificate authorities and PKI
PKI overview
 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
Certificates
 One party can vouch for the public key of another
 Cert(AB) = SignSKA(“B”, PKB, info)
– “info” can contain expiration time, restrictions, etc.
 Can view this as a directed edge in a graph:
PKA
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?
Usage of certificates
 “Trust anchors” = set of public keys already
known (and trusted to certify others)
 How to obtain certificates?
 Some possibilities:
– B “collects” certificate(s) for itself, sends these 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
PKI components
 Certificates
 Distributing the keys of the “trust anchors”
 CAs
 Revocation
 (Means for retrieving certificates)
 (Naming conventions)
 (Trust model/method for evaluating a certificate
chain)
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 CA 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
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
E.g., X.509 certificates
 Distinguished names identify a principal
– Series of fields, each with key and value
• E.g. /O=University of Maryland/OU=College
Park/OU=Computer Science/CN=J. Katz
• “O” - organization; “OU” - organizational unit; “CN” =
common name
What does identity mean?
 Ultimately, identity is proved using physical
means
– Driver’s license, fingerprints, etc.
 If these are compromised, then certificates are
irrelevant!
– Certificate is just a binding between external identity
and (DN, PK)
Trust
 How much to trust a particular certificate?
 Based on:
– CA authentication policy
– Rigor with which policy is followed
– Assumptions inherent in the policy
– Security of CA’s secret key
Trust models
 Define:
– Valid trust anchors,
– How a verifier chooses trust anchors
– 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…
 In practice, monopoly model not used globally but
may be used within an organization
Monopoly + RAs…
 The CA can appoint registration authorities (RAs)
 RAs check identities and vouch for keys, but the
CA does all actual signing
– Certainly 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
CA hierarchy
 Hierarchical structure of CAs
– Nodes correspond to CAs
– Children of a CA are constrained by the policies of their
parents
Conflicts
 What if two different CAs issue certificates for the
same distinguished name (but to different
principals)?
 An easy way to address these is to have
hierarchical names for CAs, and to incorporate CA
distinguished name into issued certificates
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 users be tricked into using “bad” trust anchors?
• Issuer name may be bogus
– Can public keys of “good” trust anchors be changed in
the software?
Anarchy model
 Users responsible for defining the trust anchors
they want to use
 Drawbacks
– Scalability/usability?
– How much trust to place in a certificate chain
PKI in practice
 PKIs are implemented in web browsers
– 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?
 PGP “web of trust” model
– PGP keyserver
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 keys
– 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”
 Verifier queries an OLRS to find out if a
certificate is still valid
– OLRS somewhat mitigates advantages of public-key
model
– 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 the
target that its 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
Self revocation
 Sign a message revoking your own public key;
propagate throughout the network
 This is essentially how revocation is done in the
web of trust model
– Deposit revocation into keyserver
Intrusion detection
Prevention vs. detection
 Firewalls (and other security mechanisms) aim to
prevent intrusion
 IDS aims to detect intrusion in case it occurs
 Use both in tandem!
– Defense in depth
– Full prevention impossible
– The sooner intrusion is detected, the less the damage
– IDS can also be a deterrent, and can be use to detect
weaknesses in other security mechanisms
IDS overview
 Goals of IDS
– Detection and response
– Deterrence
– Recovery
– Defense against future attacks
 Two classes of behavior to be detected
– Illegal access by outsiders
– Illegal access by insiders
IDS tradeoff
 IDS based on the assumption that attacker
behavior is (sufficiently) different from legitimate
user behavior
 In reality, there will be overlap
– Some legitimate behavior may appear malicious
– Intruder can attempt to disguise their behavior as that of
an honest user
False positives/negatives
 False positive
– Alarm triggered by acceptable behavior
 False negative
– No alarm triggered by illegal behavior
 Always a tradeoff between the two…
– Note: credit card companies face the same tradeoff