Re: cgd and remote keys

["Erik Berls" <cyber%netbsd.org@localhost>]

You really have to work to balance the multiple encrypted volumes.  I
don't think for a minute that the courts are going to believe that
your 4G volume only contains 1 8k text file.  Especially in front of a
jury.  [;-)

However I think we're getting a bit off focus.  The goal is the
against theft of the key, not resistance to compulsion to divulge the
(a) key.

The first paragraph contains loads of good points.  I'm willing to
keep track of requirements/moderate a discussion on the topic,
however, I can't be active in suggestions on implementation
suggestions at this point.

-=erik.


On 1/5/08, Gavan Fantom <gavan%coolfactor.org@localhost> wrote:
> Martin J. Laubach wrote:
> > |  Just additional note, it is possible to store /etc/cgd/* content on usb
> > |  memory, already tested. You just need to add a line into /etc/fstab.
> >
> >   I was thinking about that (keeping local data safe yet not be a
> > hassle on every reboot) some time ago and came up with three variants:
> >
> >   - an USB storage on a cable, reasonably secured (ie. bolted to the
> >     wall, so an attacker is more likely to just plug it off)
> >   - a bluetooth device for key storage that could be hidden/securely
> >     mounted somewhere nearby the server
> >   - a remote server that only responds to the expected IP address
> >     (which causes pain when your internet connection goes down)
>
> These things should all have secure protocols for communication,
> especially the bluetooth and IP solutions. Authentication should be
> two-way (and not just based on IP / MAC address) and should be resistant
> to replay attacks. It should also be as resistant as possible to
> somebody obtaining the server as well as the client. (This is not 100%
> possible, but allowing for the possibility of the server keeping its
> secret foo on an encrypted disk itself, with a chain of such clients /
> servers seems to be a good start, especially if some of those items are
> tiny and sufficiently well hidden).
>
> >   Additional brownie points given for auto-destruction which seems
> > necessary wrt recent legislation in certain parts of the world ("Sorry,
> > I don't have the key, your [law enforcement] agents destroyed it when
> > they confiscated the server").
>
> Auto-destruction is a good idea, but is something that must be done very
> carefully, and for carefully considered reasons. Using it to circumvent
> law enforcement is potentially very dangerous, as if that is the sole
> purpose of such a scheme it could land you in serious trouble for
> deliberate attempts to circumvent such laws.
>
> While it is certainly the case that auto-destruction is worthwhile, it
> should be done to allow an administrator to prevent sensitive data from
> getting into the wrong hands in the face of extreme duress by criminals,
> not by law enforcement.
>
> ("Sorry, I don't have the key, your goons destroyed it when they took
> all the servers and smashed up the place.")
>
> Mind you, that situation is also likely to land you in (different) trouble.
>
> Possibly a better strategy would be for cgd (or something similar) to
> support multiple keys for the same partition, and return alternative
> datasets depending on which key is given. Plausible deniability tends to
> work much better when under duress than not being in a position to give
> anything. If you can give them something that is sufficient to convince
> them that they have got everything there is to get from you, and that it
> will be of some value to them, then you are more likely to escape with
> your life (or without a criminal record).
>
> In the case of criminals, presumably some slightly secret information
> that you would plausibly encrypt (while the ultra-secret stuff is
> encrypted with an auto-destructed key, of which no trace exists). In the
> case of law enforcement, presumably some softcore porn or details of
> swiss bank accounts which contain trivial amounts of money. Basically,
> enough to warrant hiding it from prying eyes, but not enough to get you
> into deep trouble.
>
> Then there is no way to prove that you have any more keys, and you can
> deny it to your heart's content.
>


-- 
"Too bad $VOLUNTEERS don't get their act together and provide
$SOLUTION_TO_VERY_DIFFICULT_PROBLEM in a decent fashion"  -- from IRC,
#netbsd, EFNet