1 / 33

COEN 350

COEN 350 . Public Key Infrastructure. PKI. Task: Securely distribute public keys. Certificates. Repository for retrieving certificates. Method for revoking certificates. Method of evaluating a chain of certificates from public keys that are known and trusted in advance (TRUST ANCHOR). PKI.

devi
Télécharger la présentation

COEN 350

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. COEN 350 Public Key Infrastructure

  2. PKI • Task: Securely distribute public keys. • Certificates. • Repository for retrieving certificates. • Method for revoking certificates. • Method of evaluating a chain of certificates from public keys that are known and trusted in advance (TRUST ANCHOR).

  3. PKI • Certificate • A message signed by someone that vouches for someone else’s public key. • {Alice’s public key is 891234567}Bob • Encrypted with Bob’s private key. • If you trust that you have Bob’s public key, and if you trust Bob, then you now trust your new knowledge of Alice’s public key. • Chain of certificates: • {Carol’s key is 901234567}Damian {Bob’s public key is 7890123456}Carol  {Alice’s public key is 891234567}Bob

  4. PKI • Alice signs a certificate vouching for Bob’s name and key: • Alice is the Issuer. • Bob is the Subject. • Alice is verifying a chain of certificates: • Alice is the verifier / relying party. • Anything with a public key is a principal. • A Trust Anchor is a public key that the verifier has decided to trust.

  5. PKI Trust Model • Monopoly • Everyone trust a single organization to be the only CA in the world. • The key of that CA is embedded in all software and hardware as the PKI trust anchor.

  6. PKI Trust Model • Monopoly • There is no universally trusted entity. • How can the CA key ever be changed? • CA needs to establish a trust relationship with you before it can give you a public key. • Monopolist would have exclusive control. • CA’s protection would be paramount.

  7. PKI Trust Model • Monopoly plus Registration Authorities (RA) • Single monopoly CA chooses RAs to securely check identities and obtain and vouch for public keys. • RAs securely send certification requests to CA. • CA issues a certificate because it trusts the RAs.

  8. PKI Trust Model • Monopoly with delegated CAs • Single trust anchor CA certifies other CAs. • Single trust anchor vouches for their public keys. • Single trust anchor vouches for their trustworthiness. • Users obtain certificates from any CA.

  9. PKI Trust Model • Oligarchy • Model used in browsers. • A number of organizations set themselves up as trust anchors. • Chances that one of these is corrupted is higher than the chance that a single trust anchor is corrupted. • Product vendor selects amongst them.

  10. PKI Trust Model • Oligarchy • Model makes it easier to dupe users into accepting a trust anchor. • Even knowledgeable users will have a hard time checking the 80+ trust anchors in a current browser.

  11. PKI Trust Model • Anarchy • Used by PGP. • Each user is responsible for configuring some trust anchors themselves. • Meeting people who hand out there PGP fingerprint (a PGP hash of the public key) and send their public key in an email message. • Search through public databases to find a path from one trust anchor to the key you want. • But you implicitly trust everyone on that path!

  12. PKI Name Constraints • Trustworthiness of PKI is not a binary value. • Trust MIT CA (run by undergrads) with MIT student public key, but not with the key of Washington officials.

  13. PKI Name Constraints • Hierarchical names “tschwarz@cse.ucsd.edu” allow name based policies. • Trust the cse CA for tschwarz. • Trust the ucsd CA for cse. • Trust the edu domain for edu. • Allows users to use the same public keys for many different identities: tjschwarz@scu.edu, tschwarzsj@calprov.org, …

  14. PKI Name Constraints • Top-Down with Name Constraints • CAs cannot change keys but at the lowest level. • Like Monopoly with delegated CA. • Delegates are restricted to part of the name hierarchy.

  15. PKI Name Constraints • Bottom-Up with Name Constraints • Each organization can create its own PKI and link it to others. • Parent certifies child (downlink), but child certifies parent as well (uplink). • Crosslinks are links from one node to another one.

  16. scu.edu ucsc.edu cse.scu.edu scudc.scu.edu engr.scu.edu cse.ucsc.edu admissions.ucsc.edu soe.ucsc.edu hadram.cse.scu.edu dc.engr.scu.edu ia.engr.scu.edu ssrc.cse.ucsc.edu PKI Name Constraints Bottom Up PKI model with two cross links (red)

  17. PKI Name Constraints • Even with a single cross-link from one tree into the other, we can establish a path from all nodes of the first tree to all of the other. • Maintaining cross-links can be expensive. • Root service providers can provide these cross-links (for a fee).

  18. PKI Name Constraints • Relative Names • Implement PKI bottom-up model with relative names. • Works for file systems. • Open to research. • Name constraints in certificates. • PKIX implements a Name Constraints field • Allows the issuer to specify what names the subject is trusted to certify.

  19. PKI: Certificate Revocation • Revocation is necessary • Key is stolen. • Someone leaves an organization. • Certificates have therefore expiration dates. • Verisign offered cheap certificates for short lifeterms (1-2 years). • Afterwards, Verisign hiked the prices. • Browsers were not checking expiration dates. • Many system administrators noticed that and did not renew their Verisign certificates. • Browsers now don’t want to enforce the expiration dates because of the many expired certificates.

  20. PKI: Certificate Revocation • Certificate Revocation List (CRL) • Signed list of all revoked certificates. • Timestamped (WHY?) • Delta CRL • First valid certificate: • No expiration date. However, certificates before a certain serial number can be declared invalid. • OLRS (On line revocation server). • Worst damage is that a revoked certificate is valid.

  21. PKI: Certificate Revocation • Bad list • Serial numbers of all bad certificates. • Good list • Serial numbers of all good certificates. • Slightly more secure: • A CA operator could be bribed to issue a certificate with a serial number from a valid certificate. • The good list can detect the bogus certificate if it contains the serial number together with a cryptographic hash of the signature.

  22. PKI and Directories • Directories can facilitate PKI, just as they work for DNS. • Each entity is listed by name (tjschwarz@scu.edu) • Associated with each name are data • IP address • Certificates it signed • Certificates by others regarding it. • Functionality can range from mere look-up (DSN) to query answering.

  23. PKI • Storage of certificates • With issuer • With subject • Speed and ease of revocation favor storing with issuer. • Speed and ease of usage favor storing with subject.

  24. X.509 • X.500 is an ITU-T recommendation for a directory service. • Directory is a server or a distributed set of servers that maintain a database of information about users. • This includes a mapping from user name to network address. • X.509 is a framework for authentication servers for X.500.

  25. X.509 • Certificate structure: • version • serial number • signature algorithm ID • issuer name • validity period • subject (user) name • subject public key information • issuer unique identifier (version 2 and 3 only) • subject unique identifier (version 2 and 3 only) • extensions (version 3 only) • signature on the above fields

  26. X.509 • X.509 has currently three versions • The X.509 standard is supported by • PEM • PKCS • S-HTTP • SSL.

  27. X.509 • Revocation of Certificates • Each certificate has a period of validity. • CRL is posted to the directory signed by the issuer and includes • The issuer’s name. • The date the list was created. • The date the next CRL is going to come out. • Each entry contains • Serial number of certificate • Revocation date.

  28. X.509 • Authentication Procedure • One-way authentication • A to B: • Timestamp. • Nonce. (which B has to store for a while to prevent replay attacks.) • Identity of B. • Signed with A’s private key.

  29. X.509 • Authentication Procedure • Two-way authentication • Message from A to B: • Timestamp. • Nonce. • Identity of B. • Signed with A’s private key. • Message from B to A: • Timestamp. • Nonce from B. • Identity of A. • Previous nonce from A. • Signed with B’s private key.

  30. X.509 • Authentication Procedure • Three-way authentication • Message from A to B: • Timestamp. • Nonce. • Identity of B. • Signed with A’s private key. • Message from B to A: • Timestamp. • Nonce from B. • Identity of A. • Previous nonce from A. • Signed with B’s private key. • Message from A to B: • Signed copy of previous nonce from B. • No longer necessary to keep nonces around.

  31. X.509 • X.509 authentication also allows the exchange of a session key KAB. • A sends along the session key encrypted with B’s public key.

  32. PKI: PKIX • PKIX is a profile of X.500. • Decides which options of X.50x are implemented.

  33. Further details in COEN 351.

More Related