Forward Secrecy
Download as ODP, PDF1 like404 views
The document discusses forward secrecy in encrypted communications. It explains that forward secrecy uses ephemeral keys for each session so that compromising a server's private key at a later date would not allow decryption of past encrypted sessions. It provides examples of Google, Twitter, and Apple implementing forward secrecy by using protocols like elliptic curve Diffie-Hellman key exchange that provide forward secrecy and help protect encrypted data even if server keys are lost or stolen in the future.
Forward Secrecy
- 1. Forward Secrecy Kevin O’Brien Washtenaw Linux Users Group
- 2. Encrypted Communication ● Most examples involve Alice and Bob trying to communicate securely ● This is not the actual most common use case ● Most of the time, we as individuals want to exchange messages with servers on the Internet ● This generally involves both Diffie-Hellman and a public key method such as RSA
- 3. Example ● I want a secure connection to my bank, and my messages are traveling over the public Internet ● I cannot rule out someone eavesdropping on my messages ● If my connection is not secure, they could get my password to the bank site and steal all of my money
- 4. Secure Connections ● Ideally, my bank offers a secure connection by default (if not, get a better bank!) ● This is usually seen as a URL the begins https, instead of the old standby http ● This should denote at the very least an ssl connection, though TLS is preferred these days ● I also have https everywhere installed, which I can get from the Electronic Frontier Foundation ● https://www.eff.org/https-everywhere
- 5. Negotiation ● Whether the site offers a secure connection by default, or offers it because my browser plug-in asked for one, this is the beginning of a negotiation ● Which security protocols does the server have available? ● Which one does my browser have? ● What is the strongest protocol we have in common?
- 6. The opening bid ● This is the start ● I initiate the connection ● Amazon has not, AFAIK, ever just logged me in and then asked if I need anything today (though if they figure out how to do that…) ● I do it with what is called the ClientHello Message
- 7. The ClientHello Message ● This will look something like this: ● TLS_DHE_RSA_WITH_AES_256_CBC_SHA ● Every piece means something ● Again, this is something I am sending to the server
- 8. Interpretation 1 ● TLS = establish a TLS (i.e. Transport Layer Security) connection ● DHE = using Diffie-Hellman Ephemeral (for the shared secret used for the session) ● RSA = combined with RSA (the public key protocol used to create the secure initial connection ● WITH_AES_256 = using Advanced Encryption Standard (AES) with 256 bits
- 9. Interpretation 2 ● CBC = using Cipher Block Chaining (CBC) ● SHA = and using the Secure Hashing Algorithm (SHA)
- 10. Negotiation ● This should represent the highest level of security my browser is capable of handling ● There have been security attacks that worked by forcing a connection at a very low level of security, such as the POODLE attack ● https://en.wikipedia.org/wiki/POODLE ● This is one reason why SSL has been deprecated in favor of TLS, which won’t allow downgrade attacks
- 11. The ServerHello Message ● The server then responds with its own message, which will either accept my proposal, or fail and propose something different ● Once there is an agreed protocol, the server will send two things – A certificate containing the public key of the server, which serves to authenticate it – A random 32 byte number which will be used for the Diffie-Hellman Key Exchange – Note that these are sent publicly
- 12. Key Exchange ● Now the client (me) creates its own random number, encrypts it using the public key of the server, and sends it to the server ● The server decrypts the message using its private key, and reads the number ● Each side now has a random secret number from the other side, and a Diffie-Hellman Key Exchange is done
- 13. Negotiations Completed ● Now that there is a shared secret key, there is a Change Cipher Spec message that switches from the Public Key to the shared Diffie-Hellman key ● This is used for the rest of the communication
- 14. How Secure? ● Diffie-Hellman is known to be secure against eavesdropping, particularly if a strong Elliptic Curve algorithm is employed ● The use of a certificate with a Public Key (perhaps using RSA) makes it more difficult to execute a man-in-the- middle attack ● That can happen, though, if someone can get in the middle at the right moment and set up communications with both sides using its own keys
- 15. Man-in-the-middle ● I send a ClientHello message to my bank, but just my darn luck, Mallory intercepts my ClientHello ● She in turn sends a ClientHello to my bank, and get back the certificate ● She then creates her own certificate, and send it to me (I am expecting a certificate, after all) ● She can sit in the middle passing messages back and forth while decrypting and reading them ● In the US, companies have the right to do this on their networks (though we hope not to clean out your account)
- 16. Securing this ● Number one, pay attention to the certificates. At least that way you’ll know if someone is getting in the middle. ● Measures like OCSP Stapling make this type of attack much harder to do ● TLS also provides improved authentication ● HTTP Public Key Pinning ● DNSSEC
- 17. End Points? ● Man-in-the-middle attacks are aimed at data in transit ● What about the end points? ● I have some control over my own computer ● But what about the server?
- 18. Server Control ● Servers can fall to malicious cracking ● Servers can be seized by law enforcement ● Possible keys can be taken from the server and used to decrypt communications ● There is a reason governments are starting to insist that companies keep e-mail servers for their citizens within the country, and it is not for your protection
- 19. Lost Control ● I might not care if it is only my order of specialty teas from Amazon ● But it might be confidential e-mails ● And if messages are kept for future decryption… ● NSA has a facility that appears to be for that exact purpose ● So even if the data is secure for now, will it be secure in the future?
- 20. Forward Secrecy ● Some call it Perfect Forward Secrecy, but it is not perfect ● Remember, this is an arms race ● And in security perfection is very hard to find ● Any encrypted message can be brute force decrypted given enough time and resources ● And with improvements in decryption (e.g. quantum computing) it will take less time and fewer resources
- 21. What can you do? ● Forward Secrecy is essentially key protection ● This is done by using new keys for every session ● So even if someone cracked your e-mail written on January 9, it would not help with your e-mail written January 10 ● Nor would it help with your web browsing on January 9
- 22. How It Can Fail ● This requires that keys are not stored, but discarded after use ● How can you be sure? ● Incompetence happens a lot with servers ● Remember those governments and the e-mail servers?
- 23. O’Brien’s First Law Every government, by its very nature, regards the security and privacy of its citizens as a flaw which it seeks to remedy by all possible means.
- 24. Still, A Step Forward ● Being used by more companies ● Google ● Twitter ● Apple ● And others
- 25. Google Adam Langley from the Security Team posted a notice on their Security Blog on November 22, 2011 called Protecting data for the long term with forward secrecy. In this short blog post he mentions that Google “support(s) forward secrecy using elliptic curve Diffie-Hellman”. https://security.googleblog.com/2011/11/prot ecting-data-for-long-term-with.html
- 26. Twitter On November 22, 2013, Twitter announced in its blog under the heading Forward Secrecy at Twitter that they would also be using forward secrecy, and similarly said the following: There are two main categories of Diffie-Hellman key exchange. Traditional Diffie- Hellman (DHE) depends on the hardness of the Discrete Logarithm Problem and uses significantly more CPU than RSA, the most common key exchange used in SSL. Elliptic Curve Diffie-Hellman (ECDHE) is only a little more expensive than RSA for an equivalent security level. Vincent Bernat (@vince2_) benchmarked ECDHE at a 15% overhead relative to RSA over 2048-bit keys. DHE, by comparison, used 310% more CPU than RSA. https://blog.twitter.com/engineering/en_us/a/ 2013/forward-secrecy-at-twitter.html
- 27. Apple Apple published a specification called App Transport Security that is now mandatory for all apps. It has several provisions, but one of them involves forward security. In an article from the SSL store there is a good description of this provision: ATS also requires the use of TLS 1.2 and a cipher suite that provides forward secrecy. Developers will need to ensure their server is configured properly. TLS 1.2 is the most recent version of the SSL/TLS protocol, and most modern servers have it turned on by default. Forward secrecy refers to the way that connections are encrypted. An encryption cipher which supports forward secrecy, like ECDHE, is able to offer security to past sessions even if the private key is compromised. https://www.thesslstore.com/blog/apple-will-require-use-ats-2017/