PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2024-12-22 04:41:33 -05:00
Code

Clean up bit

Browse Source 
Signed-off-by: Tommy <contact@tommytran.io>
This commit is contained in:
Tommy 2024-06-13 05:27:10 -07:00
parent 12ddd5e97b
commit 47678a8672
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 pinning a secret against certain PCRs. Rate limiting is useful if the user does not have a sufficiently strong encryption password, however it 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 pinning a secret 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