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 checked when a keyY was written, for when the final-normalkey needs updated via the key-generator.

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	Key-data initialized by ARM9 bootrom	Key-data initialized by Process9
0x00-0x03	These are the TWL keyslots, the key-data for these can be set via the REG_AESKEY0-REG_AESKEY3 registers. These keyslots are initialized by NATIVE_FIRM. The console-unique portion of two of these keyslots are only initialized by NATIVE_FIRM during initial hard-boot.	No	Yes
0x0D	See EncryptDecryptAes, this uses the hardware key-scrambler.	Yes	No
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.	No	Yes, when using this keyslot
0x12	Unused	No	No
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.	Yes	See description
0x20..0x23	All of these keyslots(initialized by bootrom) 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.	Yes	No
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.	Yes	No
0x25	The keyX and keyY initialized by bootrom for this keyslot are console-unique. This keyslot is used for the v7.0 NCCH encryption, the keyX is initialized during NATIVE_FIRM boot. The keyY/CTR used for this keyslot is the same as keyslot 0x2C.	?	See description
0x26	Unused	No	No
0x27	Unused	No	No
0x28	This is set to the same normal-key as keyslot 0x24 by bootrom. The keyX written to this keyslot before writing the normal-key by the bootrom, is console-unique(separate from the keyslot 0x24 keyX).	Yes	No
0x2C	Used to decrypt NCCH, the keyY is set by Process9(see here regarding the keyY). Keyslots 0x2C..0x2F all use the same keyX, set by bootrom.	Yes	Yes
0x2D	See EncryptDecryptAes, this uses the hardware key-scrambler.	Yes	No
0x2E	See EncryptDecryptAes. This keyY is set by NATIVE_FIRM.	Yes	Yes
0x2F	Initially this keyslot has the same keyY as keyslot 0x2D, initialized by bootrom. This keyY is initialized during NATIVE_FIRM boot. This is the keyslot used for calculating v6.0 gamecard savegames' keyYs.	Yes	See description
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. Process9 may write the keyY for all of these keyslots except for 0x32.	Yes	Yes
0x31	See EncryptDecryptAes, this uses the hardware key-scrambler. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.	Yes	Yes
0x32	See EncryptDecryptAes.	Yes	No
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.	Yes	Only for keyslot 0x37
0x38-0x3B	All of these keyslots use the same keyX. Keyslot 0x3B uses an unique keyY initialized by bootrom.	Yes	No
0x38	See EncryptDecryptAes, this uses the hardware key-scrambler.	Yes	No
0x39	See EncryptDecryptAes. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.	Yes	Yes
0x3C	The keyX for this is unique for this keyslot. The keyY for this initialized by bootrom is the same as keyslot 0x38.	Yes	No
0x3D	This keyslot uses keyY. Used to decrypt title keys in Ticket. Used by Gateway.	Yes	Yes
0x3E	This keyslot uses an unique keyX/keyY.	Yes	No
0x3F	This keyslot uses an unique keyX/keyY.	Yes	No

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.

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.