CMSC 414 Computer and Network Security Lecture 20

1. CMSC 414Computer and Network SecurityLecture 20 Jonathan Katz

2. Certificate authorities and PKI

3. Naming and certificates • Identifiers correspond to principals • Must uniquely identify the principal • (Real) names alone are not enough!

4. E.g., X.509 certificates • Distinguished names identify a principal • Series of fields, each with key and value • E.g. /O=University of Maryland/OU=College Park/OU=Computer Science/CN=J. Katz • “O” - organization; “OU” - organizational unit; “CN” = common name

5. Certificates • Certification authorities vouch for the identity of the principal to whom a certificate is issued • 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 CA can “act” as multiple CAs, each with their own policies…

6. Example: Verisign (1996) • Three levels of authentication • Verification of valid email address • Verification of name/address • Background check • Different authentication policies; same issuance policy (individuals) • Another issuance policy was for issuing certificates to web servers

7. Certificate infrastructure • Hierarchical structure of CAs • Nodes correspond to CAs • Children of a CA are constrained by the policies of their parents

8. Conflicts • What if a single CA issues certificates under different policies? • What if a CA issues a certificate tied to an email address, but the owner of this address changes? • What if two CAs have the same dist. name? • What if two different CAs issue certificates for the same distinguished name (to different principals)?

9. Easy solution • For organizational certificates, the last type of conflict can be prevented by incorporating CA name into distinguished name • Does not solve the other problems, in general…

10. Handling conflicts • Conflict detection database… • Before a PCA may issue a certificate to a CA, it checks for a conflict in the database • Sends a hash of the CAs dist. name, the CAs public key, and the dist. name of the PCA • If first two fields conflict with a database entry, the two PCAs must resolve the conflict • Note that this only ensures uniqueness of (DN, PK) pairs

11. Handling conflicts (in action) • Two CAs with same dist. name? • Will have different public keys… • Same CA with two different policies? • Will use different public keys for each

12. What does identity mean? • Ultimately, identity is proved using physical means • Driver’s license, fingerprints, etc. • If these are compromised, then certificates are irrelevant! • Certificate is just a binding between external identity and (DN, PK)

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

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

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

16. Trust • How much to trust a particular certificate? • Based on: • CA authentication policy • Rigor with which policy is followed • Assumptions inherent in the policy

17. Example… • Certificate issued based on a passport • Assumptions: • Passport not forged • Passport issued to the right person • Person presenting passport is the right person • CA actually checked the passport when issuing the certificate

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

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

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

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

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

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