For offline analysis and to be used as evidence, presumably.
> Did SR2 not use full disc encryption using LUKS? (...) longest private key ever
So the process for you would be slightly different: There would be a "power outage" in your rack, your encrypted disk would be imaged and (unencrypted) bootloader would be bugged.
Then they'd wait for you to see that your server had some issues, upon which time you'd have two choices:
-enter your private key to resume the service.
-abandon the server.
The correct choice would be (2), but you don't have enough information to make that call.
I'd compare the bootloader to a known good image as an early boot step and if it isn't what you expect immediately start destroying data. :-)
Here's how I would do it:
- I assume that your hard drives are in RAID. I gamble that they're in RAID 1 - most typical - and strip one out while the server is still running. Some kernel messages are logged, whatever.
- I start imaging the disk. If it isn't a mirror of the other after all, I strip the remaining drive(s) out and start imaging them too.
- While the disk(s) is/are transferring, 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.
- When the disk(s) are done, I power cycle your server. I may cold-boot your RAM and get the passphrases there if i'm lucky. The downtime was either seconds (if it kept going with one RAID 1 disk) or <however long the imaging takes>.
- When you realise your service is down you may contact customer support. In that case they will respond (with their usual timing) about something-something-blown-fuse-UPS in your rack.
- When you log onto your server, you will most likely be faced with the passphrase input and most likely will go for it, but even if you don't...
> I'd compare the bootloader to a known good image as an early boot step
If you do so after you've given away the passphrase, you've lost already. Destroying the data won't help, as they have the encrypted copy of it and you just gave them the key.
I don't think you could detect a good boot/OS rootkit remotely at all. One would cover for the other. You can't unplug the disk and examine it. You can't plug a read-only drive in and boot some forensic tool. All you have is your lying bootloader and your lying OS. Your encrypted partition doesn't protect the integrity of the binaries there either, as after it's been decrypted, the rootkit would happily intercept any values that would give it away.
I'm not sure how you could ensure hardware security without ensuring physical security. Usually, physical access == pwned. Maybe TPM changes/will change that, but I somehow doubt it. Some other routes not covered here (probably easier, heh): Getting host to decrypt your TLS/KVM session where you typed the passphrase in the first place, malware in firmware on misc devices, etc.
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.
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]
--
[1] A Real SMM Rootkit: Reversing and Hooking BIOS SMI Handlers http://phrack.org/issues/66/11.html#article
[2] http://en.wikipedia.org/wiki/Real_mode
[3] http://resources.infosecinstitute.com/nsa-bios-backdoor-god-...
[4] http://en.wikipedia.org/wiki/Trusted_Platform_Module
[5] http://en.wikipedia.org/wiki/Rootkit#Bootkits ("Bootkits??")
[6] https://www.blackhat.com/presentations/bh-usa-07/Heasman/Pre...