How does TLS generate the shared secret?

Question

From many readings, I got to know that TLS generates master shared secrets using pre-master keys and uses the DH algorithm to generate the shared secret/Master secret.

What values during the hello messages act as
1. P - Prime number
2. G - Generator
3. Secret primes owned by each parties
?

Why does it need a client-server random number along with the pre-master secret to generate the master secret as DH requires only p, q and (a,b) are generated on each side?

Answer 1

Selection of the Diffie-Hellman parameters

If you are asking about the TLS cipher suites that use a Diffie-Hellman exchange (basically the ones containing "DH" or "DHE"), it depends on whether static or ephemeral Diffie-Hellman certificates are used.

• The ephemeral cipher suites (DHE_DSS, DHE_RSA, DHE_anon and the various elliptic counterparts) transmit the generator, the prime modulus and the public value in the server and client key exchange messages.

• The static cipher suites using Diffie-Hellman (DH_DSS, DH_RSA) use the (fixed) parameters embedded in the server certificate. If a client certificate is used, the parameters have to match the server's.

Not all cipher suites use a Diffie-Hellman exchange, though; in the (widely used) RSA_* cipher suites, the client sipmly selects a random premaster secret and encrypts it using the server's public RSA key.

Purpose of the client/server random values

The client and server randomness serves to avoid ever using the same emaster secret twice; for example, when a static Diffie-Hellman ciphersuite is used with a client certificate, the server's and the client's Y value don't change between sessions. This is done by securely hashing the premaster secret (which might or might not be equal for different sessions) and the client and server random values (which are required to be different for different sessions).

Reusing the master secret could allow replay attacks or cause the symmetric cipher to reveal information about the payload data.

Answer 2

To answer your question about:

What values during the hello messages act as
1. P - Prime number 
2. G - Generator 
3. Secret primes owned by each parties  

In the TLS Handshake protocol for DH/DHE, the P and G are found in the ServerKeyExchange message. The secret primes owned by each parties would NEVER be transmitted over the communication channel, otherwise the whole DH key exchange mechanism would be compromised. A good idea would be to use Wireshark to examine the TLS packets. Otherwise, the ServerKeyExchange message would take this message format:

Content Type: 0x16 (1 byte) || TLS Version (2 bytes) || Length of Overall Message (2 bytes) || Handshake Type: 0x0c (2 bytes) || Length of Handshake Message (3 bytes) || DH P Length (2 bytes) || DH P value (variable) || DH G length (2 bytes) || DH G value (variable) || DH Ys Length (2 bytes) || DH Ys value (variable) || Signature (if any) ...

Furthermore, if you want see the computed value (i.e. g^a mod p, where a is the client's secret integer) by the client being sent to the server, you can check the ClientKeyExchange message by identifying the Handshake Type: 0x10.

Note: Ys represents g^b mod p, where b is the server's secret integer. (A good reference could be found here on page 15)

Answer 3

RFC 4279 contains all the information you need about the Pre-Shared Key (PSK) Ciphersuites for Transport Layer Security (TLS). The TLS-PSK standard consists of mainly the following three ciphersuites, TLS_PSK, TLS_DHE_PSK, and TLS_RSA_PSK. Each of them will derive the master secret differently.

In TLS_DHE_PSK, the master secret is computed using the pre-shared keys and a fresh DH key that is exchanged between client and server. The TLS handshake protocol consists of 10 handshake messages and the values of p, q and g (or DH key exchange parameters) are include inside the ServerKeyExchange instead of being inside the hello messages. The ClientHello message only includes the client preferred ciphersuites while the ServerHello message contains the chosen ciphersuite.

The PSK is used in the computation of the Pre-Master Secret and subsequently for computing the Master Secret. i.e. Pre-Master Secret = length of Z ||Z||length of PSK || PSK where || denotes contencation and Z is the symmtetic key exchanged during the DH phase.

Not too sure about the usage of the two random nonces here, maybe the nonces are used to verify that you are still communicating with the same server and not some third party who intercepted the message halfway.

Answer 4

It depends on both the cipher suite and on the server implementation.

• If one of the DHE cipher suites is negotiated, the server will send the group parameters P and G together with a public key Y in a Server Key Exchange Message that will be signed using the private key corresponding to the server certificate. The TLS standard does not specify how these parameters are generated, all it says on the matter is that implementations should take care to avoid small sub group attacks.
• If a DH_anon cipher suite is negotiated, the situation is the same as in the DHE case, except that the server will not sign the Server Key Exchange Message, which means that the key agreement is vulnerable to man-in-the-middle attacks. The standard still doesn't say much on how the parameters are to be generated.
• If a DH cipher suite is negotiated, the server must use a certificate with a DH public key. A static-ephemeral key agreement will be initiated, where the server will always use the same key pair (the one corresponding to the certificate). The parameters will be encoded into the certificate and signed by the Certification Authority when the certificate is issued. The X.509 PKIX standard does not specify exactly how this is supposed to be done.