Re: [dm-crypt] passkey over network

[Alex Elsayed <eternaleye@gmail.com>]

Roberto Spadim wrote:

> in my case it's a server, in any place in the world, and the https server
> that will send the key, is a server in my house or somewhere that i can
> 'block'/'unblock' server
> in other words, others servers only can use the disk if i say what's the
> passkey, without my passkey no mount exists
> 
> i will read your links, and understand what could be done
> any others ideas?

There are still real issues here. For one, let's say there's a time when the 
server will (predictably) ask - say a power loss. If someone spoofs a 
request at that time, you'll need a more robust authentication mechanism 
than 'looks okay to me,' something that will positively ID the machine.

The issue there is that the list of things which are usable in such a manner 
is VERY limited. MAC addresses? Even if they weren't *totally* meaningless 
beyond the local network where they're part of the protocol, they're 
trivially spoofed. The only thing I can think of off the top of my head is 
to use the TPM to store a signing key in an opaque manner and do a well-
designed challenge-response (already harder than it sounds, see the 
revisions and issues of MS-CHAP), at which point I suspect we start 
exceeding the amount of effort you are willing to go to.

If you also want to defend against someone taking the actual hardware and 
booting an attack system on it, you'd need to use some form of Trusted Boot 
to lock that key as well, and it starts becoming rather cumbersome indeed.

...for rather marginal gain.

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.

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