Post on 31-Dec-2015
description
PKI
Robin Burke
ECT 582
Outline
Discussion Review
The need for PKI PKI
hierarchical PKI networked PKI bridging
Certificate policies rationale examples X.509 implementation
Review
Private key cryptographyshared secrets
Public key cryptographyproving identity
Public key certificatestrusting a certificate
Certificate trust
Bob has a certificate signed by T saying that k is Alice's public key
What does Bob need to convince him to trust T? Proof that the signature on the certificate
was made by T Proof that T is not a front for Eve, or Proof that T is a trustworthy organization Proof that T's standard of proof for Alice's
identity is appropriate
Hand-waving
The CA's public key is "well-known" Why doesn't this work?
Too many CAs Different public keys for different purposes How are keys published?
New assumption Every user has their own certificate Every user has a relationship with some CA
Certification paths
Basic idea root CA non-root CAs
Really we mean root certificate non-root certificates
• signed by root or• some other CA
Certification path A path through hierarchy to a root CA
Path validation
Certificate path is not included with the certificate just the signature of the issuing CA
Path validation requires a directory where each link of the path can be retrieved
Path validation is not just putting all the links together
Inefficient path validation is the enemy of PKI
Path validation issues
Verifying the digital signature and checking basic constraints
Checking that the subject of every certificate is the issuer of the next certificate
Checking the validity periods Checking that each certificate has not been
revoked Checking the required certificate policies Checking name constraints
New problem
How to organize multiple certification authorities?
How to manage public keys/certificates on a large scale?
Not just a technical problemlegal changesbusiness practice changes
Public key infrastructure
A system of public key encryption using digital certificates from Certificate Authorities and other registration authorities that verify and authenticate the validity of each party involved
in an electronic transaction.
- FOLDOC
Hierarchical PKI
Simplest case All certification paths start from the root CA Everyone absolutely trusts the top CA
uses it as root CA Advantages
Good scalability Easy to find certification path
• Unique certificate path for any end entity CA restrictions established by root
Disadvantage: For commercial world, hard to identify a top CA A single point of failure
Example: Verisign
Forest (multi-root) PKI
C1
Alice Bob
C2
Carol
C3
Dave
How to manage?
Combinehierarchical CA relationship, orpeer-to-peer
Multiple trust points
Hierarchical combination
Back to hierarchical PKI Either
Add a new master rootSelect one existing root as master
Combination
C1
Alice Bob
C2
Carol
C3
Dave
CM
C1
Alice Bob
C2
Carol
C3
Dave
Problem
Back to hierarchy
Peer-to-peer
mesh CA CAs certify each other
C1
Alice Bob
C2
Carol
C3
Dave
Advantages
Easy to establishUsers don't have to change their trust
relationships Resilient
Compromise of one CA can't destroy network
Other CA's revoke certificates
Disadvantages
Certification paths difficult to computepossible loops, dead-endscould be as long as the number of
CAs in mesh No controlling CA
restrictions hard to establish / enforce
Multiple trust points
Don't join trust hierarchiesAccept multiple trusted entities
Who makes this decision?user / administrator
How is it accomplished?direct trust relationshipcross-certification
Multi-rooted PKI
C1
Alice Bob
C2
Carol
C3
Dave
User-controlled direct
IE model Multiple root certificates available To add a new one
user must choose to trust or not Problem
can the user make adequate trust decisions?
User-controlled cross-certification
Lotus Notes model User acts as a mini-CA
each trusted certificate signed by user Converts forest back to hierarchy Again, user has to make trust
decisions
Domain-controlled
SAP model As above but with an administrator
installs trusted certificates, oracts as local CA
Problemadministrative overhead
• eventually enterprise is doing its own PKI
Multi-rooted
AdvantagesEach CA forms a hierarchyEasy to add new hierarchies
DisadvantagesNot scalableToo many trust decisions
PGP
Accepts X.509 certificates Also, has alternative to CA
"web of trust" Model
local key ring trust individuals as introducers levels of trust
• trusted• untrusted• case-by-case• marginal
multiple marginal introducers = 1 trusted
Advantages
SimplicityEvery user his own CA
FreeNo contracts to sign
Counter-cultural Multiple signers
independent confirmation of identity
Disadvantages
Certification standards Counter-cultural End user responsibility Technical
Multiple signatures not part of X.509
Bridge CA
Establish a CAjust for the bridging function
BCA establishes bi-directional trustwith the root of each hierarchycross-signed certificates
Bridge PKI
C1
Alice Bob
C2
Carol
C3
Dave
BCA
Advantages
Doesn't matter what type of PKI are joining hierarchies can join with meshes
Doesn't establish a new hierarchy with attendant political issues
Bridge is not a single point of failure if bridge is compromised, joining CAs revoke their
certification bridging must be restablished, but CAs still function
independently Bridge adds only minimally to the certification path
p1 + p2 + 2 hard to see how to do better
Disadvantages
New entity (BCA) must be establishedsufficiently trusted by root CAs
Example
Federal Bridge Certification Authority Original plan
hierarchical CA infighting about who would control the root
Meanwhile federal agencies developed separate PKIs need to integrate
Development of Bridge CA (2003) now different agencies can communicate
securely
Break
Trusted Third Party
The CA is a trusted third party How do we come to trust the CA?
published practices• how the business operates
independent audit• fourth party verification of conformance
statement of liability• assumption of liability for non-
performance
CPS
"Certification Practice Statement" Documentation of internal practices used in
CA Many dimensions
technical personnel insurance procedures
Example on line
Certificate policy
CPS usuallysets forth different types of certificatesconditions under which those
certificates will be issuedrelevant certificate policy IDs
• X.509 OID
pertinent extensions
Certificate Policies
Requirements for various secure transactionsusually community-defined
Different CAs may issue certificates in accordance with the policy
Application software can recognize a key appropriate for a particular task
Examples
Procurement Under $100 Under $5000, etc.
Inter-library loan General loan Reference/Periodical
Music Low-quality download High-quality download
Components of policy
key usage security level
Key Usage
signature non-repudiation key encipherment data encipherment key agreement certificate signing CRL signing
Security level
Two factorshow secure the private key ishow thoroughly the identity of the
holder is verified
Levels of Assurance
Test interoperability testing between the FBCA and Principal CAs.
Rudimentary lowest degree of assurance concerning identity of the individual. Data integrity only Risk low No for authentication, confidentiality
Basic basic level of assurance Risk low May be used to secure private information
Medium Transactions having substantial monetary value or risk of fraud Access to private information where likelihood of malicious access is substantial
High Consequence of failure are high, or risk is high High-value transactions
-- FBCA
Documentation standards
Test None
Rudimentary email address only
Basic in-person appearance or data comparison against trusted DB or attestation of authorized agent
Medium in-person appearance information shall be verified pre-existing relationship may suffice (employee documents) one Federal Gov't issue photo ID (passport/green card), or State
photo ID (drivers license) plus one other form of ID High
same as Medium but in-person appearance required
Key protection standards
Test, Rudimentary, Basicsoftware OK
Mediumhardware preferred
Highhardware onlytamper-evident hardware preferred
X.509 Implementation
A policy has a OIDBook example: {joint-iso-itu-t (2)
country (16) us (840) organization (1) sharons (15678) policies (4) general-use (2)}
A policy is eithercritical ornot critical
Examples
Certificate profileoutline of certificate contents
CertificateData format
Midterm
take-home due 9 pm 2/4 no class
Midterm, cont'd
3 questionsSignature protocolAttacksInfrastructure