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. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
