Secure Buffer for an HDD - Is it possible?

[HAL-42b]

It recently came out that NSA is planting spyware directly into the firmware of hard disks. This makes it possible to survive formats and remain on the system indefinitely. Since there are so many models of hard disks it would be impossible to identify and remove the spyware from all of them.

So my question is, whether it would be possible to design an intermediary board that would scramble the information, thusly prevent the spyware from communicating with the outside world?

I imagine it would work somewhat like this: A black box is connected between the PC and the HDD. The PC thinks that the black box is a HDD. The HDD thinks the black box is a PC.

The black box takes any data sent by the PC and encrypts it with a key before sending it to the actual HDD. When asked for data the black box reads the encrypted data from the HDD, decrypts it and sends it to the PC.

- The PC only ever sees cleartext. It never sees the key or the cyphertext.

- The HDD only ever sees cyphertext. It never sees any cleartext or the key.

- The key can only be loaded manually from a separate port (JTAG, PS/2 or even DIP switches). Once loaded it is not accessible to the outside. Loading a new key erases the previous key.

What do you guys think? Possible?

[Mechanical Menace]

Possible? Yeah. Better than just using LUKS if you're so paranoid? Nope. Not a single advantage and many an added problem.

And it's not that they hide it on HDDs coming from manufacturers, it's that they made rootkits for the firmware themselves.

EDIT:

Which they got on there by infecting Windows machines, which would bypass your encryption because they've already got r00t on the encrypted OS install.

EDIT the second:

And this would be less secure than a "type in at the keyboard" password style key. If they seize your PC, or just the HDD and "magic controller" they'd have the key and seamless access to the unencrypted data. They can't force you to enter a password

[tom66]

I'm sure it's possible, but it's a lot of data. You'd need a dedicated ASIC or FPGA to do the task.

Why not use full disk encryption with a TPM device?

[Phaedrus]

And it's not that they hide it on HDDs coming from manufacturers, it's that they made rootkits for the firmware themselves.

The reports I saw said that they were infecting drives from the factory, presumably ones going to certain customers or distributors.

[Mechanical Menace]

The reports I saw said that they were infecting drives from the factory, presumably ones going to certain customers or distributors.

I heard retailers at first, but The Register disagrees and I'm prone to trust them on this sort of thing.

The agency spread its spy tools through compromised watering hole jihadist sites and by intercepting and infecting removable media including CDs.

http://www.theregister.co.uk/2015/02/17/kaspersky_labs_equation_group/

The firmware mod seems to be a rather sophisticated version of an old MBR TSR attack to me though lol.

[cyr]

Encryption in the OS is probably useless against a rootkit that runs before the OS even starts (at least if you boot from a compromised drive, or the BIOS attempts to boot from it)

An FPGA with high-speed transceivers that can be made to talk SATA could do the job I guess.

But if you are on an NSA target list you should probably just give up using electronic devices for ever... 

[Mechanical Menace]

Encryption in the OS is probably useless against a rootkit that runs before the OS even starts (at least if you boot from a compromised drive, or the BIOS attempts to boot from it)

If the data on the drive is encrypted at the block level with a key the firmware isn't aware of it can't infect the bootloader which can't infect the kernel. It also only affects the Windows 1st stage bootloader so if you use another it wouldn't work either.

But if that became the standard workaround they just target GRUB and probably any kernel or bootloader it can chainload. And that wouldn't only affect Lunix users either.

[HAL-42b]

Why not use full disk encryption with a TPM device?

Because that wouldn't prevent the PC from talking to the HDD frimware.


I do not know how the spyware actually works but I presume it is something like this:

 A malware is running on the PC as an unprivileged process. Normally the OS prevents the malware process from accessing protected areas on the hard disk, places like the MBR for example. The malware can only write to limited areas on the HDD. If however the malware tries to write a special hidden bit sequence this triggers the spyware on the HDD. That spyware converts that special address on the HDD into a sort of a portal for accessing any part of the HDD.

All of this without the need for privilege escalation. (pure conjecture of course)

[Mechanical Menace]

I do not know how the spyware actually works but I presume it is something like this:

Oh no, not at all. First they get malware onto your computer that used 3 possible exploits, 2 of them 0-day, for privilege escalation. Having admin rights allowed it to not only access the FS through the driver but the HDD as a device itself*. That let it infect the firmware which on boot patched the bootloaders, which patched the kernel when loading it, which gave them "undetectable" in most cases access. It was a way to keep the infection persistent even if you got rid of the more obvious rootkits. Patching the kernel directly lets them get around most counter measures, even the best virus scanner would be blocked form picking it up as the kernel wouldn't let it. And if you scanned the HDD using a livecd tool all you'd see on the HDD is the normal, unpatched code.


*As well as delivering other "normal" rootkit style payloads

[free_electron]

wouldn't work.

it's not just data flying through the pipe. there are command codes as well.
there may be an attack vector by sending the 'payload' embedded in command codes.

a small program like a javascript could send command codes to the drive. the drive responds to the command codes by giving a return block. that return block is not userdata but it doesn't matter. the java program receives it , saves it as a file. boom you're infected.
 

[Mechanical Menace]

wouldn't work.

it's not just data flying through the pipe. there are command codes as well.
there may be an attack vector by sending the 'payload' embedded in command codes.

You'd have to only encrypt block data and let the command codes through unfettled. It could work as a transparent encryption and would stop the firmware patching code, but yeah you couldn't stop it getting the modded firmware on there at all*. And it wouldn't stop the fact that you've already had a serious security breach for it to get so far.


*Well you could, at the risk of blocking necessary firmware upgrades and screwing with some other none standard commands for that drive.

[dexters_lab]

many years ago i got one of these free with a motherboard i bought:

http://abit.ws/page/en/multimedia/multimedia_detail.php@pMODEL_NAME=SecureIDE&fMTYPE=Encryption+Device

i am sure there are loads of much newer options

[HAL-42b]

many years ago i got one of these free with a motherboard i bought:

http://abit.ws/page/en/multimedia/multimedia_detail.php@pMODEL_NAME=SecureIDE&fMTYPE=Encryption+Device

i am sure there are loads of much newer options

This is exactly what I had in mind. Of course my aim is to isolate the firmware and prevent it from accessing the outside world in a meaningful manner. The encryption of the data is only a side effect, there are better ways to do that.

[Mechanical Menace]

This is exactly what I had in mind. Of course my aim is to isolate the firmware and prevent it from accessing the outside world in a meaningful manner.

You can't do that though, no communication between the PC and the HDDs firmware means no usable HDD. Your best defence is not to run programmes you don't trust, and only trust the trustworthy ones.

The firmware was just another vector, a way to get greater levels of persistence. It wasn't that the firmware of an HDD can magically attack your OS.

[HAL-42b]

You can't do that though, no communication between the PC and the HDDs firmware means no usable HDD.

Not at all. As long as the PC thinks that my black box is an HDD and as long as the HDD thinks that the black box is a PC it should work fine.

[HAL-42b]

many years ago i got one of these free with a motherboard i bought:

http://abit.ws/page/en/multimedia/multimedia_detail.php@pMODEL_NAME=SecureIDE&fMTYPE=Encryption+Device

i am sure there are loads of much newer options

Backdoored straight from the factory!

[cyr]

If the data on the drive is encrypted at the block level with a key the firmware isn't aware of it can't infect the bootloader which can't infect the kernel.

Sure, but you also can't boot from the disk.

Of course you could boot the first stage boot loader from some other medium, if you were sure *that* was free from malware.

And all pretty much moot unless you are sure the BIOS and any other firmware that runs at boot time has not been tampered with (network boot ROMs, video BIOS, RAID controller firmware......)

[Lukas]

I wasn't really surprised that the NSA does that, since you don't need the NSA to hack hard drives: http://spritesmods.com/?art=hddhack