CMSC 414
Computer and Network Security
Lecture 20
Jonathan Katz
Certificate authorities and PKI
Naming and certificates
 Identifiers correspond to principals
– Must uniquely identify the principal
– (Real) names alone are not enough!
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
Certificates
 Certification authorities vouch for the identity of
the principal to whom a certificate is issued
 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…
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)
 Another issuance policy was for issuing
certificates to web servers
Certificate infrastructure
 Hierarchical structure of CAs
– Nodes correspond to CAs
– Children of a CA are constrained by the policies
of their parents
Conflicts
 What if a single CA issues certificates under
different policies?
 What if a CA issues a certificate tied to an email
address, but the owner of this address changes?
 What if two CAs have the same dist. name?
 What if two different CAs issue certificates for the
same distinguished name (to different principals)?
Easy solution
 For organizational certificates, the last type of
conflict can be prevented by incorporating CA
name into distinguished name
 Does not solve the other problems, in general…
Handling conflicts
 Conflict detection database…
 Before a PCA may issue a certificate to a CA, it
checks for a conflict in the database
– Sends a hash of the CAs dist. name, the CAs
public key, and the dist. name of the PCA
 If first two fields conflict with a database entry,
the two PCAs must resolve the conflict
 Note that this only ensures uniqueness of
(DN, PK) pairs
Handling conflicts (in action)
 Two CAs with same dist. name?
– Will have different public keys…
 Same CA with two different policies?
– Will use different public keys for each
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)
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
Trust
 How much to trust a particular certificate?
 Based on:
– CA authentication policy
– Rigor with which policy is followed
– Assumptions inherent in the policy
Example…
 Certificate issued based on a passport
 Assumptions:
– Passport not forged
– Passport issued to the right person
– Person presenting passport is the right person
– CA actually checked the passport when issuing
the certificate
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
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?