Given the revelations since The Equation Group was discovered. As well as that it is possible to not guarantee removal of a rootkit even with a nuke from high orbit.
What properties of a harddrive hardware can be added to prevent these rootkits from taking control/replacing of the firmware?
One solution is to require all firmware to be signed and have the device check the signature before writing that firmware image to its memory; my current laptop has an option to enable this in its BIOS (the option is permanent - if I enable it now I can't disable it anymore, that's why I didn't enable it).
There are many drawbacks however :
induces a false sense of security, as we don't know how the manufacturer protects the private key used for signing and I don't expect them to admit their failure and send a nice "Sorry the firmware key leaked" email to each customer; also even if the key didn't leak, the NSA and other evil agencies may still have stolen it and no one would know.
making custom firmware is impossible - while I'm fine with the fact that they're for-profit companies and their firmware is closed source, I am definitely not fine that they prevent me from installing whatever I want on my own devices I paid money for, for some so-called "security" even though the NSA already stole the key from them (I remember installing a custom BIOS on my old Thinkpad because the original one had a wireless card PCI ID whitelist preventing me from changing their outdated 802.11g for a 11n model, something impossible with firmware signature checks in place).
Another, better solution is to require physical intervention (a press of a hardware button on the device itself) to allow firmware to be installed, which doesn't have the above drawbacks; the firmware authenticity check is to be done by the user and he is free to install whatever he wants. Whether the user wants to install firmware, he presses the button and the device allows one firmware install before locking itself again (or timing out after a minute if nothing was installed).
The only drawback with that option is each device would have its own hardware button, on a typical desktop computer there's the BIOS/EFI (which will often update everything else embedded on the board - NIC, "fake" RAID controller, etc), possibly the third-party video card's option ROM (also called video BIOS), third-party RAID controller or NIC, storage drives, etc.
While everything on the board could be wired to a single button, all third party hardware would have its own button, sometimes hard to press due to the hardware being inside the computer's case. This isn't too problematic as users incapable of opening a computer case usually don't update firmware anyway due to the "risk" (it's minimal but creating bootable DOS disks feels scary) and complexity.
A theoretical solution would be to require all commonly used ports (SATA, PCIe, etc) to include a dedicated "firmware flash" line that would be hard-wired to the board's main firmware flash button.
The only way it could be completely prevented is to not have any type of writable non-volatile memory on the device. The problem with this is it would prevent the the firmware from ever being changed which could complicate things.
The issue these days, from my understanding, is there needs to be low level read/write commands to access spaces in memory which holds the firmware. Even when they are not made public, these commands can be found via brute-force if necessary (if not sniffing an interface while upgrading). So I think the question would be better posed "Is it feasible to completely prevent read/write to locations where firmware is located?" Which brings me right back to my first sentence.
One option might be to implement signed certificates and to hold a certificate from the manufacturer in ROM. The firmware could be signed and checked via the certificate upon powerup. This would add a LOT of overhead that doesn't exist today and isn't without its own issues. If a certificate is compromised how do you revoke it in a situation like this. What would happen if it were to expire? Could it expire? Also, you would need to add capabilities (processing and memory) to use any crypto functions on-board the device and not accessible via the normal I/O. All this would likely add a significant cost increase (in both design and manufacturing).
As a final comment, I would say it is likely possible to make it much more difficult, but it would likely not be worth the cost increase to the end-user. Basing my opinion on it would be very expensive to make countermeasures and that it takes a very specifically crafted piece of malware (for model and likely firmware version) to exploit, I would say its probably infeasible for nearly any application. This might exclude anyone with extremely deep-pockets (or pockets that extend down to tax payers).
I like André's answer of having a switch or button to program the firmware. Some devices already have this, many motherboards for example have a jumper to protect the BIOS against writing.
Forcing the device to not function properly in firmware program mode would allow a user to see if something was iffy. Like an audio device that output no audio, or a video card that only allowed basic video mode. Combining a write protect jumper with a program button may be excessive, but would be more secure.
Another option is to have a write code imprinted on the outside of a circuit board or IC, and have the same code permanently etched into the IC guts. A firmware flash would only succeed if you enter this code during programming. The code cannot be read by the device itself, only verified if it is correct or not. This would require access to the circuit board to get the code, and is not an obstacle to a targeted attack. A device manufacturer can also collude and provide a list of device serial numbers and their codes. However when combined with signed firmware and a write-lock jumper, it will make malicious firmware programming much more difficult.
A longer term effort to create a standard for chain of custody for hardware devices may also help, which would include only allowing firmware to be sent to a PCI(e) or USB device if the controller it was plugged into allowed it, and have the chain go all the way up to the main system firmware. The BIOS password would then protect every device down against firmware changes, unless there was a vulnerability that allowed a bypass.
I think just as important there should be a way to verify the firmware is not compromised, which means some way for a device to report a cryptographic checksum of its firmware to its controlling device in a way that cannot be manipulated by malicious firmware. Standardization of this would be a great way to instill confidence when hardware is used in sensitive situations.
