CMSC 414 Computer and Network Security Lecture 16

CMSC 414 Computer 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(A B) = Sign. SKA(“B”, PKB, info) – “info” can include expiration time, restrictions, etc. ¨ Can view this as a directed edge in a graph: A/PKA B/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 already known PKC

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 (“keysigning 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 OLRS http: //www. imperialviolet. org/2011/03/18/revocation. html ¨ Google Chrome disabling revocation checks http: //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 regraded, and why – I will re-grade the entire exam