CMSC 414 Computer and Network Security Lecture 16

CMSC 414Computer and Network Security

Lecture 16

Jonathan Katz

PKI and certificate authorities

“Public-key infrastructure” (PKI) 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-the-

middle 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

PKI components

Certificates– (Means for obtaining/retrieving certificates)

– (Trust model/method for using certificates)

“Trust anchors”/CAs– (Naming conventions; authentication policy)

Revocation

Certificates

One party can vouch for the public key of another

Cert(AB) = SignSKA(“B”, PKB, info)– “info” can include expiration time, restrictions, etc.

Can view this as a directed edge in a graph:

If you know A’s public key (and trust its certification), you can learn B’s public key

A/PKA B/PKB

Transitivity/“certificate chains”

Can learn keys via multiple hops:

Semantics are slightly different here: you may trust A to certify B, but do you trust A to certify that B can certify others?

PKA PKB PKC

Cert(AB) Cert(BC)

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 PKC

PKD PKE

Public keys already known

Obtaining certificates

How does B get a certificate on its public key?

For best security, done in some out-of-band manner– E.g., B shows a physical ID along with a USB stick

containing its public key

Other mechanisms possible– E.g., via email (under certain assumptions on reliability

of email)

Retrieving certificates

How does A retrieve certificates for B?– “Trust anchors” = set of public keys already known to

A (and trusted to certify others)

Some possibilities:– B “collects” certificate(s) for itself, sends them 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

Trust anchors?

Who are A’s trust anchors?

Two main possibilities:– Certificate authorities

– “Web of trust”

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 entity 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

Trust

How much to trust a particular certificate?

Based on:– CA authentication policy

– Rigor with which policy is followed

– Security of CA’s secret key

– …

In practice (for most people), all CAs trusted equally

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

Monopoly model

A single CA certifies everyone

Drawbacks– Single point of failure

– Not very convenient

– Complete monopoly…

Monopoly model does not scale to the Internet, but may be used within a single organization

Monopoly + RAs…

The CA can appoint registration authorities (RAs)

RAs check identities and vouch for keys, but the CA does all actual signing– 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

Oligarchy

Multiple trust anchors– E.g., multiple keys pre-configured in software

– User can add/remove trust anchors

Issues:– Security can reduce to least secure trust anchor

– Who says the user trusts the trust anchors?

– Can users be tricked into using “bad” trust anchors?

– Can public keys of “good” trust anchors be changed in the software?

“Web of trust” model

Users responsible for defining the trust anchors they want to use– E.g., their friends; people they met in person (“key-

signing parties”)

Drawbacks– Scalability/usability?

– How much trust to place in a certificate chain

PKI in the real world PKI is implemented in modern web browsers

– Firefox: Tools →Options→Advanced →Encryption– IE/Chrome (via Windows):

• Windows XP: Start →Run →”certmgr.msc”• Windows Vista and later: Start →”certmgr.msc”

– “Trust” is only as good as your trust anchors• Do you know who your trust anchors are?

“Web of trust” model– PGP keyserver (http://pgp.mit.edu)

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 certificates– 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”)

Also known as OCSP (“Online Certificate Status Protocol”)

Verifier queries an OLRS to find out if a certificate is still valid– OLRS somewhat mitigates advantages of having a

public-key model in the first place– 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 a user that the user’s certificate is valid at a certain time

Self revocation

Sign a message revoking your own public key; send to the CA who issued your certificate

This is how revocation is done in the web-of-trust model– Deposit revocation into keyserver

Revocation in practice (2011)

Browsers (or users) tend to ignore a failure to obtain a current CRL/connect to an OLRShttp://www.imperialviolet.org/2011/03/18/revocation.html

Google Chrome disabling revocation checkshttp://www.imperialviolet.org/2012/02/05/crlsets.html

– Instead, pushing CRLs into software updates

Midterm review A: 79-100

B: 65-78

C: 50-65

D/F: < 50

Re-grade policy: – Submit brief write-up of what question(s) should be re-

graded, and why– I will re-grade the entire exam