1,359
edits
Changes
Jump to navigation
Jump to search
Line 10:
Line 10: − + − + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 30:
Line 68: − ==== Summary of key derivations ====+ − − The device keyblob seed generation key is unique to each device and obtained from the Falcon. It is used to generate one or several of the keyblob key seeds by decrypting keybloob's seed constants. The keyblob key seeds are decrypted by the SBK to create the keyblob keys. − Each keyblob key is used to decrypt its associated keyblob's keydata, and the keyblob key for the first keyblob is additionally used to generate the master device key. − Each keyblob stores 8 master static key encryption keys, and the stage 2 bootloader decryption key. The master static key is generated by decrypting the master static key seed (one of two constants depending on retail or dev unit) with the master static key encryption key. Line 53:
Line 87: − +
trying to reduce redundancy without ruining everything
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 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.
== Bootloader stage 1 ==
== Bootloader stage 0 ==
=== Key generation ===
=== Key generation ===
Bootloader stage 1 generates three keys: the stage 2 decryption key, stored in keyslot 0xB; the master static key, which will be used by stage 2 to generate all the static keys, stored in keyslot 0xC; and the master device key, which will be used by stage 2 to generate all the device-specific keys, stored in keyslot 0xD.
{| class="wikitable" border="1"
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).
|-
! Keyslot
! Name
! Set by
! Cleared by
! Per-console
|-
| 0xB
| Pk11DecryptionKey
| [[Package1]]
| [[Package1]]
| No
|-
| 0xC
| MasterKey
| [[Package1]]
| Forever
| No
|-
| 0xD
| ConsoleKey
| [[Package1]]
| Forever
| Yes
|-
| 0xE
| SecureBootKey
| Bootrom
| [[Package1]]
| No
|-
| 0xF
| SecureStorageKey
| Bootrom
| [[Package1]]
| Yes
|}
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.
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.
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 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).
The key-derivation is described [[#Package1#Key_generation|here]].
==== Table of used keyblobs ====
==== Table of used keyblobs ====
|}
|}
== Bootloader stage 2 ==
== 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.