Transcript PKI - DePaul University

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 cryptography


Public key cryptography


shared secrets
proving identity
Public key certificates

trusting 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


Path validation requires a directory



just the signature of the issuing CA
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 problem

legal changes
 business 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
C3
Carol
Dave
How to manage?

Combine
hierarchical CA relationship, or
 peer-to-peer


Multiple trust points
Hierarchical combination
Back to hierarchical PKI
 Either

Add a new master root
 Select one existing root as master

Combination
CM
C1
Alice
Bob
C2
C3
Carol
Dave
C2
C1
C3
Carol
Alice
Bob
Dave
Problem

Back to hierarchy
Peer-to-peer
mesh CA
 CAs certify each other

C1
Alice
Bob
C2
C3
Carol
Dave
Advantages

Easy to establish


Users 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 compute
possible loops, dead-ends
 could 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 hierarchies


Who makes this decision?


Accept multiple trusted entities
user / administrator
How is it accomplished?
direct trust relationship
 cross-certification

Multi-rooted PKI
C1
Alice
Bob
C2
C3
Carol
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 crosscertification
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, or
 acts as local CA


Problem

administrative overhead
• eventually enterprise is doing its own PKI
Multi-rooted

Advantages
Each CA forms a hierarchy
 Easy to add new hierarchies


Disadvantages
Not scalable
 Too 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

Simplicity


Every user his own CA
Free

No 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 CA


just for the bridging function
BCA establishes bi-directional trust
with the root of each hierarchy
 cross-signed certificates

Bridge PKI
BCA
C1
C3
C2
Alice
Bob
Dave
Carol
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 established

sufficiently trusted by root CAs
Example


Federal Bridge Certification Authority
Original plan



Meanwhile



hierarchical CA
infighting about who would control the root
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 nonperformance
CPS



"Certification Practice Statement"
Documentation of internal practices used in
CA
Many dimensions





technical
personnel
insurance
procedures
Example on line
Certificate policy

CPS usually
sets forth different types of certificates
 conditions under which those
certificates will be issued
 relevant certificate policy IDs

• X.509 OID

pertinent extensions
Certificate Policies

Requirements for various secure
transactions

usually 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



Inter-library loan



Under $100
Under $5000, etc.
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 factors
how secure the private key is
 how thoroughly the identity of the
holder is verified

Levels of Assurance

Test


Rudimentary







basic level of assurance
Risk low
May be used to secure private information
Medium



lowest degree of assurance concerning identity of the individual.
Data integrity only
Risk low
No for authentication, confidentiality
Basic


interoperability testing between the FBCA and Principal CAs.
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


Rudimentary




in-person appearance or
data comparison against trusted DB or
attestation of authorized agent
Medium





email address only
Basic


None
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, Basic


Medium


software OK
hardware preferred
High
hardware only
 tamper-evident hardware preferred

X.509 Implementation

A policy has a OID


Book example: {joint-iso-itu-t (2)
country (16) us (840) organization (1)
sharons (15678) policies (4) generaluse (2)}
A policy is either
critical or
 not critical

Examples

Certificate profile


outline of certificate contents
Certificate

Data format
Midterm
take-home
 due 9 pm 2/4
 no class

Midterm, cont'd

3 questions
Signature protocol
 Attacks
 Infrastructure
