Cryptosystem

BootROM

The bootrom initializes two keyslots in the hardware engine:

• the SBK (Secure Boot Key) in keyslot 14
• the SSK (Secure Storage Key) in keyslot 15.

Reads from both of these keyslots are disabled by the bootROM. These keys is stored in fuses, and can no longer be accessed after bootrom.

SBK should be shared amongst all consoles, and SSK console-unique. But we don't know this is the case.

Falcon coprocessor

The falcon processor (TSEC) stores a special console-unique key (that will be referred to as the "tsec key").

This is presumably stored in fuses that only microcode authenticated by NVidia has access to.

The tsec key is the source of all per-console entropy, because SSK is not used on retail.

Package1

Key generation

Keyslot	Name	Set by	Cleared by	Per-console
11	Package1Key	Package1	Package1	No
12	MasterKey	Package1	Forever	No
13	PerConsoleKey	Package1	Forever	Yes
14	SecureBootKey	Bootrom	Package1	No
15	SecureStorageKey	Bootrom	Package1	Yes

If bit0 of 0x7000FB94 is clear, it will initialize keys like this (probably used for internal development units only):

 // Final keys:
 package1_key    /* slot11 */ = aes_unwrap(f5baeadb.., sbk)
 master_key      /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x11 ? aff11423.. : 5e177ee1.., aes_unwrap(5ff9c2d9.., sbk))
 per_console_key /* slot13 */ = aes_unwrap(4f025f0e..., aes_unwrap(6e4a9592.., ssk))

Normal key generation looks like this on 1.0.0/2.0.0:

 keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(df206f59.., tsec_key /* slot13 */, sbk /* slot14 */)
 cmac_key    /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)
 
 if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
   panic()
 
 aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)
 
 // Final keys:
 package1_key    /* slot11 */ = keyblob[0x80:0x90]
 master_key      /* slot12 */ = aes_unwrap(is_debug ? 0542a0fd.. : d8a2410a.., keyblob+0x20)
 per_console_key /* slot13 */ = aes_unwrap(4f025f0e.., keyblob_key)

SBK and SSK keyslots are cleared after keys have been generated.

See table above for which keys are console unique.

The key used to verify a keyblob's MAC is not the keyblob key but a key derived from it; this is likely part of an attempt to mitigate side-channel attacks as the MAC is an alterable part of the keyblob.

The bootloader only stores the hardcoded constants for the keyblob used in the current revision. Nintendo are withholding all the future hardcoded constants.

This means that if you have an attack on the bootloader, you need to re-preform it every time they move to a new keyblob.

Dumping the SBK and TSEC key of any single system should be enough to derive all key material on the system.

The key-derivation is described in more detail here.

Table of used keyblobs

System version	Used keyblob	Used master static key encryption key in keyblob
1.0.0-2.3.0	1	1
3.0.0	2	1
3.0.1-3.0.2	3	1

Bootloader stage 1

It is currently unknown what key generation the stage 2 bootloader does.

Secure Monitor

The secure monitor performs some runtime cryptographic operations. See SMC for what operations it provides.