1. PKI Robin Burke ECT 582

2. Outline Discussion Review The need for PKI PKI hierarchical PKI networked PKI bridging Certificate policies rationale examples X.509 implementation

3. Review Private key cryptography shared secrets Public key cryptography proving identity Public key certificates trusting a certificate

4. Certificate trust Bob has a certificate signed by T saying that k is Alice's public key What does Bob need to convince him to trust T? Proof that the signature on the certificate was made by T Proof that T is not a front for Eve, or Proof that T is a trustworthy organization Proof that T's standard of proof for Alice's identity is appropriate

5. Hand-waving The CA's public key is "well-known" Why doesn't this work? Too many CAs Different public keys for different purposes How are keys published? New assumption Every user has their own certificate Every user has a relationship with some CA

6. Certification paths Basic idea root CA non-root CAs Really we mean root certificate non-root certificates signed by root or some other CA Certification path A path through hierarchy to a root CA

7. Path validation Certificate path is not included with the certificate just the signature of the issuing CA Path validation requires a directory where each link of the path can be retrieved Path validation is not just putting all the links together Inefficient path validation is the enemy of PKI

8. Path validation issues Verifying the digital signature and checking basic constraints Checking that the subject of every certificate is the issuer of the next certificate Checking the validity periods Checking that each certificate has not been revoked Checking the required certificate policies Checking name constraints

9. New problem How to organize multiple certification authorities? How to manage public keys/certificates on a large scale? Not just a technical problem legal changes business practice changes

10. Public key infrastructure A system of public key encryption using digital certificates from Certificate Authorities and other registration authorities that verify and authenticate the validity of each party involved in an electronic transaction. - FOLDOC

11. Hierarchical PKI Simplest case All certification paths start from the root CA Everyone absolutely trusts the top CA uses it as root CA Advantages Good scalability Easy to find certification path Unique certificate path for any end entity CA restrictions established by root Disadvantage: For commercial world, hard to identify a top CA A single point of failure

12. Example: Verisign

13. Forest (multi-root) PKI

14. How to manage? Combine hierarchical CA relationship, or peer-to-peer Multiple trust points

15. Hierarchical combination Back to hierarchical PKI Either Add a new master root Select one existing root as master

16. Combination

17. Problem Back to hierarchy

18. Peer-to-peer mesh CA CAs certify each other

19. Advantages Easy to establish Users don't have to change their trust relationships Resilient Compromise of one CA can't destroy network Other CA's revoke certificates

20. Disadvantages Certification paths difficult to compute possible loops, dead-ends could be as long as the number of CAs in mesh No controlling CA restrictions hard to establish / enforce

21. Multiple trust points Don't join trust hierarchies Accept multiple trusted entities Who makes this decision? user / administrator How is it accomplished? direct trust relationship cross-certification

22. Multi-rooted PKI

23. User-controlled direct IE model Multiple root certificates available To add a new one user must choose to trust or not Problem can the user make adequate trust decisions?

24. User-controlled cross- certification Lotus Notes model User acts as a mini-CA each trusted certificate signed by user Converts forest back to hierarchy Again, user has to make trust decisions

25. Domain-controlled SAP model As above but with an administrator installs trusted certificates, or acts as local CA Problem administrative overhead eventually enterprise is doing its own PKI

26. Multi-rooted Advantages Each CA forms a hierarchy Easy to add new hierarchies Disadvantages Not scalable Too many trust decisions

27. PGP Accepts X.509 certificates Also, has alternative to CA "web of trust" Model local key ring trust individuals as introducers levels of trust trusted untrusted case-by-case marginal multiple marginal introducers = 1 trusted

28. Advantages Simplicity Every user his own CA Free No contracts to sign Counter-cultural Multiple signers independent confirmation of identity

29. Disadvantages Certification standards Counter-cultural End user responsibility Technical Multiple signatures not part of X.509

30. Bridge CA Establish a CA just for the bridging function BCA establishes bi-directional trust with the root of each hierarchy cross-signed certificates

31. Bridge PKI

32. Advantages Doesn't matter what type of PKI are joining hierarchies can join with meshes Doesn't establish a new hierarchy with attendant political issues Bridge is not a single point of failure if bridge is compromised, joining CAs revoke their certification bridging must be restablished, but CAs still function independently Bridge adds only minimally to the certification path p1 + p2 + 2 hard to see how to do better

33. Disadvantages New entity (BCA) must be established sufficiently trusted by root CAs

34. Example Federal Bridge Certification Authority Original plan hierarchical CA infighting about who would control the root Meanwhile federal agencies developed separate PKIs need to integrate Development of Bridge CA (2003) now different agencies can communicate securely

35. Break

36. Trusted Third Party The CA is a trusted third party How do we come to trust the CA? published practices how the business operates independent audit fourth party verification of conformance statement of liability assumption of liability for non- performance

37. CPS "Certification Practice Statement" Documentation of internal practices used in CA Many dimensions technical personnel insurance procedures Example on line

38. Certificate policy CPS usually sets forth different types of certificates conditions under which those certificates will be issued relevant certificate policy IDs X.509 OID pertinent extensions

39. Certificate Policies Requirements for various secure transactions usually community-defined Different CAs may issue certificates in accordance with the policy Application software can recognize a key appropriate for a particular task

40. Examples Procurement Under $100 Under $5000, etc. Inter-library loan General loan Reference/Periodical Music Low-quality download High-quality download

41. Components of policy key usage security level

42. Key Usage signature non-repudiation key encipherment data encipherment key agreement certificate signing CRL signing

43. Security level Two factors how secure the private key is how thoroughly the identity of the holder is verified

44. Levels of Assurance Test interoperability testing between the FBCA and Principal CAs. Rudimentary lowest degree of assurance concerning identity of the individual. Data integrity only Risk low No for authentication, confidentiality Basic basic level of assurance Risk low May be used to secure private information Medium Transactions having substantial monetary value or risk of fraud Access to private information where likelihood of malicious access is substantial High Consequence of failure are high, or risk is high High-value transactions -- FBCA

45. Documentation standards Test None Rudimentary email address only Basic in-person appearance or data comparison against trusted DB or attestation of authorized agent Medium in-person appearance information shall be verified pre-existing relationship may suffice (employee documents) one Federal Gov't issue photo ID (passport/green card), or State photo ID (drivers license) plus one other form of ID High same as Medium but in-person appearance required

46. Key protection standards Test, Rudimentary, Basic software OK Medium hardware preferred High hardware only tamper-evident hardware preferred

47. X.509 Implementation A policy has a OID Book example: {joint-iso-itu-t (2) country (16) us (840) organization (1) sharons (15678) policies (4) general- use (2)} A policy is either critical or not critical

48. Examples Certificate profile outline of certificate contents Certificate Data format

49. Midterm take-home due 9 pm 2/4 no class

50. Midterm, cont'd 3 questions Signature protocol Attacks Infrastructure