Difference between revisions of "AES Registers"

From 3dbrew
Jump to navigation Jump to search
 
Line 1: Line 1:
#REDIRECT [[AES Registers2]]
+
== Registers ==
 +
{| class="wikitable" border="1"
 +
!  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 ==
 +
{| class="wikitable" border="1"
 +
!  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
 +
| ? (something 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 ==
 +
 
 +
{| class="wikitable" border="1"
 +
!  Bit
 +
!  Description
 +
|-
 +
| 16-31
 +
| (Data length)>>4
 +
|}
 +
 
 +
== REG_AESKEYCNT ==
 +
{| class="wikitable" border="1"
 +
!  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, however that's not actually needed(keydata gets updated regardless of whether this bit is set).
 +
|}
 +
 
 +
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 ==
 +
{| class="wikitable" border="1"
 +
!  Keyslot
 +
!  Description
 +
|-
 +
| 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 [[CONFIG|initialized]] by NATIVE_FIRM during initial hard-boot.
 +
|-
 +
| 0x0D
 +
| See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]], this uses the hardware key-scrambler.
 +
|-
 +
| 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.
 +
|-
 +
| 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 [[PSPXI:EncryptDecryptAes|here]].
 +
|-
 +
| 0x20..0x23
 +
| All of these keyslots(initialized by bootrom) are set to the same key-data. These seem to be set to a regular normal-key?
 +
|-
 +
| 0x25
 +
| The keyX and keyY initialized by bootrom for this keyslot are console-unique. This keyslot is used for the [[7.0.0-13|v7.0]] [[NCCH]] encryption, the keyX is initialized during NATIVE_FIRM [[Savegames#6.0.0-11_Savegame_keyY|boot]]. The keyY/CTR used for this keyslot is the same as keyslot 0x2C.
 +
|-
 +
| 0x2C
 +
| Used to decrypt [[NCCH|NCCH]], the keyY is set by Process9(see [[NCCH|here]] regarding the keyY). Keyslots 0x2C..0x2F all use the same keyX, set by bootrom.
 +
|-
 +
| 0x2D
 +
| See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]], this uses the hardware key-scrambler.
 +
|-
 +
| 0x2E
 +
| See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]]. This keyY is set by NATIVE_FIRM.
 +
|-
 +
| 0x2F
 +
| Initially this keyslot has the same keyY as keyslot 0x2D, initialized by bootrom. This keyY is initialized during NATIVE_FIRM [[Savegames#6.0.0-11_Savegame_keyY|boot]]. This is the keyslot used for calculating v6.0 gamecard savegames' keyYs.
 +
|-
 +
| 0x31
 +
| See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]], this uses the hardware key-scrambler. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
 +
|-
 +
| 0x32
 +
| See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]]. This keyslot keyX is the same keyX used for keyslot 0x31.
 +
|-
 +
| 0x34-0x37
 +
| All four of these keyslots use the same keyX. Keyslots 0x35/0x36 use the same keyY, see [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]] for keyslot 0x36.
 +
|-
 +
| 0x38
 +
| See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]], this uses the hardware key-scrambler.
 +
|-
 +
| 0x39
 +
| See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]]. This keyslot keyX is the same keyX used for keyslot 0x38. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
 +
|-
 +
| 0x3D
 +
| This keyslot uses keyY. Used to decrypt title keys in [[Ticket]]. Used by Gateway.
 +
|-
 +
| 0x3E
 +
| This keyslot uses an unique keyX/keyY.
 +
|-
 +
| 0x3F
 +
| This keyslot uses an unique keyX/keyY.
 +
|}
 +
 
 +
=== Hardware key generator ===
 +
Unless noted otherwise, all keyslots on retail units use the hardware key-scrambler, where the final normal-key is generated in hardware using the input keyX and keyY. This normal-key is then written to the hardware keyslot by the AES engine, all of the AES engine key registers are write-only. The internal normal-key keyslot is only updated when the keyY is written to, the keyslot's normal-key is not immediately updated when writing to the keyX.
 +
 
 +
=== keyX ===
 +
The ARM9 bootrom initializes the keyX for each 3DS keyslot, the ARM9 bootrom also initializes the keyY for the keyslots where NATIVE_FIRM doesn't set the keyY. In certain cases Process9 may also set the keyX.
 +
 
 +
=== Updating keydata ===
 +
After writing to a keyslot when the keyslot is already selected, the keyslot must be re-selected for the updated keyslot key-data to be used.
 +
 
 +
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.
 +
 
 +
=== 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), so the New3DS Process9 presumably does this too.

Revision as of 19:57, 28 October 2014

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 ? (something 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_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, however that's not actually needed(keydata gets updated regardless of whether this bit is set).

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

Keyslot Description
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.
0x0D See EncryptDecryptAes, this uses the hardware key-scrambler.
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.
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.
0x20..0x23 All of these keyslots(initialized by bootrom) are set to the same key-data. These seem to be set to a regular normal-key?
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.
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.
0x2D See EncryptDecryptAes, this uses the hardware key-scrambler.
0x2E See EncryptDecryptAes. This keyY is set by NATIVE_FIRM.
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.
0x31 See EncryptDecryptAes, this uses the hardware key-scrambler. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
0x32 See EncryptDecryptAes. This keyslot keyX is the same keyX used for keyslot 0x31.
0x34-0x37 All four of these keyslots use the same keyX. Keyslots 0x35/0x36 use the same keyY, see EncryptDecryptAes for keyslot 0x36.
0x38 See EncryptDecryptAes, this uses the hardware key-scrambler.
0x39 See EncryptDecryptAes. This keyslot keyX is the same keyX used for keyslot 0x38. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
0x3D This keyslot uses keyY. Used to decrypt title keys in Ticket. Used by Gateway.
0x3E This keyslot uses an unique keyX/keyY.
0x3F This keyslot uses an unique keyX/keyY.

Hardware key generator

Unless noted otherwise, all keyslots on retail units use the hardware key-scrambler, where the final normal-key is generated in hardware using the input keyX and keyY. This normal-key is then written to the hardware keyslot by the AES engine, all of the AES engine key registers are write-only. The internal normal-key keyslot is only updated when the keyY is written to, the keyslot's normal-key is not immediately updated when writing to the keyX.

keyX

The ARM9 bootrom initializes the keyX for each 3DS keyslot, the ARM9 bootrom also initializes the keyY for the keyslots where NATIVE_FIRM doesn't set the keyY. In certain cases Process9 may also set the keyX.

Updating keydata

After writing to a keyslot when the keyslot is already selected, the keyslot must be re-selected for the updated keyslot key-data to be used.

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.

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), so the New3DS Process9 presumably does this too.