7

I'm trying to deeply understand the steps during a TLS handshake.

I've read this answer (which is btw pretty complete), but I still got a question about the utilization of the MasterSecret, in the frame of a ECDHE-RSA-AES-GCM-SHA TLS handshake.

At the end of the handshake, we have used SHA as PRF to generate the Mastersecret (from the pre-MS and the random numbers). We expand it to create key and MAC key. The key is used to cipher the messages, and the MAC key to compute the hash (on the ciphered message if GCM mode). OK.

I have 2 questions about the expansion of the MasterSecret :

  1. In section 8:3, they say that we create 2 MAC keys and 2 keys. Isn't that enough safe if the client and the server use the same key and MAC key ? (given that these key are generated from no less than a MasterSecret). I kind of think that it seem a bit overprotected..

  2. When you have the MasterSecret, how do you expand it to create MAC keys and keys ? I doubt that we just take the first N bytes for the key and the rest for the MAC key...

    Moreover, the phrase When keys and MAC keys are generated, the master secret is used as an entropy source. (section 8:3) bothers me. Is it why I'm not able to understand how expanding the keys ?

Community
  • 1
3isenHeim
  • 313
  • 2
  • 13
  • 1
    on the second question: expansion is made by PRF, which is not just SHA-1, see http://tools.ietf.org/html/rfc5246#section-5. – Trueblacker Sep 04 '15 at 10:22
  • I should have editied my post... By expand, I meant how is the MasterSecret **splitted** into 2 `keys` and 2 `MAC keys` – 3isenHeim Sep 04 '15 at 11:05
  • 1
    see http://tools.ietf.org/html/rfc5246#section-6.3 . You get the keyblock with help of PRF, then slice it into the keys & IVs – Trueblacker Sep 04 '15 at 11:48
  • http://security.stackexchange.com/questions/20803/how-does-ssl-work/ is more complete for SSL/TLS overall and intended to be canonical, but http://crypto.stackexchange.com/questions/1139/what-is-the-purpose-of-four-different-secrets-shared-by-client-and-server-in-ssl focusses on this specific point. – dave_thompson_085 Sep 05 '15 at 06:25
  • I recall facing a similar problem. Please refer to this post. The last answer is a way to extract the keys and will give you more insight for the solution to your answer. I was able to separate out the key block from which 6 keys are further derived and used for the record phase in TLS. http://security.stackexchange.com/questions/119720/ssl-browser-session-keys – Choi Jun 14 '16 at 18:29

1 Answers1

5

Q1. Why two sets of key material?

In section 8:3, they say that we create 2 MAC keys and 2 keys. Isn't that enough safe if the client and the server use the same key and MAC key ? (given that these key are generated from no less than a MasterSecret). I kind of think that it seem a bit overprotected..

No. This is done for a serious reason. This makes it actually harder to attack. There is a class of attack, where you just reflect what one side said back to itself. This is called a Reflection Attack. And by having direction fixed keys, you make that class of attack impossible.

Q2. How to chop up the key block?

When you have the MasterSecret, how do you expand it to create MAC keys and keys ? I doubt that we just take the first N bytes for the key and the rest for the MAC key

Sorry to disappoint you, but that's it actually. There is not much magic here.

You have the key block which is a long octet string. And then you simply chop it up into 6 smaller parts.

RFC

Here's the section in the TLS 1.2 RFC:

  client_write_MAC_key[SecurityParameters.mac_key_length]
  server_write_MAC_key[SecurityParameters.mac_key_length]
  client_write_key[SecurityParameters.enc_key_length]
  server_write_key[SecurityParameters.enc_key_length]
  client_write_IV[SecurityParameters.fixed_iv_length]
  server_write_IV[SecurityParameters.fixed_iv_length]

So that's six parts. And in that exact order. Odd entries (1, 3, 5) are for the client_write direction. Even entries (2, 4, 6) are for the server_write direction.

OpenSSL

Here's the chopping bit in OpenSSL:

  • p is the key block.

This gets chopped up into:

  • ms, MAC secret
  • key, bulk encryption key
  • iv, initialization vector

Source code from OpenSSL's t1_enc.c:

if ((which == SSL3_CHANGE_CIPHER_CLIENT_WRITE) ||
    (which == SSL3_CHANGE_CIPHER_SERVER_READ)) {
    ms = &(p[0]);
    n = i + i;
    key = &(p[n]);
    n += j + j;
    iv = &(p[n]);
    n += k + k;
    exp_label = (unsigned char *)TLS_MD_CLIENT_WRITE_KEY_CONST;
    exp_label_len = TLS_MD_CLIENT_WRITE_KEY_CONST_SIZE;
    client_write = 1;
} else {
    n = i;
    ms = &(p[n]);
    n += i + j;
    key = &(p[n]);
    n += j + k;
    iv = &(p[n]);
    n += k;
    exp_label = (unsigned char *)TLS_MD_SERVER_WRITE_KEY_CONST;
    exp_label_len = TLS_MD_SERVER_WRITE_KEY_CONST_SIZE;
    client_write = 0;
}

I don't speak C too well. So I don't really get it.

  • I don't understand the indexing into p.
  • I don't understand why they only select one half of the keys. Each end needs both sets. One set to write to the other end. And one set read what the other end said. -- I guess that chopping happens elsewhere.
Community
  • 1
StackzOfZtuff
  • 17,923
  • 1
  • 51
  • 86
  • 1
    `tls1_change_cipher_state` (or the `ssl3` version) is called twice at each end. When the client sends CCS it sets its sending key(s) and when the server receives CCS it sets its receiving key(s). When the server sends CCS it sets its sending key(s) and when the client receives CCS it sets its receiving key(s). (In all cases also IV for CBC in SSL3 and TLS1.0, before that design flaw was fixed.) C programming isn't on-topic here, but trust me to a C programmer it is reasonably clear, plus if it was wrong all OpenSSL apps would fail on almost every use, and people would have noticed that. – dave_thompson_085 Sep 05 '15 at 06:29
  • Thanks ! I have a `MasterSecret` of 32 bytes (SHA256). How could I make him generate the 2 `128bit-keys` and the 2 `128bit-MACs` ? Should I run it 2 times, or use `SHA512` instead ? – 3isenHeim Sep 11 '15 at 11:08