Protecting systems with the TPM [LWN.net]

Protecting systems with the TPM

Posted Feb 9, 2016 22:54 UTC (Tue) by PaXTeam (guest, #24616)
Parent article: Protecting systems with the TPM

> A hostile drive could provide correct code for a critical binary once to pass the IMA test, then provide corrupt code thereafter.

how's that possible if the block device itself is encrypted?

to post comments

Protecting systems with the TPM

Posted Feb 10, 2016 0:35 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (11 responses)

Competent encryption should protect against that, yes

Protecting systems with the TPM

Posted Feb 10, 2016 1:02 UTC (Wed) by zx2c4 (subscriber, #82519) [Link] (1 responses)

Unfortunately, XTS is not authenticated.

Protecting systems with the TPM

Posted Feb 10, 2016 2:24 UTC (Wed) by luto (subscriber, #39314) [Link]

On the other hand, XTS is wide block, which makes exploiting this weakness somewhat tricky. You'd either need to find an interesting valid block and replay it (which is doable under some circumstances) or replace a 512-byte block with random garbage and hope that does something interesting.

On the pessimistic side, the rowhammer exploit is a great example of a way that random poorly-controlled corruption can sometimes lead to privilege escalation.

Protecting systems with the TPM

Posted Feb 11, 2016 6:34 UTC (Thu) by rahvin (guest, #16953) [Link] (8 responses)

I'm not sure how I follow that encryption would mitigate the attack. Couldn't the drive monitor the system and ensure it's booted before it switches to the hostile firmware? As long as the drive encryption is software based I don't see how encryption could protect you. In fact couldn't the hostile firmware honor all normal functioning and only react on it's hostile intentions once certain things happen (say loading a particular program where it monitors it passing through the cache). Hard drives, video cards and a lot of components these days have hardware systems and firmware that are simply general purpose CPU's and systems and if you have the technical skill to write a replacement firmware you can essentially implement a completely invisible exploit.

Firmware is one of the scary things that came out of the Snowden revelations about the NSA, the information indicated that the NSA is not only capable of replacing firmware on various components but extremely adept at it and that they used such tactics frequently. It's the ideal spy tool, hardware firmware can be full processors with non-volatile memory and even have DMA access and there is essentially not a single way to verify firmware images which isn't dynamically loaded at boot. In fact it would appear your only security against firmware exploits is to have un-servicable firmware and a trusted manufacturer that validates all flashed firmwares before they leave the factory or to have only loadable firmwares where you have a way to validate the image. But even with unserviceable firmware you are still at risk the NSA will divert the package and physically replace the firmware chips with a compromised firmware.

I'd love to see you keep up your research in these areas and help FOSS keep going in this direction to close more and more exploit avenues. TPM has been around for years and I've read a lot about them but your talk is the first real analysis I've ever seen of just how they operate and what some of their strength's and weaknesses are.

Protecting systems with the TPM

Posted Feb 11, 2016 8:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Disk encryption is usually done by the CPU.

Protecting systems with the TPM

Posted Feb 11, 2016 8:24 UTC (Thu) by dlang (guest, #313) [Link] (6 responses)

> Disk encryption is usually done by the CPU.

Except if you need high performance, at which point you get Self Encrypting Disks, SSDs that do the encryption on the drive itself.

Protecting systems with the TPM

Posted Feb 11, 2016 16:11 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (3 responses)

> Except if you need high performance, at which point you get Self Encrypting Disks...

If you need such high performance that you can't do the encryption on the CPU, you might as well do without encryption entirely. You can't prove that the black box encryption built into the disk is actually any more *effective* at protecting your data than no encryption. Even assuming that it doesn't include deliberate backdoors, the odds are good that there are bugs in the implementation. As it's closed-source and proprietary, you have no way to audit the security of the firmware.

Protecting systems with the TPM

Posted Feb 11, 2016 23:38 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

not saying that you are wrong, just saying that companies that make extremely expensive "Enterprise" class storage arrays 'solve' the data at rest encryption requirement by plugging such devices into their existing arrays, adding a little initialization (typically with pathetically poor key management practices), and add another 0 to the cost of their array.

This is what is presented to upper management as being the state of the art in data security.

Protecting systems with the TPM

Posted Feb 11, 2016 23:59 UTC (Thu) by jhhaller (guest, #56103) [Link]

The real advantage of the SEED devices is that if one breaks, you can ship it back for repair without worrying about someone being able to read you put on the drive. The inept key management is unlikely to leak the key back to the drive manufacturer, but one never knows if the SEED keeps a copy of the decryption key. Certainly, three-letter-agencies which can replace disk firmware, are capable of such an attack.

Protecting systems with the TPM

Posted Feb 12, 2016 13:09 UTC (Fri) by james (guest, #1325) [Link]

It depends what your threat model is, surely?

If you're trying to hide personal data from the NSA, GCHQ, or whoever, then you're absolutely right. If you're trying to hide top-secret corporate data, then you may have to worry about nation-state-sponsored corporate espionage.

But if you're storing credit card details or personally-identifying information, and the threat is random thieves, then the chances that they can blow the encryption on the disk is pretty minimal. Anyone who could get the data out of the disk would have easier ways to do it, but you can honestly tell customers that the data on the stolen disk was fully encrypted.

Protecting systems with the TPM

Posted Feb 12, 2016 8:49 UTC (Fri) by jezuch (subscriber, #52988) [Link]

> Except if you need high performance, at which point you get Self Encrypting Disks, SSDs that do the encryption on the drive itself.

Well, the drive has to run the encryption on *something* too. I guess the controller has some specialized hardware for that but still...

That said, I don't think I trust the on-drive encryption. It may be better in that the /boot will be encrypted as well, but since nobody can lift the hood and look inside the firmware, I think I'll stay with LUKS :)

Secure storage is pure marketing

Posted Feb 12, 2016 12:25 UTC (Fri) by ksandstr (guest, #60862) [Link]

CPUs have implemented AES in hardware for half a dozen years now. It's fast enough to run at near copy speed. What circuitry would a SSD have that could possibly perform better than a multiple-gigahertz top-of-the-line processor?

This is the same issue as with TCP offload engines on Ethernet cards: the CPU usually does better, and for the cost difference between dumb and smart hardware one can simply buy more CPU. Generally the CPU has better utilization than smart peripherals, which yields higher efficiency per dollar. (hence multitasking on commodity hardware, and the death of channel architectures.)

Storage has the additional issue of trust: in the case of self-encrypting storage devices, it's unverifiable[0] that the manufacturer's firmware doesn't simply use the key-setting interface as an unlocking password and store all data verbatim, or encrypt the data with a session key different from what the host provides. Firmware can also fuck the user at the NSA's request where a CPU's verifiable AES implementation would need more than National Security Letters pointed at a small number of CTOs' foreheads.

[0] besides desoldering the flash chips & having a highly specialized poke at them