Re: MRAM, persistence of memory
In all likelyhood the flashbang armored ninjas with automatics, night vision, "get the fuck on the floor and shut the fuck up bitch" entry will happen while you're asleep, so you won't have time to hit the big red button anyway.
Take a relay and connect it to a door switch. When they open the door without authorization[1], the power to the machines is switched off. Then the ninjas' with their typical noisy entry will switch off the system themselves, without you having to touch the Red Button. [1] can be an ID button, can be a wireless ID token (advantage: the reader and the whole identification action can be invisible), can be a keypad, can be an arbitrary complex biometric ID, or any combination of the above, for a low-tech approach can be a reed relay under the wallpaper and a magnet touched to the given spot on the wall The system can be easily coupled with a common-grade burglar alarm, further increasing the range of conditions the shutdown can be triggered with. (Optionally with several levels, depending on the tradeoff between the recoverability from a false alarm and the consequences of missing the alarm: power-down, erase of a long key (unlocked by a passphrase) from NVRAM, physical destruction of the disk array once forceful penetration of outer zones (triggering sequentially the previous lower events in reaction) is followed by physical breach of the server room door or walls (or the so often woefully neglected ceiling and floor).)
So, the best way to avoid that situation and not being able to reach the big red switch, is simply not to attract their attention in the first place by not following the footsteps of Jim Bell. :)
True. But once the adversary becomes totally information-aware, it will be rather difficult to not attract attention.
A more likely, and far more important, scenario to worry about is the black bag job whereby a hardware keystroke recorder can get installed without your knowledge...
Another reason for employing a security system.
There may be ways to prevent/detect this... Software (open or closed source) alone won't help very much.
May be the crucial part of implementing the security system. Eg, as an embedded system handling signals from webcams, distributed over the building as several nodes (instead of a central one), mimicking the nerve system of insect.
On 2003-07-15, Thomas Shaddack uttered:
Take a relay and connect it to a door switch.
Precisely. It's not just about manual shutdown, but all surprise shutdowns. Also, I'm afraid of the possibility that simply switching the power off might not do the trick -- we don't care about how dirty the system state will become short of dataloss outside the current working set, but we do need to be sure all crypto and plaintext I/O relevant state is properly purged from memory and peripherals. There are plenty of examples like printer buffers, random pools, already keyed smartcards, anything you're currently showing on-screen (I wouldn't be surprised if that could be read after sustained powerdown), any battery backed memory, off-the-shelf peripherals which do not admit crypto, and so on. Probably we'd also want to make the machine as dead as possible, shutting down any remote power-on features, network connections (otherwise retries might go on for a fair while), open phone lines, whathaveyou. That's why we might need software, and not just the power switch. I can also imagine situations where we'd want to be able to perform manual shutdowns remotely. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
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.
participants (2)
-
Sampo Syreeni -
Thomas Shaddack