cwerling

Please note, though, that's imperative to then go for a BitLocker TPM+PIN configuration at least. A standalone (discrete) TPM with TPM-only protectors can be attacked by bus sniffing, a hardware attack much simpler than ours. [1]

The beauty of a discrete TPM is its anti-hammering protection, making a numerical PIN a very effective security measure (akin to a SIM/SmartCard).

[1] https://www.sciencedirect.com/science/article/pii/S089812211...

Your idea roughly goes into the direction of what the industry has started implementing: Tunable Replica Circuits:

https://www.intel.com/content/www/us/en/newsroom/news/the-st...

Thanks for the pointer, we haven't checked out OPAL yet. It seems to be the most popular standard when it comes to "Self Encrypting Drives" (SED).

Looking into it shortly, I've found a paper from 2019 from Meijer et al. ([1]) finding several flaws with OPAL-compliant drives. They further find that BitLocker entirely depends on SSD-based encryption if the hardware advertises it. This finding's nature is very similar to ours in that BitLocker's Disk Encryption is insecure/unreliable in particular hardware configurations.

[1] https://ieeexplore.ieee.org/document/8835339

One of the authors here. This attack is relevant if your machine is physically exposed to attacks, e.g., in an office environment or while traveling, and if you don't use any additional pre-boot passphrase to protect the disk (but rely solely on AMD's fTPM).

When TPMs became popular, dedicated TPMs were mainly used, being a separate chip on the mainboard connected via the SPI or LPC bus. These were prone to (relatively primitive) bus sniffing attacks, where you would hook up a Logic Analyzer to the bus, watch a regular boot procedure grab the disk key, and then use software like Dislocker to extract all data from a USB Live Linux or alike.

Nowadays, most modern CPUs (both on Intel and AMD) ship firmware TPMs that are "included" with CPU die, making them safe against the bus sniffing attacks. However, they can still be prone to more sophisticated attacks like ours.

PSPTool author here. Since all PSP firmware must be signed by AMD, something like a psp_cleaner would be possible given that a bug in the firmware allows to inject arbitrary code. This was shown by CTS-Labs earlier. [1]

[1] https://msrnd-cdn-stor.azureedge.net/bluehat/bluehatil/2019/...

The author here. Although some previous work on this controversial subsystem that is comparable to Intel ME was done [1, 2], this tool aims to lower the entry barrier for looking into the code running on the PSP (and other AMD subsystems, too). The PSP is running completely proprietary, undocumented code provided by AMD. It has full access to the x86 memory and is therefore a valuable target for attacks.

[1] https://seclists.org/fulldisclosure/2018/Jan/12

[2] https://msrnd-cdn-stor.azureedge.net/bluehat/bluehatil/2019/...