1,359
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − Like the 3DS, the Switch relies on a number of cryptographic keys to prevent unauthorized persons from dumping and analyzing its software and assets. This page will focus on the "symmetric" cryptography involved in the Switch's cryptosystem.+ + − == BootROM ==+ + + + + − The Switch's BootROM does no symmetric cryptographic operations. However, it sets up two keys in the hardware security engine's keyslots: the SBK (Secure Boot Key) in keyslot 0xE and the SSK (Secure Storage Key) in keyslot 0xF. Reads from both of these keyslots are disabled by the bootROM. The material used to generate these keys is stored in special fuses that have their access disabled by the bootROM.+ − The SBK is common to all consoles while the SSK is console unique. The SSK is not used on retail devices. + + + − + − + Line 22:
Line 29: − + − + − + Line 34:
Line 41: − + − + − + Line 46:
Line 53: − + Line 53:
Line 60: − Bootloader stage 0 generates three keys. Keyslot 0xB is cleared after it is used to decrypt the stage 2 bootloader; only keyslots 0xC and 0xD will be transferred to stage 2. Additionally, keyslots 0xC and 0xD are set read-only after they are generated. The SBK and the SSK are also cleared after use (although the SSK isn't used at all, except on dev units).+ + + + − The master static key is generated by decrypting the master static seed (a constant stored in bootloader .data) with the master static key encryption key. The master static seed used varies depending on whether the console is a retail unit or a dev unit.+ − Both the master static key encryption key and the stage 2 key are stored in a keyblob. The keyblob format is described [[Flash_Filesystem#Keyblob|here]].+ + + + + + + + + + + + − The 32 blobs are stored in the eMMC. Only one at a time is loaded, it is controlled by the bootloader version field in the BCT (at +0x2330).+ − Although the keydata is presumably common to all consoles, each keyblob is console-unique, because the key used to encrypt it is at the factory is console unique. Each keyblob has its own encryption key, with keyblob key N generated by decrypting keyblob key seed N with the SBK, and keyblob key seed N generated by decrypting keyblob N's seed constant with the device keyblob seed generation key obtained from the Falcon. Keyblob key 1 is special: In addition to being used to decrypt keyblob 1, it is also used to generate the master device key by decrypting a constant block.+ − + − + − + − + Line 94:
Line 115: − −
simplifying
== 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 ==
== 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 falcon processor (TSEC) stores a special console-unique key (that will be referred to as the "device keyblob seed generation key") 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.
== Bootloader stage 0 ==
== Package1 ==
=== Key generation ===
=== Key generation ===
! Per-console
! Per-console
|-
|-
| 0xB
| 11
| Pk11DecryptionKey
| Package1Key
| [[Package1]]
| [[Package1]]
| [[Package1]]
| [[Package1]]
| No
| No
|-
|-
| 0xC
| 12
| MasterKey
| MasterKey
| [[Package1]]
| [[Package1]]
| No
| No
|-
|-
| 0xD
| 13
| ConsoleKey
| PerConsoleKey
| [[Package1]]
| [[Package1]]
| Forever
| Forever
| Yes
| Yes
|-
|-
| 0xE
| 14
| SecureBootKey
| SecureBootKey
| Bootrom
| Bootrom
| No
| No
|-
|-
| 0xF
| 15
| SecureStorageKey
| SecureStorageKey
| Bootrom
| Bootrom
|}
|}
If bit0 of 0x7000FB94 is clear, it will initialize keys like this (probably used for internal development units only):
keyslot11 = aes_unwrap(f5baeadb.., sbk)
keyslot12 = aes_unwrap(5ff9c2d9.., sbk)
keyslot13 = 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 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 seed constants for the keyblob loaded by the current revision and for keyblob 1 (So that the master device key can be generated).
The bootloader only stores the hardcoded constants for the keyblob used in the current revision. Nintendo are withholding all the future hardcoded constants.
This mechanism provides several advantages. If the stage 2 bootloader is compromised, stage 1 can just use another master static key in the keyblob. If stage 1 itself is glitched or exploited in such a way the keyblob is dumped, Nintendo just has to change the loaded keyblob: the vulnerable bootloader won't be able to decrypt the new keyblob, as the keyblob key it knows is different from the one needed. Even if somehow an exploit or glitch allowed one to be able to use the SBK to generate keyblob keys, the seed constants for future keyblobs are unknown (and will be until Nintendo releases new bootloaders that use them), and so the exploit or glitch would have to be re-done on each new bootloader revision (if it's not patched).
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 fuses and TSEC key of any single system would effectively bypass all of the above security mechanisms.
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 [[Package1#Key_generation|here]].
The key-derivation is described in more detail [[Package1#Key_generation|here]].
==== Table of used keyblobs ====
==== Table of used keyblobs ====
== Bootloader stage 1 ==
== Bootloader stage 1 ==
It is currently unknown what key generation the stage 2 bootloader does.
It is currently unknown what key generation the stage 2 bootloader does.
== Secure Monitor ==
== Secure Monitor ==
The secure monitor performs some runtime cryptographic operations. See [[SMC]] for what operations it provides.
The secure monitor performs some runtime cryptographic operations. See [[SMC]] for what operations it provides.