AES-CCM Attack
WARNING: This page under construction!
The following is an overview of the AES-CMM attack done by Eyal Ronen, detailed in his paper IoT Goes Nuclear: Creating a ZigBee Chain Reaction. If using this attack please do not cite this page, instead cite the original research. Note as of now (Nov/2016) the paper has not been submitted to any conference, so this is still very much new/draft research.
This page is presented as an example of using Python/ChipWhisperer to perform attacks against the AES-CCM cipher, without needing to do a more complex attack against AES-CTR mode.
AES-CCM Overview
AES-CCM provides both encryption and authentication using the AES block cipher. This is a widely used mode since it requires only a single cryptographic primitive. That primitive is used in two different modes: CBC and CTR mode. The difference is explained below:
Cipher Block Chaining (CBC): The plaintext is XORed with the previous ciphertext before being encrypted. There is no ciphertext before the first plaintext, so a randomly chosen initialization vector (IV) is used instead:
Counter (CTR): An incrementing counter is encrypted to produce a sequence of blocks, which are XORed with the plaintexts to produce the ciphertexts:
Background on Attack
The following uses the notation from IoT Goes Nuclear: Creating a ZigBee Chain Reaction.
Assume first the basic AES-ECB cipher is $CT = E_k(PT)$, where we are encrypting a block with secret key $k$.
AES-CCM combines AES-CTR mode and AES-CBC mode as mentioned. We could consider AES-CTR to be performing the following operation:
Performing Attack
Building Example
Collecting Traces
Step #1: AES-CBC MAC Block #1
Step #2: AES-CBC MAC Block #2
Step #3: Recovery of AES-CTR Nonce
Step #4: Recovery of AES-CBC I.V.
Step #5: AES-CTR Pad
Example Bootloader
The example bootloader has a simplified AES-CCM implementation (NB: do NOT use this as a reference for a good implementation!). It accomplishes the basic goals only of having:
- Header data that is authenticated but not encrypted
- An encrypted MAC tag
- A bunch of encrypted firmware blocks
Each block sent to the bootloader is 19 bytes long. The first byte indicates the type - header, auth tag, or data. If a new 'header' message is received it will abort any ongoing processing of existing data and restart the bootloader process.
The following shows the three message types, where length in the header is the number of encrypted data frames. This is used for the bootloader to know when to perform the AES-MAC comparison.
This frame has four parts:
-
0x00: 1 byte of fixed header - Signature: A secret 4 byte constant. The bootloader will confirm that this signature is correct after decrypting the frame.
- Data: 12 bytes of the incoming firmware. This system forces us to send the code 12 bytes at a time; more complete bootloaders may allow longer variable-length frames.
- CRC-16: A 16-bit checksum using the CRC-CCITT polynomial (0x1021). The LSB of the CRC is sent first, followed by the MSB. The bootloader will reply over the serial port, describing whether or not this CRC check was valid.
+------+------+------+------+ .... +------+------+------+------+ | 0x01 | Header Info (14 bytes)| Length | CRC-16 | +------+------+------+------+ .... +------+------+------+------+
|<----- Encrypted block (16 bytes) ------>|
| AES-CTR Encryption with CTR=0 |
| |
+------+------+------+------+ .... +------+------+------+------+
| 0x02 | Auth-Tag (encrypted MAC) | CRC-16 |
+------+------+------+------+ .... +------+------+------+------+
|<----- Encrypted block (16 bytes) ------>|
| AES-CTR Encryption with CTR=1,2,3..N |
| |
+------+------+------+------+ .... +------+------+------+------+
| 0x03 | Data (16 Bytes) | CRC-16 |
+------+------+------+------+ .... +------+------+------+------+
The bootloader responds to each command with a single byte indicating if the CRC-16 was OK or not: