Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

38
Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Transcript of Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Page 1: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Securing Wireless Channels

(Or the Case for Certificateand Public Key Pinning)

Page 2: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

What is OWASP?

• The Open Web Application Security Project– Not just web anymore

• Mission Driven– World wide, nonprofit, unbiased organization

• Community Driven– 30,000 Mail List Participants– 200 Active Chapters in 70 countries – 1600+ Members, 56 Corporate Supporters – 69 Academic Supporters

Page 3: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

200 Chapters, ~1600 Members, 30000+ Builders, Breakers and Defenders

Around the World

Page 4: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

About Me

• Jeffrey Walton–Roles include•Mobile Security Architect• Senior Consultant• Security Engineer

–Secure Coding Evangelist• Live and die by SDLCs

Page 5: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Agenda and Topics

• Background– Architectures– Expectations

• VPN/SSL/TLS Issues– Past Problems– Current Issues

• Shared Secret– PSK– SRP

• Pinning– Certificate– Public Key

• Futures– Pinning (IETF)– Sovereign Keys– Convergence

• Wrap Up– Questions

Page 6: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

It’s All About the Data

• Data is the only thing that matters– Who owns it– Who controls it– Who accesses it

• Share data with appropriate parties– Must determine identity of parties

• Can’t determine identity?– Don’t share data

Page 7: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Data Attributes

• Data States– Data at Rest

• Server/Desktop/Device• Remote and Local

– Data on Display• View/Read/Write/Edit• Local

– Data in Transit• Secure Channel• Local ↔ Remote

• Data Sensitivity– Low

• Public Information• Contact Information

– Medium• Social Security Number• Bank Account• Single Sign On?

– High• Pending Litigation, M&A• FERPA, HIPPA, GLBA, etc

Page 8: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Expectations

• User Expectations?– End-to-end security

• Web Applications– Padlocks tell me its secure– Green Bars tell me its secure– Marketing tells me its secure

• How can {VPN|SSL|TLS} not be secure?– When did that happen?

Page 9: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Training (Conditioning?)

• Padlock looks secure• Green bar looks secure• $1,500,000 is a lot of money• It looks secure• It must be secure

Page 10: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Two Architectures

• Two architectures in play– Employee ↔ Organization• VPN

– Individual ↔ Service Provider• SSL/TLS

• Security Boundaries– Sometimes Trust Zones– How many are traversed?

Page 11: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Architecture (Enterprise, VPN)

Page 12: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Architecture (Mobile, SSL/TLS)

Page 13: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Comes down to…

• Infrastructure– Domain Name System (DNS)– Public Key Infrastructure (PKI{X})– Certificate Authorities (CAs)

• Employee ↔ Organization– Organization

• Individual ↔ Service Provider– Individual, Provider

Page 14: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)
Page 15: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

What’s Gone Wrong (1)?

• Governments Want/Require Interception– Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL,

cryptome.org/ssl-mitm.pdf– http://www.dailymail.co.uk/indiahome/indianews/article-2126277/No-secrets-

Blackberry-Security-services-intercept-data-government-gets-way-messenger-service.html

• Governments Engage in Interception– http://www.thetechherald.com/articles/Tunisian-government-harvesting-usernames-

and-passwords/12429/

• Vendors Provide Interception Taps– http://www.cisco.com/web/about/security/intelligence/LI-3GPP.html

• Governments Use Interception Taps– https://www.eff.org/nsa-spying

• Mobile Interception is Patented– Lawful interception for targets in a proxy mobile internet protocol network,

http://www.google.com/patents/EP2332309A1

Page 16: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)
Page 17: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

What’s Gone Wrong (2)?

• Handset manufactures add trusted roots– http://gaurangkp.wordpress.com/tag/nokias-man-in-the-middle-attack/

• Carriers can add trusted roots– No reference yet, but http://www.theregister.co.uk/2011/12/15/carrier_iq_privacy_latest/

• CAs can become compromised– http://isc.sans.edu/diary.html?storyid=11500

• Researchers can create Rogue CAs– http://www.win.tue.nl/hashclash/rogue-ca/

• DNS can become compromised– http://forums.theregister.co.uk/forum/2/2011/09/05/dns_hijack_service_updated/

• Physical plant can become compromised– http://www.pcworld.com/article/119851/paris_hilton_victim_of_tmobiles_web_flaws.html

• Its easy to set up an AP or Base Station (Chris Paget's IMSI Catcher)– http://www.wired.com/threatlevel/2010/07/intercepting-cell-phone-calls/

Page 18: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)
Page 19: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

What’s Gone Wrong (3)?

• Can't trust some CAs – they will sell you out and issue subordinate CAs for money– http://www.net-security.org/secworld.php?id=12369– http://www.zdnet.com/trustwave-sold-root-certificate-for-surveillance-3040095011/

• Can't trust some browsers – they will sell you out and elide their responsibility– https://bugzilla.mozilla.org/show_bug.cgi?id=724929

• Can't trust some browsers – they include questionable certificates out of the box– https://bugzilla.mozilla.org/show_bug.cgi?id=542689

• Can't override some browser's CA list– http://my.opera.com/community/forums/topic.dml?id=1580452

• Can't override OS's CA list– http://support.google.com/android/bin/answer.py?hl=en&answer=1649774

• CRL/OCSP does not work as expected/intended– http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-

browsers.html– https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-

browser-collusion

Page 20: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)
Page 21: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

What’s Gone Wrong (4)?

• User will break it too (not just bad guys)– http://www.esecurityplanet.com/mobile-security/hacker-bypasses-apples-ios-in-app-

purchases.html– http://www.h-online.com/security/news/item/Apps-for-Windows-8-easily-hacked-

1767839.html

• Interception proxies add additional risk– http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-

fail.html

• HTTPS is broken– http://www.thoughtcrime.org/software/sslstrip/

• PKI is broken– www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf

• The Internet is Broken :)– http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html

Page 22: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Decisions, Decisions…

Page 23: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)
Page 24: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Remediation

• Stop Conferring Trust!• Cut-out the middle men

• Harden the Channel!• Leverage the pre-existing relationship• Verify the Host

• Password Authenticated Key Exchange– Shared secret

• Public Key Cryptography– Public/Private key pair

Page 25: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)
Page 26: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Secure Remote Password (SRP)

• Secure Remote Password (SRP)– Thomas Wu, RFC 5054

• User knows the password– Client hashes before use

• Server knows the verifier– Similar to Unix passwd file

• Diffie-Hellman based– Discrete logs (hard problem)– gab → g{(salt + password)|verifier} + nonces

Page 27: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Pre Shared Key (PSK)

• Pre Shared Key (PSK)– RFC 4279

• Three Flavors– PSK Key Exchange

• Secret used as Premaster Secret, use only symmetric key algorithms

– DHE_PSK Key Exchange• PSK authenticates Diffie-Hellman exchange

– RSA_PSK Key Exchange• combines public-key-based server authentication with mutual

authentication using a PSK

Page 28: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)
Page 29: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Public Key Cryptography

• All we need is a signing key for identity…– RSA, DSA, ECDSA

• … and an ephemeral exchange– DHE, ECDHE, MQV, HMQV, FHMQV, etc

• SSH got it right– StrictHostKeyChecking option

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that the RSA host key has just been changed.

Page 30: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

General Idea

• Whitelist expected Certificates or Public keys– There’s a pre-existing relationship–Or, make a note during first connect– Side step the “key distribution” problem

• Certificate or Public Key Pinning– Libraries offer ‘OnConnect’ callback– In the callback, inspect certificate or public key

Page 31: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Bad Cases

• Good case– Server is identified by expected cert or key

• Bad case– Adversary is using a different public key

• Not expected, so fail

– Adversary is advertising expected public key• Can’t decrypt communications

• Really Bad Case– Adversary is using expected public key

• Can decrypt communications – pwn’d

Page 32: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Certificate or Public Key?

• X509 Certificate– Binds public key to entity– Version 3 information– Certificate may be rotated

• Public Key– Must be static, cannot change– May violate some key rotation policies– Does not depend on certificate

Page 33: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Sample Code

• Sample Code–Windows/.Net–Android/Java– iOS/Objective C–OpenSSL/C

Page 34: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)
Page 35: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Futures

• Public Key Pinning Extension for HTTP– draft-ietf-websec-key-pinning-04– http://www.ietf.org/id/draft-ietf-websec-key-pinning-

04.txt

• Sovereign Keys Project– http://www.eff.org/sovereign-keys– DNSSEC to distribute certificates and keys

• Convergence– http://convergence.io– Redundant view of sites and certificates/keys

Page 36: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Does It Work?

Page 37: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

Wrap Up

• Data is all that matters– Identify parties, then share data

• PSK, SRP and Pinning– Does not confer trust– Don’t care about answers from DNS or CAs– Leverages pre-existing relationship

• Sovereign Keys and Convergence– Does confer trust– Still getting answers from others– Useful if no pre-existing relationship

Page 38: Securing Wireless Channels (Or the Case for Certificate and Public Key Pinning)

• Questions?–Hopefully useful Answers

• Jeffrey Walton–jeffrey.waltο[email protected]οm

Wrap Up