21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

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!