How does non-ephemeral Diffie-Hellman key exchange become compromised in SSL when the RSA private key is leaked?

Question

From my understanding, one of the major reasons we recommend Diffie-Hellman Ephemeral (e.g. DHE or ECDHE) over non-ephemeral DH, for SSL / TLS, is that compromise of the RSA private key (i.e. private certificate) would allow an attacker to decrypt previously captured conversations. In contrast, ephemeral should prevent decryption unless the attacker is in posession of the key at the time of the conversation.

How does this decryption of non-ephemeral Diffie-Hellman key exchange work in this context? Is it simply a case of observing the unencrypted primitives that are exchanged over the wire? If so, what is the point of using DH, if it provides no additional security over encrypting the key with RSA, and RSA already provides authentication of the server?

Answer 1

First let's be sure that we talk about the same thing. In SSL, there are "ephemeral DH cipher suites" (DHE) and "non-ephemeral DH cipher suites" (DH).

With DHE, the server private key (the permanent one, the one which is stored in a file, and whose public key is in the server certificate) is of type RSA (DHE_RSA cipher suites) or DSS (DHE_DSS cipher suites), and is used only for signatures. The server generates a new random DH key pair (the private key will not be stored, which is how perfect forward secrecy is achieved: a private key cannot be stolen afterwards if it has never been stored), and sends the public key to the client, in a message which the server signs with its RSA or DSS private key.

With DH cipher suites, the permanent server private key is a DH private key. The server certificate contains the DH public key. The server cannot see its RSA key be stolen because the server does not have a RSA key. The server only has a DH key. When a cipher suites is called "DH_RSA", it means "the server key is a DH key, and the server certificate was issued (i.e. signed) by a Certification Authority who uses a RSA key".

Stealing the DH private key of one party involved in a DH key exchange allows ulterior reconstruction of the shared secret, just like RSA. In "ephemeral DH", the PFS is obtained through "ephemeral", not through "DH". Technically, it would be possible to have "ephemeral RSA" but it is not done in practice(*) because generating a new RSA key pair is kinda expensive, whereas producing a new DH key pair is cheap.

^{(*) Ephemeral RSA keys were possible with old versions of SSL as part of the "export" cipher suites, meant to comply with the pre-2000 US export regulations: the server could have a 1024-bit signature RSA key, and generate an ephemeral 512-bit RSA key pair for key exchange, used in encryption mode. I don't recall having ever seen that in the wild, though, and it is a moot point since US export regulations on key sizes were lifted.}

---

Non-ephemeral DH cipher suites exist in order to allow servers with DH certificates to operate. DH keys in certificate exist because in older times, RSA was patented but DH was not, so standardization bodies, in particular NIST, were pushing DH as the must-implement standard.

Reality caught up with that, though. I have never seen a SSL server using a DH certificate. Everybody uses RSA. The RSA patent expired a decade ago anyway.

Answer 2

For SSL/TLS, we need 2 things:

1) client needs to authenticate the server.
2) client and server need to compute a symmetric session key.

A few ways of doing both:

Most common: TLS_RSA_WITH_AES_...

RSA is used for both 1 (authentication) and 2 (computing symmetric key).

Preferred: TLS_DHE_RSA_WITH_AES_... or TLS_ECDHE_RSA_WITH_AES_...

RSA is used for 1 (authentication) and for signing the DHE keys.
DHE is used for 2 (computing symmetric key).

Preferred, because you get Perfect Forward Security (PFS)

Not common: DH_RSA_... (this is the non-ephemeral DH in OP's question)

DH is used for both 1 (Authentication) and 2 (computing symmetric key).

The case you are referring to is the 3rd ("Not common") and as you can see, RSA is used neither for 1 (Authentication) nor for 2 (computing symmetric key) and so there is no question of RSA private key being leaked. The RSA in DH_RSA could be misleading but as Tom Leek mentioned, the Administrator of the server will provide credentials and their DH public key to a CA (Certificate Authority) who will then sign the DH public key with the CA's RSA private key.

Answer 3

You've asked about the use of non-ephemeral (static) Diffie-Hellman key exchange and its advantages or disadvantages over encrypting the key session key (premaster secret) with RSA.

In TLS_DH_RSA_WITH_... the signature algorithm (RSA/DSS) indicates the signature algorithm the CA used to sign the certificate and there is no signature as part of the handshake; if the server arrives at the same session key, then it must have the matching DH private key. (Mike Ounsworth)

Thus the "RSA" or "DSS" part in the "TLS_DH_" cipher suite is misleading. It only denotes an algorithm used by the CA to sign the DH parameters (public key), not the actual signature algorithm used during TLS handshake.

In “TLS_DH_” cipher suites, there are two ways for the client to provide its public DH parameters (public key) to the server:

1. via the client certificate;
2. via the ClientKeyExchange message of ClientDiffieHellmanPublic type.

If the client has sent a certificate which contains a suitable Diffie-Hellman key (for fixed_dh client authentication), then Yc is implicit and does not need to be sent again. In this case, the client key exchange message will be sent, but it MUST be empty. (RFC 5246, 7.4.7.2)

When using static Diffie-Hellman with a client certificate, you get mutual authentication in one shot, because a client certificate and a server certificate are used to generate the session keys.

DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). [...] The server [...] request a Diffie-Hellman certificate. Any Diffie-Hellman certificate provided by the client must use the parameters (group and generator) described by the server. (Section A.5 of RFC 5246)

Note that certificates with DH parameters are rather rare anyway.

In theory, if you compare speed and security of DH vs RSA, there are no major differences (nevertheless, there are some details).

In practice, since public CAs no longer issue certificates with the DH parameters, you cannot use "TLS_DH_" cipher suites, so RSA is the only choice between the two non-PerfectForwardSecrecy algorithms that you have mentioned.