AES Registers
Registers
| NAME | PHYSICAL ADDRESS | WIDTH | RW |
|---|---|---|---|
| REG_AESCNT | 0x10009000 | 4 | RW |
| REG_AESBLKCNT | 0x10009004 | 4 | W? |
| REG_AESWRFIFO | 0x10009008 | 4 | W |
| REG_AESRDFIFO | 0x1000900C | 4 | R |
| REG_AESKEYSEL | 0x10009010 | 1 | RW |
| REG_AESKEYCNT | 0x10009011 | 1 | RW |
| REG_AESCTR | 0x10009020 | 16 | W |
| REG_AESMAC | 0x10009030 | 16 | W |
| REG_AESKEY0 | 0x10009040 | 48 | W |
| REG_AESKEY1 | 0x10009070 | 48 | W |
| REG_AESKEY2 | 0x100090A0 | 48 | W |
| REG_AESKEY3 | 0x100090D0 | 48 | W |
| REG_AESKEYFIFO | 0x10009100 | 4 | W |
| REG_AESKEYXFIFO | 0x10009104 | 4 | W |
| REG_AESKEYYFIFO | 0x10009108 | 4 | W |
REG_AESCNT
| Bit | Description |
|---|---|
| 4-0 | Write FIFO count (0-16) |
| 9-5 | Read FIFO count (0-16) |
| 10 | Flush write FIFO (1=Clear write FIFO) |
| 11 | Flush read fifo (1=Clear read FIFO) |
| 18-16 | MAC size (encoding = (maclen-2)/2) |
| 19 | ? (MAC related) |
| 20 | MAC input control (0 = read MAC from FIFO, 1 = read from MAC register) |
| 21 | MAC status (0 = invalid, 1 = verified) |
| 22 | Output endianness (1=Big endian, 0=Little endian) |
| 23 | Input endianness (1=Big endian, 0=Little endian) |
| 24 | Output word order (1=Normal order, 0=Reversed order) |
| 25 | Input word order (1=Normal order, 0=Reversed order) |
| 26 | Update keyslot (set to 1 when the keyslot is changed) |
| 29-27 | Mode (0=CCM decrypt, 1=CCM encrypt, 2=CTR, 3=CTR, 4=CBC decrypt, 5=CBC encrypt, 6=ECB decrypt, 7=ECB encrypt) |
| 30 | Interrupt enable (1=enable, 0=disable) |
| 31 | Start (1=enable/busy, 0=idle) |
REG_AESBLKCNT
| Bit | Description |
|---|---|
| 16-31 | (Data length)>>4 |
REG_AESWRFIFO/REG_AESRDFIFO
TODO: Explain what this does.
Up to 128 bytes of input data can be buffered.
REG_AESKEYCNT
| Bit | Description |
|---|---|
| 5-0 | Keyslot |
| 6 | Hardware key-generator type: 0 = 3DS, 1 = DSi. |
| 7 | This normally has value 1 written here when updating keys. 0 = disable key FIFO flush, 1 = enable key FIFO flush. |
Bit6 is only used when keyslots >=4 are used, value1 has the same affect as doing key-init with the TWL keyslots. Bit6 is only checked when a keyY was completely written, for when the final-normalkey needs updated via the key-generator. Changing bit6 has no affect on the generated normalkey when writing to this bit immediately after writing the last keyY word.
REG_AESCTR
This register specifies the counter (CTR mode), nonce (CCM mode) or the initialization vector (CBC mode) depending on the mode of operation. For CBC and CTR mode this register takes up the full 16 bytes, but for CCM mode the nonce is only the first 12 bytes.
REG_AESMAC
This register specifies the message authentication code (MAC) for use in CCM mode.
Endianness and word order
When writing to the REG_AESCTR or REG_AESMAC register, the hardware will process the written data according to the current input endianness specified in AESCNT. However, the current specified input word order will not be honored for this register, and always defaults to reversed word order. Therefore, for normal word order, the reversal must be carried out manually if required.
Keyslots
There are 0x40 keyslots, each of which stores three keys called keyX, keyY and normalkey. All keys can be set explicitly, but the normalkey can optionally be generated using a hardware key scrambler instead (see below). There is no way to read the contents of a keyslot.
| Keyslot | Description | KeyX | KeyY | Normal-key | Old3DS |
|---|---|---|---|---|---|
| 0x00-0x03 | TWL keyslots. | NATIVE_FIRM hard-boot. | NATIVE_FIRM hard-boot. | - | Yes |
| 0x04..0x07 | These keyslots use the same console-unique keyX. Each keyslot has a separate keyY. These are the NAND encryption keyslots, which keyslot gets used is determined by the NCSD partition FS type and the partition encryption type. | Bootrom. | Bootrom. | - | Yes |
| 0x08..0x0B | These keyslots use the same console-unique keyX. Each keyslot has a separate keyY. | Bootrom. | Bootrom. | - | Yes |
| 0x0A | This is the console-unique keyslot used for encrypting the all-zero 0x10-byte block in the DSiWare_Exports header. | See above keyslot info. | See above keyslot info. | - | Yes |
| 0x0C..0x0F | All of these keyslots are set to the same key-data, which is a regular normal-key. The keyX written before the normal-key is console-unique, this keyX is the same for all of these keyslots. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x0D | SSL-certificate key. See EncryptDecryptAes. | - | - | Bootrom. | Yes |
| 0x10 | The console-unique keyX is set before the normal-key. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x11 | This is used for general normal-key crypto, where the normal-key is set by FIRM. This keyslot is also used by the New3DS FIRM arm9 binary loader. | Arm9Loader. | Arm9Loader. | NATIVE_FIRM. | Yes |
| 0x12 | Unused | - | - | - | - |
| 0x13 | Unused | - | - | - | - |
| 0x14 | Starting with 5.0.0-11, NATIVE_FIRM Process9 now sets the keyY for this to the same one it uses for initializing 3 of the keyslots' keyYs from here. | Bootrom. | NATIVE_FIRM boot. | - | Yes |
| 0x15..0x16 | The console-unique keyX is set before the normal-key. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x15 | Used/initialized by the New3DS arm9 binary loader, see here. | Arm9Loader. | Arm9Loader. | See previous info for this keyslot. | No |
| 0x16 | Used/initialized by the New3DS arm9 binary loader starting with 9.5.0-X, see here. | Arm9Loader. | Arm9Loader. | See previous info for this keyslot. | No |
| 0x17 | The console-unique keyX is set before the normal-key. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x18..0x1B | All of these keyslots are set to the same key-data, which is a regular normal-key. The console-unique keyX is set before the normal-key, this keyX is the same for all of these keyslots. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x1C..0x1F | All of these keyslots are set to the same key-data, which is a regular normal-key. The console-unique keyX is set before the normal-key, this keyX is the same for all of these keyslots. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x18..0x1F | These are the New3DS keyslots, where the keyX is generated with keyslot 0x11 by the New3DS arm9 binary loader. As of FIRM 9.5.0-X keyslots 0x1B..0x1F are not yet used by Process9. | Arm9Loader. | NATIVE_FIRM / see previous info for these keyslots. | See previous info for these keyslots. | No |
| 0x18 | New3DS NCCH keyslot, starting with 9.3.0-X. | See above keyslot info. | NATIVE_FIRM | - | Yes |
| 0x19 | New3DS gamecard savedata keyslot equalivant of keyslot 0x33, used when a NCSD flag is set to a certain value(implemented with 9.3.0-X). | See above keyslot info. | NATIVE_FIRM | - | Yes |
| 0x1A | New3DS gamecard savedata keyslot equalivant of keyslot 0x37, used when a NCSD flag is set to a certain value(implemented with 9.3.0-X). | See above keyslot info. | NATIVE_FIRM | - | Yes |
| 0x20..0x23 | All of these keyslots are set to the same key-data, which is a regular normal-key. The keyX written to these keyslots before writing the normal-key by the bootrom, is console-unique. | Bootrom. | - | Bootrom. | Yes |
| 0x24 | This is set to a normal-key by bootrom. The keyX written to this keyslot before writing the normal-key by the bootrom, is console-unique. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x25 | v7.0 NCCH key. | NATIVE_FIRM boot. | NATIVE_FIRM. | - | Yes |
| 0x26 | Unused | - | - | - | Yes |
| 0x27 | Unused | - | - | - | Yes |
| 0x28 | Unknown. The normal-key for this is the same as keyslot 0x24, the console-unique keyX written before the normal-key is different from keyslot 0x24. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x29 | Unknown. The keyX written before the normal-key is console-unique. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x2A | Unknown. The keyX written before the normal-key is console-unique. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x2B | Unknown. The keyX written before the normal-key is console-unique. | Bootrom. | Bootrom? | Bootrom. | Yes |
| 0x2C..0x2F | All of these keyslots use the same keyX initialized by bootrom. During key-init in arm9 bootrom, keyslots 0x2D and 0x2F are set to the same keyY. | Bootrom. | Bootrom, then NATIVE_FIRM for keyslots 0x2C and 0x2F on >=v6.0 FIRM. | - | Yes |
| 0x2C | NCCH key. Keyslots 0x2C..0x2F all use the same keyX, set by bootrom. | Bootrom. | Process9. | - | Yes |
| 0x2D | UDS local-WLAN CCMP key. See EncryptDecryptAes. | Bootrom. | Bootrom. | - | Yes |
| 0x2E | See EncryptDecryptAes. | Bootrom. | NATIVE_FIRM. | - | Yes |
| 0x2F | v6.0 save key. | Bootrom. | Bootrom, then later NATIVE_FIRM. | - | Yes |
| 0x30-0x33 | All of these keyslots use the same keyX. The keyY for keyslots 0x32 and 0x33 are set to the same keyY by bootrom. | Bootrom. | Bootrom, then later NATIVE_FIRM except for keyslot 0x32. | - | Yes |
| 0x30 | This keyY is initialized via movable.sed. This is used for calculating the AESMACs under SD /Nintendo 3DS/<ID0>/<ID1>/(except DSiWare_Exports) and NAND /data/. | Bootrom. | Bootrom(?), then later NATIVE_FIRM. | - | Yes |
| 0x31 | APT wrap key. See EncryptDecryptAes
NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E. |
Bootrom. | Bootrom(?), then later NATIVE_FIRM. | - | Yes |
| 0x32 | See EncryptDecryptAes. | Bootrom. | Bootrom. | - | Yes |
| 0x33 | This is the keyslot for the gamecard savedata AESMAC. | Bootrom. | Bootrom, then later NATIVE_FIRM. | - | Yes |
| 0x34-0x37 | All four of these keyslots use the same keyX. Keyslots 0x35, 0x36, and 0x37 use the same bootrom keyY. See EncryptDecryptAes for keyslot 0x36. | Bootrom. | Bootrom, then NATIVE_FIRM for keyslot 0x37. | - | Yes |
| 0x34 | This keyY is initialized via movable.sed. This is used for encrypting *all* SD card data under /Nintendo 3DS/<ID0>/<ID1>/. | Bootrom. | Bootrom(?), then later NATIVE_FIRM. | - | Yes |
| 0x35 | This is the keyslot used for movable.sed encryption + AESMAC with the import/export commands. | Bootrom. | Bootrom. | - | Yes |
| 0x36 | Unknown. | Bootrom. | Bootrom. | - | Yes |
| 0x37 | This is the keyslot for the actual gamecard savedata encryption. | Bootrom. | Bootrom, then later NATIVE_FIRM. | - | Yes |
| 0x38-0x3B | All of these keyslots use the same keyX. Keyslot 0x3B uses an unique keyY initialized by bootrom. | Bootrom. | Bootrom, then NATIVE_FIRM for keyslot 0x3A. | - | Yes |
| 0x38 | See EncryptDecryptAes. | Bootrom. | Bootrom. | - | Yes |
| 0x39 | See EncryptDecryptAes. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E. | Bootrom. | Bootrom, then NATIVE_FIRM. | - | Yes |
| 0x3A | This keyY is initialized via movable.sed. This is used for calculating the AESMACs for SD DSiWare_Exports. | Bootrom. | Bootrom(?), then later NATIVE_FIRM. | - | Yes |
| 0x3B | Unknown. | Bootrom. | Bootrom. | - | Yes |
| 0x3C | Unknown. The keyX for this is unique for this keyslot. The keyY for this initialized by bootrom is the same as keyslot 0x38. | Bootrom. | Bootrom. | - | Yes |
| 0x3D | Common key. Used to decrypt title keys in Ticket. Used by Gateway. | Bootrom. | NATIVE_FIRM. | - | Yes |
| 0x3E | Unknown. This keyslot uses an unique keyX/keyY. | Bootrom. | Bootrom. | - | Yes |
| 0x3F | Unknown. This keyslot uses an unique keyX/keyY. | Bootrom. | Bootrom. | - | Yes |
Updating keydata
The contents of the keyslot specified in REG_AESKEYCNT can be updated by consecutively writing four words to REG_AESKEYXFIFO (keyX), REG_AESKEYYFIFO(keyY), or REG_AESKEYFIFO (normalkey).
After writing to a keyslot, the keyslot in REG_AESKEYCNT must be set again, even when writing to the same keyslot.
Writing to the key FIFOs with byte writes results in the AES engine converting the byte to a word for setting the key word, with this: word = (byteval) | (byteval<<8) | (byteval<<16) | (byteval<<24). The result is the same regardless of which FIFO register byte was written to.
The TWL keyslots 0x00-0x03 can be set directly by writing to the REG_AESKEY0-REG_AESKEY3 registers.
The key FIFOs can be written simultaneously. For example, executing the following 4 times will result in the keyX and keyY being set to all-zero(unknown for normalkey): memset(0x10009100, 0, 0x100);
keyX
The ARM9 bootrom initializes the keyX for certain 3DS keyslots, the ARM9 bootrom may also initialize the keyY for certain keyslots. In certain cases Process9 may also set the keyX.
Hardware key generator
A dedicated hardware key generator can be used to generate a keyslot's normalkey from its keyX and keyY by enabling the corresponding bit in REG_AESKEYCNT. If enabled, the hardware key generator is triggered by writing the keyY (which also seems to be the only way to trigger it). The algorithm used for key generation is unknown.
Unless noted otherwise, all keyslots on retail units use the hardware key-scrambler.
FIRM-launch key clearing
Starting with 9.0.0-20 the Process9 FIRM-launch code now "clears" the following AES keyslots, with certain keydata by writing the normal-key: 0x15 and 0x18-0x20. These are the keyslots used by the New3DS FIRM arm9bin loader(minus keyslot 0x11), the New3DS Process9 does this too.