[Help-gnutls] Re: Announcement: Yet another GnuTLS-using program: Mandos

[Simon Josefsson]

Teddy Hogeborn <teddy at fukt.bsnet.se> writes:

>> I'm not sure you have to do the handshake backwards, couldn't just
>> the mandos server have a OpenPGP key that the mandos client doesn't
>> need to validate?
>
> Yeah, but why?  First we'd have to generate a key on the server on
> installation, which would take a lot of time and entropy for no
> reason.  And then we'd have an extra file to read (extra code) and
> manage (more code at installation and uninstallation to make sure the
> file is there and preserved, etc.).  We'd also have to make sure the
> server requires an OpenPGP certificate from the clients, which would
> mean even more code.  But, doing the handshake the other way around
> gets us exactly what we want, for free.
>
> Is there a good reason to go though all that trouble to do it the
> "normal" way?

No, probably not, and I agree with reducing complexity in this way here.

>> This might introduce network timeouts, but if the Mandos client is
>> robust about that there shouldn't be a problem.
>
> I'm not sure what you mean.  Should not a TLS connection over TCP be
> alive indefinitely even if no data is sent over it?

NAT firewalls tend to drop TCP sessions without any traffic over them
after some time.  Possibly the client could retry after some interval.
Maybe your protocol could contain a ping-function.  This would add some
complexity, so for simplicity might be better to avoid.

>> You'll have a problem if someone also gets control of the Mandos
>> server though...
>
> If you by "control" mean "physical access", then no, not if the Mandos
> server also has an encrypted file system.  But if you by "control"
> mean "root", then yes, if someone gets root on the Mandos server and
> *also* physical access to the Mandos clients, the game is lost.  Root
> access has always been bad news.
>
> The point is, any one of those things only gives half of the key; an
> attacker would need both physical control of a Mandos client *and*
> root on the Mandos server to successfully decrypt the clients' disks.

Right.  The blob sent from the Mandos server is only possible to decrypt
by the particular Mandos client, right?

>> Maybe one could extend the scheme, so that N out of M machines have
>> to participate in reconstructing the blob before any single machine
>> can boots.  Just getting control of <N of the M machine should not
>> reveal any information.
>
> I don't really see how this could be useful, since the client machine
> must be able to construct a file system key using only its OpenPGP key
> and a network connection.  Therefore, regardless what hoops you make
> it jump through, anyone with access to that key could perform the same
> action it does and get the file system key.

Only if the Mandos servers send the blob to the system.

> Wait a minute, you mean to protect against someone getting root access
> on the Mandos server?  Then you are correct, it would lower the
> information exposure if that were to happen.

Yes, protecting against an attacker getting control of the Mandos server
was what I was thinking about.  If you have many Mandos servers, getting
control of sufficient many of them will be practically difficult.  You
can make them run wildly different OS's that are unlikely to suffer from
similar security problems as well.  If the protocol requires that you
need co-operation from >=N Mandos servers to boot a particular server,
this approach would add some assurance for sufficiently paranoid
individuals.

> Oh well, that can wait until version 2.  :-)

Or left as an exercise for the reader. :)

> Protecting against someone with root access has never been our
> priority; our primary goal has always been to protect against physical
> removal of the servers.  Not saving the encryption keys in the clear
> on the server was just a sudden attack of common sense, not really
> meant as a real defense against someone with root on the Mandos
> server.

Understood.

/Simon