Switch System Flaws: Difference between revisions

Line 80:

| December 16, 2018

| Everyone (independently).

|-

| TSEC ROM does not clear crypto registers after signature verification

|

TSEC supports executing signed-microcode at a greater privilege level than normal payloads.

When jumping to signed microcode, the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.

TSEC ROM then calculates the expected signature and compares it to the user-supplied one in $c6. On match, the secure payload is executed, and on failure an exception is raised.

However, TSEC ROM fails to clear the crypto registers used to calculate the expected signature in either of the success/failure cases.

Thus, with some way of obtaining the contents of crypto registers (e.g. ROP under some secure payload), an attacker can dump intermediary values from signature calculation.

With enough data/trial/error, this is enough to reconstruct the signature algorithm:

* mac = <davies meyer hash of (page || address of page) for each 0x100 page in the payload>

* key = AES-ENCRYPT(hardware csecret 0x1, seed)

* signature = AES-ENCRYPT(key, mac)

| None

| HAC-001 (Tegra210)

| Late 2018/Early 2019

| August 2020

|-

| TSEC signature validation design flaw leads to fake-signing

|

As mentioned above, when jumping to signed microcode the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.

However, TSEC ROM performs no validation on the input seed used to generate the signing key.

This leads to the following attack:

* Attacker gains rop under any secure microcode payload with signature = S.

* Attacker uses the "csigenc" instruction to obtain K = AES-ENCRYPT(hardware csecret 0x1, S).

* Attacker jumps to their own microcode with $c6 = <signature calculated on pc using K>, $c7 = S

* TSEC ROM calculates key = AES-ENCRYPT(hardware csecret 0x1, S) = K, and the signature check passes.

* Attackers microcode is executed in secure mode as though it were signed by NVidia.

Thus an attacker who has exploited *any* secure payload may use this to obtain a "fake signature key", which can be used to sign and execute arbitrary microcode in secure mode.

Note: this does not break the TSEC cryptosystem, as the csigenc mechanism relies on the signature of the executing microcode, and fakesigning produces different signatures from NVidia that cannot be controlled.

| None

| HAC-001 (Tegra210)

| Late 2018/Early 2019

| August 2020

|}

@@ Line 80: / Line 80: @@
 | December 16, 2018
 | Everyone (independently).
+|-
+| TSEC ROM does not clear crypto registers after signature verification
+|
+TSEC supports executing signed-microcode at a greater privilege level than normal payloads.
+When jumping to signed microcode, the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.
+TSEC ROM then calculates the expected signature and compares it to the user-supplied one in $c6. On match, the secure payload is executed, and on failure an exception is raised.
+However, TSEC ROM fails to clear the crypto registers used to calculate the expected signature in either of the success/failure cases.
+Thus, with some way of obtaining the contents of crypto registers (e.g. ROP under some secure payload), an attacker can dump intermediary values from signature calculation.
+With enough data/trial/error, this is enough to reconstruct the signature algorithm:
+* mac = <davies meyer hash of (page || address of page) for each 0x100 page in the payload>
+* key = AES-ENCRYPT(hardware csecret 0x1, seed)
+* signature = AES-ENCRYPT(key, mac)
+| None
+| HAC-001 (Tegra210)
+| Late 2018/Early 2019
+| August 2020
+| [[User:qlutoo|qlutoo]]/[[User:Hexkyz|hexkyz]]/[[User:Shuffle2|shuffle2]], [[User:SciresM|SciresM]]/[[User:motezazer|motezazer]] (independently).
+|-
+| TSEC signature validation design flaw leads to fake-signing
+|
+As mentioned above, when jumping to signed microcode the caller is expected to load hardware crypto register $c6 = <signature>, $c7 = <seed (zero for all officially-signed microcode)>.
+However, TSEC ROM performs no validation on the input seed used to generate the signing key.
+This leads to the following attack:
+* Attacker gains rop under any secure microcode payload with signature = S.
+* Attacker uses the "csigenc" instruction to obtain K = AES-ENCRYPT(hardware csecret 0x1, S).
+* Attacker jumps to their own microcode with $c6 = <signature calculated on pc using K>, $c7 = S
+* TSEC ROM calculates key = AES-ENCRYPT(hardware csecret 0x1, S) = K, and the signature check passes.
+* Attackers microcode is executed in secure mode as though it were signed by NVidia.
+Thus an attacker who has exploited *any* secure payload may use this to obtain a "fake signature key", which can be used to sign and execute arbitrary microcode in secure mode.
+Note: this does not break the TSEC cryptosystem, as the csigenc mechanism relies on the signature of the executing microcode, and fakesigning produces different signatures from NVidia that cannot be controlled.
+| None
+| HAC-001 (Tegra210)
+| Late 2018/Early 2019
+| August 2020
+| [[User:qlutoo|qlutoo]]/[[User:Hexkyz|hexkyz]]/[[User:Shuffle2|shuffle2]], [[User:SciresM|SciresM]]/[[User:motezazer|motezazer]] (independently).
 |}