"secure" file flag?

[Poul-Henning Kamp]

In message <200311280014.49356.wes at softweyr.com>, Wes Peters writes:

>If you want an interesting problem to work on, come up with a solution to 
>the keying problem for disk encryption.  It somehow needs to allow 
>automated, unattended reboots during "normal" operations but prevent 
>attackers from compromising the system.  Maybe you could have the system 
>send an SMS message when it needs a key, you reply with a one-time key 
>from your mobile phone?

I have already described one solution to this in my GBDE paper at
BSDcon.

You use weak-link/strong-link setups for that:

Put the computer and a small UPS (5 minutes) in a good quality safe,
drill a tiny hole in it, through which you run the power cord and
a fiberoptic network connection.

Put serious violation sensors *inside* the safe: corner integrity,
door opening, tilt, humidity, mositure, temperature, pressure, gas,
smoke, vibration.   In addition put serious sensors on the network
connection:  packet filters, monitor the media state, wrong password
attempts, significant changes in trafic level etc etc.

As long as the violation sensors don't trigger (the weak link) the
safe protects the keys (the strong link).

If any of these sensors trip, if the safe is rocked, gets warmer,
if the external power disappears, if the network connection looses
connection, if somebody attempts to enter with a wrong sshd password,
the computer *immediately* nukes its keys and other sensitive
material and turns itself off, after which a breach of the strong
link is no longer a risk to the data.

Now *that* is a DIY project for the dedicated hobbyist :-)

The terminology and principle, is from atomic weapons which have a
similar security profile:
http://nuclearweaponarchive.org/Usa/Weapons/Pal.html

enjoy

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.