CMSC 414 Computer and Network Security Lecture 25

1. CMSC 414Computer and Network SecurityLecture 25 Jonathan Katz

2. Certificate authorities and PKI

3. PKI overview • 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. PKA PKB Certificates • One party can vouch for the public key of another • Cert(AB) = SignSKA(“B”, PKB, info) • “info” can contain 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

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

6. Usage of certificates • “Trust anchors” = set of public keys already known (and trusted to certify others) • How to obtain certificates? • Some possibilities: • B “collects” certificate(s) for itself, sends these 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

7. PKI components • Certificates • Distributing the keys of the “trust anchors” • CAs • Revocation • (Means for retrieving certificates) • (Naming conventions) • (Trust model/method for evaluating a certificate chain)

8. 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 CA can “act” as multiple CAs, each with their own policies… • Use distinct public keys (with different security)

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

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

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

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. Trust • How much to trust a particular certificate? • Based on: • CA authentication policy • Rigor with which policy is followed • Assumptions inherent in the policy • Security of CA’s secret key

14. Trust models • Define: • Valid trust anchors, • How a verifier chooses trust anchors • What certification paths create a legal chain from trust anchor to target

15. Monopoly model • A single CA certifies everyone • Drawbacks • Single point of failure • Not very convenient • Complete monopoly… • In practice, monopoly model not used globally but may be used within an 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 • Certainly 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. CA hierarchy • Hierarchical structure of CAs • Nodes correspond to CAs • Children of a CA are constrained by the policies of their parents

19. Conflicts • What if two different CAs issue certificates for the same distinguished name (but to different principals)? • An easy way to address these is to have hierarchical names for CAs, and to incorporate CA distinguished name into issued certificates

20. 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 users be tricked into using “bad” trust anchors? • Issuer name may be bogus • Can public keys of “good” trust anchors be changed in the software?

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

22. PKI in practice • PKIs are implemented in web browsers • 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? • PGP “web of trust” model • PGP keyserver

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

24. 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 CRL before verifying a certificate • Using “delta CRLs” improves efficiency

25. OLRS • “On-line revocation server” • Verifier queries an OLRS to find out if a certificate is still valid • OLRS somewhat mitigates advantages of public-key model • 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 the target that its certificate is valid at a certain time

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

27. Self revocation • Sign a message revoking your own public key; propagate throughout the network • This is essentially how revocation is done in the web of trust model • Deposit revocation into keyserver

28. Intrusion detection

29. Prevention vs. detection • Firewalls (and other security mechanisms) aim to prevent intrusion • IDS aims to detect intrusion in case it occurs • Use both in tandem! • Defense in depth • Full prevention impossible • The sooner intrusion is detected, the less the damage • IDS can also be a deterrent, and can be use to detect weaknesses in other security mechanisms

30. IDS overview • Goals of IDS • Detection and response • Deterrence • Recovery • Defense against future attacks • Two classes of behavior to be detected • Illegal access by outsiders • Illegal access by insiders

31. IDS tradeoff • IDS based on the assumption that attacker behavior is (sufficiently) different from legitimate user behavior • In reality, there will be overlap • Some legitimate behavior may appear malicious • Intruder can attempt to disguise their behavior as that of an honest user

32. False positives/negatives • False positive • Alarm triggered by acceptable behavior • False negative • No alarm triggered by illegal behavior • Always a tradeoff between the two… • Note: credit card companies face the same tradeoff