Approved_users
510
edits
| As of August 2020 the site you are on (wiki.newae.com) is deprecated, and content is now at rtfm.newae.com. |
Changes
→Bootloader Design: Cleaned up communication protocol
This tutorial will work with a simple AES-256 bootloader. The victim will receive data through a serial connection, decrypt the command, and confirm that the included signature is correct. Then, it will send back a reply, either stating that the firmware was or was not correctly signed. To make this system more robust against attacks, the bootloader will use cipher-block chaining (CBC mode). Our goal is to find the secret key and the CBC initialization vector so that we could successfully fake our own firmware.
Commands sent to the bootloader look as follows:
<pre>
|<-------- Encrypted block (16 bytes) ---------->| | |+------+------+------+ ... ------+------+------+ .... +------+------+------+| 0x00 | Encrypted Block Signature (16 4 Bytes) | Data (12 Bytes) | CRC-16 |+------+------+------+ ... ------+------+------+ .... +------+------+------+</pre> This frame has four parts:* <code>0x00</code>: 1 byte of fixed header* Signature: A secret 4 byte constant. The CRC uses 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 calculated CRC-16 is sent first, followed by the MSB. The bootloader will reply over the serial port, describing whether or not this CRC check was valid.As described in the diagram, the 16 byte block is not sent as plaintext. Instead, it is encrypted using AES-256 in CBC mode. This encryption method will be described in the next section. The bootloader responds to each command with a single byte indicating if the CRC-16 was OK or not:
<pre>
+------+
CRC Failed: | 0xA4 |
+------+</pre> ==== Encrypted Block ==== In this design each encrypted block is always 16 bytes long. In practical bootloaders a number of encrypted blocks might be sent as part of one message. To generate an encrypted block, the data is split into 12-byte chunks: <pre>+------+------+------+------+ ... +------+------+------+------+------+| Flash Data (many bytes) |+------+------+------+------+ ... +------+------+------+------+------+ +------+------+ ... +------+ +------+------+ ... +------+ +---...| 12 Bytes of Data | | 12 Bytes of Data | | 12...+------+------+ ... +------+ +------+------+ ... +------+ +---...</pre>Each 12-byte chunk gets a 4-byte signature prepended to it. When the bootloader decrypts a chunk of data, it can verify the signature is as expected. This signature verification is required to ensure the correct encryption key was used, and the system is not just decrypting garbage:
=== Details of AES-256 CBC ===
