PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2024-12-21 20:31:33 -05:00
Code

Blah

Browse Source 
Signed-off-by: Tommy <contact@tommytran.io>
This commit is contained in:
Tommy 2024-06-13 05:27:54 -07:00
parent 114bcf2ca7
commit 9a039ef949
Signed by: Tomster
GPG Key ID: 555C902A34EC968F
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/posts/hardware/Misinformation on x86 Hardware/index.md
View File

@ -73,4 +73,4 @@ The Trusted Platform Module (TPM) is very often misunderstood, and there have be
- It is a passive chip. It does not have the capability to measure what is going on on a system - it only receive measurements given to it by the firmware, Trusted Execution Technology, bootloader, and so on. It cannot serve as a root of trust, and it cannot verify the integrity of the firmware, firmware settings, operating system status, etc on its own.
- It does not weaken disk encryption when used properly. The TPM provides 2 important properties: it enforces rate limiting, and it pins secrets against certain PCRs. Rate limiting is useful if the user does not have a strong encryption password, but is not strictly necessary when a diceware encryption passphrase is used. Pinning secrets against PCRs on the other hand are critical, as SRTM and DRTM technologies rely on it to be useful. The general idea is that
- It does not weaken disk encryption when used properly. The TPM provides 2 important properties: it enforces rate limiting, and it pins secrets against certain PCRs. Rate limiting is useful if the user does not have a strong encryption password, but is not strictly necessary when a diceware passphrase is used. Pinning secrets against PCRs on the other hand are critical, as SRTM and DRTM technologies rely on it to be useful. The general idea is that