There is currently a lot of discussion going on across the Internet about the "Equation Group" family of malicious hard disk drive firmware.
One thing that has me wondering is the claim that malicious HDD firmware would be able to access details on any running full-disk encryption scheme. For example, we have How the NSA's Firmware Hacking Works and Why It's So Unsettling, by Wired which states, in part (referring here to unused portions of the firmware EEPROM):
“Taking into account the fact that their GrayFish implant is active from the very boot of the system, they have the ability to capture the encryption password and save it into this hidden area,” [Costin Raiu, director of Kaspersky’s Global Research and Analysis Team] says.
Maybe I'm missing something obvious, but I don't understand how this follows. There are two cases I can see here:
- Microsoft Windows, with Bitlocker enabled. The firmware loader is apparently a Windows executable, and Windows is a common OS, so you could have some leverage with "out of the box" code.
- Some other OS with FDE, say Linux with LUKS or FreeBSD with GEOM. These would, at the very least, be immediately unaffected by a Windows binary.
When using full-disk encryption, the storage device (whether HDD, SSD, floppy, or whatever) is tasked with safekeeping the encrypted bits. Certain headers are known to exist in different FDE schemes, do often contain key material, and can presumably be detected based on magic numbers or on-disk location, but the meaty parts are encrypted by the time they reach the storage device.
How can a storage device's firmware meaningfully subvert properly implemented full disk encryption, in which the storage device sees only encrypted data in READ and WRITE commands?
The only real possibility I can see is if the storage device firmware can somehow influence other parts of the system perhaps by exploiting DMA, but wouldn't the CPU's memory manager step in there? Or is DMA always done in supervisor mode (ring 0 in Intel terminology)? That would seem to open up a whole different can of worms.
Let's assume here a fairly typical FDE setup: BIOS or UEFI, handing off to a tiny unencrypted bootloader that prompts the user for a password and proceeds to initialize the cryptosystem state before going resident to intercept disk I/O and doing encryption/decryption as the data flows between the normal I/O layer of the OS and the storage device itself. All "one way or another", leaving technical implementation details aside unless they directly pertain to answering the main question.