1. CMSC 414 Computer and Network Security Lecture 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. Certificates  One party can vouch for the public key of another  Cert(A  B) = Sign SKA (“B”, PK B, 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/PK A B/PK B

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

7. 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 PK A PK B PK C PK D PK E 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 the entire exam