1 / 50

PKI

PKI. Robin Burke ECT 582. Outline. Discussion Review The need for PKI PKI hierarchical PKI networked PKI bridging Certificate policies rationale examples X.509 implementation. Review. Private key cryptography shared secrets Public key cryptography proving identity

chelsa
Download Presentation

PKI

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

More Related