CMSC 414Computer 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?