PKI by Gene Itkis

50 %
50 %
Information about PKI by Gene Itkis

Published on March 4, 2014

Author: natemiller67



PKI by Gene Itkis

Public Key Infrastructures Gene Itkis 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 ♦ 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 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

Add a comment

Related presentations

Related pages

Gene Itkis | LinkedIn

View Gene Itkis's professional profile on LinkedIn. LinkedIn is the world's largest business network, helping professionals like Gene Itkis discover inside ...
Read more

Forward Security - Computer Science

Forward Security Adaptive Cryptography: Time Evolution Gene Itkis? Computer Science Department Boston University Abstract. We survey the development of ...
Read more

Mid-term Review - Computer Science

Mid-term Review Network Security ...
Read more

Public Key Infrastructures - Boston University powerpoint ...

Download Public Key Infrastructures - Boston University powerpoint ... Public Key Infrastructures Gene Itkis Based on “Understanding PKI ...
Read more

CiteSeerX — Citation Query Securing Bulk Content Almost ...

CiteSeerX - Scientific documents that cite the following paper: Securing Bulk Content Almost for Free
Read more

Ppt Infrastructures | Powerpoint Presentations and Slides ...

Public Key Infrastructures - Computer Science PPT. Presentation Summary : Public Key Infrastructures Gene Itkis Based on “Understanding PKI ...
Read more

Public Key Infrastructure: A Tutorial - Department Of ...

Public Key Infrastructure: A Tutorial - Department Of ... Public Key Infrastructures Gene Itkis Based on “Understanding PKI” by ...
Read more

Forward security, adaptive cryptography: Time evolution (2004)

Forward security, adaptive cryptography: Time evolution (2004) Cached. ... by Gene Itkis Citations: 6 - 0 self: Summary; Active Bibliography; Co-citation ...
Read more