PKI by Gene Itkis

Public Key Infrastructures

Gene Itkisitkis@bu.edu

Based on “Understanding PKI” by Adams & Lloyd

What and How?

Services

Secure communication Notarization Time-Stamping Non-Repudiation Privilege Management

– Authorization & Authentication– Authorization & Policy Authorities– Delegation

• Blind vs. Auditable

PKI and the Services

CLAIM: PKI can help in all Question (subjective – GI)

– Where is the source of trust in all these?– Suggestion (subjective – GI)

• Try to do the same without PKI, using only symmetric techniques (usually possible!); find the problem; see how this problem is manifested and addressed in the PKI solution.

• Easier to “cheat” (including yourself!) with PKI. Symmetric techniques are more explicit.

Make all the security & trust assumptions explicit!

Mechanisms

Crypto– Signatures, hash, MAC, ciphers

Infrastructure– Tickets– Certificates– Authorities (Trusted Third Parties)

• Ticket Granting, Key Distribution• Certificate, Policy, Authorization,Time, Notary, etc.• Archives

Pitfalls Security breaches

– Key compromises Inherent difficulties

– Revocation Negligence

– Certificates are routinely not checked or some of the attributes ignored

– Alarms and warnings ignored (“certificate not valid. Press OK to proceed.”)

Inconsistencies & human factors(“that’s not what I meant by this policy!”)

Certificates

Certificates

Introduced in 1978[Kohnfelder’s Bachelor’s thesis]

X.509 – “the standard standard” today– v.1 (1988) – not extendable– v.2 – not much better– v.3 (1997) is much better – optional extensions

Today, X.509=v.3– Many other standards extend X.509

Others– PGP, SPKI, etc.

Certificates

Certificates Signature– Certificates are implemented using Signatures

Certificates Authentication– Authentication can be implemented using

Certificates– Same for Authorization, etc.

Certificates are static– Change => Re-Issue

• *This could be challenged, but not in standard x509

X.509 Certificate Format

See [AL] pg.76

Certificate Validation

Integrity: signature is valid Signed by a trusted CA

– or certification path is rooted in a trusted CA

Certificate is valid now: – We are between Not Valid Before and Not Valid

After time points in the certificate

Not Revoked Use is consistent with the policy

Alternatives to X.509

Brief detour

SPKI – A Simple PKI

Authorization certificates Delegation SDSI – a Simple Distributed Security

Infrastructure Question #1:

it may be very nice, but will it ever be used by anyone?

PGP – Pretty Good Privacy

Tendencies– Email

• Incompatibilities between PGP and S/MIME

• OpenPGP v6.5 supports x509 certs, but still…

– Personal (rather than corporate)

SET – Secure Electronic Transaction

Credit card payment protocol Adopts and extends X.509

– See [AL] pg.84

Back to X.509

End detour

Infrastructure:Policies and Authorities

Certificate Policies

Certificate Policy– “high level what is supported” document

CPS – Certification Practice Statement– “detailed, comprehensive, technical how policy

is supported” document

No agreement on the roles and meanings of the above

Might be not public; hard to enforce

Certificate Policies

Distinguished by OIDs (Object ID)– “form letters”

Equivalences– Policy Mapping ext. declare policies equivalent

Established & registered by Policy [Management] Authorities– Internal – e.g. corporate – External – community

CA – Certification Authority

Issuer/Signer of the certificate– Binds public key w/ identity+attributes

Enterprise CA Individual as CA (PGP)

– Web of trust

“Global” or “Universal” CAs– VeriSign, Equifax, Entrust, CyberTrust, Identrus, …

Trust is the key word

RA – Registration Authority

Also called LRA – Local RA Goal: Off-load some work of CA to LRAs Support all or some of:

– Identification– User key generation/distribution

• passwords/shared secrets and/or public/private keys

– Interface to CA– Key/certificate management

• Revocation initiation• Key recovery

PKI management

Key & Certificate Management

Key/Certificate Life Cycle Management– Identity Key. Focus on Key!

Stages Initialization Issued (active) Cancellation

• Generation

• Issuance

• [Usage]

• Cancellation

Initialization Registration

– Via RA– Identity verification

• According to CP/CPS docs– If on-line, should be protected+authenticated (?)(?)– Secret shared by user and CA

• New or pre-existing relationship

Key pair generation Certificate creation & delivery [Key backup]

Key pair generation Where? (by who?)

– CA– RA– Owner (e.g. within browser)– Other Trusted 3rd Party

What for?– Non-repudiation owner generation

Dual key pair model– Separate key pairs for authentication,

confidentiality, etc.

Key pair generation Performance

– Laptop, smart cards – used to be too slow• Today – many smart cards can generate own keys

– Centralized generation • Scalability: bottleneck for performance & security

Assurance– “Is the smart card’s random number generator

good enough?”– Minimal security requirements guarantees

Legal/Liabilities– Who to sue? Who backs up above assurances?

Certificate Creation+Distribution

Creation – CA only Distribution (to the owner)

– Certificate only– Certificate + private key

• Deliver key securely!– X509 rfc2510

– Direct to owner– To depository– Both

Certificate dissemination

Out-of-band Public repositories

– LDAP-like directories– Used mostly for confidentiality

In-band– E.g. signed e-mail usually carries certificate

Issues:– Privacy, scalability, etc.

Key backup

Backup Escrow– Backup= only owner can retrieve the (lost) key– Escrow= organization/government can retrieve

the key even against owner’s wish

Non-repudiation conflicts with Backup

Where & how to backup securely???

Issued Phase

Certificate retrieval– To encrypt msg or verify signature

Certificate validation– Verify certificate integrity+validity

Key recovery– Key backup – automate as much as possible

Key update– When keys expire: new certificate [+new keys]

Certificate Cancellation

Certificate Expiration– Natural “peaceful” end of life

Certificate Revocation– Untimely death, possibly dangerous causes

Key history– For owner: eg to read old encrypted msgs

Key archive– “For public”: audit, old sigs, disputes, etc.

Certificate Expiration

No action Certificate renewal

– Same keys, same cert, but new dates– Preferably automatic– but watch for attributes change!

Certificate update– New keys, new certificate

Certificate Revocation

Certificate Revocation

Requested by– Owner, employer, arbiter, TTP, ???, …

Request sent to – RA/CA

Mechanisms for Revocation checks– Certificate Revocation Lists (CRLs)– On-line Certificate Status Protocol (OCSP)

• Will it live? (SCVP)

Revocation delay– According to Certificate Policy

Publication Mechanisms

Complete CRLs Authority Revocation Lists (ARLs) CRL distribution points (partition CRLs) Delta CRLs Indirect CRLs Enhanced CRL distribution points &

Redirect CRLs Certificate Revocation Trees (CRTs)

White lists vs Black lists

CRL versions

Version 1 (from x509 v1)– Flaws:

• Scalability

• Not extendable

• Can replace one CRL with another

Version 2 (similar to x509 v3)– Extensions

• critical and non-critical

• Per-CRL and per-entry

– Format: see [AL] pg.112

Complete CRLs

Advantage:– Self-contained, simple, complete

Problems:– Scalability

• CRL may grow too big

– Timeliness• Also results from CRL size

Conclusion: appropriate for some domains

Authority Revocation Lists

ARL = CRL for Cas– Revokes certificates of Cas– Rarely needed/used

• Decommissioned

• Compromised

CRL Distribution Points

Partition CRL into smaller chunks Static partitions:

– Certificate points to its CRL distribution point

Dynamic partitions– Enhanced/Redirect CRL DPs

• Certificate points to a Redirect CRL

• Redirect CRL directs to the proper CRL partition

Delta CRL

Incremental change – From Complete or Partition CRL

– CRLnew=BaseCompleteCRLold + DeltaCRL

– Possibly many DeltaCRLs from same BaseCRL• E.g. complete CRL issued once a week, and a new

DeltaCRL (containing the previous DeltaCRLs) issued every day

Indirect CRL

Combines CRLs of many CAs– Potentially a “for fee” service by T3rdP

Certificate Revocation Trees

– Valicert [Kocher]– Based on Merkle’s hash trees– Similar/Relevant work: [Micali; Naor&Nissim]

Construct hash-tree; leaves – certificates Sign root To verify a certificate in the tree: path from

the certificate to root + the siblings Certificate Owner can offer proof of not

being revoked as of the current CRT date!

Trust modelsTrust models

Trust model issues

Who to trust?– Which certificates can be trusted

Source of Trust– How it is established?

Limiting/controlling trust in a given environment

Common Trust Models

CA Hierarchy Distributed Web User-centric

Tool Cross-certification

Trust – definition(??) “A trusts B = A assumes B will behave

exactly as A expects”– Problem 1: A expects B to try every way of

cheating A that B can find, and A assumes B will do exactly that == A trusts B?

– Problem 2: Is it a tautology? What’s the difference between “assumes” and “expects”?

X trusts a CA = X assumes CA will establish and maintain accurate binding of attributes and PK’s – Maintain? Includes secure the binding, CA’s

keys binding, security, etc…

Trusted Public Key

PK is trusted by X when X is convinced the PK corresponds to SK which legitimately and validly belongs only to a specific named entity

CA Hierarchy

Tree architecture Single Root CA

– Number of subordinate CA’s• Etc…

– Parent certifies children– Leaves are non-CA (end-) entities

Typically CA either certifies other CA’s or end-entities, but not both

Everyone has Root CA PK

Context is important

Privacy Enhanced Mail (PEM) adopted strict hierarchy of CAs approach and failed

DoD could use hierarchy fine

Distributed Trust Architecture

A set of independent hierarchies– May evolve as independent historically

Cross-certification or PKI networking– Connect the hierarchies

Fully-meshed – all CAs are cross-certified Hub & spokes or bridge CA

– Not= Hierarchy• No root CA: every end-entity holds its CA PK

Web Model

A bunch of root CAs pre-installed in browsers

The set of root CAs can be modified– But will it be?

Root CAs are unrelated (no cross-certification)– Except by “CA powers” of browser

manufacturer– Browser manufacturer = (implicit) Root CA

User-Centric

PGP User = her own Root CA

– Webs of trust

Good – User fully responsible for trust

Bad– User fully responsible for trust– Corporate/gov/etc. like to have central control

• User-centric not friendly to centralized trust policies

Cross-Certification

Mechanism:– Certificates for CAs (not end-entities)

Intra- vs. Inter- domain One or two directions

– CA1 certifies CA2 and/or CA2 certifies CA1

Control– Cross-certificate limits trust

• Name, policy, path length, etc. constraints

Entity Naming

What’s the identity? (the one bound by certificate to the PK [+sk])– If a certificate is issued to “GeoTrust ”, rather

than “Geotrust”, you may be talking to a different entity than what you think

Name Uniqueness

X.500 Distinguished Name (DN)– Tree of naming authorities– X.509 Subject is a DN; – IP addresses, email, etc. are similar

Problems– Not too user-friendly– Central naming authority not always there

• => lots of cooperation required from participating entities

Names (continued)

So, how useful are names?– SDSI, SPKI, etc – not very– X.509 allows alternative names

• Extensions subjectAltName• If this extension is used Subject name (DN) is not

required

– Global uniqueness – not always crucial– Piggy-back on existing naming/identity

infrastructures

Certificate Path

Alice “trusts” CA1– Alice has CA1’s PK in its browser

• CA1’s PK = “trust anchor”– “trust anchor” depends on the model

CA1 certifies CA2; CA2 certifies CA3 CA3 certifies Bob => Alice “trusts” Bob

– Alice associates PK in Bob’s certificate with Bob

Certificate Path Processing

Path construction– Aggregation of necessary certificates

Path validation– Checking the certificates and the keys

• Includes all steps of certificate validation

Path Construction

“Just a [Shortest] Path graph algorithm” Not so simple – graph is not known

– Edges (certificates) need to be queeried

Once Path Construction is done Path Validation is straight-forward

Multiple Certificates per Entity