CMSC 414 Computer (and Network) Security Lecture 17

1. CMSC 414Computer (and Network) SecurityLecture 17 Jonathan Katz

2. More on PKI (Chapter 15, KPS)

3. 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?)

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

5. Trust models • Define how a verifier chooses trust anchors, and what certification paths create a legal chain from trust anchor to target

6. Monopoly model • A single CA certifies everyone • Drawbacks • Single point of failure • Not very convenient • Complete monopoly… • Pure monopoly not used in practice

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

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

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

10. Anarchy model • Users responsible for defining the trust anchors they want to use • Drawbacks • Scalability? • How much trust to place in a certificate chain

11. “Top down” w/ name constraints • Like monopoly model with delegated CAs • But delegated CAs are only allowed to certify their portions of the namespace • This makes it easier to find a certificate chain, and also is more likely to be trustworthy

12. 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 • Expiration dates improve efficiency

13. Cert. revocation lists (CRLs) • CA issues signed list of (un-expired) revoked keys • Must be updated and released periodically • Must include timestamp • Verifier must obtain most recent CRLs before verifying a certificate • Using “delta CRLs” improves efficiency

14. OLRS • “On-line revocation server” • Verifier queries an OLRS to find out if a certificate is still valid • If OLRS has its own key, it can certify that a certificate is valid at a certain time

15. “Good lists” • The previous approaches basically use lists of “bad” certificates • Also possible to use a list containing only “good” certificates • Likely to be less efficient

16. Directories • PKIs do not require directories • Users can store and present their own certificate chains to a trust anchor • Directories can make things easier, and enable non-interactive setup

17. Finding certificate chains • Two approaches: work “forward” from target toward a trust anchor, or “backward” from trust anchor to target • The better approach depends on implementation details • For example, in system with name constraints, easier to work “backward”

18. Final notes: 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?