Docstoc

Public Key Infrastructures

Document Sample
Public Key Infrastructures Powered By Docstoc
					Public Key Infrastructures

Gene Itkis
itkis@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            • Generation

 Issued (active)           • Issuance

 Cancellation              • [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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:6/21/2013
language:English
pages:60
vivien renata vivien renata
About