Right, there are at least two workable solutions-

Hard drives with user alterable firmware. I surprised that none of the major drive manufacturers seems to have thought about offering a version of their controllers, for substantially more money, that offers this.

A retrofit device that screws into the side of the hard drive and is set to inject a corrosive that almost instantly destroys the drive surfaces. The device can be triggered by any number of intrusion detectors or a voice-activated system keyed to the operators voice print.

Maybe there is also a third solution: a FPGA sitting on the IDE bus between the disk and the controller (optionally as a PCI controller card), realtime-encrypting the data with something suitably strong, eg. AES256, with the key stored in a way that's easy to destroy it - most likely a self-contained tamper-resistant device that forgets the key under a range of conditions: if a wrong access code gets entered n times, if a door sensor detects forced entry, if a kill-switch is pressed, if a machine is moved without the correct movement-authorizing code is entered before, anything that fits the threat model. The key itself can be destroyed pyrotechically (burn, chip, burn), or just let a RAM forget it (where the RAM may be a battery-backed microcontroller system which shuffles the bits through a SRAM periodically in order to avoid problems with retention after power-off; the algorithm then can be chosen in the way that makes it more difficult to eavesdrop on the electromagnetical emissions and power consumption variations - a lot of this problematics is already solved by the secure-smartcards industry). Optionally, backup of the code is possible in many forms, if the desired safety/reliability requires recovery from accidental key erase. The key, being just 256 bits, may be stored in myriads ways, including a m-of-n scheme where the parts are stored in various places or under control of different people. Serial EEPROM chips could be suitable as containers, as they are easy to work with, small, easy to transport and hide; this requires a degree of security-by-obscurity, but the possibility to require m chips (or other containers) (which could be under control of other people, including offshore entities) could alleviate this to certain degree.

On Sat, 24 Apr 2004, Bill Stewart wrote:

That's really overkill. Computers these days have enough horsepower to run file system encryption in the CPU.

That's true, but it's possible to get access to the key in memory. Once the machine is compromised, the keys are leaked. It's true that when the machine is compromised the plaintext data may be leaked, but it's more difficult to inspect and transfer couple gigs of data than just the key and then come and haul away the machine. Or to compromise the encryption software itself. It's much more difficult to do that with a hardware unit (and much more difficult if the case was eg. spot-welded - you still can get inside using power tools, but not without visibly damaging the case). Another advantage of a pure-hardware solution is independence on software, thus no risk of present nor future incompatiBILLities.

If you want to get fancy about rubber-hose prevention and avoid the except-for-terrorism clause in the 5th amendment, you could do something with secret-sharing with your unindicted co-conspirators (oh, wait, they don't bother with indictments these days, do they?) so that all of you need to cooperate in a challenge-response thing to restart some of the services.

I'd suggest a m-of-n scheme because of reliability issues. It won't be good to lose all data because one of the co-conspirators died in a car crash.

Or you could hide that little 802.11 widget on the shelf that stores one of the keyfiles you need to access the secure drive. Once UWB's widely available, it'll be better for that (lower power - harder to detect.)

A 802.11 standalone data storage unit (I think they're on sale already) hidden under the floor, over the ceiling, or between the drywalls could do the job nicely.

Just make sure that your system _is_ restartable after power failures, because those are a much more likely event than cop invasions.

Reliability vs security is a big dilemma. Maybe a good approach could be forgetting the key if the machine is moved without telling the processor guarding the key that it should stop watching a movement sensor for a given time interval, or after entering a wrong (or kill-) PIN? A power blackout then won't affect the operation, but switching the equipment off and hauling it away would destroy the keys. Same as an attempt to bruteforce the access code, or opening the machine case by force.