headers
David Holland | 1 Jan 2008 18:54
Picon

Re: cgd and remote keys

On Mon, Dec 31, 2007 at 05:59:04PM -0500, Greg Troxel wrote:
 >   Yeah, I was originally thinking in terms of SSL, for which one does
 >   (AFAIK) need curl or something of the sort, then designed it out.
 >   Woops.
 > 
 > I think the solution should provide perfect forward secrecy, so that
 > passively tapping the net ahead of time together with the assumed
 > physical possession doesn't get the attacker the key.  That was why I
 > suggested IPsec, although I should have explained why

Right, hence the bit about nonces that I alluded to.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 0 comments |
headers
Alan Barrett | 2 Jan 2008 13:39
Gravatar

Re: cgd and remote keys

On Mon, 31 Dec 2007, Curt Sampson wrote:
> [encrypted disk on machine with inaccessible console]
> Is there an existing protocol we might use that would be as simple as
> a simple TCP connection? (HTTP comes to mind.)

Under FreeBSD with the "geli" disk encryption scheme, I once
embedded an HTTPS server in the code that prompts for a password.
The password prompt appears on the console as usual, and a web
server starts listening on a configurable port; whichever gets a
password first wins.  I used a modified verion of shttpd as the
embedded web server.  shttpd is not in pkgsrc, but is available from
<http://shttpd.sourceforge.net/>.  My code is not ready for public
consumption, but I could get it ready if there's interest.

> Would anybody object to me writing and committing this, along with
> committing a simple server to pkgsrc?

I have no objection to your idea, but I prefer the HTTPS idea.

--apb (Alan Barrett)
Permalink | Reply | 3 comments |
headers
Erik Berls | 2 Jan 2008 22:43
Picon

Re: cgd and remote keys

I'm thinking we might want to take a step back and look at a general
key storage and distribution mechanism for these types of things
within NetBSD.

From the looks of the thread, and the various solutions presented, it
sounds like we are 80% of the way there.

That said, if a solution moved along that was specific to this
particular problem merely took into account potential reuse in a
larger scheme, I think we would be ahead.

-=erik.

On 1/2/08, Alan Barrett <apb <at> cequrux.com> wrote:
> On Mon, 31 Dec 2007, Curt Sampson wrote:
> > [encrypted disk on machine with inaccessible console]
> > Is there an existing protocol we might use that would be as simple as
> > a simple TCP connection? (HTTP comes to mind.)
>
> Under FreeBSD with the "geli" disk encryption scheme, I once
> embedded an HTTPS server in the code that prompts for a password.
> The password prompt appears on the console as usual, and a web
> server starts listening on a configurable port; whichever gets a
> password first wins.  I used a modified verion of shttpd as the
> embedded web server.  shttpd is not in pkgsrc, but is available from
> <http://shttpd.sourceforge.net/>.  My code is not ready for public
> consumption, but I could get it ready if there's interest.
>
> > Would anybody object to me writing and committing this, along with
> > committing a simple server to pkgsrc?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Cem Kayali | 3 Jan 2008 00:22
Picon
Gravatar

Re: cgd and remote keys


Hi,

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. 

Although this does not allow you to enable remote reboot, it is much more
secure than storing cgd key on / partition.

Best wishes,

Curt Sampson wrote:
> 
> I've been thinking recently about how to add some additional security
> to hosts in less-secure physical locations, where there's a possibility
> they could be stolen. I'd like to use CGD to encrypt parts of the disks,
> but it always seemed rather pointless if the key was in a file on the
> disk, and of course the machine can't reboot unattended if it's not.
> 
> A solution to this did occur to me, however. If I added a new key
> generation method to cgdconfig that made a TCP connection to a given
> host, sent an identifier, and read back a key or passphrase, I could
> have a server (or group of servers) elsewhere on the net supply that.
> That server could refuse to return the information if the request came
> from an unexpected IP address, and I could also disable that key in the
> server if I found out the machine had been stolen (which I would very
> quickly if I were monitoring it via Nagios or whatever).
> 
> For an unecrypted connection, this means that the perpetrator of a back
> bag job would need to either sniff the key/passphrase in an exchange
(Continue reading)

Permalink | Reply | 7 comments |
headers
Hubert Feyrer | 3 Jan 2008 00:42
Picon
Favicon

Re: cgd and remote keys

On Wed, 2 Jan 2008, Erik Berls wrote:
>> From the looks of the thread, and the various solutions presented, it
> sounds like we are 80% of the way there.
>
> That said, if a solution moved along that was specific to this
> particular problem merely took into account potential reuse in a
> larger scheme, I think we would be ahead.

What's wrong with ssh?

- Hubert
Permalink | Reply | 1 comment |
headers
Erik Berls | 3 Jan 2008 00:56

Re: cgd and remote keys

On 1/2/08, Hubert Feyrer <hubert <at> feyrer.de> wrote:
> On Wed, 2 Jan 2008, Erik Berls wrote:
> >> From the looks of the thread, and the various solutions presented, it
> > sounds like we are 80% of the way there.
> >
> > That said, if a solution moved along that was specific to this
> > particular problem merely took into account potential reuse in a
> > larger scheme, I think we would be ahead.
>
> What's wrong with ssh?

SSH is a transport, not a mechanism?
More than "configuration" needs to be done to use SSH to deal with cgd
keys, or ssl certs, or ...

-=erik.

>
>
> - Hubert
>

--

-- 
"Too bad $VOLUNTEERS don't get their act together and provide
$SOLUTION_TO_VERY_DIFFICULT_PROBLEM in a decent fashion"  -- from IRC,
#netbsd, EFNet
Permalink | Reply | 0 comments |
headers
Curt Sampson | 4 Jan 2008 02:53

Re: cgd and remote keys

Thanks for all of your helpful replies. I'm glad people think that this is
a worthwhile idea.

On 2008-01-02 13:43 -0800 (Wed), Erik Berls wrote:

> I'm thinking we might want to take a step back and look at a general
> key storage and distribution mechanism for these types of things
> within NetBSD....

Well, it's definitely a good idea to generalize where you can, but I'm
not sure that I see a lot of generality here. There are many different
ways to do this key distribution thing for various purposes, and many
of them (such as getting web server SSH keys) are outside of the base
system. However, I'm open to thoughts on this.

On 2007-12-31 03:25 -0700 (Mon), John R. Shannon wrote:

> An approach used in military applications is to keep a symmetric key on your 
> server with encrypted storage that is used only for key encryption. This is 
> usually called a "cryptographic ignition key".

This is an understandable approach, but it seems to me that the same
level of security is achieved merely by having the server provide part
of the key and the local client provide another part; thus, if the
server's part of the key is stolen, it alone can't be used to decrypt
anything, either. (I'm sorry I didn't say so explicitly in my previous
post, but I was assuming that this would almost invariably be the way
the system would be configured.)

On 2007-12-31 17:16 +0000 (Mon), David Holland wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin J. Laubach | 4 Jan 2008 14:31
Picon

Re: cgd and remote keys

|  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)

  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").

  Cheers,

	mjl
Permalink | Reply | 6 comments |
headers
Gavan Fantom | 5 Jan 2008 16:08
Gravatar

Re: cgd and remote keys

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
(Continue reading)

Permalink | Reply | 5 comments |
headers
David Brownlee | 5 Jan 2008 20:25
Picon

Re: cgd and remote keys

On Sat, 5 Jan 2008, Gavan Fantom wrote:

> 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.

 	TrueCrypt allows for nesting a hidden volume inside a normally
 	encrypted volume. A trivial implementation of this would not
 	interact well with an FFS outer encrypted volume, but could
 	definitely be a good approach for those interested:

 	http://www.truecrypt.org/docs/?s=hidden-volume
 	http://www.truecrypt.org/docs/?s=plausible-deniability

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane