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?