Re: [dm-crypt] passkey over network

[Alex Elsayed <eternaleye@gmail.com>]

Arno Wagner wrote:

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

Yes, hence my statements regarding 'used blindly' and how it is fortunately 
better understood and has better defaults.
 
>> 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.

The issue there is that adding a new local user, making sure to set them to 
a restricted give-them-the-key shell, &c is cumbersome and error prone. 
There is a reason gitolite uses the method it does; the security-conscious 
setup is for one account and happens once, and thereafter you just add a 
pubkey to a list.

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

The above is why I made the note of storing a private key as an opaque 
(read: you call into the TPM's API to use the key, and it has no ability to 
leave the TPM). If you lock that down into the Trusted Boot thing, which 
verifies that the boot process went according to expectations, you basically 
have the 'remote attestation' feature that TPMs touted from the beginning.

I do agree that it's an extraordinary amount of effort for minimal gain, 
most of which is in making it easier to create automated deployment 
mechanisms that are primarily relevant to datacenter operation rather than 
any useful security on the part of the servers.