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 cryptographyshared secrets

Public key cryptographyproving identity

Public key certificatestrusting 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 problemlegal changesbusiness 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

C1

Alice Bob

C2

Carol

C3

Dave

How to manage?

Combinehierarchical CA relationship, orpeer-to-peer

Multiple trust points

Hierarchical combination

Back to hierarchical PKI Either

Add a new master rootSelect one existing root as master

Combination

C1

Alice Bob

C2

Carol

C3

Dave

CM

C1

Alice Bob

C2

Carol

C3

Dave

Problem

Back to hierarchy

Peer-to-peer

mesh CA CAs certify each other

C1

Alice Bob

C2

Carol

C3

Dave

Advantages

Easy to establishUsers 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 computepossible loops, dead-endscould 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 hierarchiesAccept multiple trusted entities

Who makes this decision?user / administrator

How is it accomplished?direct trust relationshipcross-certification

Multi-rooted PKI

C1

Alice Bob

C2

Carol

C3

Dave

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, oracts as local CA

Problemadministrative overhead

• eventually enterprise is doing its own PKI

Multi-rooted

AdvantagesEach CA forms a hierarchyEasy to add new hierarchies

DisadvantagesNot scalableToo 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

SimplicityEvery user his own CA

FreeNo 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 CAjust for the bridging function

BCA establishes bi-directional trustwith the root of each hierarchycross-signed certificates

Bridge PKI

C1

Alice Bob

C2

Carol

C3

Dave

BCA

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 establishedsufficiently 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 usuallysets forth different types of certificatesconditions under which those

certificates will be issuedrelevant certificate policy IDs

• X.509 OID

pertinent extensions

Certificate Policies

Requirements for various secure transactionsusually 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 factorshow secure the private key ishow 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 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

Key protection standards

Test, Rudimentary, Basicsoftware OK

Mediumhardware preferred

Highhardware onlytamper-evident hardware preferred

X.509 Implementation

A policy has a OIDBook example: {joint-iso-itu-t (2)

country (16) us (840) organization (1) sharons (15678) policies (4) general-use (2)}

A policy is eithercritical ornot critical

Examples

Certificate profileoutline of certificate contents

CertificateData format

Midterm

take-home due 9 pm 2/4 no class

Midterm, cont'd

3 questionsSignature protocolAttacksInfrastructure