Line 234:
Line 234:
|-
|-
| 0x20
| 0x20
−
| IOSC_EncryptBlocks();
+
| IOSC_EncryptBlocks(IOSCSecretKeyHandle keyHandle, int mode, u8 * ivOrNonce, u32 ivOrNonceSize, u8 * inData, u32 inSize, u8 * outData, u8 * outSize);
| IOS_Ioctlv(FD, 0x20, 3, 1, vector);
| IOS_Ioctlv(FD, 0x20, 3, 1, vector);
| Software AES encryption, this supports multiple AES-modes (AES-CTR, ...). Used by IOS-PAD to encrypt amiibo data.
| Software AES encryption, this supports multiple AES-modes (AES-CTR, ...). Used by IOS-PAD to encrypt amiibo data.
+
{| class="wikitable" border="1"
+
|-
+
! Mode
+
! Description
+
|-
+
| 0x0
+
| AES-ECB
+
|-
+
| 0x1
+
| AES-CBC
+
|-
+
| 0x2
+
| AES-CTR
+
|}
|
|
|-
|-
| 0x21
| 0x21
−
| IOSC_DecryptBlocks();
+
| IOSC_DecryptBlocks(IOSCSecretKeyHandle keyHandle, int mode, u8 * ivOrNonce, u32 ivOrNonceSize, u8 * inData, u32 inSize, u8 * outData, u8 * outSize);
| IOS_Ioctlv(FD, 0x21, 3, 1, vector);
| IOS_Ioctlv(FD, 0x21, 3, 1, vector);
| Software AES decryption version of the above ioctlv. Used by IOS-PAD to decrypt amiibo data.
| Software AES decryption version of the above ioctlv. Used by IOS-PAD to decrypt amiibo data.
Line 259:
Line 273:
|}
|}
−
==Key object handles==
+
== Key object handles ==
−
The above crypto commands use key/crypto object handles. These handles can be either from IOSC_CreateObject (which can then be initialized with IOSC_ImportSecretKey in the case of AES), or a built-in handle. The available built-in handles/ids are listed below.
+
The above crypto commands use key/crypto object handles. These handles can be either from IOSC_CreateObject (which can then be initialized with IOSC_ImportSecretKey in the case of AES), or a built-in handle. The available built-in handles are listed below.
The maximum number of keyobject-handles is 0x80, hence the highest valid keyobject-handle is 0x7F. Keyobject-handles <=0x40 are reserved for built-in handles, the rest are available for user-processes. Commands which write keyobjects' keydata are only allowed to use handles with value >0x40 (user-process handles).
The maximum number of keyobject-handles is 0x80, hence the highest valid keyobject-handle is 0x7F. Keyobject-handles <=0x40 are reserved for built-in handles, the rest are available for user-processes. Commands which write keyobjects' keydata are only allowed to use handles with value >0x40 (user-process handles).
{| class="wikitable sortable"
{| class="wikitable sortable"
−
! ID
+
! Handle
! Type
! Type
+
! Owner
! Description
! Description
|-
|-
| 0x00
| 0x00
−
| ECC-233
+
| ECC-B233
−
| IOSC_DEV_SIGNING_KEY_HANDLE (Wii U device private key)
+
| IOS-MCP
+
| IOSC_DEV_SIGNING_KEY_HANDLE
+
Wii U device private key.
|-
|-
| 0x01
| 0x01
| NONE
| NONE
−
| IOSC_DEV_ID_HANDLE (Wii U device ID)
+
| ALL
+
| IOSC_DEV_ID_HANDLE
+
Wii U device ID.
|-
|-
| 0x02
| 0x02
| AES-128
| AES-128
−
| IOSC_FS_ENC_HANDLE (SLC key)
+
| IOS-FS
+
| IOSC_FS_ENC_HANDLE
+
SLC NAND key.
|-
|-
| 0x03
| 0x03
−
| HMAC SHA-1
+
| HMAC-SHA-1
−
| IOSC_FS_MAC_HANDLE (SLC HMAC)
+
| IOS-FS
+
| IOSC_FS_MAC_HANDLE
+
SLC NAND HMAC key.
|-
|-
| 0x04
| 0x04
| AES-128
| AES-128
−
| IOSC_COMMON_ENC_HANDLE (Wii common key)
+
| IOS-MCP
+
| IOSC_COMMON_ENC_HANDLE
+
Wii common key.
|-
|-
| 0x05
| 0x05
| AES-128
| AES-128
−
| IOSC_BACKUP_ENC_HANDLE (Wii U backup key)
+
| IOS-MCP
+
| IOSC_BACKUP_ENC_HANDLE
+
Wii U backup key.
Used by commands 0x15, 0x16, 0x17 and 0x18.
Used by commands 0x15, 0x16, 0x17 and 0x18.
|-
|-
| 0x06
| 0x06
| AES-128
| AES-128
−
| IOSC_APP_ENC_HANDLE (Wii SD key)
+
| ALL
+
| IOSC_APP_ENC_HANDLE
+
Wii SD key.
|-
|-
| 0x07
| 0x07
| AES-128
| AES-128
−
| IOSC_BOOTOSVER_ENC_HANDLE (SEEPROM key)
+
| IOS-MCP
+
| IOSC_BOOTOSVER_ENC_HANDLE
+
SEEPROM key.
|-
|-
| 0x08
| 0x08
| NONE
| NONE
−
| IOSC_CACRLVER_HANDLE (Unused)
+
| NONE
+
| IOSC_CACRLVER_HANDLE
+
Unused.
|-
|-
| 0x09
| 0x09
| NONE
| NONE
−
| IOSC_SIGNERCRLVER_HANDLE (Unused)
+
| NONE
+
| IOSC_SIGNERCRLVER_HANDLE
+
Unused.
|-
|-
| 0x0A
| 0x0A
| NONE
| NONE
−
| IOSC_FSVER_HANDLE (Unused)
+
| NONE
+
| IOSC_FSVER_HANDLE
+
Unused.
|-
|-
| 0x0B
| 0x0B
| AES-128
| AES-128
−
| IOSC_COMMON2_ENC_HANDLE (Wii common2 key)
+
| IOS-MCP
+
| IOSC_COMMON2_ENC_HANDLE
+
Wii common2 key.
|-
|-
| 0x0C
| 0x0C
| AES-128
| AES-128
+
| IOS-FS
| Drive key
| Drive key
|-
|-
| 0x0D
| 0x0D
| AES-128
| AES-128
+
| IOS-MCP
| Starbuck [[Ancast_Image|ancast]] key
| Starbuck [[Ancast_Image|ancast]] key
|-
|-
| 0x0E
| 0x0E
| RSA-2048
| RSA-2048
+
| IOS-MCP
| Starbuck [[Ancast_Image|ancast]] modulus
| Starbuck [[Ancast_Image|ancast]] modulus
|-
|-
| 0x0F
| 0x0F
| RSA-2048
| RSA-2048
+
| IOS-MCP
| Boot1 [[Ancast_Image|ancast]] modulus
| Boot1 [[Ancast_Image|ancast]] modulus
|-
|-
| 0x10
| 0x10
| AES-128
| AES-128
+
| IOS-MCP
| Wii U common key
| Wii U common key
|-
|-
| 0x11
| 0x11
| AES-128
| AES-128
−
| MLC key
+
| IOS-FS
+
| MLC NAND key
|-
|-
| 0x12
| 0x12
| AES-128
| AES-128
−
| USB WFS and WagonU key
+
| IOS-MCP
−
This key is generated by ECB-encrypting the IVS seed from SEEPROM with the IVS key from the OTP.
+
IOS-FS
+
| STRM key
+
Generated by ECB-encrypting the IVS seed from SEEPROM with the IVS key from the OTP.
+
Used for USB WFS and WagonU file streaming.
|-
|-
| 0x13
| 0x13
| AES-128
| AES-128
−
| SLCCMPT key
+
| IOS-FS
+
| SLCCMPT NAND key
|-
|-
| 0x14
| 0x14
−
| HMAC SHA-1
+
| HMAC-SHA-1
−
| SLCCMPT HMAC
+
| IOS-FS
+
| SLCCMPT NAND HMAC key
|-
|-
| 0x15
| 0x15
| AES-128
| AES-128
+
| IOS-MCP
| vWii common key
| vWii common key
|-
|-
| 0x16
| 0x16
| AES-128
| AES-128
+
| IOS-PAD
| DRH WLAN data key
| DRH WLAN data key
|-
|-
| 0x17
| 0x17
| AES-128
| AES-128
+
| IOS-NET
| UDS local-WLAN CCMP key
| UDS local-WLAN CCMP key
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (used by IOS-NET).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
−
This key is shared with the 3DS.
+
Shared with the 3DS.
|-
|-
| 0x18
| 0x18
| AES-128
| AES-128
+
| IOS-NET
| DLP key
| DLP key
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (used by IOS-NET).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
−
This key is shared with the 3DS.
+
Shared with the 3DS.
|-
|-
| 0x19
| 0x19
| AES-128
| AES-128
+
| ALL
| APT wrap key
| APT wrap key
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (used by IOS-ACP).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
−
This key is shared with the 3DS.
+
Shared with the 3DS.
|-
|-
| 0x1A
| 0x1A
| AES-128
| AES-128
−
| Unknown
+
| IOS-FS
+
| Wii media title key
|-
|-
| 0x1B
| 0x1B
| AES-128
| AES-128
−
| SSL RSA kek
+
| IOS-NSEC
+
| SSL RSA key encryption key
|-
|-
| 0x1C
| 0x1C
−
| ECC-233
+
| ECC-B233
−
| Wii U NSS device certificate private key
+
| IOS-NSEC
+
| Wii U device unique certificate private key
|-
|-
| 0x1D
| 0x1D
−
| ECC-233
+
| ECC-B233
−
| Wii NSS device certificate private key
+
| IOS-NSEC
+
| Wii U device authentication common certificate private key
|-
|-
| 0x1E
| 0x1E
| AES-128
| AES-128
+
| IOS-NSEC
| APPSTORE objinfo/objdata key
| APPSTORE objinfo/objdata key
−
This key is the first 0x10 bytes of the Wii U NSS device certificate private key.
+
Generated by copying the first 0x10 bytes of the Wii U device unique certificate private key.
|-
|-
| 0x1F
| 0x1F
| AES-128
| AES-128
+
| IOS-NIM-BOSS
| SpotPass data file key
| SpotPass data file key
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (used by IOS-NIM-BOSS).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
|-
|-
| 0x20
| 0x20
−
| HMAC SHA-256
+
| HMAC-SHA-256
+
| IOS-NIM-BOSS
| SpotPass data file HMAC key
| SpotPass data file HMAC key
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (0x40 bytes, used by IOS-NIM-BOSS).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
|-
|-
| 0x21
| 0x21
−
| UNK
+
| HMAC-SHA-256
−
| Unknown
+
| IOS-NIM-BOSS
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (0x20 bytes).
+
| VersionList HMAC key
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
|-
|-
| 0x22
| 0x22
−
| AES-128
+
| HMAC-SHA-256
+
| IOS-PAD
| Amiibo HMAC key 1
| Amiibo HMAC key 1
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (used by IOS-PAD).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
−
This key is used to generate a SHA-256 HMAC for the Amiibo data.
|-
|-
| 0x23
| 0x23
−
| AES-128
+
| HMAC-SHA-256
+
| IOS-PAD
| Amiibo HMAC key 2
| Amiibo HMAC key 2
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (used by IOS-PAD).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
−
This key is used to generate a SHA-256 HMAC for the Amiibo data.
|-
|-
| 0x24
| 0x24
| AES-128
| AES-128
+
| IOS-PAD
| NFC key
| NFC key
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (used by IOS-PAD).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
−
This key is shared with the 3DS.
|-
|-
| 0x25
| 0x25
| AES-128
| AES-128
+
| IOS-PAD
| Wii U NFC key block key
| Wii U NFC key block key
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (used by IOS-PAD).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
−
This key is used to decrypt a block of 0x70 bytes inside IOS-PAD.
+
Used for decrypting the Wii U specific "unfixed infos" and "locked secret" keys.
−
Once decrypted, this block contains the Wii U specific "unfixed infos" and "locked secret" keys.
|-
|-
| 0x26
| 0x26
| AES-128
| AES-128
+
| IOS-FS
| Unknown
| Unknown
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (0x10 bytes).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO.
|-
|-
| 0x27
| 0x27
| AES-128
| AES-128
+
| IOS-NIM-BOSS
| Pushmore link key
| Pushmore link key
−
Generated by XORing the XOR key with static data inside IOS-CRYPTO (used by IOS-NIM-BOSS).
+
Generated by XORing the XOR key with static data inside IOS-CRYPTO
|-
|-
| 0x28
| 0x28
| AES-128
| AES-128
−
| Wii U extra storage key
+
| IOS-FS
−
In debug hardware with an internal HDD (Kiosk and certain DevKits) this key is generated by decrypting the SHDD seed from SEEPROM with the SHDD key from the OTP.
+
| SHDD key
−
In debug hardware without additional internal storage, this is the same as the MLC key.
+
This key is only set for board types IH or ID.
−
In retail hardware this key is never set.
+
If the ShddConfig flag in SEEPROM is 0x0000 and the system is a development unit, it is the same as the MLC NAND key.
+
If the ShddConfig flag in SEEPROM is 0xFFFF, it is generated by decrypting the SHDD seed from SEEPROM with the SHDD key from eFuses.
|-
|-
−
| 0x29 to 0x40
+
| 0x29-0x40
−
| UNK
+
| NONE
+
| NONE
| Unused
| Unused
|}
|}