Where is Challenge/Response and Certifcate Verification in TLS-DHE

Question

We have been give a task to identify the following three components in TLS-DHE:

1. Diffie Hellman Key Exchange

I am fairly certain that this Part can be found in the Exchange of SKE and CKE, since they contain the public Key with Signatures and can be used by the other party to derive a shared key

2. Challenge/Response

I am having trouble identifying this part. Since this part is usually something you would do before exchange a key, i reccon it can only occur in the Part with the CH. However, i fail to see how CH (CHallenge?) is a challenge for the Server S, because usually challenges are solved by using private information

3. Certificate Verify

I know the Certificate consists of Public Key and digital Signature, but how can a Certificate be authenticated here without having established a shared secret yet? I do not see any Certification Authority here as well, so i am clueless

Answer 1

Diffie Hellman Key Exchange

The assignment $y\overset{s}\gets{\mathbb{Z}_q}$ generates a random 48 bytes value (no idea what $s$ and $q$ are here) which remains private secret for the server throughout the whole handshake.

The server users a DH group of its liking with generator $g$ and modulo $p$ and calculates $Y\gets{g^y} \mod p$ for its public key and all these "parameters" $p$, $g$ and $Y$ are sent in $SKE$ message to the client as plaintext.

The client generates its own 48 bytes random private secret with $x\overset{s}\gets{\mathbb{Z}_q}$ and uses DH group's $g$ and $p$ as received in the server $SKE$ message to calculate and send back its $X\gets{g^x} \mod p$ public key in $CKE$ message.

Both client and server are ready to calculate the premaster secret $pms = CDH(X, Y) = g^{xy}\mod p$ with the client using $pms = Y^x\mod p$ and the server calculating $pms = X^y\mod p$ and both arrive at a common premaster secret $pms$ which a MITM cannot calculate because CDH is computationally intractable and both $x$ and $y$ are not sent over the wire.

Challenge/Response

This $r_C\overset{s}\gets\{0,1\}^{224}$ generates a client random of length 224 bits (must be 256 bits for TLS) and the same for $r_S$ server's random.

Both of these get used in generating master secret $ms$ from premaster secret $pms$ using TLS's $PRF$ function like this $ms = PRF_{pms}(l_1, r_C, r_S)$ where $l_1$ is a label like master secret or extended master secret as plain text and $pms$ is feeded as the starting key for the $HMAC$ used in $PRF$.

If $pms$ at both parties do not match then $HMAC$ and $PRF$ will produce different master secrets $ms$. If these in turn do not match the expanded keys and IVs for the symmetric encryption in both directions will not match too, so the protected $FIN_C$ and $FIN_S$ messages will fail MAC auth check as a result.

So if an attacker replays client traffic the different $r_S$ will prevent $ms$ repeating the original session and $FIN_C$ MAC fail. And if the attacker replays server traffic to a client request then the different $r_C$ will prevent $ms$ from matching again.

Certificate Verify

$Sign_{sk_S}$ uses server's secret key $sk_S$ to produce $\sigma_S$ signature while the client can extract the servers public key $pk_S$ from the leaf certificate as received in the $CRT$ message so the client can verify $\sigma_S$ signature. If this is correct the client can be sure the server is in posession of the certificate's private key indeed.

From the other side when the client has to be autheticated the $Sign_{sk_C}$ function uses client certificate's private key to produce $\sigma_C$ signature in $CV$ message which the server verifies with the client certificate's public key as received in client $CRT$ message.

Answer 2

Aside: that diagram is only correct (or nearly) for TLS 1.0 through 1.2, not 1.3. It mentions, without explanation, the number 3.2, which is the internal version for TLS 1.1, suggesting it is intended to match that version, for the two DHE key exhanges (DHE_RSA and DHE_DSS). But it references CDH, which usually means Cofactor Diffie-Hellman, which TLS does not use -- and in that step it doesn't show $p,g$ as parameters which for these protocols they definitely are. (In 1.3 they still are, but via predefined curves which could be considered the 'source'.) 1.0 and 1.2 are identical for most of the handshake, but vary slightly in the second part of the (shared) key derivation.

1. Diffie Hellman Key Exchange
   I am fairly certain that this Part can be found in the Exchange of SKE and CKE, since they contain the public Key with Signatures and can be used by the other party to derive a shared key

Basically, yes. SKE contains the parameters (p,g) and publickey which this calls Y but the RFCs call Y_s; CKE contains publickey here X but in RFCs Y_c. The server also provides a signature in SKE, and the client may provide a signature in CV (adjacent to but not in CKE); while these contribute to the overall handshake they don't contribute to DH itself.

2. Challenge/Response
   I am having trouble identifying this part. Since this part is usually something you would do before exchange a key, i reccon it can only occur in the Part with the CH. However, i fail to see how CH (CHallenge?) is a challenge for the Server S, because usually challenges are solved by using private information

First, the all-caps and mostly-caps items (other than SID = Session Identifier, PRF, and CDH) are clearly abbreviations of the TLS message types:
CH = Client Hello
SH = Server Hello
SKE = Server Key Exchange
CRT = Certificate
CReq = Certificate Request
SHD = Server Hello Done
CKE = Client Key Exchange
CV = Certificate Verify
CCS = Change Cipher Spec
FIN = Finished

See e.g. the summary diagram in RFC 4346 7.3 at page 33. Note Creq in server's first flight, and CRT and CV in client's second flight, are shown in brackets, indicating they are optional; this corresponds to asterisks in the RFC summary diagram.

There are two challenges in the TLS handshake: the client and server randoms, shown here as $r_C$ and $r_S$. These are included in the data signed (server always, client sometimes, as above), and the (shared) key derivation, and the Finished message values (which MAC the handshake).

3. Certificate Verify
   I know the Certificate consists of Public Key and digital Signature, but how can a Certificate be authenticated here without having established a shared secret yet? I do not see any Certification Authority here as well, so i am clueless

Certificate verification and validation (terms which are often interchanged, although a distinction can be made) as applied to TLS includes several steps, and I'm not sure which your teacher intends you to cover. First off, a certificate (of the type relevant here) contains a publickey and signature, but also much other information. And the cert itself is not authenticated, rather it is used to authenticate something else -- in TLS the server is almost always authenticated by a certificate, and the client sometimes (but rarely) is. And although TLS connections almost always use cert-based authentication, strictly speaking it isn't part of the TLS protocol: TLS only conveys the cert data, leaving its processing up to the relying endpoint(s). TLS can also convey certificate 'status' (i.e. revocation) information, in the form of pre-generated OCSP responses; this is called 'stapling' and has become very common since about 2012, but is not in your diagram. And while each certificate is issued by a Certificate Authority, and the related CRL and/or OCSP information either by or on behalf of the CA, the CA is not involved in the TLS protocol.

For a basic explanation of cert chain usage and validation for HTTPS see my old answer to this Q. A bit more formally:

• every certificate is issued and signed by a CA; in practice your server's cert is not signed directly by a root CA, instead there is at least one intermediate CA in between, and the list of certs from your server's cert (or client's when used) through the intermediate(s) to the root is called a chain

• each certificate below the root in a chain is verified by verifying its signature using the publickey from the next cert in the chain or the root; and checking a number of items in the certificate data, see RFC5280 section 6; and checking for revocation, for which there are several options, and expiration

• the set of root CAs that are trusted can be defined separately for each relier, although typically a system-provided or browser-provided default is used; the root CA information is usually stored as a series of self-signed certficates (although this isn't strictly necessary, see e.g. the Java CertPathValidator API) and called a 'truststore'

• for some TLS applications like HTTPS, the name in the 'leaf' (end-entity) certificate for the server is checked to make sure it identifies the correct server (the one the client wanted to connect to)

Answer 3

The best way to learn this is to inspect the packet capture of an actual TLS/DTLS handshake Here is one with TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite. The explanation is here. This blog was written in Chinese, but you can translate it to English with Chrome browser.

Key stages of the handshake:

• The server sends out a Server Key Exchange message, which contains its DH public key $(p,g,A)$ and the signature signed with rsa_pkcs1_sha512
• After that is the Certificate Request message and Server Hello Done message
• The client sends a Certificate message first, the certificate includes the client's RSA public key.
• Then the client sends Client Key Exchange message, which contains its DH public key $B$.
• The client now sends a Certificate Verification message, which contains the signature that covers all messages so far except for Hello/Hello-Verify-Request. This signature is generated with SHA512 then encrypted with the client RSA private key.
• Now both sides verify the signature, then run DH to generate the same pre-master-key, then calls PRF to create master-key and the final key block (48-byte).
• There is a final verification stage for the master key after Change Cipher Spec messages.
• Secure channel is established, data exchange starts