On Tue, 15 Jul 2003, Sampo Syreeni wrote:
There are plenty of examples like printer buffers,
They shall be on encrypted partition, if possible by a session key (as they are temporary files which we won't need after next powerup), which gets lost after powerdown.
random pools,
Why not initialize them after each powerup with fresh data from a hardware generator?
already keyed smartcards,
...whose status gets lost with powerdown,
anything you're currently showing on-screen (I wouldn't be surprised if that could be read after sustained powerdown),
An issue (though I don't know how serious) with CRTs, where there could be detectable residual charge, but with a bit of luck that could get undetectable in just couple seconds in normal room temperatures.
any battery backed memory,
IMPORTANT issue. But as NVRAM is a kind of permanent storage, nothing unencrypted shall touch it anyway.
off-the-shelf peripherals which do not admit crypto,
If we consider them plaintext, it doesn't matter here if they contain crypto or not.
and so on. Probably we'd also want to make the machine as dead as possible, shutting down any remote power-on features,
Why? The adversary can power up the machine once he gets physical access, anyway. By then, though, he shouldn't get anything more than a machine with data with either missing session key (and hence unrecoverable) or encrypted data missing the key that has to be supplied by the user to complete the power-up.
network connections (otherwise retries might go on for a fair while),
...which is no harm, as the data should be encrypted and without the key, lost to the powerdown, they won't reveal anything than that there was some connection in progress. Which is something the adversary most likely knows anyway; before physical intrusions, passive surveillance usually takes place. Keyword: Carnivore.
open phone lines,
...hung up by power loss to the modems...
whathaveyou.
Everything must lose critical inner state with the powerdown. Everything that carries plaintext data has to be power-dependent.
That's why we might need software, and not just the power switch.
That's why we need the software designed to cope with the possibility of unpredictable power-down. There should be no dependability on proper function of software at the moment of the power-down itself, as we need to keep the system as reliable (and as simple) as possible. Remember that years in jail, and possibly even lives, are in stake. The software could be able to communicate with the hardware though, issuing "locks" to prevent power-down in the middle of a critical operation (eg, writing to disk) and delay it a little. The locks should be issued for maximum time of some few 100s milliseconds, expiring in hardware if not cancelled from the software. There should be a period of allowed shutdown every period (100s msec?) even in the worst possible combination of issued locks. This should prevent damage to data during an emergency shutdown event while not compromising the security due to software bug (eg, forgotten unlock). The delay time has to be determined to the worst possible combination of events, to not allow the best-trained best-equipped adversary to prevent the machine from shutting down in that time.
I can also imagine situations where we'd want to be able to perform manual shutdowns remotely.
That's the simple part. Just take the output of the computer (or an external device, eg. a cellphone, a radio receiver, anything suitable) and use it as one of the event inputs of the power-down system. You raise the event (tell the computer over SSH, send a SMS, broadcast a tone...), the computer shuts down.