21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

we might have the client and server send messages in lockstep, or we might have<br />

them send messages asynchronously. If they send messages asynchronously, we can<br />

use a separate key for each direction or, if using a nonced encryption mode, manage<br />

two nonces, while ensuring that the client and server nonces never collide (we’ll use<br />

this trick in the code below).<br />

If you do need multiple keys for your setup, you can take the exchanged key and use<br />

it to derive those keys, as discussed in Recipe 4.11. If you do that, use the exchanged<br />

key only for derivation. Do not use it for anything else.<br />

At this point, on each end of the connection, we should be left with an open file<br />

descriptor and whatever keys we need. Let’s assume at this point that we’re using<br />

CWC mode (using the API discussed in Recipe 5.10), our communication is synchronous,<br />

the file descriptor is in blocking mode, and the client sends the first message.<br />

We are using a random session key, so we don’t have to make a derived key, as happens<br />

in Recipe 5.16.<br />

The first thing we have to do is figure out how we’re going to lay out the 11-byte<br />

nonce CWC mode gives us. We’ll use the first byte to distinguish who is doing the<br />

sending, just in case we want to switch to asynchronous communication at a future<br />

point. The client will send with the high byte set to 0x80, and the server will send<br />

with that byte set to 0x00. We will then have a session-specific 40-bit (5-byte) random<br />

value chosen by the client, followed by a 5-byte message counter.<br />

The message elements will be a status byte followed by the fixed-size nonce, followed<br />

by the length of the ciphertext encoded as a 32-bit big-endian value, followed<br />

finally by the CWC ciphertext (which includes the authentication value). The byte,<br />

the nonce, and the length field will be sent in the clear.<br />

The status byte will always be 0x00, unless we’re closing the connection, in which<br />

case we’ll send 0xff. (If there is an error on the sender’s end, we simply drop the<br />

connection instead of sending back an error status.) If we receive any nonzero value,<br />

we will terminate the connection. If the value is not 0x00 or 0xff, there was probably<br />

some sort of tampering.<br />

When MAC’ing, we do not need to consider the nonce, because it is an integral element<br />

when the CWC message is validated. Similarly, the length field is implicitly<br />

authenticated during CWC decryption. The status byte should be authenticated, and<br />

we can pass it as associated data to CWC.<br />

Now we have all the tools we need to complete our authenticated secure channel.<br />

First, let’s create an abstraction for the connection, which will consist of a CWC<br />

encryption context, state information about the nonce, and the file descriptor over<br />

which we are communicating:<br />

#include <br />

#include <br />

#include <br />

494 | Chapter 9: Networking<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!