Скачать презентацию Public Key Infrastructures Gene Itkis itkis bu edu Based Скачать презентацию Public Key Infrastructures Gene Itkis itkis bu edu Based

96543a94008a5b4fa79f623ff5e39e77.ppt

  • Количество слайдов: 60

Public Key Infrastructures Gene Itkis itkis@bu. edu Based on “Understanding PKI” by Adams & Public Key Infrastructures Gene Itkis itkis@bu. edu Based on “Understanding PKI” by Adams & Lloyd

What and How? What and How?

Services ¨ Secure communication ¨ Notarization ¨ Time-Stamping ¨ Non-Repudiation ¨ Privilege Management – 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 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 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 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

Certificates ¨ Introduced in 1978 [Kohnfelder’s Bachelor’s thesis] ¨ X. 509 – “the standard” Certificates ¨ Introduced in 1978 [Kohnfelder’s Bachelor’s thesis] ¨ X. 509 – “the 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 – 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 x 509

X. 509 Certificate Format ¨ See [AL] pg. 76 X. 509 Certificate Format ¨ See [AL] pg. 76

Certificate Validation ¨ Integrity: signature is valid ¨ Signed by a trusted CA – 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 Alternatives to X. 509 Brief detour

SPKI – A Simple PKI ¨ Authorization certificates ¨ Delegation ¨ SDSI – a 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 PGP – Pretty Good Privacy ¨ Tendencies – Email • Incompatibilities between PGP and S/MIME • Open. PGP v 6. 5 supports x 509 certs, but still… – Personal (rather than corporate)

SET – Secure Electronic Transaction ¨ Credit card payment protocol ¨ Adopts and extends SET – Secure Electronic Transaction ¨ Credit card payment protocol ¨ Adopts and extends X. 509 – See [AL] pg. 84

Back to X. 509 End detour Back to X. 509 End detour

Infrastructure: Policies and Authorities Infrastructure: Policies and Authorities

Certificate Policies ¨ Certificate Policy – “high level what is supported” document ¨ CPS 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 – 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/ 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 – Veri. Sign, Equifax, Entrust, Cyber. Trust, Identrus, … ¨ Trust is the key word

RA – Registration Authority ¨ Also called LRA – Local RA ¨ Goal: Off-load 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 PKI management

Key & Certificate Management Key/Certificate Life Cycle Management – Identity Key. Focus on Key! 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 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 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 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 Certificate Creation+Distribution ¨ Creation – CA only ¨ Distribution (to the owner) – Certificate only – Certificate + private key • Deliver key securely! – X 509 rfc 2510 – Direct to owner – To depository – Both

Certificate dissemination ¨ Out-of-band ¨ Public repositories – LDAP-like directories – Used mostly for 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 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 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 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 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

Certificate Revocation ¨ Requested by – Owner, employer, arbiter, TTP, ? ? ? , 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 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 x 509 v 1) – Flaws: • Scalability CRL versions ¨ Version 1 (from x 509 v 1) – Flaws: • Scalability • Not extendable • Can replace one CRL with another ¨ Version 2 (similar to x 509 v 3) – 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 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 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 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=Base. Complete. Delta CRL ¨ Incremental change – From Complete or Partition CRL – CRLnew=Base. Complete. CRLold + Delta. CRL – Possibly many Delta. CRLs from same Base. CRL • E. g. complete CRL issued once a week, and a new Delta. CRL (containing the previous Delta. CRLs) issued every day

Indirect CRL ¨ Combines CRLs of many CAs – Potentially a “for fee” service Indirect CRL ¨ Combines CRLs of many CAs – Potentially a “for fee” service by T 3 rd. P

Certificate Revocation Trees – Valicert [Kocher] – Based on Merkle’s hash trees – Similar/Relevant 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 models

Trust model issues ¨ Who to trust? – Which certificates can be trusted ¨ 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 ¨ Common Trust Models ¨ CA Hierarchy ¨ Distributed ¨ Web ¨ User-centric Tool ¨ Cross-certification

Trust – definition(? ? ) ¨ “A trusts B = A assumes B will 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 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 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 Context is important ¨ Privacy Enhanced Mail (PEM) adopted strict hierarchy of CAs approach and failed ¨ Do. D could use hierarchy fine

Distributed Trust Architecture ¨ A set of independent hierarchies – May evolve as independent 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 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 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 Cross-Certification ¨ Mechanism: – Certificates for CAs (not end-entities) ¨ Intra- vs. Inter- domain ¨ One or two directions – CA 1 certifies CA 2 and/or CA 2 certifies CA 1 ¨ 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 Entity Naming ¨ What’s the identity? (the one bound by certificate to the PK [+sk]) – If a certificate is issued to “Geo. Trust ”, 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 – 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 Names (continued) ¨ So, how useful are names? – SDSI, SPKI, etc – not very – X. 509 allows alternative names • Extensions subject. Alt. Name • 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” CA 1 – Alice has CA 1’s PK in Certificate Path ¨ Alice “trusts” CA 1 – Alice has CA 1’s PK in its browser • CA 1’s PK = “trust anchor” – “trust anchor” depends on the model ¨ CA 1 certifies CA 2; CA 2 certifies CA 3 ¨ CA 3 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 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 – 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 Multiple Certificates per Entity