1 / 25

CMSC 414 Computer and Network Security Lecture 18

CMSC 414 Computer and Network Security Lecture 18. Jonathan Katz. Administrative. Exam April 22 Based on material through April 15 Next HW out later today, will be Exercises rather than a project One more project (buffer overflows) later in the semester. WireShark demonstration.

ivana-avila
Download Presentation

CMSC 414 Computer and Network Security Lecture 18

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CMSC 414Computer and Network SecurityLecture 18 Jonathan Katz

  2. Administrative • Exam April 22 • Based on material through April 15 • Next HW out later today, will be Exercises rather than a project • One more project (buffer overflows) later in the semester

  3. WireShark demonstration • NYTimes sends the password in the clear • View SSL/TLS session • Old (insecure) Yahoo! email authentication

  4. Certificate authorities and PKI

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

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

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

  8. 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 I already know

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

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

  11. CAs and certificates • A certificate authority (CA) is just 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)

  12. 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 only) • Another issuance policy was for issuing certificates to corporations/web servers

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

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

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

  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. Trust models • Define valid trust anchors, how a verifier chooses trust anchors, and what certification paths create a legal chain from trust anchor to target

  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 • 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 • (Note: delegation can be incorporated into other models as well)

  21. CA hierarchy • Hierarchical structure of CAs • Nodes correspond to CAs • Children of a CA are constrained by the policies of their parents

  22. Conflicts • What if two CAs have the same distinguished name? • 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

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

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

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

More Related