PKI

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