Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I was looking through the working of SSL V3, and found that a connection state is defined by a set of things, including

  • client write mac secret,
  • server write mac secret,
  • server write key,
  • client write key.

I couldn't found the use of these in the SSL protocol.

As I understood from reading, after having a handshake, SSL creates a 48 byte master secret, which is used in encryption and this secret is shared by both client and server.

For what are these four values used?

share|improve this question

2 Answers 2

up vote 7 down vote accepted

In TLS (that's the standard name for SSL; TLS 1.2 is like "SSL version 3.3"), client and server ends up with a shared secret (the "master secret", a 48-byte sequence; when using RSA key exchange, the master secret is derived from the "premaster secret" which is the 48-byte string that the client encrypts with the server public key). That shared secret is then "extended" into six values:

  • the "client write key";
  • the "client write IV";
  • the "client write MAC key";
  • three similar values for the server.

The "extension" uses the PRF described in section 5; it can be thought of as a hash function with a flexible output length.

TLS main purpose is to keep data confidential; however, it also aims at maintaining data integrity: if someone or something, willingly or not, alters data in transit, then the receiver must be able to reliably detect it. Detecting alterations is important in many protocols; moreover, if an attacker can modify data, he can often handcraft precise alteration which, when sent to the peer in lieu of the correct data, may result in reactions which leak information about the encrypted data. Therefore, we not only want to detect alterations for the own sake of integrity, but also because unconstrained alteration may result in a confidentiality breach.

So we need encryption (for confidentiality) and integrity control (to support confidentiality, and because integrity is also needed by itself). This calls for several algorithms, typically AES for the symmetric encryption part, and HMAC for the integrity control. HMAC is a Message Authentication Code algorithm, which is a kind of "hash function with a key" (HMAC is built over a true hash function, like SHA-256, with a key inserted "the right way"). The HMAC value is computed by the client with its "client write MAC key" and appended to the record data; the server will recompute the HMAC value and see if it matches the one which was sent.

The encryption part requires a key (and an IV for symmetric encryption algorithms which use CBC mode, and this is subject to a few subtleties which depend on the SSL protocol version, so I will not detail these here). The MAC also needs a key. Using the same key for two distinct algorithms is, as a general rule, not recommended at all: there may be unwanted interactions between the two algorithms, an improbable but not impossible event which has not been thoroughly studied. So, to be on the safe side, we generated two keys, one for encryption and one for the MAC. The two keys come from the master secret, but the derivation mechanism is like a hash function, so it supposedly makes it impossible to guess the MAC key even if you know the encryption key, and vice versa.

Since TLS has a key derivation function (the "PRF") which can produce outputs of arbitrary length, it was easy to mandate production of encryption and MAC keys distinct for both directions (the key used by the client to encrypt data -- and that the server uses to decrypt received data -- is distinct from the key used by the server to encrypt data it sends to the client). Using distinct keys avoids problems with attackers who could otherwise get a copy of an encrypted record sent by the client, and feed it back to the client as if it was sent from the server. With distinct keys, the client will reject the attempt, because the HMAC value will not match what the client expects (it will be a HMAC computed with the client write MAC key, not with the server write MAC key).

There are newer symmetric encryption modes which do the encryption and the MAC with the same key in a controlled way, e.g. GCM -- and AES-with-GCM can be used with TLS although you may have a hard time finding compatible implementations (this is rather new).

share|improve this answer

SSL does more than just encrypt the data. It also protects it from undetected modification. To do this, when it encrypts data, it also generates a cryptographical checksum (which is termed a message authentication code or 'mac') of the plaintext record, and includes that in with the encrypted record. Now, to make sure that someone in the middle can't compute their own mac if they modify the record, the computation of these mac's use keys (which are ultimately derived from the master record, just like the encryption keys are). On decryption, the decrypter also computes the mac of the plaintext it got (using its copy of the keys), and compares it to the mac within the record; if they are identical, then the record was not modified in transit.

So, the client_write_mac_secret is the secret key used to protect records that the client sends (writes) and the server receives; the server_write_mac_secret is the secret key used to protect records that the server sends, and the client receives.

Note that both sides has both secrets; the client uses client_write_mac_secret to protect the records it sends to the client, and the server uses client_write_mac_secret to validate the records that it receives from the client.

share|improve this answer
    
why we have server_write_key and client_write_key? –  user5507 Nov 7 '11 at 15:58
    
@user5507 Well, one of the things you don't want to have happen is if someone in the middle grabbed a record from the client, and presented it to the client as if it came from the server. If the client used the same key for both putting the mac on records, and verifying the mac on records, an attacker just might be able to manage it (it'd be tricky, though). By using separate keys for the two directions, we know that that won't be a problem. –  poncho Nov 7 '11 at 18:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.