> I patch both your boot loader and your kernel with a rootkit. This should be laughably easy for the level of adversary we're talking about.
Well, you won't be getting the kernel, its on the drives. It would have to be in a separate partition so you can start it before mounting the sensitive filesystems, and you may have a key that the bootloader uses on it, but in either case if you are not present and a sever goes offline you basically have to do the following:
Verify the ROMs integrity in that first stage - before you put in the key for your actually sensitive data. That means you need open firmware or some mechanism to hash the ROM that is installed, you need to have a means to read it in its entirety, and then you need to hash it.
I say open firmware because you need to be able to guarantee the FBI couldn't embed a backdoor firmware. If you can get open spec / openfirmware mainboards and verify their authenticity only then can you be safe.
Then you verify the kernel, which is much easier because you can compile it yourself, maybe even pad it with some random and scramble the ELF tables in some custom orientation.
And then you need to worry about how you input the key - if its by USB, you can backdoor the USB and network controllers and keylog in hardware depending on the vendor and model of the mainboard. Over the network, just the NIC is in question, because any secret sharing over ethernet better be over a secure connection.
But that should be it. It is a fine line at best, and a bottomless pit at worse, but there are ways to try to be hardware secure.
> Verify the ROMs integrity in that first stage (...) need open firmware or some mechanism to hash the ROM that is installed, you need to have a means to read it in its entirety"
Does such a mechanism exist? If you can do this[1] from BIOS, why is it safe to assume that the same can't be done for the dump-bios-image routine? AFAIK the BIOS handles this in real-mode [2] (overrides the OS), and "returns" the image by copying it somewhere in low memory. So, you're trusting the BIOS that it's copied the right data out for you. (goodguybios)
> I say open firmware because you need to be able to guarantee the FBI couldn't embed a backdoor firmware.
This reminds me of this NSA RAID controller rootkit for Dell Poweredge Servers [3]. Nuts. Every closed firmware on your servers is a potential hiding place to someone with (soldering-iron-to-the-motherboard) physical access.
In our Dread Pirate use case, you don't even have to think that far as you can't ensure your own BIOS. Who are you going to buy TPM servers [4] from, when you're defending against the FBI? Intel? HP?
The Rootkit wikipedia page is alarming, to say the least. [5]
Well, you won't be getting the kernel, its on the drives. It would have to be in a separate partition so you can start it before mounting the sensitive filesystems, and you may have a key that the bootloader uses on it, but in either case if you are not present and a sever goes offline you basically have to do the following:
Verify the ROMs integrity in that first stage - before you put in the key for your actually sensitive data. That means you need open firmware or some mechanism to hash the ROM that is installed, you need to have a means to read it in its entirety, and then you need to hash it.
I say open firmware because you need to be able to guarantee the FBI couldn't embed a backdoor firmware. If you can get open spec / openfirmware mainboards and verify their authenticity only then can you be safe.
Then you verify the kernel, which is much easier because you can compile it yourself, maybe even pad it with some random and scramble the ELF tables in some custom orientation.
And then you need to worry about how you input the key - if its by USB, you can backdoor the USB and network controllers and keylog in hardware depending on the vendor and model of the mainboard. Over the network, just the NIC is in question, because any secret sharing over ethernet better be over a secure connection.
But that should be it. It is a fine line at best, and a bottomless pit at worse, but there are ways to try to be hardware secure.