The RP2040 solution was pretty clever. And that’s just for line sniffing. He can still add clock or crowbar glitching into the toolkit to work around more advanced defenses. This is something that car ECU hackers figured out a long time ago. There’s no software solution to work around that bit of nightmare. FWIW, ChipWhisperer can do all of these, including the synchronous sampling method used to fake a clock signal right out of the box.

As the piece mentions, setting a PIN can help, but all it does is annoy the user (who will likely choose something obvious and easy to remember) and transfer the problem to a simple dictionary attack.

The minute you put the security component in a separate module, you’ve opened yourself up to line-sniffing and MITM. And as soon as someone has physical access to a device, all bets are off.

An interesting take on the previous attack om TPMs for sure. This once again establishes the importance of unlocking the TPM with a PIN for secure disk encryption. Even a relatively basic password will mitigate this attack and make recovering the disk encryption key many times more difficult.

The software attack underscores the important of things like secure boot when it comes to these security mechanisms. If you’re only running one operating system (whether that’s Linux or Windows), enforcing that only the signatures you permit are bootable will quickly shut down such software attacks. On Linux, you can use automated tooling to sign the entire boot process with your own keys; in Windows, you’ll have no such luck, though I imagine it may be theoretically possible to sign your own chainloader which will only boot your specific Windows install.

I’m surprised how well modern fTPMs have stood up against this attack. I suppose the makes it possible to still use unauthenticated TPM based disk encryption by leveraging the processor’s internal TPM, as long as your processor and motherboard still get microcode updates.