AES Engine

From DSiBrew

Jump to: navigation, search

Contents

Registers

NAME ADDRESS WIDTH
REG_AESCNT 0x04004400 4
REG_AESBLKCNT 0x04004404 4
REG_AESWRFIFO 0x04004408 4
REG_AESRDFIFO 0x0400440C 4
REG_AESCTR 0x04004420 16
REG_AESMAC 0x04004430 16
REG_AESKEY0 0x04004440 48
REG_AESKEY1 0x04004470 48
REG_AESKEY2 0x040044A0 48
REG_AESKEY3 0x040044D0 48

REG_AESCNT

BIT DESCRIPTION
4-0 Write fifo count
9-5 Read fifo count
10 Flush write fifo
11 Flush read fifo
15-12  ?
18-16 MAC size (size in bytes = s*2+2, e.g, 7 == 16 bytes)
19  ?
20 MAC input control (0 = read MAC from FIFO, 1 = read MAC from REG_AESMAC)
21 MAC status (0 = invalid, 1 = verified)
23-22  ?
24 Key select
25 Key schedule busy
27-26 Key slot (0..3)
29-28 Mode (0=AES CCM decrypt, 1=AES CCM encrypt, 2=AES CTR)
30 Interrupt enable
31 Enable


REG_AESBLKCNT

BIT DESCRIPTION
15-0 CBC-MAC associated data blocks to process (1 block = 4 words)
31-16 CTR or payload data blocks to process (1 block = 4 words)

REG_AESKEY0/1/2/3

BYTE DESCRIPTION
0-15 Key data
16-31 Special key data X
32-47 Special key data Y


Key gets updated when either the last word of the key data or the last word of "special key data y" is written. When writing to special key data the actual key is F((key data x) xor (key data y)) where F is some unknown function implemented in hardware.

AES CCM mode (Counter with CBC-MAC)

AES CCM mode combines AES CTR with AES CBC-MAC, to provide confidentiality and authenticity of a message.

The message contains optional associated data and an actual payload. The payload is XORed with an AES CTR generated stream, while AES CBC-MAC is used to generate a MAC based on both the associated data and the payload. The MAC can be used to verify integrity of the message. In addition, a nonce is used to initialize the AES CTR and CBC-MAC modes of operation.

More information can be found in NIST 800-38C or RFC 3610.

The used MAC size can be adjusted in hardware, but usually a MAC size of 16 bytes is used. The hardware has a hardcoded maximum payload size of 24 bits for CCM, and this automatically means the nonce is 12 bytes.

When encrypting or decrypting, the first 12 bytes of REG_AESCTR are used for the nonce. The actual counter used is defined in NIST 800-38C, and looks like this: (02 <nonce> 00 00 00). The last 3 bytes are the counter and is incremented for each subsequent AES CTR operation. The first block for AES CBC-MAC is also defined in NIST 800-38C, and looks like this: (<flags> <nonce> <payloadsize>), where flags is (0 <adata> <m> <q>), where adata is 1 or 0 if associated data is used, m the encoded mac size, and q the sizebytes (always 2).

CCM hardware encryption

First, the optional associated data is written to the write fifo. During this time, the hardware will internally update the MAC with the associated data. If no associated data is used, this step can be skipped. Then, the actual payload is written to the write fifo. The crypted payload will appear in the read fifo, and during this time the MAC will be internally updated with the payload data. Once all blocks are done, the MAC can be read from the read fifo. The hardware knows when this is because the number of associated blocks and payload blocks are specified in REG_AESBLKCNT.

CCM hardware decryption

It is possible to let the hardware use the dedicated MAC slot in REG_AESMAC or from the write fifo for verification. This option depends on bit 20 of REG_AESCNT. Like encryption, first the optional associated data is written to the write fifo. Then the actual payload is written to the write fifo, and the crypted payload will appear in the read fifo. If using the dedicated MAC slot, the hardware will now verify whether the MAC matches. Otherwise, the MAC must be supplied into the write fifo for verification.

Personal tools