The vulnerability should be obvious: at some point in the boot process, the VMK transits unencrypted between the TPM and the CPU. This means that it can be captured and used to decrypt the disk.
The vulnerability should be obvious: at some point in the boot process, the VMK transits unencrypted between the TPM and the CPU. This means that it can be captured and used to decrypt the disk.
And that’s the problem with trusted computing, it inherently depends on hardware integrity. Even on-chip tpms and things like the AMD PSP and Intel ME rely on the CPU, RAM and bus. Even if you AES encrypt the RAM, it still depends on the CPU, microcode and TPM not being compromised. It is possible, if rather hard, to take a chip out of its epoxy, ceramic or metal shell ,(decapping)and then use very tiny to steal or even modify the program and data.
@nothacking @tedu In the end it is all chips and circuits. But these techniques are still above the general ability so the system wont change just because of the bypass options.
From my perspective, the circus around ‘trusted computing’ seems to be about businesses preventing people from easily putting their own software into devices so that when new devices are manufactured people need to upgrade.
It saddens me that cryptography is being used to support this wasteful business cycle.
There are certainly useful uses for trusted computing, like discouraging tampering with distributed computing projects, but they are used much more often to implement DRM and restrict hardware. They don’t it to be impossible, just hard enough that the average user gives up.
Currently it is possible for an average user to to install Linux, but if that process requires hardware tampering (no normal person will decap chips), almost no one will do it.