Public Key Infrastructure

1. Public Key Infrastructure Levi Broderick April 18, 2006 05-899 / 17-500 – USABLE PRIVACY & SECURITY – CRANOR, HONG, REITER

2. 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.

3. 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. 100110

4. 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. ??????

5. 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.

6. 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.

7. Communication under PKI • Peter and Ulysses can communicate since they share Mary Jane as an ancestor. • Jill and Sheryl can communicate since they share a root element.

8. Communication under PKI Bob’s public key Alice’s public key 100110 • The public key is used for encryption and digital signature verification. • The private key is used for decryption and the creation of digital signatures.

9. 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)

10. 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.

11. amazon.com X.509 certificates X.509 certificate name public key

12. X.509 hierarchy issuer subject • And a demonstration . . .

13. 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

14. 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

15. 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

16. 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

17. 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)

18. CRLs • Requires database of all invalidated, unexpired certificates. • Verifier queries this database whenever he wants to see whether a certificate has been revoked. • Two models • 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

19. 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

20. 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

21. Encrypting email with PKI • Lotus Notes/Domino makes it easy to encrypt messages because of its use of PKI.

22. Encrypting email with PKI • If the key exists locally, encrypt and send the message. • If not, contact LDAP server and download key.

23. 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.

24. Encrypting email with PKI • Behind-the-scenes look & demonstration . . .

25. 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.

26. 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.

27. 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

28. 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.

29. PGP’s Web of Trust

30. PGP’s Web of Trust

31. 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?

32. Robot CAs • Public / private keys without a central CA. • Robot is a trusted, neutral third party whose signatures provide some validation for email addresses: • 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

33. 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?

34. The fun part! • Groove Virtual Office demo . . . • www.groove.net