public key infrastructures l.
Skip this Video
Loading SlideShow in 5 Seconds..
Public Key Infrastructures PowerPoint Presentation
Download Presentation
Public Key Infrastructures

Loading in 2 Seconds...

play fullscreen
1 / 60

Public Key Infrastructures - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Public Key Infrastructures' - vesta

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
public key infrastructures

Public Key Infrastructures

Gene Itkis

Based on “Understanding PKI” by Adams & Lloyd

  • Secure communication
  • Notarization
  • Time-Stamping
  • Non-Repudiation
  • Privilege Management
    • Authorization & Authentication
    • Authorization & Policy Authorities
    • Delegation
      • Blind vs. Auditable
pki and the services
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!
  • Crypto
    • Signatures, hash, MAC, ciphers
  • Infrastructure
    • Tickets
    • Certificates
    • Authorities (Trusted Third Parties)
      • Ticket Granting, Key Distribution
      • Certificate, Policy, Authorization,Time, Notary, etc.
      • Archives
  • 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 extensionsToday, X.509=v.3
    • Many other standards extend X.509
  • Others
    • PGP, SPKI, etc.
  • Certificates  Signature
    • Certificates are implemented using Signatures
  • Certificates  Authentication
    • Authentication can be implementedusing Certificates
    • Same for Authorization, etc.
  • Certificates are static
    • Change => Re-Issue
      • *This could be challenged, but not in standard x509
certificate validation
Certificate Validation
  • Integrity: signature is valid
  • Signed by atrusted 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
spki a simple pki
SPKI – A Simple PKI
  • Authorization certificates
  • Delegation
  • SDSI – a Simple Distributed Security Infrastructure
  • Question #1: it may be very nice, butwill it ever be used by anyone?
pgp pretty good privacy
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
SET – Secure Electronic Transaction
  • Credit card payment protocol
  • Adopts and extends X.509
    • See [AL] pg.84
back to x 509

Back to X.509

End detour

certificate policies
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 policies19
Certificate Policies
  • Distinguished by OIDs (Object ID)
    • “form letters”
  • Equivalences
    • Policy Mapping ext. declare policies equivalent
  • Established & registered byPolicy [Management] Authorities
    • Internal – e.g. corporate
    • External – community
ca certification authority
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
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
key certificate management
Key & Certificate Management

Key/Certificate Life Cycle Management

    • Identity  Key. Focus on Key!


  • Initialization
  • Issued (active)
  • Cancellation
  • Generation
  • Issuance
  • [Usage]
  • Cancellation
initia liza tion
  • 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
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 generation26
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
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
Certificate dissemination
  • Out-of-band
  • Public repositories
    • LDAP-like directories
    • Used mostly for confidentiality
  • In-band
    • E.g. signed e-mail usually carries certificate


    • Privacy, scalability, etc.
key backup
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
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 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
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 revocation34
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
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
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
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
Authority Revocation Lists
  • ARL = CRL for Cas
    • Revokes certificates of Cas
    • Rarely needed/used
      • Decommissioned
      • Compromised
crl distribution points
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
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
Indirect CRL
  • Combines CRLs of many CAs
    • Potentially a “for fee” service by T3rdP
certificate revocation trees
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
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
Common Trust Models
  • CA Hierarchy
  • Distributed
  • Web
  • User-centric


  • Cross-certification
trust definition
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
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
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
Context is important
  • Privacy Enhanced Mail (PEM) adopted strict hierarchy of CAs approach and failed
  • DoD could use hierarchy fine
distributed trust architecture
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
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
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
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
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
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
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
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