[dm-crypt] passkey over network
eternaleye at gmail.com
Mon Jul 1 12:54:32 CEST 2013
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
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.
More information about the dm-crypt