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!”)
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
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 3 rd 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+validityintegrity+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
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 –CRL new =BaseCompleteCRL old + 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 T3 rd P
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 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 validationcertificate 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