CMSC 414 Computer and Network Security Lecture 16

1. CMSC 414Computer and Network SecurityLecture 16 Jonathan Katz

2. PKI and certificate authorities

3. “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

4. PKI components • Certificates • (Means for obtaining/retrieving certificates) • (Trust model/method for using certificates) • “Trust anchors”/CAs • (Naming conventions; authentication policy) • Revocation

5. A/PKA B/PKB Certificates • One party can vouch for the public key of another • Cert(AB) = 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

6. Cert(AB) Cert(BC) PKA PKB PKC 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?

7. PKA PKB PKC 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 PKD PKE Public keys already known

8. 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)

9. 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

10. Trust anchors? • Who are A’s trust anchors? • Two main possibilities: • Certificate authorities • “Web of trust”

11. 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)

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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?

19. “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

20. 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)

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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 theentire exam