PKI and Secure Communication Usable Privacy and Security Ahren Studer 4/28/08

1. PKI and Secure CommunicationUsable Privacy and SecurityAhren Studer4/28/08

2. Basics • Asymmetric cryptography • 2 keys (private and public keys) • Can sign (decrypt) using private key • Can verify (encrypt) using public key • Need an authentic copy of the public key • Multiple Ways to Acquire these • PKI • PGP Web of Trust • Other

3. PKI Basics Certificate Authority (CA) books.amazon.com motors.ebay.com jill@ebay.com monkey_wrench@motors.ebay.com

4. Ideal PKI • Decades ago goal was a global PKI • Not just server identification • If you were online you’d have a certificate • Convenient secure communication • No spam (know your friends public keys) • Helps fight fishing (know your banks’ keys)

5. Why this is great. • Once we have we can authenticate any entity in the tree. • No need to share a-priori information. • Authority doesn’t have to be online. • CA can delegate work to others. • E.g. CMU signs keys for each department, department signs professors’ keys, professor signs students keys

6. Why PKIs aren’t so great. • Security Weaknesses • Implicit trust • Usability Weaknesses • Public key storage methods • Removing invalid certificates • Private key management • Concept of asymmetric key • Doesn’t fulfill user’s expectations • Sometimes a better solution exists Partially based on Don Davis. “Compliance Defects in Public-Key Cryptography”

7. Security Vulnerabilities in PKIs • Simple question: Who must you trust in a PKI? • Certificate Authority • Entities with Certifying Authority • Your software??!

8. I need to trust my software? • Your software can install new CAs. • Your software can access the hosts files. • hosts file translates URL to IP address • URL is in the certificate not the IP address

9. A potential attack

10. A potential attack

11. A potential attack • Computer is infected • Malcode can change crucial files • Add CAs to Thunderbird, IE, Safari, Opera, … • Add entries to the hosts file • Translates URL to IP address (no DNS lookup) • What happens the next time you type in/click eBay.com, amazon.com, www.pnc.com …?

12. A potential attack • Everything looks right • Certificate is “valid” • How can we fix this?

13. A potential attack • How can we fix this? (software vulnerabilities will always exist) • Verify the CA’s public key each time it is used (usability headache) • Store the key in non-writable memory • Smart card

14. How else is trust involved? • Trust the CA to identify the correct entities

15. Why should you trust the CA?

16. Who can we trust (in a PKI)? • Need to trust the CA, without it no PKI • Once the CA makes a mistake, we need a mechanism to address the mistake • How do we address CA mistakes? Certificate Revocation Lists (CRLs)

17. Certificate Revocation Lists • Indicates which certificates are no longer valid • Wrong entity received a certificate • Server is compromised and private key is leaked • Anything else? • All are valid reasons to revoke a certificate

18. Drawbacks to a CRL • CRL needs checked before any verification • CRL database and user must be online • Central point of failure (focus of attack) • Shut down the CRL database • That private key you stole is valid again

19. Revocation in Reality • How are “bad” certificates identified in reality? • Answer: Not CRLs • Microsoft uses automatic update • Majority of cases utilize time • Certificates just expire after X years

20. Why PKIs aren’t so great. • Security Weaknesses • Implicit trust – trust CA & system • Usability Weaknesses • Public key storage methods • Removing invalid certificates • Private key management • Concept of asymmetric key • Doesn’t fulfill user’s expectations • Sometimes a better solution exists

21. Managing your private key • Imagine you have a private key to • Sign emails • Perform transactions • Whatever you can imagine • This is your online identifier

22. Managing your private key • You want to protect your digital identity • If this is stolen, the thief can act as you • What about 2 factor authentication? • Who would waste the time typing in passwords if you had a key to perform authentication automatically?

23. Managing your private key • A password (authentication) is still needed, why? • You personally can’t remember the key. • Who can remember a 1024 bit number? • Proves to the system you are the owner of the key.

24. Managing your private key • Private key is needed to sign/decrypt messages • Where should this key be stored? • On local machine • Security implications • Mobility implications • On mail server • Security implications • Mobility implications

25. Managing your private key • Once you prove to the system you’re the owner, how long should the private key be present in memory? • Just long enough to generate the signature • Strong security • Annoying (bad usability) • The entire session • More chance to be leaked

26. Why PKIs aren’t so great. • Security Weaknesses • Implicit trust • Usability Weaknesses • Public key storage methods • Removing invalid certificates • Private key management • User’s concepts • Doesn’t fulfill user’s expectations • Sometimes a better solution exists Partially based on Don Davis. “Compliance Defects in Public-Key Cryptography”

27. Real users and PKIs • Concepts are hard to follow • Non-intuitive • Users expect too much from PKIs

28. Non-intuitive concepts • Asymmetric crypto is strange • How many physical systems use two keys: one to lock, one to unlock? • Called trap doors to help people understand

29. What do trapdoors have to do with my online bank account? • A PKI doesn’t really make sense with the current task • “Why do I need to know the CA to talk to my bank?” • “Why should I ask the CA if my bank is still valid? My bank is my bank.” • “How is my communication secure if I don’t share a key with the bank?” • “Why is my money a series of 1’s and 0’s on the Internet?”

30. Johnny 2 proves otherwise • Repeated “Why Johnny Can’t Encrypt” with new techniques • More description later when covering different secure communication methods • “it was clear that users generally understood signing a message allowed a recipient to verify…” S. Garfinkel & R. Miller. “Johnny 2: A User Test of Key Continuity Management with S/MIME and Outlook Express”

31. Johnny 2 proves otherwise • Main goal was secure communication • Will users understand why PKIs are needed when they just want to …? • When attacked, users leveraged email based identification and authentication • Roughly the same properties that Veri-sign requires

32. Why PKIs don’t fix everything • If everyone had a certificate • Would phishing still be a problem? • No real change (the wrong page is used, not the wrong user) • Helps if it is part of a two-token system • Depends on the backup mechanism

33. PKIs aren’t always the best solution • PKIs aren’t the only mechanism to allow entities that trust a third party to communicate securely • Symmetric Alternatives • Key Distribution Center (KDC) • Asymmetric Alternatives • PGP web of trust • Leap-of-faith • Location-limited channels

34. A,B, proof of KAT Enc(KAB,KBT) Enc(Enc(KAB,KBT) KAB, KAT) Key Distribution Center KAT KBT KCT … KAT KBT KAB KAB

35. KDCs vs. PKIs • Both require work to register users • What needs to be online • KDC needs to be online (easy revocation) • CRL database needs to be online • What needs protected • KDC • CA, client, CRL

36. KDC model seems better than some iPKIs • Examine the applications and ask • What PKI advantage still applies? • What portion requires asymmetric cryptography? • Why not just use a KDC and symmetric cryptography? D. Balfanz, G. Durfee, & D.K. Smetters “Making the Impossible Easy: Usable PKI”

37. Example Scenarios • Network in a Box • Casca (collaboration application) • Both use infrared to securely exchange data • Both use a “CA” which is online as part of the task • How can you use an AP that is offline or collaborate without your collaborator?

38. PKI Advantages • Public key allows communication with anyone in the PKI. • Authority doesn’t have to be online. • CA can delegate work to others. • None still hold. • Only real benefit is storage • In a PKI, client stores key and certificate • In a KDC, server stores per client info

39. Other mechanisms for secure communication • PGP web of trust • Use trusted parties to identify public keys • Trusted parties are friends, coworkers, … • Leap-of-faith authentication • Assume an attack isn’t present • Alert the user when the key changes • Location-limited channels • Securely get the key from the user

40. PGP Communication • Should remember from “Why Johnny Can’t Encrypt” • Friends sign each others’ keys • Advantages versus a PKI • Everyone can have a key for free, just need trustworthy friends • Disadvantages versus a PKI • You need to deal with revocation yourself • Privacy invasive to find a key • Your friends are CAs

41. PGP Communication http://www.xkcd.com/364

42. Leap-of-Faith/Key Continuity • Majority of the time an attack is not a threat • Just proceed as though the key is correct • Currently the model used in SSH

43. Leap-of-Faith • User is told when a new key is used • Keys are associated with identities

44. Leap-of-Faith • If the server’s key changes, the user is alerted • Disadvantages • Key might have legitimately changed • No revocation mechanism • Doesn’t provide an alternative solution • Advantages • No need for authorities • Simple for users

45. Johnny 2 • A repeat of the experiment in “Why Johnny Can’t Encrypt” • Looked at Outlook Express with built in asymmetric crypto support • Investigated Key Continuity Management • Yellow border – new key for a new user • Green border – key matches record • Red border – key differs from record • Gray border – no key used, but one on record

46. Johnny 2 • Investigated whether users could detect attacks • Sent an email signed with the wrong key • Sent an email using a new identity (email address) • Sent an email that was unsigned

47. Johnny 2 • With KCM users didn’t fall for attacks that used different keys • When given a short briefing • Users still sent messages to new emails for a recognized user • Social attack “I’m at home” • User was less likely to accept an unsigned message

48. Johnny 2 • A simple integrated visible mechanism can improve security • However, it is not a panacea • New identities are a problem • (I feel) However, the solution does help compared to a PKI • At least you notice a new identity is being used

49. Location-limited key exchange • Exchange or verify keys using a physically-limited mechanism • Numerous mechanisms • Infrared • Wired connections (Stajano et al.) • Pictures (McCune et al.) • Shaking (Bichler et al.) • Pressing Buttons Simultaneously (Soriente et al.)

50. Location-limited key exchange • Advantages • Leverage physical trust, know the key corresponds to the right entity • Often a simple user-friendly mechanism • The focus of lots of research • Disadvantages • Need to physically interact with other entity