CMSC 414
Computer and Network Security
Lecture 18
Jonathan Katz
Administrative
 Exam April 22
– Based on material through April 15
 Next HW out later today, will be Exercises rather
than a project
 One more project (buffer overflows) later in the
semester
WireShark demonstration
 NYTimes sends the password in the clear
 View SSL/TLS session
 Old (insecure) Yahoo! email authentication
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?
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 I already know
PKC
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”
 (Means for retrieving certificates)
 (CAs)
 (Naming conventions)
 (Trust model/method for evaluating a certificate
chain)
 (Revocation)
CAs and certificates
 A certificate authority (CA) is just 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 (1996)
 Three levels of authentication
– Verification of valid email address
– Verification of name/address
– Background check
 Different authentication policies; same issuance
policy (individuals only)
 Another issuance policy was for issuing
certificates to corporations/web servers
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
Trust models
 Define valid trust anchors, 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
 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
 (Note: 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 CAs have the same distinguished
name?
 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