Tuesday, June 13, 2017

An Intro to Securing your Cryptocurrencies

A lot of my friends outside of the infosec communities have recently started showing interest in buying and trading cyrptocurrencies.  I wrote this informal response as a primer on why securing your coins can be much harder and more important than any of your other assets, as well as some general recommendations.

TLDR - Hardware wallets are currently your best option for securing crypto wallets. It's worth buying one if you hold any amount you're uncomfortable losing.

Disclaimer: This post offers no financial advice and is making no recommendation to invest in crypto-currencies. Additionally, it is not the intent of this post to endorse any specific services, hardware, or software.

 Enjoy!

---------------------------------

So, you've decided to buy some crypto coins. Congratulations! Welcome to the circus.

Maybe you started out by buying a bit of ETH on Coinbase, just as an experiment. Maybe that little bit you bought 2 months ago has suddenly doubled, tripled, quadrupled. Exciting right??

But then you start reading the reddit threads and hear some stories about people who have lost their coins due to carelessness. You realize that this isn't like a bank account where if a hacker gets in and causes a ruckus, you can just call a phone number and report the fraud. In crypto, your money is just gone. Permanently.

So you get serious about your security. You make sure you have a super strong password on your Coinbase account and Gmail account too, since a hacked Gmail can just do a password reset on your Coinbase, right? Maybe you realize that you should use 2FA so that a stolen password doesn't mean everything is gone right that second.[1] Maybe you even use Google Authenticator or Authy since you've read the recent stories about phone companies letting hackers transfer your phone number over without verification so that they can steal your 2FA codes.[2]

Are you safe yet?

No.

Exchanges hold a lot of funds but more importantly they own the keys to moving your funds. This is important. They own those keys, not you. If they get hacked, you're stuck and there's nothing you can do about it because you gave them custodial rights over your assets. On top of that, because they store so many different users' coins all at once, they're a HUGE target. The higher the reward for a hacker, the more time they are going to spend trying to break in.

But wait, aren't exchanges run by super smart people and will never get hacked?

Nope. If history has taught us anything, almost everything has security flaws and the bigger the target, the more likely these flaws will be exploited. See: Mt Gox, Bitfinex, Bitstamp, etc. [3]

Ok, so you decide to get your coins off an exchange. Good right? That way you'll have complete control of the keys and you can be in charge of securing yourself. You google (RandomCoinName) Wallet and download the first one on the list. Are you safe now?

NO! This ones a big one so lets start from the top.

1) Where did that wallet came from? Making a fake wallet is a highly profitable activity for a hacker. Its an easy formula: get enough popularity so that a ton of people use your software, then 6 months later activate your backdoor so you can permanently steal everyone's funds. [4] [5]

2) What about when your computer dies? Hardware doesn't live forever and if your wallet keys aren't backed up somewhere, then the coins will be gone. There will be no way to get any of it back without those keys. So should you back them up on Dropbox or something? Well then you're back to the issue from before where you're trusting your keys with someone else, who is probably an even bigger target than yourself.
Maybe you encrypt your keys. Thats better right? But then those encrypted wallets are only as secure as the password or encryption algorithm you used. Plus now if you forget that password, once again those funds are stuck unmovable for the remainder of time.
Maybe you chose to back up your wallet on a bunch of thumb drives. Now you have to hope that all those thumb drives don't fail at the same time or go missing or are crushed under a some cement after the next major earthquake. [6] How long is the typical shelf-life of a thumb drive anyway? Years? [7]

3) Even if you download a valid wallet application and you trust your clever backup scheme, your computer IS insecure. Think of all the questionable sites you've visited. Those torrents you downloaded with the cracked music production software. Are you willing to wager all your money that none of them have infected you with some hidden malware that is just waiting for the right moment to make money in the easiest way possible? The NSA might have a whole toolkit of unknown exploits that might just get leaked to the wrong people. [8] People that might use them to steal crypto wallets. 

But what if your wallet is encrypted? How can malware steal your keys then?

Doesn't matter. The next time you manually unlock your wallet, the unencrypted keys are sitting there in RAM just waiting to be stolen by some sneaky, persistent malware. The truth is, if you've ever connected your machine to the internet, there is no way of proving it hasn't been compromised.

OK OK OK. So you realize having a wallet on your computer is not the safest option. But what about mobile? iOS has an Appstore that reviews all apps and as long as the device is not jailbroken, sandboxing can protect your keys. Safer right?

Maybe. But still not good enough. Remember that NSA leak from before? They are not the only ones with exploits written for unknown vulnerabilities.  iOS remote exploits are highly profitable, selling for literally millions of dollars [9], but you know what else is highly profitable? Stealing thousands and thousands of keys from mobile wallets. You have to assume that somewhere in the world there is a hacker group that has the perfect SMS based iOS exploit that would allow them to remotely jailbreak thousands of iPhones all at once. What better opportunity to use it than when people all over the world decide to store irreversible, anonymous cash on their devices.

So whats next?

Well, you could try a paper wallet. These are keys that you generate on a computer, convert to a readable format, write down on a piece of paper, and then send funds to. The keys are as safe as the paper they're written on. There's the minor inconvenience in usability, but its worth it for what's considered strong "cold storage".

You're good now, right?

Maybe. But maybe not.

Remember that computer you used to create the paper wallet? How sure are you that that device has never had malware? 100%? Even if you have never ever EVER connected that laptop to the internet, it was made by a large company. There is a reasonable possibility that hardware backdoors were added in the interest of "national security". [10]

SO WHATS LEFT? ANYTHING?

Yes.

Hardware Wallets.

These are custom hardware devices that usually sell for less than $100. These are simple devices designed purely to secure your keys.

So what makes them better than any of the other options?

1) The keys never leave the device. Even if you plug them into the worst, most nasty, virus-ridden computer you've ever seen, the keys are protected. When you want to make a transaction you send the device some parameters (like the amount and destination) via usb. The device creates the TX and signs it on the custom hardware, then returns only the signed transaction.

2) They are easy to use and backup. When you initialize the HW wallet, it gives you 24 words to write down on paper using a standardized generation technique.[11] This is your key. If your HW wallet gets crushed under a bus, you can still use these 24 words to recover everything. These words never touch an internet connected device thanks to good old fashion pen and paper, so they're safe from those unknown electronic threats.

3) They are made for one purpose and one purpose alone. The more complex a system is, the more vulnerabilities that system will have. You don't need an operating system with 50 million lines of code [12] in order to store some keys and sign some transactions. The more code, the more bugs.

So are HW wallets fool-proof?

Not entirely.  Nothing is fool-proof.

You have to trust the creator of the HW wallet, trust that the source of randomness they use when creating your keys during initialization is a good one, and trust that hackers wont steal the manufacturer's keys in order to create rogue firmware.

But even with all this, its a lot better than any of the alternatives.

One other note, you still need to trust the computer you are connecting with to some extent. For example, is the laptop giving you the correct destination address when you want to send your money? How do you know it's not a hacker controlled fake one that malware switched at the last minute? Many HW wallets have a display screen showing the destination address that you can use to confirm, but its still best to verify the address you're using from multiple sources, like both your phone and the laptop.

The two big HW wallets right now are the Ledger Nano S and the Trezor. My current preference is the Nano S due to its strong memory isolation and use of a secure element chip. [13] 

One last bonus bit:

So now your keys are resting quietly on your Ledger Nano S, locked away in a safe, with your paper recovery key in a vault somewhere across the world. Are your (RandomCoinName) coins finally safe?

Not necessarily. (RandomCoinName) might be total garbage. Just because people bought into a coin and pumped up its values doesn't mean the tech behind it is secure. Many cryptocurrency protocols have had massive vulnerabilities! Some of those vulnerabilities have been disastrous and irrecoverable. [14] [15] [16] [17] [18] [19]

At the end of the day, its all about what risk you're comfortable with.  If your wallet is only a couple hundred USD worth, you might not care as much about hardware backdoors in Intel chips.  Maybe you keep an amount you're willing to lose on your mobile app and the rest on your HW wallet for cold storage. 

All that being said, if you hold any amount that you don't want to lose, maximize your security where you can. There has never been a better target for malicious hackers to go after, and as popularity increases, the target only gets bigger.

Research what you're buying, look for proof that the developers know what their talking about and are prioritizing third-party security reviews, and protect your keys as best you can.

And of course, #hodl

Friday, October 14, 2016

AuthMatrix v0.6 Released

Since its release a year ago, AuthMatrix has enabled countless engineers to unwind the manual loop of authorization testing and simplify the task of securing web applications.

Today I am excited to announce the newest major version release: AuthMatrix v0.6.

AuthMatrix v0.6 is a three week effort resulting in approximately 1000 additional lines of code to provide a suite of new features, improvements, and bug fixes. With these changes, the capabilities of AuthMatrix have been heavily expanded. AuthMatrix can now be used to achieve more comprehensive authorization testing in more complex web applications and services.

Whats New?


A complete list of new improvements and features can be found the CHANGES file on Github.

Some of the highlighted changes include:

Failure Response Regex


One of the most requested features for AuthMatrix was the ability to set regexes for failure cases rather than success cases.  This might be handy in situations where every page returns a unique response on success, but returns a predictable error when the application fails due to authorization errors.

For example, let's say your application returns a unique response on success, but consistently returns an HTTP 303 when authorization fails.  With AuthMatrix v0.6 you can simply set your Response Regex to that HTTP code, right click the relevant messages, and Toggle the Regex Mode to Failure.  The regex will be highlighted in purple to indicate the setting and AuthMatrix will successfully confirm that only users with insufficient permissions see that failure response code.



Edit Requests from AuthMatrix


Before this release, if you wanted to edit the baseline request of a message in AuthMatrix, you had to move that message to another area of Burp like repeater and edit it there, adding it back to AuthMatrix once completed.  Now AuthMatrix allows users to edit requests from within AuthMatrix itself, saving users the hassle of removing and reorganizing messages. Simply select the message you would like to change and type in the Original Request text box as you would with Repeater.

Additionally, users can now right click messages within the message table and modify the target server as well. Through this interface, users can edit the target host, port, and HTTPS configuration of any message.

One of the common use-cases is to configure AuthMatrix against a target webapp in a development environment.  This presented challenges to users who had saved AuthMatrix states with messages targeting domains that had changed or were no longer accessible.  Now users can load AuthMatrix State Files and simply edit all requests to point at the new target.




AuthMatrix Chains


AuthMatrix Chains is a new feature for advanced configuration of AuthMatrix.  With chains, you can link values found in a message's response and replace them into the body of another message.  Users have the option of connecting messages to perform advanced actions within AuthMatrix, such as populating fresh CSRF tokens into each request or running authorization checks against newly generated IDs/GUIDs.

Chains can be configured through clicking the New Chain button at the bottom of AuthMatrix.  Once clicked, a new table appears that allows configuring a Chain using regex search and replacement.



To configure a Chain, enter the source message's ID, an optional User ID (for Pitchfork Mode discussed below), a regex to extract the value from the source message's response, a list of destination messages, and the regex used to replace the value into the proper location.

When a chain is enabled, AuthMatrix will run the regex against the source message's response and identify the value to be extracted.  For each of the destination messages that are run after, AuthMatrix will automatically insert this value into the request as defined by the regex.

Additionally, since chains require destination messages to be run after a source message, the message table now supports the ability to drag-and-drop messages in order to modify their run order.


AuthMatrix Chain Modes


There are two modes in which chains can be used: Standard and Pitchfork

Standard Mode: A value will be extracted from the message response for each individual user and then placed into those corresponding users' destination messages. Chains in this mode are not directly used for testing new authorization scenarios, but may be useful in order to run an AuthMatrix configuration successfully. A common scenario for using Chains in Standard Mode is with Anti-CSRF tokens, since these tokens can be short-lived and user-specific.

For example, Message 1 might be a simple GET request to a "Contact Us" page that returns a form with a new Anti-CSRF token. Message 2 might then be a POST request submitting that form.  By chaining the token from Message 1 into Message 2, you can successfully use AuthMatrix to test authorization, despite any advanced CSRF protections present in the application.

To set a chain to Standard Mode, leave the SRC - User ID field empty.

Example Chain Entry: 
Name:   CSRF
SRC - Msg ID:   1
SRC - User ID:
SRC - Regex:   <input .* name="csrfToken" value="(.*)" />
DEST - Msg ID:   2
DEST - Regex:   csrfToken=(.*?)&


Pitchfork Mode: The source value is extracted from the message response of only one selected user. This value is then inserted into the subsequent requests for all users. This is most useful when testing new authorization cases where a newly created identifier must only be accessible to that one specific user.

For example, Message 1 might be a request that creates a new order on an e-commerce website and returns an Order ID. Message 2 might then be a request that views the status of that order.  To test this authorization case, you can define a new role called "Only Bob" and set Message 2 to only allow that role.

You can then define a chain that propagates the Order ID generated when user "Bob" runs request 1 into the parameters of Message 2 for all users.  If any user that is not "Only Bob" succeeds with this new Order ID, AuthMatrix will flag this as a vulnerability.

Pitchfork Mode can be enabled by entering the User ID of the user whose response value is to be propagated.

Example Chain Entry: 
Name:   OrderStatus
SRC - Msg ID:   1
SRC - User ID:   0
SRC - Regex:   "orderID"="(.*?)"
DEST - Msg ID:   2
DEST - Regex:   GET /orderStatus\?id=(.*?) HTTP/1.1


Try it Now!


AuthMatrix v0.6 is available on Github and will be updated in the BApp Store soon. Give it a try and be sure to submit any feedback to the Github issues page!

https://github.com/SecurityInnovation/AuthMatrix

Cheers,
-Mick

Wednesday, January 27, 2016

AuthMatrix for Burp Suite

I'm very excited to announce the release of a project that I have been working on for some time now. AuthMatrix is an extension to the Burp Suite testing utility designed to improve the process of verifying authorization protections in web applications and web services.

The idea for AuthMatrix came in an attempt to solve a huge problem in web security testing. Unlike many other classes of vulnerabilities common in webapps, authorization bugs are hard to generalize between applications and because of that, the process for validating all authz cases can be time consuming and painstakingly manual. Not only this, but once the testing is completed, it is rarely possible to quickly repeat the test or verify the tester's results with any level of assurance.

As I describe during my talk given at Appsec California 2016 introducing AuthMatrix, the current manual process for testing authorization in web apps and web services can look a bit like this.

  • Enumerate roles and map entire application's functionality
  • Authenticate all necessary users
  • Test every combination of user and request:
    • Run request
    • Observe response
    • Determine if behavior is correct for that user's privilege level
    • Record results to a notes file

There are several major choke points to note with this testing methodology. The first being that the majority of this process is done manually, with only a checkbox in a notes doc to verify the results.  Additionally, the testing process described in the last item above can essentially be viewed as a LARGE manual for-loop, where initiating requests, calculating results, and recording the output is all done by hand. This combination introduces a significant number of opportunities for human error to occur with no ability to verify the tests were performed correctly. This, unfortunately, can often result in critical authorization vulnerabilities being missed, even by the most skilled and diligent pentesters.

With AuthMatrix, we restructure this process so that defining your system's characteristics are front-loaded and the application takes care of all the testing and validation.  Pentesters define a set of roles, users, and requests that sufficiently cover their target application's capabilities and assemble tables similar to those used in many threat modeling techniques. These tables can be verified at any stage of the testing process and saved to disk for later regression testing.



The primary goal of the project was to create a tool that made this process easier and more efficient for the tester.  No point in making an App that no one will use. AuthMatrix achieves a high level of usability with a simple UI and provides an easy to read interface indicating the results of the test.

With AuthMatrix, we've managed to unwind the manual for-loop in the methodology above so that the risk of missed vulnerabilities due to complexity and human error is significantly reduced.

So, after a warm reception at the Appsec California 2016 conference, I'm happy to say that the extension is now fully available to the public. AuthMatrix can be found through the Security Innovation public Github page or can simply be installed directly in Burp for free in the BApp Store.

Give it a try and let me know what you think.

-Mick Ayzenberg


Links:

https://github.com/SecurityInnovation/AuthMatrix

https://portswigger.net/bappstore/ShowBappDetails.aspx?uuid=30d8ee9f40c041b0bfec67441aad158e

http://schd.ws/hosted_files/appseccalifornia2016/50/AppSec-AuthMatrix-MickAyzenberg.pdf




Tuesday, July 15, 2014

Bitcoin Research Whitepaper Announcement

I'm very pleased to announce the release of the whitepaper describing my research into Bitcoin and associated mining software.  This paper outlines some existing weaknesses in the Bitcoin network, presents the findings from my research, and discusses the security impact of these vulnerabilities on the mining community and the Bitcoin network.

Contributing to the security of this cutting-edge technology has been an incredible experience. Learning about this exciting technology, formalizing a research plan, responsibly disclosing my vulnerabilities, and presenting my results at Toorcamp 2014 has all been tremendously rewarding.  Thank you to my company Deja vu Security for providing time and guidance throughout the entire process.

The paper can be found at the following URL:
http://www.dejavusecurity.com/s/Bitcoin-Mining-Security-Deja-vu-Security-2014.pdf

- Mick Ayzenberg

Wednesday, December 11, 2013

Perfect Forward Secrecy

There comes a time in every security consultant's career when they must step up to the plate and rehash some old topics in a blog. It is a right of passage to go out and share some insight into an interesting technical topic, often one that has already been covered to death, with hopes that their point of view will be just a tiny bit more interesting or understandable than the last article's.  Well this is that time for me and I've decided to write on the topical subject of Perfect Forward Secrecy.

I like the idea of discussing Perfect Forward Secrecy (PFS) for a few reasons. First, the term has become a very notable buzz word lately in relation to the recent government scandals we've all grown to love. Second, the math behind it is fairly simple to understand and it requires only a basic understanding of SSL and Public-key cryptography to get a grasp of the ideas. Third, it is not supported nearly enough and hopefully, when more people understand why it's absolutely necessary, more organizations will decide it is important enough to require.

Perfect Forward Secrecy is a property of cryptography. It is implemented in certain cipher suites of SSL and offers tremendous privacy benefits. But before we go into what PFS accomplishes and how it works, lets talk about what we are trying to fix.

What is the problem?


We need the ability to communicate privately over the web. This fact is not debatable. A modern user of the web must have the ability to visit sites and communicate knowing that their sensitive data (passwords, credit card numbers, etc) will arrive where it is intended to go without being viewed or tampered with. Right now SSL/TLS is our browsers' primary protection from eavesdropping over the net.  It uses a combination of asymmetric and symmetric cryptography to accomplish this.

When you enter a website and you see the little lock symbol next to the URL this informs you that your session is encrypted over SSL.  A lot of things are happening in the background during this communication.

Lets say for example you are visiting your bank's website that communicates over SSL.  A very simplified view of this connection is the following:
  1. Your browser asks for the bank's certificate, or public key, and verifies it is legitimate.
  2. Your browser creates a new, random, one-time, shared secret key.
  3. You encrypt this new secret with the banks public key and send it to the bank over the internet.
  4. The various properties of asymmetric cryptography prove that the only way to decrypt a message encrypted with a public key is with the matching private key. The bank is the only entity with this matching private key and uses it to decrypt the message and obtain the shared secret from earlier.
  5. All communications onward for the duration of the session are encrypted with the shared secret. Only you and the bank know this secret and thus only you and the bank can decrypt these messages.
  6. Once your session has completed the shared secret is discarded by both parties and never used again.
                  You                                  Internet                                      Bank                          
_____________________________________________________________________________

1)          [ pubkey ]             <-------------------------------------                  [ pubkey ]

2)           [ secret ]

3)     [ encrypt(secret, pubkey) ]         --------------->                [ encrypt(secret, pubkey) ]

4)                                                                              [ decrypt(encrypt(secret,pubkey),privkey) ]
                                                                                                           =
                                                                                                       [ secret ]



5)    [ encrypt(message, secret) ]        -------------->             [ encrypt(message, secret) ]

                                                                            [ decrypt(encrypt(message, secret),secret) ]
                                                                                                           =
                                                                                                    [ message ]


       [ encrypt(message2, secret) ]            <-----------           [ encrypt(message2, secret) ]

 [ decrypt(encrypt(message2, secret),secret) ]
                         =
                  [ message2 ]                                                                        
_____________________________________________________________________________


Now, there are a lot of points in this process where things can go drastically wrong. The public key used in step 1 can be fake or compromised through various methods, the secret/private keys may be small enough to bruteforce or crack, the cryptographic functions used to encrypt and decrypt might be provably insecure, or the random number generators might be compromised.  All of these are valid threat vectors for breaking SSL, but we are not going to focus on any of them today. We are going to assume that everything above just works.

Under our current assumptions we assume that this methodology accomplishes what it is set out to do.  You are choosing a secret that only you and your bank's website know and using it to encrypt all of your communication.  You are able to tell the bank, and only the bank, this secret because you encrypted it with their real public key and the only way they can decrypt it is with their real private key.

The pressure point we are going to explore here is around an attacker stealing the bank's private key.  If an attacker obtains a private key they will have the ability to impersonate whomever the true owner is and it is game over.  The attacker can trick your browser into thinking it is the bank in question and decrypt any messages you send to it without any warning.

But what makes this problem an interesting problem?  There are already various methods of responding to this kind of breach in ways where the attacker can't use old and stolen private key. These include revoking the certificate and in some cases shutting down the service altogether.

What makes this threat interesting is when an attacker is storing all the encrypted internet traffic from across the planet in their colossal data centers until the end of time.  With the protocol defined above an attacker would only need to obtain a private key,  possibly months or even years later, and decrypt the message sent in step 3.  By decrypting that message the attacker obtains the shared secret and can decrypt all the private communications of that session.

We are now aware that this not only something that can be done, but something that is actively being done.

This is the problem.  This is what Perfect Forward Secrecy so elegantly solves.

What is PFS?


Perfect Forward Secrecy is a concept where communication between two parties is not only encrypted, but will remain encrypted even if their primary encryption keys are later stolen. In the context of SSL it is an exchange that allows a browser and a website to agree on a shared secret without ever needing to say what that secret is over the wires. This way even when private keys are stolen, they can not be used to decrypt the shared secret. Since the shared secret is needed to decrypt every subsequent message in the session the stored communication remains indecipherable.

The math behind this is surprisingly simple and intuitive.  It uses the Diffie-Hellman key exchange to create the shared secret using some simple properties of integers.

When simplified, Diffie-Hellman works something like this:

  1. Your browser comes up with two numbers that anyone can know, p and g. lets say ours are p=5 and g=3.
  2. Your browser then picks a secret number that only it knows, a.  Lets say a=4
  3. Your browser sends the bank those two public numbers, p and g, along with (g^a) mod p.  
    • (3^4) mod 5 = 81 mod 5 = 1
    • (g^a) mod p = 1
  4. The bank then picks a secret number b, we'll say b=7, and sends back (g^b) mod p.
    • (3^7) mod 5 = 2187 mod 5 = 2
    • (g^b) mod p =2
  5. Since ( (g^a)^b) and ( (g^b)^a) are equal mod p, both parties can calculate ( (g^a)^b) mod p and agree that this value will be the shared secret.  
    • The bank can compute this because it knows b, p, and (g^a) mod p:
      • ( ( (g^a) mod p) ^ b) mod p = ( (g^a)^b) mod p
      • ( (1) ^ 7) mod 5 = 1
      • Shared Secret = 1
    • The browser can compute this because it knows a, p, and (g^b) mod p:
      • ( ( (g^b) mod p) ^ a) mod p = ( (g^a)^b) mod p
      • ( (2) ^ 4) mod 5 = 16 mod 5 = 1
      • Shared Secret = 1
    • Most interestingly, anyone who has intercepted the traffic will know p, g(g^a) mod p, and (g^b) mod p, but there is no efficient way to generate ( (g^a)^b) mod p from those values. Thus an attacker who can see this traffic will still not know the shared secret.
    * Note: the algorithm above was highly simplified and used small numbers for clarity.  To ensure the shared secret is not cracked p must be prime, g  must be primitive root mod p, and all integers must be much larger.

If you add this key exchange method into the graph from before it will look something like this:

  1. Your browser asks for the bank's certificate, or public key, and verifies it is legitimate.
  2. Your browser generates p, g and a for its side of the Diffie-Hellman exchange.
  3. You  encrypt the Diffie-Hellman parameters with the banks public key and send it to the bank over the internet.
  4. The bank generates a value for b and responds in the clear with its Diffie-Hellman parameters.
  5. Both the browser and the bank now agree on a shared secret that was never explicitly stated. 
  6. All the rest of the communication is encrypted with that shared secret that only you and the bank know.
  7. Once your session has completed the shared secret, variable a, and variable b are all discarded by both parties and never used again.


                  You                                       Internet                                Bank                          
_____________________________________________________________________________

1)             [ pubkey ]             <-----------------------------------                [ pubkey ]

2)                [ a ]

            [ p,g, (g^a) mod p ]

3)    [ encrypt((p,g, (g^a) mod p), pubkey) ]      ----->        [ encrypt((p,g, (g^a) mod p), pubkey) ]

                                                               [ decrypt(encrypt((p,g, (g^a) mod p),pubkey),privkey) ]
                                                                                                                 =
                                                                                                    [ p,g, (g^a) mod p ]



4)                                                                                                       [ b ]

               [ (g^b) mod p ]                     <-----------------------          [ (g^b) mod p ]

         

 5)     secret = [ ( (g^a)^b) mod p ]                                        secret = [ ( (g^a)^b) mod p ]  



 6)    [ encrypt(message, secret) ]        ----------------->          [ encrypt(message, secret) ]

                                                                              [ decrypt(encrypt(message, secret),secret) ]
                                                                                                             =
                                                                                                      [ message ]


       [ encrypt(message2, secret) ]            <-------------               [ encrypt(message2, secret) ]

 [ decrypt(encrypt(message2, secret),secret) ]
                         =
                  [ message2 ]                                                                      
_____________________________________________________________________________

The server's public key is still used to guarantee authenticity of the web server. The new shared secret is freshly generated every session and once the Diffie-Hellman parameters have been deleted, the private key can not be used against stored traffic.

What's next?


We have to live with the fact that all encrypted internet traffic will be stored permanently.  We also have to live with the fact that the websites we trust so dearly may eventually have to surrender their private keys.  What we don't have to live with is that those private keys will be able to decrypt our session's data years later.  There are already SSL cipher suites that support PFS such as the following:

ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-RC4-SHA
DHE-RSA-AES256-SHA
To identify suites with PFS look for either DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman) in the name. In order to mitigate this threat these suites must be supported and prioritized by browsers and web servers by default.

Hopefully over time web servers will begin to support PFS suites by default in the same way that many sites are now migrating to SSL all the time. I'm crossing my fingers that this happens sooner than later.