CNS - 27 - TLS Handshake II

Lecture Info

  • Date: [2020-11-23 lun 14:00]

  • Lecturer: Giuseppe Bianchi

  • Slides:

  • Introduction:

1 Entity Authentication

Notice that even after introducing the concept of a certificate, which binds a public key to an entity, we still did not solve the problem of entity authentication. You can show google certificate, but it does not mean that you are google.

What actually works for entity authentication is rather to show that you know the private key associated to the public key included in the certificate. To actually do this there are two possible ways:

  • Using digital signature, in which the client shows the certificate and then signs a nonce given by the authenticator. This method works because only the owner of the private key can correctly sign the nonce.

  • Using encryption, in which the client sends the public key to an authenticator through a certificate, and the authenticator sends back some encrypted text using the public key of the client. For the client to prove his authenticity he/she has to decrypt the text using her/his own private key.

    This method can be implemented in a slightly different way, by proving knowledge of the transferred key. With this other approach after the client sends the authenticator his/her public key, the authenticator replies back with a symmetric key encrypted with the public key received. Then the authenticator sends another message, encrypted with the symmetric message sent before, and the client, to prove that he is real, can simply decrypt the data using the symmetric key. This is the base approach used by TLS.

2 TLS Handshake (cont.)

Let us then resume our discussion about the TLS handshake process. So far we had discussed about the first two phases, which are here briefly described

  • Phase 1: In this first phase both the client and the server start the handshake with the basic negotiation, which is done in plaintext with the two messages client hello and server hello.

  • Phase 2: Then, in the second phase, the server sends the client the certificate.

Let us now discuss the last two phases of the TLS handshake process.

Observation: these "distinct phases" are just a way to understand better the TLS handshake process. They do not exist per se, but are rather denoted like this just for teaching purposes. The key point is that each phase does something logically different.

2.1 Phase 3: Client Auth

In the third phase we deal with client authentication, which is implemented using a digital signature mechanism, in which the server sends us a nonce and we sign it with our private key.

Notice that even if in the diagram there it doesnt show any nonce beign sent from the server to the client, in pratice the nonce is sent in the server hello message sent during the first phase of the handshake.

The contents of the messages send by the client are:

  • Certificate: contains the certificate of the client.

  • Client Key Exchange: contains either the DH public coefficient or the RSAencoded symmetric key to be used for later encryption.

  • Certificate Verify. contains the digital signature of the nonce sent by the server.

In the third message, the certificate verify message, there is a beautiful optional approach: instead of having the client sign only the nonce, the client signs instead all the messages exchanged up to now. With this approach TLS is able to detect at an early stage tampering attacks, such as cipher suite downgrade attacks, and things of the sort. While this is a beautiful approach, it is also an optional approach, since most of the time client authentication is not supported.

2.1.1 Biddown attacks

Downgrade attacks are when you attack a system by forcing the client or the server to use an old, vulnerable version of a given protocol. There are other attakcs, call biddown attacks, in which you force the other party to use specific options. Conceptually however downgrade attacks and biddown attacks are the same.

To protect against this types of attacks the idea is: exchange plaintext messages for the negotation, but before switching to encrypted mode to secure protected data, each parties repeats everything they have agreed to. More generally, each parties repeats the hash of the entire sequence of messages.

2.2 Phase 4: Finishing up

The final phase of the TLS handshake has two fundamental goals:

  • Switch to the new security connection state and activate encryption and message authentication.

  • Authenticate all the previous handshake messages to avoid MITM tampering.

The messages sent at this stage are depicted below

In this phase we also have server authentication, because in the finished message sent by the server the clients expects to find something encrypted with the symmetric key, which the server is able to obtain only if he has the private key associated to the public key contained in the certificate.

2.3 Handshake with Encrypt but w/o Auth

TLS supports various cipher suites, such as

  • \(\textbf{TLS_RSA_WITH_NULL_NULL}\)

  • \(\textbf{TLS_RSA_WITH_NULL_SHA}\)

however it does not support a cipher suite characterized by having an encryption algorithm but no message authentication such as

\[\textbf{TLS_RSA_WITH_AES_NULL}\]

This is because if something like that was used, then TLS would be broken by a biddown attack. Indeed, with this cipher an attacker could simply intercept the last finished message and change in such a way as to encrypt properly a tampered log to show to the server.

2.4 Abbreviated Handshake

When we resume a session we keep the same pre-master secret but we change the master secret and the various connection state keys. This means that the handshake is shorter, and it works as follows.

For more information about the pre-master secret and the master secret. Read further to the Secret Hierarchy section.

3 Change Cipher Spec

Historically up until TLS v1.3 to move to encryption mode a different protocol colled Change Cipher Spec was used.

This is the simplest protocol known in the internet, which consists of a single message, of a single byte, of a fixed content.

Nowadys it is not used anymore.

4 TLS Key Computation

So far in our discussion of TLS we have analyzed how to generate a single secret between the client and the server. There could be need to generate more keys however, one for each security service. Also, depending on the transport protocol used to exchange the key, different problems could arise:

  • If RSA transport is used, the key is completely generated on the client side, which could lead to problem with the quality of the randomness used.

  • If DH key agreement is used, the final value \(g^{x \cdot y} \mod p\) could not be uniformly distributed in \(\{1, 2, \ldots, p-1\}\).

Let us now understand better how keys are generated and managed in TLS.

4.1 Secret Hierarchy

In general in any protocol we have the following hierarchy of secrets

the particular terminology used is described as follows:

  • Pre Master Secret: This is the key generated by the RSA transport or by the DH key agreement. It could always be the same value for the same C-S pair, for example when using Fixed-DH.

  • Master Secret: This key is obtained by the pre master secret by combining it with a random values from the client and the server and timestamps from the client and servers. It is recomputed at session resumption. During the computation of this master secret we also perform the extract operation, meaning that even if the pre master secret key was not uniformly distributed, we make sure that the master secret is uniformly distributed.

  • Connection State Keys: These are the keys which are used for the specific security services. Each service, like encryption and authentication, requires a different key. In TLS for example up to 6 keys are generated from the master secret, since we have three kind of services (encryption, authentication, and initalization vectors), and for each direction of the flow we have a different key. These keys are obtained by performing an expand operation.

4.2 Extract-then-Expand

As we can see to create this hierarchy we have to solve the following two procedures:

  • Extract operation: The operation that lets us generate the master secret from the pre master secret. It should guarantee good statistical properties for the master secret.

    The extract operation is crucial, because all the theorems derived in formal crypto start from the assumption that the key we're working with is uniformly distributed.

  • Expand operation: The operation that lets us generate the various keys to be used for the actual security services.

4.3 Pseudo Random Functions (PRFs) in TLS

The basic building blocks for these operations are the so-called pseudo random functions. A pseudo random function is a function which takes in a seed, some oher data, and a secret, and procudes in output random unlimited data

The PRFs used in TLS had various problems:

  • In SSL v3.0 the PRF used was fixed and not fully satisfactory.

  • In TLS v1.0 and 1.1 they used a good PRF but the construction used the MD5 and SHA-1 hash functions, which later both got broken.

  • in TLS 1.2 finally they introduced a negotiable PRF, where the default construction is based on SHA-256.

4.4 HMAC-based Key Derivation Function (HKDF)

In 2010 H. Krawezyk proved the security of a new mechanism which he called HKDF (HMAC-based key derivation function), standardized in RFC 5869.

The algorithm is straight forward: we use an HMAC function, which takes in input a key \(k\) and an hash function, and we simply use a counter to generate new keys by compuing each time the HMAC of a context string, which stays the same, and the counter, which gets increased by \(1\) everytime.

Observation: The context string was introduced to allow multiple processes to generate different keys from the same master secret.

The HKDF is used for both the extract and the expand operation, even though theoretically the theorems proved by Krawezyk broke down when using a HKDF with a pre-master secret.