Re: [dm-crypt] passkey over network

[Arno Wagner <arno@wagner.name>]

On Mon, Jul 01, 2013 at 03:54:32AM -0700, Alex Elsayed wrote:
[...]
> In addition, HTTPS/SSL/TLS (at least by default) has some real issues for 
> this kind of thing. SSH used blindly is likely to share some of them, but is 
> (fortunately) somewhat better understood and ships with better defaults in 
> most cases.

SSH done right has full 2-sided authentication of users _and_ hosts.

> Also, the whole question of authenticating with TLS vs SSH is the wrong 
> layer - you don't want to have any authorized machine get any key, you want 
> to tie the key given out *to* the machine. 

That is why I proposed separate accounts per machine. That ties
the account to the machine, and the other machines cannot log into 
it.

> That means either doing something 
> like gitolite, and linking the pubkey to the data it gets OR nesting Yet 
> Another Authentication Mechanism inside of the session, with all of the 
> (squamous, rugose) pitfalls involved in designing a cryptographic protocol 
> of any kind.

Not needed, see above.

However, there is another problem: If you need the local machine to
authenticate itself to get the keys, you could just use the secret
credential as passphrase instead, with better security. Anybody getting
access to the machine with the storage can just request the passphrase
anyways. 

That means this whole scheme is about as secure as a locally stored
passphrase, i.e. not secure at all. The only benefit a remotely
stored passphrase has, is that if you take down the remote server 
_before_ the local machine is compromised and when the local volume 
is _not_ decrypted, you can deny the unlock. If the local machine
is compromised while the remote server is running, or while the
encrypted volume is mounted, the attacker gets everything. If
the local machine is not compromised, you do not even need encryption 
to be secure.

With that, I have the impression that the security model of this 
is fundamentally broken on a conceptual level. 

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare