Difference between revisions of "Ernie Secure"

Revision as of 21:53, 6 January 2019

SNVS

The syscon provides raw storage. Kermit partitions some of this storage for encrypted data. The keys to encrypt/decrypt this data is from slots 0x502-0x504. They are derived by second_loader by encrypting a constant buffer with key slot 0x216 using AES-256-CBC, which is console unique. Consoles with factory firmware < 0.996 use a set of static keys found in second_loader. Factory firmware comes from idstorage.

Shared Secrets

Class	Shared Key A	Shared Key B	Shared Key C	Shared Data A	Shared Data B
0xB	`BB644721CB4C55072E83177BEB3BBEE9`	`DC6B6EE0F457DF0E7BAD1C5EA338027F`	`00000000000000000000000000000000`	`CF2E93E9F94E28CCA48026134C7C77CE`
0xF	`50E4C3A77264167C409C72A9B57A8609`	`9E34087C48985B4B351A63572D9B481B`	`EBE3460D84A41754AC441368CF0200D8`	`C86B51FB019A207F32118E55462D5008`	`457798C6D9B8390DDCA49745746F65A000000000000000000000000000000000`

Syscon four part key exchange

The 0F here appears to be a class id. Only 0F and 0B has been seen but only 0F seems to be supported by the update sm using the command 0xD0002 (with different sequence number for each part).

Part 1: Ernie challenges Kermit

Generate an empty buffer 30 00 00 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 and send it to Syscon.
Syscon returns header 30 01 00 0F 00 00 00 00 + 8 byte challenge.

Part 2: Kermit responds and challenges Ernie

F00D composes a data buffer that is 8 bytes of RNG value, 8 bytes copied from challenge in part 1.2, and 16 bytes of Shared Data A.
This data is encrypted using AES-128-CBC with all zero IV and Shared Key A as the key.
A header is prepended 30 02 00 0F 01 00 00 00 to the data and sent to Syscon

Part 3: Session Key Establishment

Gets a 0x28 byte response from Syscon with a header 30 03 00 0F 00 00 00 00 and 0x20 buffer.
Decrypt with AES-128-CBC with all zero IV and the key Shared Key B.
Check that first 8 byte matches the challenge from part 1.2 and next 8 byte matches the F00D nonce generated in part 2.1. The remaining 16 bytes are zero.
Encrypt the same buffer back using Shared Key C for 16 bytes. The IV will be the last 16 bytes from the encrypted input buffer.
This is now the session key!

Part 4: Verification

Using the session key, encrypt a known value, Shared Data B.
Append the header 30 04 00 0F 00 00 00 00 and send to Syscon
Get a response back from Syscon (header 30 05 00 0F 00 00 00 00), decrypt the buffer with the session, and check that it matches the known value. Both the plaintext and ciphertext should match.

This part is only seen used with command 0xD0 and not 0xA0.

Channel Protocol

Packets sent/received with command 0xD2 are encrypted with the session key and IV = 0. There is a 4 byte command field, 4 byte counter (from keyslot 0x512) that increments per send, 6 bytes of zeros, optional data, and a 2 byte checksum. The checksum is the sum of all previous bytes and then negated.

Syscon 0xA0

This command uses class 0xB and is only seen in secure_loader. No data transfer is seen. The session key derived here is actually not used. The hypothesis is that this handshake serves as a checkpoint for the Syscon to know that F00D has successfully decrypted IDPS and OpenPSID since in between the handshake each decryption happens. The decryption does not use any data from this handshake.

Syscon 0xD0

Establishes a secure channel for class 0xF used by updater 0xD0002 as well as second_loader.

After handshake:

Keyslot 0x511 is programmed with the session key.

Keyslot 0x512 is programmed with a 32 bit random number from Bigmac.

Syscon 0xD2

Data transfer for class 0xF.

Seen at boot

First transaction

F00D => Syscon: 00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 6C FD

F00D <= Syscon: 00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 01 DD C7 AB 57 AD 28 9E 00 93 51 F8 D3 D2 29 2E 78 B6 8C 63 5A 26 7A A9 6B C8 E3 AC F3 3D 61 77 F0 EC

Data decrypted using a slot in 0x502-0x504 and result is written to slot 0x50B (8 bytes).

Second transaction

F00D => Syscon: 20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 4B FD

F00D <= Syscon: 20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 95 AD 79 D1 FE 5E 96 4B 3F 66 7D 47 04 28 05 E9 EB D1 26 86 E2 C1 9B 7B 53 B6 D3 11 76 8F 2D 3F 80 ED

Decrypted is a list of versions, two are read using some information from the MBR. On a default 3.60 retail system, the two offsets used are at 0x4 and 0x8. Those are both checked to be 0x03600000 on 3.60 (hard coded). If they are 0xDEADBEEF, the check is skipped. Additionally, in the decrypted buffer from the previous command (written to slot 0x50B), if bit 1 at byte offset 0x4 is set, then the version check is skipped. Then, if boot is not resume the version from kernel_boot_loader.self is also checked. Finally slot 0x50E and 0x518 are written with these two version codes.

@@ Line 1: / Line 1: @@
-== Syscon 0xD0 four part key exchange ==
+== SNVS ==
-The <code>0F</code> here appears to be a context id. Only <code>0F</code> and <code>0B</code> has been seen but only <code>0F</code> seems to be supported by the update sm.
+The syscon provides raw storage. Kermit partitions some of this storage for encrypted data. The keys to encrypt/decrypt this data is from slots 0x502-0x504. They are derived by second_loader by encrypting a constant buffer with key slot 0x216 using AES-256-CBC, which is console unique. Consoles with factory firmware < 0.996 use a set of static keys found in second_loader. Factory firmware comes from idstorage.
-=== Part 1 ===
+== Shared Secrets ==
+{| class="wikitable sortable"
+|-
+! Class !! Shared Key A !! Shared Key B !! Shared Key C !! Shared Data A !! Shared Data B
+|-
+| 0xB || <code>BB644721CB4C55072E83177BEB3BBEE9</code> || <code>DC6B6EE0F457DF0E7BAD1C5EA338027F</code> || <code>00000000000000000000000000000000</code> || <code>CF2E93E9F94E28CCA48026134C7C77CE</code> ||
+|-
+| 0xF || <code>50E4C3A77264167C409C72A9B57A8609</code> || <code>9E34087C48985B4B351A63572D9B481B</code> || <code>EBE3460D84A41754AC441368CF0200D8</code> || <code>C86B51FB019A207F32118E55462D5008</code> || <code>457798C6D9B8390DDCA49745746F65A000000000000000000000000000000000</code>
+|-
+|}
+== Syscon four part key exchange ==
+The <code>0F</code> here appears to be a class id. Only <code>0F</code> and <code>0B</code> has been seen but only <code>0F</code> seems to be supported by the update sm using the command [[F00D_Commands#0xD0002|0xD0002]] (with different sequence number for each part).
+=== Part 1: Ernie challenges Kermit ===
 # Generate an empty buffer <code>30 00 00 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00</code> and send it to Syscon.
-# Syscon returns header + 8 byte challenge.
+# Syscon returns header <code>30 01 00 0F 00 00 00 00</code> + 8 byte challenge.
-=== Part 2 ===
+=== Part 2: Kermit responds and challenges Ernie ===
-# F00D composes a data buffer that is 8 bytes of RNG value, 8 bytes copied from challenge, and 16 bytes of shared data. On 1.69, the shared data is <code>C86B51FB019A207F32118E55462D5008</code>
+# F00D composes a data buffer that is 8 bytes of RNG value, 8 bytes copied from challenge in part 1.2, and 16 bytes of '''Shared Data A'''.
-# This data is encrypted using AES-128-CBC with all zero IV and a shared key. On 1.69, it is <code>50E4C3A77264167C409C72A9B57A8609</code>
+# This data is encrypted using AES-128-CBC with all zero IV and '''Shared Key A''' as the key.
 # A header is prepended <code>30 02 00 0F 01 00 00 00</code> to the data and sent to Syscon
-=== Part 3 ===
+=== Part 3: Session Key Establishment ===
-# Gets a 0x28 byte response from Syscon with a 0x20 buffer.
+# Gets a 0x28 byte response from Syscon with a header <code>30 03 00 0F 00 00 00 00</code> and 0x20 buffer.
-# Decrypt with AES-128-CBC with IV from part 2 (it is the last ciphertext generated, or the last 16 bytes of the ciphertext sent from F00D) and a shared key. On 1.69 it is <code>9E34087C48985B4B351A63572D9B481B</code>
+# Decrypt with AES-128-CBC with all zero IV and the key '''Shared Key B'''.
-# Check that first 8 byte matches unknown and next 8 byte matches the F00D nonce generated in part 1.
+# Check that first 8 byte matches the challenge from part 1.2 and next 8 byte matches the F00D nonce generated in part 2.1. The remaining 16 bytes are zero.
-# Encrypt the same buffer back using a shared key for 16 bytes. On 1.69 it is <code>EBE3460D84A41754AC441368CF0200D8</code> and the IV will be the last 16 bytes from the encrypted input buffer.
+# Encrypt the same buffer back using '''Shared Key C''' for 16 bytes. The IV will be the last 16 bytes from the encrypted input buffer.
 # This is now the session key!
-=== Part 4 ===
+=== Part 4: Verification ===
-# Using the session key, encrypt a known value. On 1.69 it is <code>457798C6D9B8390DDCA49745746F65A000000000000000000000000000000000</code>
+# Using the session key, encrypt a known value, '''Shared Data B'''.
 # Append the header <code>30 04 00 0F 00 00 00 00</code> and send to Syscon
-# Get a response back from Syscon, decrypt the buffer with the session, and check that it matches the known value. Both the plaintext and ciphertext should match.
+# Get a response back from Syscon (header <code>30 05 00 0F 00 00 00 00</code>), decrypt the buffer with the session, and check that it matches the known value. Both the plaintext and ciphertext should match.
-# Keyslot 0x511 is programmed with the session key.
+This part is only seen used with command 0xD0 and not 0xA0.
-# Keyslot 0x512 is programmed with a 32 bit random number from Bigmac.
+=== Channel Protocol ===
+Packets sent/received with command 0xD2 are encrypted with the session key and IV = 0. There is a 4 byte command field, 4 byte counter (from keyslot 0x512) that increments per send, 6 bytes of zeros, optional data, and a 2 byte checksum. The checksum is the sum of all previous bytes and then negated.
+== Syscon 0xA0 ==
+This command uses class 0xB and is only seen in secure_loader. No data transfer is seen. The session key derived here is actually not used. The hypothesis is that this handshake serves as a checkpoint for the Syscon to know that F00D has successfully decrypted IDPS and OpenPSID since in between the handshake each decryption happens. The decryption does not use any data from this handshake.
+== Syscon 0xD0 ==
+Establishes a secure channel for class 0xF used by updater 0xD0002 as well as second_loader.
+After handshake:
+Keyslot 0x511 is programmed with the session key.
+Keyslot 0x512 is programmed with a 32 bit random number from Bigmac.
+== Syscon 0xD2 ==
+Data transfer for class 0xF.
+=== Seen at boot ===
+First transaction
+F00D => Syscon: <code>00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 6C FD</code>
+F00D <= Syscon: <code>00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 01 DD C7 AB 57 AD 28 9E 00 93 51 F8 D3 D2 29 2E 78 B6 8C 63 5A 26 7A A9 6B C8 E3 AC F3 3D 61 77 F0 EC</code>
+Data decrypted using a slot in 0x502-0x504 and result is written to slot 0x50B (8 bytes).
+Second transaction
+F00D => Syscon:  <code>20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 4B FD</code>
+F00D <= Syscon:  <code>20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 95 AD 79 D1 FE 5E 96 4B 3F 66 7D 47 04 28 05 E9 EB D1 26 86 E2 C1 9B 7B 53 B6 D3 11 76 8F 2D 3F 80 ED</code>
+Decrypted is a list of versions, two are read using some information from the MBR. On a default 3.60 retail system, the two offsets used are at 0x4 and 0x8. Those are both checked to be 0x03600000 on 3.60 (hard coded). If they are 0xDEADBEEF, the check is skipped. Additionally, in the decrypted buffer from the previous command (written to slot 0x50B), if bit 1 at byte offset 0x4 is set, then the version check is skipped. Then, if boot is not resume the version from kernel_boot_loader.self is also checked. Finally slot 0x50E and 0x518 are written with these two version codes.