3

With perfect forward secrecy, if an attacker gains access to a certificate private key, my understanding is that all traffic previously encrypted using that private key remains safe from decryption.

But does perfect forward secrecy provide any guarantees with regards to future traffic encrypted using the compromised private key? Does the degree of vulnerability change with periodic regeneration of Diffie-Hellman parameters?

Of course, compromise of a certificate private key exacerbates a variety of MITM attacks and must be replaced as soon as possible, but in cases where the compromise might not be discovered for some time, what level of secrecy is provided during the interim between the compromise and the replacement of the private key?

1 Answers1

8

If information was directly encrypted to the compromised key, it's not forward secret.

Forward secrecy generally works by having the long term keys (the ones that have the greatest chance of being compromised) used for authentication only. These are used during a key agreement protocol which generates a set of ephemeral keys which are actually used to encrypt and decrypt data. These ephemeral keys are then discarded after use, and new ones are generated when needed.

In TLS, the cipher suites that provide forward secrecy are the ones with DHE or ECDHE in the name. For example, TLS_RSA_WITH_AES_128_GCM_SHA256 is not forward secret, while TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 is forward secret. The difference is how the RSA key from the certificate is used in the key exchange part of the handshake.

In the non-forward secret TLS_RSA_WITH_AES_128_GCM_SHA256, keying material is encrypted to the RSA key. If that RSA key is later compromised, that keying material can be decrypted, and the TLS traffic is exposed.

In the forward secret TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, the RSA key is used to authenticate the Diffie-Hellman key exchange, from which keying material is derived. Even if the RSA key is stolen, the keying material for that session is safe, because the RSA private key was not used for encryption of keying material.

From this, it should be easy to see that if an RSA key is compromised but not detected, then it can still be used to break some future sessions with forward secrecy enabled. A client would connect to the MITM, trust it because it has the right key, and the session key will actually be negotiated with the MITM, leaking supposedly private info. If the client connects to the real server with forward secrecy turned on, then the attacker gets nothing, because they still can't use the stolen RSA key to break the Diffie-Hellman key exchange. If forward secrecy is turned off, connections to a server with a compromised key can still be snooped on by the attacker with access to the private RSA key in the same way they could decrypt past sessions.