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 Public key certificates trusting a certificate

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

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

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

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

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

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

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

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

Example: Verisign

Forest (multi-root) PKI

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

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

Combination

Problem Back to hierarchy

Peer-to-peer mesh CA CAs certify each other

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

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

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

Multi-rooted PKI

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?

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

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

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

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

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

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

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

Bridge PKI

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

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

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

Break

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

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

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

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

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

Components of policy key usage security level

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

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

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

Documentation standards Test None Rudimentary 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

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

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

Examples Certificate profile outline of certificate contents Certificate Data format

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

Midterm, cont'd 3 questions Signature protocol Attacks Infrastructure