Difference between revisions of "AES Registers"
(keyslot 0x24 confirmed)
|Line 334:||Line 334:|
Revision as of 19:10, 25 October 2015
|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 (selects the keyslot specified by REG_AESKEYSEL when this bit is set)|
|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)|
When bit31 is clear, the AES engine will handle keyslot-selection when bit26 is set immediately. When bit31 is set, the AES engine won't handle bit26 immediately, instead the AES engine will automatically handle the already-set bit26 once bit31 clears(current AES operation finishes).
Clearing bit31 while the AES engine is doing crypto will result in the AES engine stopping crypto, once it finishes processing the current block.
Up to 128 bytes of input data can be buffered.
The input data for the AES crypto operation is written to REG_AESWRFIFO, the output data is read from REG_AESRDFIFO.
Reading from REG_AESRDFIFO when there's no data available in the RDFIFO will result in reading the last word that was in the RDFIFO.
|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.
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. The AES engine will automatically increment the counter up to the maximum BLKCNT, after which point it must be manually incremented and set again.
This register specifies the message authentication code (MAC) for use in CCM mode.
AES_KEY0/1/2/3These registers are the same as they were on TWL, and are likely preserved for compatibility reasons. The keyslot is updated immediately after *any* data(u8/u32/...) is written here, which was used on DSi to break the key-generator.
Endianness and word order
When writing to the AES_CTR or AES_MAC register, the hardware will process the written data according to the current input endianness specified in AES_CNT. 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.
This is approximately a table of what is set by bootrom before booting into FIRM. Often it appears that keyslots in groups of 4 have the same keyX, and sometimes also same keyY set.
|0x00-0x03||TWL keys.||Probably unset.||Probably unset.||-|
|0x04-0x07||NAND partition keys.||Same for all.||Different for all.||Yes|
|0x08-0x0B||See below.||Same for all.||Different for all.||Yes|
|0x0C-0x0F||SSL cert key.||Same for all.||Same for all.||No|
|0x10-0x17||-||Not set.||Not set.||-|
|0x18-0x1B||Never used.||Same for all.||Same for all.||Yes|
|0x1C-0x1F||Never used.||Same for all.||Same for all.||Yes|
|0x20-0x23||Never used.||Same for all.||Same for all.||Normalkey is not. keyX is. keyY unknown.|
|0x24||Never used.||Individually set.||Individually set.||Normalkey is not. keyX is. keyY unknown.|
|0x25-0x27||-||Not set.||Not set.||-|
|0x28-0x2B||Never used.||Individually set.||Individually set.||Normalkey is not. keyX is. keyY unknown.|
|0x2C-0x2F||Various uniques.||Same for all.||Same for all, probably.||No|
|0x30-0x33||Various uniques.||Same for all.||Same for all, probably.||No|
|0x34-0x37||Various uniques.||Same for all.||Same for all, probably.||No|
|0x38-0x3B||Various uniques.||Same for all.||Different for all.||No|
|0x3C-0x3F||Various uniques.||Individually set.||Individually set.||No|
Keyslot pairs (0x24, 0x28) and (0x38, 0x3C) shares the same normal-key, while at the same time having different keyX's. This suggests they were set to same normal-key by bootrom.
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 generator instead (see below). There is no way to read the contents of a keyslot.
|Keyslot||Description||KeyX set by||KeyY set by||Normal-key||Old3DS|
|0x00-0x03||TWL keys.||NATIVE_FIRM hard-boot.||NATIVE_FIRM hard-boot.||-||Yes|
|0x04..0x07||NAND partition keys.
Keyslot is determined by NCSD partition FS type and encryption type. The New3DS Process9 sets the keyY for keyslot 0x05 (New3DS CTRNAND) to a key from .(ro)data. Its keyX is console-unique and set by the bootloader.
|0x0A||DSiWare export key.
Used for encrypting the all-zero 0x10-byte block in the DSiWare_Exports header. Console-unique.
|See above keyslot info.||See above keyslot info.|
|0x0B||This is console-unique. This keyslot is used for the NAND dbs images AESMACs, and the Nand/private/movable.sed AESMAC(when used).||See above keyslot info.||See above keyslot info.||-||Yes|
Used by FIRM for general normal-key crypto. Also used by the New3DS FIRM arm9 binary loader.
|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||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|
|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.6.0-X keyslots 0x1C..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 9.3.0-X NCCH key, when ncchflag is 0x0A.||Arm9Loader.||NATIVE_FIRM||-||No|
|0x19||New3DS gamecard savedata AES-MAC key.||Arm9Loader.||NATIVE_FIRM||-||No|
|0x1A||New3DS gamecard savedata actual key.||Arm9Loader.||NATIVE_FIRM||-||No|
|0x1B||New3DS 9.6.0-X NCCH key, when ncchflag is 0x0B.||Arm9Loader.||NATIVE_FIRM||-||No|
|0x24||AGB_FIRM savegame AES-MAC key.||Bootrom.||AGB/NATIVE_FIRM.||-||Yes|
|0x25||v7.0 NCCH key, when ncchflag is 0x01.||NATIVE_FIRM boot.||NATIVE_FIRM.||-||Yes|
|0x2C||Original NCCH key, when ncchflag is 0x00 and always for certain NCCH sections.||Bootrom.||Process9.||-||Yes|
|0x2D||UDS local-WLAN CCMP key.
|0x2F||v6.0 save key.||Bootrom.||NATIVE_FIRM.||-||Yes|
|0x30||SD/NAND AES-MAC key.||Bootrom.||NATIVE_FIRM.||-||Yes|
|0x31||APT wrap key.
See EncryptDecryptAes. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
|0x33||Gamecard savedata AES-MAC.||Bootrom.||NATIVE_FIRM.||-||Yes|
This is the keyslot used for movable.sed encryption + AES-MAC with the import/export commands.
|0x36||Unknown. Used by friends module.
|0x37||Gamecard savedata actual key.||Bootrom.||NATIVE_FIRM.||-||Yes|
|0x39||Download Play key, and the actual NFC key for generating retail Amiibo keys.
This keyslot is used for two different keys. Both are available via EncryptDecryptAes. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
|0x3A||DSiWare export key.||Bootrom.||NATIVE_FIRM.||-||Yes|
|0x3B||CTR-CARD hardware-crypto seed decryption key.
AES-CCM is used, the keyY, nonce and MAC are stored in the Card Info Header.
Used to decrypt title keys in Ticket.
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 must be selected again(write REG_AESKEYSEL + set REG_AESCNT bit26), even when writing to the same keyslot. Writing the last word to a key FIFO immediately after selecting a keyslot will not affect the keyslot keydata that gets used at that time, the new keydata will not get used until the keyslot gets selected again.
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);
Each key FIFO has a 0x10-byte tmp-buffer for storing the words written to that FIFO. Once the last word is written to a key FIFO, the filled tmp-buffer is then written to the key-data for the keyslot selected by REG_AESKEYCNT at the time the last word was written.
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. The hardware key generator is triggered by writing the keyY, which is the only way to trigger it with the 3DS keyslots. The algorithm used for key generation is unknown.
Unless noted otherwise, all keyslots on retail units use the hardware key-generator.
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.