1 / 57

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

PKI and Secure Communication Usable Privacy and Security Ahren Studer 4/28/08. 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

uma
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related