Security: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[File:ChainOfTrust.png]]
[[File:ChainOfTrust.png]]


Right and down are less trusted. kernel_boot_loader.self does not itself run on F00D but only contains encrypted segments for ARM to run. Unless indicated otherwise, all processes are encrypted and require F00D to decrypt. This diagram reflects current knowledge and may contain inaccuracies (specifically everything on the F00D side is only a best guess).
Right and down are less trusted. kernel_boot_loader.self does not itself run on cmep but only contains encrypted segments for ARM to run. Unless indicated otherwise, all processes are encrypted and require cmep to decrypt. This diagram reflects current knowledge and may contain inaccuracies (specifically everything on the cmep side is only a best guess).


== Root Chain of Trust ==
== Root Chain of Trust ==


The root is F00D's bootrom (First Loader). This is where root keys are seeded and wiped from memory. Either second_loader.enp_ or second_loader.enp are loaded from the eMMC (SLB2 partition). Both .enp files are per-console encrypted (by F00D) during the update process. This is in addition (wraps over) to the already encrypted enp from the update file and is to hinder downgrade attacks (by externally flashing to eMMC a bootloader from another PSVita).
The root is Cmep's bootrom (First Loader). This is where root keys are seeded and wiped from memory. second_loader.enp is loaded from the eMMC (SLB2 partition) or SD Card (if [[SLSK#Secret_debug_mode|SD BOOT]] challenge passes). Both second_loader.enp and secure_kernel.enp files are per-console encrypted from their respective .enc files (by cmep) during the update process. This is in addition (wraps over) to the already encrypted .enc from the update file and is to hinder downgrade attacks (by externally flashing to eMMC a bootloader from another PS Vita).


== Algorithm ==
== Algorithm ==


ECDSA 160/224 with SCE pointbase. (Also ecp_nistz256 for [[SceKrm]]. It looks like an algorithm that speeds up secp256r1)
{| class="wikitable"
|-
! Algorithm
! Used by
! Comments
|-
| ECDSA160
| [[SceNpDrm]] files (act.dat, RIF)/PKG header/some PSP files
| With SCE pointbase
|-
| ECDSA224
| [[SceMsif]]/[[SceNpDrm]] files (?)
| With SCE pointbase
|-
| ECDSA256
| [[SceKrm]]
| With ecp_nistz256 (it looks like an algorithm that speeds up secp256r1)
|-
| RSA2048
| [[SceNpDrm]]/[[SceAppMgr]]/qaf token/Kit activation file/Certified File/[[SceNpDrm]] files (act.dat, RIF)
| N/A
|-
| AES 128/192/256
| In too many places to list.
| N/A
|-
| DES/3DES
| [[SceMsif]]
| For rmauth
|-
| SHA 1/224/256
| In too many places to list.
| N/A
|-
| PRNG
| [[SceKernelModulemgr]]
| For ASLR
|-
| TRNG
| [[SceMsif]]/[[SceSblSsMgr]]
| N/A
|-
| base64
| [[SceNpCommon#SceNpCommon_5601E9A2|SceNpCommon]]
| N/A
|}


RSA 512/1024/2048.
== Boot FW version check ==
 
AES 128/192/256.
 
DES/3DES.
 
SHA 1/224/256
 
P/T RNG
 
== Boot fw check ==


IdStorage SMI leaf. (If smi_fw > second_loader_fw_version, error out)
IdStorage SMI leaf. (If smi_fw > second_loader_fw_version, error out)


SNVS two fw check. (If snvs_fw != second_loader_fw_version, error out)
There are two FW version checks in SNVS. (if snvs_fw != second_loader_fw_version, error out)


kernel_boot_loader.self sw version. (If is_resume == 0 && kbl_fw != second_loader_fw_version, error out)
FW version check in kernel_boot_loader.self. (if is_resume == 0 && kbl_fw_version != second_loader_fw_version, error out)


Maybe more?
Maybe more?
Line 33: Line 68:
== Decryption Request ==
== Decryption Request ==


If something needs to be decrypted from a user/system application ([[PVF]], SELF or [[PUP]] for example), first the request is passed to the non-secure kernel. The non-secure kernel does some checks (mostly integrity checks) then makes a request to [[TrustZone]] to load a new [[SM|Secure Module]] (to have the right keys and the right program to parse the data format). Next the non-securekernel passes the data to the secure kernel to decrypt and the secure kernel passes it to F00D. F00D does the real checks (integrity, signature, format, etc) and decrypts the data directly into the shared DRAM. After clearing the cache, the non-secure kernel has access to the data. F00D will not decrypt if anything fails in its checks.
If something needs to be decrypted from a user/system application ([[PVF]], SELF or [[PUP]] for example), first the request is passed to the non-secure kernel. The non-secure kernel does some checks (mostly integrity checks) then makes a request to [[TrustZone]] to load a new [[Secure_Modules|Secure Modules]] (to have the right keys and the right program to parse the data format). Next the non-securekernel passes the data to the secure kernel to decrypt and the secure kernel passes it to cmep. Cmep does the real checks (integrity, signature, format, etc) and decrypts the data directly into the shared DRAM. After clearing the cache, the non-secure kernel has access to the data. Cmep will not decrypt if anything fails in its checks.


== Security ==
== Security ==


Since most decryption happens on F00D and a signed revoke list is passed early during startup (in [[TrustZone]] modules initialization), it is possible to revoke just about anything on the system. Any hack that can happen before the revoke list is loaded would likely count as a "permanent hack" that cannot be patched without a hardware revision.
Since most decryption happens on cmep and a signed revoke list is passed early during startup (in [[TrustZone]] modules initialization), it is possible to revoke just about anything on the system. Any hack that can happen before the revoke list is loaded would likely count as a "permanent hack" that cannot be patched without a hardware revision.


=== Usermode ===
=== Usermode ===
Line 47: Line 82:
=== Non-secure Kernel ===
=== Non-secure Kernel ===


A hack at this level allows for running unsigned code and also pirated games. Decryption must be done through the secure kernel and F00D, so attempts at loading SELFs from past and future firmwares would not work. To counter piracy, Sony can encrypt new games with new keys and prevent them from running on old compromised firmwares.
A hack at this level allows for running unsigned code and also pirated games. Decryption must be done through the secure kernel and cmep, so attempts at loading SELFs from past and future firmwares would not work. To counter piracy, Sony can encrypt new games with new keys and prevent them from running on old compromised firmwares.


=== ARM Secure Kernel ===
=== ARM Secure Kernel ===


Same level of access and same results as non-secure kernel. Direct access to F00D interrupts could allow for a F00D attack though but there is little gain compared to simply having non-secure kernel code execution.
Same level of access and same results as non-secure kernel. Direct access to cmep interrupts could allow for a cmep attack though but there is little gain compared to simply having non-secure kernel code execution.


=== Secure/non-secure Kernel Bootloader ===
=== Secure/non-secure Kernel Bootloader ===
Line 57: Line 92:
Allows for "non-tethered" hacks. Can be used to load unsigned kernel at an early stage. It does not allow getting more keys than Kernel hacks allowed.
Allows for "non-tethered" hacks. Can be used to load unsigned kernel at an early stage. It does not allow getting more keys than Kernel hacks allowed.


=== F00D Secure Modules ===
=== Cmep Secure Modules ===


All keys are stored in F00D [[SM|Secure Modules]] SELFs, which are validated and decrypted just like ARM SELFs. If [[SM]]s are compromised, keys can be extracted to decrypt updates, bootloader, kernel SELFs, application SELFs, and more.
All keys are stored in cmep [[Secure_Modules|Secure Modules]] SELFs, which are validated and decrypted just like ARM SELFs. If [[Secure_Modules|Secure Modules]]s are compromised, keys can be extracted to decrypt updates, bootloader, kernel SELFs, usermode SELFs, and more.


Sony can revoke most keys by updating slb2:prog_rvk.srvk, keys in SM SELFs, ENC files keys, etc... But SPKG key cannot be changed else older and current firmwares PUPs would not be installable anymore... Once SPKGs are decrypted, filesystem is accessible, but that doesn't mean Certified Files it embeds are decryptable because keys can change.
Sony can revoke most keys by updating slb2:prog_rvk.srvk, keys in SM SELFs, ENC files keys, etc... But SPKG key cannot be changed else older and current firmwares PUPs would not be installable anymore... Once SPKGs are decrypted, filesystem is accessible, but that does not mean Certified Files it embeds are decryptable because keys can change.


=== cMeP Secure Kernel ===
=== cMeP Secure Kernel ===


[[Secure Kernel]] has ability to freely access F00D and ARM memory, so a hack would allow dumping SMs i.e keys. It so has complete control over F00D and ARM. A hack would also allow to read the content of [[F00D_Key_Ring_Base|Bigmac keyslots]] for which some embed keys.
[[Secure Kernel]] has ability to freely access cmep and ARM memory, so a hack would allow dumping SMs i.e keys. It so has complete control over cmep and ARM. A hack would also allow to read the content of [[Cmep_Key_Ring_Base|Cmep keyrings]] for which some embed keys.


=== Second Loader ===
=== Second Loader ===


Compare to [[Secure Kernel]], [[Second Loader]] has access to more [[F00D_Key_Ring_Base|Bigmac keyslots]] because they are not locked yet so a hack would allow to get a few more keys. However at the time [[Second Loader]] runs, [[Secure Kernel]] and ARM kernel bootloaders nor kernel are not in memory yet so a Second Loader hack would have to play with Bigmac keyslots or to run Secure Kernel itself in order to get code execution on lower levels.
Compare to [[Secure Kernel]], [[Second Loader]] has access to more [[Cmep_Key_Ring_Base|Cmep keyrings]] because they are not locked yet so a hack would allow to get a few more keys. However at the time [[Second Loader]] runs, [[Secure Kernel]] and ARM kernel bootloaders nor kernel are not in memory yet so a Second Loader hack would have to play with Bigmac keyrings or to run Secure Kernel itself in order to get code execution on lower levels.


=== First Loader (Boot ROM) ===
=== First Loader (Boot ROM) ===


Boot rom handles the master keys so once it is hacked, most static derived key are computable once for all. As is not updatable (ROM) a First Loader hack
Boot rom handles the master keys so once it is hacked, most static derived key are computable once for all. As is not updatable (ROM) a First Loader hack
is not patchable. However it is almost impossible to hack First Loader without hardware techniques.
is not patchable. However it is currently impossible to hack First Loader on final revision units without hardware techniques.





Latest revision as of 08:27, 4 August 2023

ChainOfTrust.png

Right and down are less trusted. kernel_boot_loader.self does not itself run on cmep but only contains encrypted segments for ARM to run. Unless indicated otherwise, all processes are encrypted and require cmep to decrypt. This diagram reflects current knowledge and may contain inaccuracies (specifically everything on the cmep side is only a best guess).

Root Chain of Trust

The root is Cmep's bootrom (First Loader). This is where root keys are seeded and wiped from memory. second_loader.enp is loaded from the eMMC (SLB2 partition) or SD Card (if SD BOOT challenge passes). Both second_loader.enp and secure_kernel.enp files are per-console encrypted from their respective .enc files (by cmep) during the update process. This is in addition (wraps over) to the already encrypted .enc from the update file and is to hinder downgrade attacks (by externally flashing to eMMC a bootloader from another PS Vita).

Algorithm

Algorithm Used by Comments
ECDSA160 SceNpDrm files (act.dat, RIF)/PKG header/some PSP files With SCE pointbase
ECDSA224 SceMsif/SceNpDrm files (?) With SCE pointbase
ECDSA256 SceKrm With ecp_nistz256 (it looks like an algorithm that speeds up secp256r1)
RSA2048 SceNpDrm/SceAppMgr/qaf token/Kit activation file/Certified File/SceNpDrm files (act.dat, RIF) N/A
AES 128/192/256 In too many places to list. N/A
DES/3DES SceMsif For rmauth
SHA 1/224/256 In too many places to list. N/A
PRNG SceKernelModulemgr For ASLR
TRNG SceMsif/SceSblSsMgr N/A
base64 SceNpCommon N/A

Boot FW version check

IdStorage SMI leaf. (If smi_fw > second_loader_fw_version, error out)

There are two FW version checks in SNVS. (if snvs_fw != second_loader_fw_version, error out)

FW version check in kernel_boot_loader.self. (if is_resume == 0 && kbl_fw_version != second_loader_fw_version, error out)

Maybe more?

Decryption Request

If something needs to be decrypted from a user/system application (PVF, SELF or PUP for example), first the request is passed to the non-secure kernel. The non-secure kernel does some checks (mostly integrity checks) then makes a request to TrustZone to load a new Secure Modules (to have the right keys and the right program to parse the data format). Next the non-securekernel passes the data to the secure kernel to decrypt and the secure kernel passes it to cmep. Cmep does the real checks (integrity, signature, format, etc) and decrypts the data directly into the shared DRAM. After clearing the cache, the non-secure kernel has access to the data. Cmep will not decrypt if anything fails in its checks.

Security

Since most decryption happens on cmep and a signed revoke list is passed early during startup (in TrustZone modules initialization), it is possible to revoke just about anything on the system. Any hack that can happen before the revoke list is loaded would likely count as a "permanent hack" that cannot be patched without a hardware revision.

Usermode

If a game/application/system application is hacked, Sony can easily distribute a firmware update to block the hack. They can also ask a game update and depending on the game that is hacked, they could enforce an update and therefore stop the exploit from triggering.

There are different sandboxes for applications, the more trusted being SceShell modules, which consist of the home screen, LiveArea, background menu, and background usermode tasks.

Non-secure Kernel

A hack at this level allows for running unsigned code and also pirated games. Decryption must be done through the secure kernel and cmep, so attempts at loading SELFs from past and future firmwares would not work. To counter piracy, Sony can encrypt new games with new keys and prevent them from running on old compromised firmwares.

ARM Secure Kernel

Same level of access and same results as non-secure kernel. Direct access to cmep interrupts could allow for a cmep attack though but there is little gain compared to simply having non-secure kernel code execution.

Secure/non-secure Kernel Bootloader

Allows for "non-tethered" hacks. Can be used to load unsigned kernel at an early stage. It does not allow getting more keys than Kernel hacks allowed.

Cmep Secure Modules

All keys are stored in cmep Secure Modules SELFs, which are validated and decrypted just like ARM SELFs. If Secure Moduless are compromised, keys can be extracted to decrypt updates, bootloader, kernel SELFs, usermode SELFs, and more.

Sony can revoke most keys by updating slb2:prog_rvk.srvk, keys in SM SELFs, ENC files keys, etc... But SPKG key cannot be changed else older and current firmwares PUPs would not be installable anymore... Once SPKGs are decrypted, filesystem is accessible, but that does not mean Certified Files it embeds are decryptable because keys can change.

cMeP Secure Kernel

Secure Kernel has ability to freely access cmep and ARM memory, so a hack would allow dumping SMs i.e keys. It so has complete control over cmep and ARM. A hack would also allow to read the content of Cmep keyrings for which some embed keys.

Second Loader

Compare to Secure Kernel, Second Loader has access to more Cmep keyrings because they are not locked yet so a hack would allow to get a few more keys. However at the time Second Loader runs, Secure Kernel and ARM kernel bootloaders nor kernel are not in memory yet so a Second Loader hack would have to play with Bigmac keyrings or to run Secure Kernel itself in order to get code execution on lower levels.

First Loader (Boot ROM)

Boot rom handles the master keys so once it is hacked, most static derived key are computable once for all. As is not updatable (ROM) a First Loader hack is not patchable. However it is currently impossible to hack First Loader on final revision units without hardware techniques.