6.4.2 l(m) and l(a) Calculation

CCM encodes two values into the message. These values are l(m), the encrypted data length, and l(a), the additional authenticated data length. These values are calculated from appropriate Encryption Offset (EO) for the message and the length of the message. Note: “length of message” in this context is assumed to be the sum of the length of MAC header, Wireless USB header and data payload. The values are calculated as:

l(a) = EO + 14

l(m) = unencrypted message length – EO – 10

6.4.3 Counter-mode Bx Blocks

For calculation of the MIC, the message is broken into 2 or more counter-mode blocks. The CCM specification refers to these blocks as blocks B0 – Bn. Table 6-4 gives the format of block B0. Table 6-5 gives the format of Block B1.

Table 6-4: Block B0 format

Table 6-5: Block B1 format

When EO is non-zero, additional authentication blocks are built from payload bytes (in transmission order) until EO bytes have been consumed. The remainder of the block is padded with zeros as needed. The padding is not transmitted. This forces the start of the encrypted data to be aligned with authentication blocks, allowing for optimization of the encryption and decryption logic.

133

6.4.4 Encryption Ax Blocks

CCM uses the Ax blocks to generate the keystream that is used to encrypt the MIC and the portion of the message to be encrypted. Counter i is initialized to zero to form block A0 and incremented for generating successive blocks. Block A0 is always used to encrypt or decrypt the MIC. Additional Ax blocks are generated as needed for encryption or decryption of the payload.

Table 6-6: Block Ax format

6.5Pseudo-Random Function Definition

This chapter makes use of cryptographic random numbers in several locations. The Pseudo-Random Function (PRF) definition provides these numbers. The function is also used for key derivation during the 4-way handshake and for calculating MICs to protect the 4-way handshake messages. As used in this chapter, 3 output sizes are needed: 64 bits, 128 bits, and 256 bits. We therefore define 3 versions of the PRF function.

•PRF-64, which outputs 64 bits,

•PRF-128, which outputs 128 bits, and

•PRF-256, which outputs 256 bits.

In the following, K denotes a 128-bit symmetric key, N denotes the CCM nonce, A denotes a unique 14-byte ASCII text label for each different use of PRF, B denotes the seed data stream to be processed, and Blen specifies the length of this data stream.

The following pseudo-function demonstrates how PRF interfaces to the CCM logic. This function takes a data string and returns the encrypted CBC Counter-mode MIC.

CCM-MAC-FUNCTION(K, N, A, B, Blen)

Format Block B0 from l(m) = 0, N, and flags = 0x59 Format Block B1 from A and l(a) = Blen + 14

Format additional blocks from B as specified by Blen

(note, last block is padded with values of zero as needed)

Format block A0 from flags = 0x01, N and Counter = 0

The Bx blocks are processed in CBC-Counter mode to generate the MIC value for the blocks. The MIC is then encrypted with the keystream generated with the A0 block.

return encrypted MIC

134

The next pseudo-function provides the logic for PRF itself. The process concatenates MIC values to create a value of the requested length.

PRF(K, N, A, B, Blen, Len) result = empty

for (i = 0; i < (Len + 63)/64; i++, N.SFN++)

result = result contatenated with CCM-MAC-FUNCTION(K, N, A, B, Blen) return result

The following definitions provide convenient handles for the 3 sizes of PRF results used in this specification.

PRF-64(K, N, A, B, Blen) = PRF(K, N, A, B, Blen, 64)

PRF-128(K, N, A, B, Blen) = PRF(K, N, A, B, Blen, 128)

PRF-256(K, N, A, B, Blen) = PRF(K, N, A, B, Blen, 256)

6.5.1 Key Derivation

Key derivation during the 4-way handshake depends on PRF-256 to generate the actual session keys from the supplied data. Key derivation using PRF-256 requires users to specify the following parameters:

The Key Derivation function creates the PRF-256 parameters from these parameters as follows:

•MK - The master key being used for derivation

•N – B11-12=Host ID, B9-10=device ID, B6-8=TKID, B0-5=zero

•A – “Pair-wise keys”

•B – HNonce || DNonce

•Blen – 32

The Key Derivation function then calls PRF-256 to compute 256bits of key stream. This key stream is then split to form the initial management and data keys. The least significant 16 bytes of Key Stream becomes the KCK while the most significant 16 bytes become the PTK.

KeyStream ← PRF-256(K, N, A, B, Blen)

135

6.5.2 Out-of-band MIC Generation

The 4-way handshake uses out-of-band MIC calculations for handshake phases 2 and 3. PRF-64 is used to provide these OOB MIC calculations. The OOB MIC function creates the PRF-64 parameters as follows:

•K - The KCK from the key derivation process

•N – B11-12=Host ID, B9-10=Device ID ID, B6-8=TKID, B0-5=zero

•A – “out-of-bandMIC”

•B – Message data to be authenticated

•Blen – length in bytes of message data

MIC ← PRF-64(K, N, A, B, Blen)

6.5.3 Example Random Number Generation

In order to implement the cryptographic protocols outlined in this specification, every platform needs to be able to generate cryptographic grade random numbers. RFC 1750 gives a detailed explanation of the notion of cryptographic grade random numbers and provides guidance for collecting suitable randomness. It recommends collecting random samples from multiple sources followed by conditioning with PRF. This method can provide a means for an implementation to create an unpredictable seed for a pseudo-random generation function. The example below shows how to distill such a seed using random samples and PRF-128. In the example below, ‘||’ denotes concatenation.

LoopCounter = 0 Nonce = 0 Result = empty

while (LoopCounter < 32) {

result = PRF-128(0, Nonce, “InitRandomSeed”,

USB Vendor ID || USB Product ID || Time || result || LoopCounter, dataLen) Nonce = Nonce + 1

result = result || <randomness samples>

}

GlobalSeed = PRF-128(0, Nonce, “InitRandomSeed”,

DevAddr || Time || result || LoopCounter, dataLen)

Once the seed has been distilled, it can be used as a key for further random number generation. The 4-way handshake requires each party to supply a 128-bit random number. This number can be generated using the seed and PRF-128

GenerateRandomNonce

N = DevAddr || DevAddr ||6 bytes of zero <<Collect randomness samples>>

result = PRF-128(Global Seed, N, “Random Numbers”, <randomness samples>, length of samples)

return result

136