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. PKI Name Constraints Bottom Up PKI model with two cross links (red) scu.edu cse.scu.edu scudc.scu.edu dc.engr.scu.edu hadram.cse.scu.edu ia.engr.scu.edu engr.scu.edu ucsc.edu cse.ucsc.edu ssrc.cse.ucsc.edu admissions.ucsc.edu soe.ucsc.edu

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 K AB. 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.