Public Key Infrastructure
Levi Broderick
April 18, 2006
05-899 / 17-500 – USABLE PRIVACY & SECURITY – CRANOR, HONG, REITER
The need for PKI
Meet Alice. She has a
secret that she wants to
send to Bob.
Meet Bob. He looks
forward to talking with
his good friend Alice.
The need for PKI

Alice and Bob can use a secret key (symmetric
cryptography) to communicate over the public
channel.

They must have agreed on this key in advance.
The need for PKI
?

But what if Alice and Bob had never spoken before?
Can Alice still send him a secure communication?

This is the primary focus of PKI.
Communication under PKI

Both Alice and Bob have their own individual
private and public keys signed by a certificate
authority.

The CA might be an employer, Verisign, or some other
organization.
Communication under PKI

All communicating parties must have each others’
public keys.

Public keys must have a common ancestor to be
considered valid.

Alternatively, some PKI implementations (Lotus Notes,
Groove Virtual Office, etc.) allow CAs outside the local
network to be individually trusted.
Communication under PKI
Company XYZ
Mary Jane Allen
Development dept. head
Linda Clay
Marketing dept. head
Freddy Hale
Supervisor
Ulysses Applegate
Supervisor
Peter Jacobson
Jill Tyson
Tyrone King
Supervisor
Jason Peters
Asst. Supervisor
Kenneth Blue


Sheryl Song
Jordan Lewis
Peter and Ulysses can communicate since they share Mary
Jane as an ancestor.
Jill and Sheryl can communicate since they share a root
element.
Communication under PKI
Bob’s public key
Alice’s public key

The public key is used for encryption and digital
signature verification.

The private key is used for decryption and the
creation of digital signatures.
X.509 certificates

ITU-T standard for PKI

V3 described in RFC 3280

Certificate authority issues binding certificate
between public key and name (URI, email, etc.)

Includes validation and revocation policy


Certificate Revocation List (CRL)
Online Certificate Status Protocol (OCSP)
X.509 certificates

V3 certificate includes:






Issuing agency information
Subject information
Period of validity
...
Cryptographic signature
For root CAs, the issuing agency and the subject of
the certificate are the same.
X.509 certificates
amazon.com
name
X.509
certificate
public
key
X.509 hierarchy
issuer
GTE Cybertrust Global Root
Comodo Class 3 Security Services CA
Microsoft Internet Authority
www.cmu.edu
Microsoft Secure Server Authority
www.microsoft.com
www.buy.com
(a248.e.akamai.net)
update.microsoft.com
subject

And a demonstration . . .
Non-repudiation

Non-repudiation and repudiation of signatures
involved in legal practice for untold generations.

Traditional paper signatures may be repudiated:


False signature
Real signature, but extenuating circumstances



Unconscionable conduct / inequality of bargaining power
Fraud
Undue influence, or signature made under duress
Source: http://firstmonday.org/issues/issue5_8/mccullagh/index.html
Non-repudiation

Increasing legislation to allow digital signatures to
serve as legally binding.

Non-repudiation as applied to digital signatures:



Provides proof of the integrity and origin of data, both
unforgeable, which can be verified by any third party at
any time.
An authentication that with high assurance can be
asserted to be genuine and that cannot subsequently be
refuted.
Thoughts? Comments?
Source: http://firstmonday.org/issues/issue5_8/mccullagh/index.html
Non-repudiation
Carl Ellison speaks out:

It is not achievable.



The private key provided the signature, not the human.
No provable link exists between the person and the
computer.
It is counter to consumer protection law.


Transfers liability from the merchant to the consumer.
Corollary: E-commerce will suffer since repudiation
guaranteed by creditors becomes nonexistent.
Source: http://world.std.com/~cme/non-repudiation.htm
Non-repudiation
Carl Ellison continues to speak out:

It circumvents contract practice and law.


When does the user ever publicly acknowledge that he
stands behind the signatures created with the private key?
It conflicts with good key management.

If there exists no audit log, the user is likely to discover a
compromised key when another party in a transaction
reveals use of the key and demands further action.
Source: http://world.std.com/~cme/non-repudiation.htm
X.509 certificate revocation

Sometimes a certificate needs to be invalidated
before its natural expiration date



Private key compromised
Employee fired from company issuing certificate
Two main ways to revoke an X.509 certificate:


Certificate Revocation List (CRL)
Online Certificate Status Protocol (OCSP)
CRLs

Requires database of all invalidated, unexpired
certificates.


Two models



Verifier queries this database whenever he wants to see
whether a certificate has been revoked.
Pull model: Verifier downloads CRL from CA as needed.
Push model: CA sends CRL to verifiers at regular
intervals.
Problems?
Source: http://www.rsasecurity.com/rsalabs/node.asp?id=2283
CRLs

Problems similar to blacklists with credit card
companies


Database is periodically pruned, but still very large
Time delay between certificate being revoked and
revocation being published in CRL

Widely-used CRLs have too many verifiers to be
able to effectively use the “push” method.

Susceptible to DOS attacks

Is the software default to accept or reject the certificate?
Sources: 18-730 (Reiter), http://www.imc.org/ietf-pkix/old-archive-01/msg02256.html
OCSP

RFC 2560

Request / response protocol


Verifier receives up-to-the-minute status info
Status list parsed server-side


Responder only sends back relevant info, reducing traffic
Responder may require requests to be signed


Allows for billing mechanisms to be put into place
Still vulnerable to DOS attacks
Source: http://www.openvalidation.org/whatisocsp/whatocsp.htm
Encrypting email with PKI

Lotus Notes/Domino makes it easy to encrypt
messages because of its use of PKI.
Encrypting email with PKI

If the key exists locally,
encrypt and send the
message.

If not, contact LDAP
server and download
key.
Encrypting email with PKI

If key is signed by the CA, not revoked, and owner
is correct:



Save to local keyring
Encrypt message and send
If incorrect owner, revoked, or unsigned, error out.
Encrypting email with PKI

Behind-the-scenes look & demonstration . . .
Problems with PKI

System was originally envisioned as encompassing
entire globe.



Would require one root CA or a specific and unchanging
list for each government.
Governments are fickle and don’t like to trust each other.
Additionally, Balfanz, Durfee, and Smetters identify
four usability problems with PKI.
Problems with PKI

Public-key cryptography is counterintuitive.


What on earth are public and private keys? What is a
certificate?
PKI seems too far removed from application goals.

Users do not understand how their tasks require PKI.

PKI tasks are too cumbersome.

Large CAs run into naming collisions.

Users shoulder the burden of ensuring that the person they’re
looking up is indeed the person they want.
Source: Security and Usability, ch. 16.
SPKI (Simple PKI)

Similar to X.509, but names are local rather than global.

Certificates are used to bind authorizations rather than
identities to public keys.

Possible uses (from RFC 2692):






Grants permission to write electronic checks.
Digital marriage license / divorce decree.
DC Metro farecard
Proof of degree earned (M.D., Ph.D., etc.)
Permission to issue nuclear launch codes
Thoughts?
Source: http://theworld.com/~cme/html/spki.html
PGP’s Web of Trust

Public / private keys with an attached name, email address,
and optional photo.

No centralized CA to sign keys.



PGP users sign keys when they’ve verified the owner’s identity,
so in essence each PGP user is acting as a CA.
Your trust of a public key is related to how many signing “hops”
you are away from that key and how much you trust each signer
along the route.
Decentralized key distribution – users send keys.

Key servers have popped up to fill the role of the CA in key
distribution.
PGP’s Web of Trust
PGP’s Web of Trust
PGP’s Web of Trust

Makes key management issues very apparent

Web of trust depends on end users verifying and signing large
quantities of keys.

Does a user understand what type of commitment he makes
by signing a key?

Just how much trust is placed in a key 3 hops away? What
about 4 hops?


Trust disappears after a default of 2 hops, maximum 8 hops
(PGP 9.0).
Thoughts?
Robot CAs

Public / private keys without a central CA.

Robot is a trusted, neutral third party whose signatures
provide some validation for email addresses:
1.
2.
3.

User uploads public key to robot CA.
Robot signs key and sends encrypted signature to email
address present in public key.
Recipient decrypts message to retrieve signed key, then
redistributed public key with robot’s signature attached.
Effectively invalidates signatures on keys not belonging to
the email addresses listed for them.
Source: http://jameshoward.us/Robot_Certificate_Authority
Robot CAs
Attempts to solve some of the key management
issues in PGP:



If key verifier’s software automatically places trust in the
robot’s signature, then keys can be downloaded from a
key server automatically by the email client.
Burden is on the key creator to get the key signed by
robot.

Process can probably be automated even at the
creation end with the right software.

Thoughts?
The fun part!
Groove Virtual Office demo . . .


www.groove.net