From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvfju7gyqkW5 for ; Mon, 1 Jul 2013 00:24:49 +0200 (CEST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 1 Jul 2013 00:24:48 +0200 (CEST) Received: by mail-oa0-f43.google.com with SMTP id i7so4167616oag.16 for ; Sun, 30 Jun 2013 15:24:47 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 30 Jun 2013 19:24:46 -0300 Message-ID: From: Roberto Spadim Content-Type: multipart/alternative; boundary=047d7b5d301a55c6de04e0669471 Subject: [dm-crypt] passkey over network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --047d7b5d301a55c6de04e0669471 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, i want to create a map to my crypted disk but, instead of putting the passkey every time, or using a pkcs11 (smart card), i want to get the passkey from a external server via network in other words: 1)place a new hard disk 2)setup dm-crypt over disk 3) mount disk using a external server like " https://www.host.com/get_passkey.php?UUID=xxxxx" anyone done something like it? or near it? maybe i'm talking about something that already exists -- Roberto Spadim --047d7b5d301a55c6de04e0669471 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys, i want to create a map to my crypted disk
but= , instead of putting the passkey every time, or using a pkcs11 (smart card)= , i want to get the passkey from a external server via network
in= other words:

1)place a new hard disk
2)setup d= m-crypt over disk
3) mount disk using a external server lik= e "https= ://www.host.com/get_passkey.php?UUID=3Dxxxxx"

anyone done something like it? or near it? m= aybe i'm talking about something that already exists
--
Roberto Spadim
--047d7b5d301a55c6de04e0669471-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFISIX43O6cp for ; Mon, 1 Jul 2013 00:55:40 +0200 (CEST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 1 Jul 2013 00:55:39 +0200 (CEST) Received: by mail-pb0-f42.google.com with SMTP id un1so4127369pbc.29 for ; Sun, 30 Jun 2013 15:55:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: ".. ink .." Date: Sun, 30 Jun 2013 18:55:16 -0400 Message-ID: Content-Type: multipart/alternative; boundary=047d7bdc773891090b04e0670299 Subject: Re: [dm-crypt] passkey over network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roberto Spadim Cc: dm-crypt@saout.de --047d7bdc773891090b04e0670299 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, i want to create a map to my crypted disk > but, instead of putting the passkey every time, or using a pkcs11 (smart > card), i want to get the passkey from a external server via network > in other words: > > 1)place a new hard disk > 2)setup dm-crypt over disk > 3) mount disk using a external server like " > https://www.host.com/get_passkey.php?UUID=xxxxx" > > anyone done something like it? or near it? maybe i'm talking about > something that already exists > > I think the proper steps would be 1. identify a LUKS based encrypted volume you want to unlock. 2. get the UUID of the encrypted volume 3. securely,get the key mapped to the UUID from another computer over the network 4. use the key to unlock the volume 5. mount the unlocked volume 6. ???? 7. profit!!! I have a project[1] that interfaces with cryptsetup and it has plugin architecture and can do the above when a plugin with the functionality is written.Source code for a plugin that get a key from gnome-keyring is here[1] so the plugin interface is simple enough. I envisioned making a plugin that does what you are thinking but never made one since i do not have a personal use case for it and nobody asked for it. [1] http://code.google.com/p/zulucrypt/ [2] http://code.google.com/p/zulucrypt/source/browse/plugins/keyring/keyring.c --047d7bdc773891090b04e0670299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi guys, i want to create a map to my crypted disk
but, instea= d of putting the passkey every time, or using a pkcs11 (smart card), i want= to get the passkey from a external server via network
in other words:

1)place a new hard disk
2)setup dm-crypt over= disk
3) mount disk using a external server like "https= ://www.host.com/get_passkey.php?UUID=3Dxxxxx"

anyone done something like it? or near it? maybe i= 'm talking about something that already exists

=A0
I think the proper steps would be
1. identify a = LUKS based encrypted volume you want to unlock.
2. get the UUID of the e= ncrypted volume
3. securely,get the key mapped to the UUID from another = computer over the network
4. use the key to unlock the volume
5. mount the unlocked volume
6. ?= ???
7. profit!!!

I have a project[1] that interfaces with crypts= etup and it has plugin architecture and can do the above when a plugin with= the functionality is written.Source code for a plugin that get a key from = gnome-keyring is here[1] so the plugin interface is simple enough. I envisi= oned making a plugin that does what you are thinking but never made one sin= ce i do not have a personal use case for it and nobody asked for it.

[1] http://code.google.= com/p/zulucrypt/
[2] http://code.google.com/p/zulucrypt= /source/browse/plugins/keyring/keyring.c


--047d7bdc773891090b04e0670299-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i90pkozFs1x0 for ; Mon, 1 Jul 2013 01:53:23 +0200 (CEST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 1 Jul 2013 01:53:22 +0200 (CEST) Received: by mail-ob0-f171.google.com with SMTP id dn14so3671291obc.16 for ; Sun, 30 Jun 2013 16:53:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Sun, 30 Jun 2013 20:53:21 -0300 Message-ID: From: Roberto Spadim Content-Type: multipart/alternative; boundary=089e0118409e17780504e067d106 Subject: Re: [dm-crypt] passkey over network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ".. ink .." Cc: dm-crypt@saout.de --089e0118409e17780504e067d106 Content-Type: text/plain; charset=ISO-8859-1 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? 2013/6/30 .. ink .. > > > Hi guys, i want to create a map to my crypted disk >> but, instead of putting the passkey every time, or using a pkcs11 (smart >> card), i want to get the passkey from a external server via network >> in other words: >> >> 1)place a new hard disk >> 2)setup dm-crypt over disk >> 3) mount disk using a external server like " >> https://www.host.com/get_passkey.php?UUID=xxxxx" >> >> anyone done something like it? or near it? maybe i'm talking about >> something that already exists >> >> > I think the proper steps would be > 1. identify a LUKS based encrypted volume you want to unlock. > 2. get the UUID of the encrypted volume > 3. securely,get the key mapped to the UUID from another computer over the > network > 4. use the key to unlock the volume > 5. mount the unlocked volume > 6. ???? > 7. profit!!! > > I have a project[1] that interfaces with cryptsetup and it has plugin > architecture and can do the above when a plugin with the functionality is > written.Source code for a plugin that get a key from gnome-keyring is > here[1] so the plugin interface is simple enough. I envisioned making a > plugin that does what you are thinking but never made one since i do not > have a personal use case for it and nobody asked for it. > > [1] http://code.google.com/p/zulucrypt/ > [2] > http://code.google.com/p/zulucrypt/source/browse/plugins/keyring/keyring.c > > > -- Roberto Spadim SPAEmpresarial --089e0118409e17780504e067d106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
in my case it's a server, in any place in the world, a= nd the https server that will send the key, is a server in my house or some= where that i can 'block'/'unblock' server
in othe= r words, others servers only can use the disk if i say what's the passk= ey, without my passkey no mount exists

i will read your links, and understand what= could be done
any others ideas?


2013/6/30 .. ink .. <mhogomchungu@gmail.com>

=

Hi guys, i want to create a map to my crypted disk
but= , instead of putting the passkey every time, or using a pkcs11 (smart card)= , i want to get the passkey from a external server via network
in other words:

1)place a new hard disk
2)setup dm-crypt over= disk
3) mount disk using a external server like "https= ://www.host.com/get_passkey.php?UUID=3Dxxxxx"

anyone done something like it? or near it? maybe i= 'm talking about something that already exists

=A0
I think the proper steps would be
1.= identify a LUKS based encrypted volume you want to unlock.
2. get the U= UID of the encrypted volume
3. securely,get the key mapped to the UUID f= rom another computer over the network
4. use the key to unlock the volume
5. mount the unlocked volume
6. ?= ???
7. profit!!!

I have a project[1] that interfaces with crypts= etup and it has plugin architecture and can do the above when a plugin with= the functionality is written.Source code for a plugin that get a key from = gnome-keyring is here[1] so the plugin interface is simple enough. I envisi= oned making a plugin that does what you are thinking but never made one sin= ce i do not have a personal use case for it and nobody asked for it.

[1] h= ttp://code.google.com/p/zulucrypt/
[2] http://code.google.com/p/zulucrypt/source/browse/plugins/keyring/keyring.= c





--
Roberto Spadim
SPAEmpresarial
--089e0118409e17780504e067d106-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giLQcVXfkMTI for ; Mon, 1 Jul 2013 01:57:01 +0200 (CEST) Received: from v6.tansi.org (unknown [87.118.116.4]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 1 Jul 2013 01:57:01 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-164-92.dclient.hispeed.ch [84.74.164.92]) by v6.tansi.org (Postfix) with ESMTPA id B9CF320DC253 for ; Mon, 1 Jul 2013 01:57:00 +0200 (CEST) Date: Mon, 1 Jul 2013 01:57:00 +0200 From: Arno Wagner Message-ID: <20130630235659.GA4928@tansi.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] passkey over network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Sun, Jun 30, 2013 at 07:24:46PM -0300, Roberto Spadim wrote: > Hi guys, i want to create a map to my crypted disk > but, instead of putting the passkey every time, or using a pkcs11 (smart > card), i want to get the passkey from a external server via network > in other words: > > 1)place a new hard disk > 2)setup dm-crypt over disk > 3) mount disk using a external server like " > https://www.host.com/get_passkey.php?UUID=xxxxx" That looks overly complicated. Why not use something like ssh "cat uuid_file_xxxx" | cryptsetup ... with a password-less ssh setup. Or improve it, use the UUID as user-name and make "cat " the login-shell. Then you just need ssh Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2otE6ik_sPa for ; Mon, 1 Jul 2013 12:54:53 +0200 (CEST) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 1 Jul 2013 12:54:53 +0200 (CEST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Utbkz-0004HE-AI for dm-crypt@saout.de; Mon, 01 Jul 2013 12:54:53 +0200 Received: from c-50-132-41-203.hsd1.wa.comcast.net ([50.132.41.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Jul 2013 12:54:53 +0200 Received: from eternaleye by c-50-132-41-203.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Jul 2013 12:54:53 +0200 From: Alex Elsayed Date: Mon, 01 Jul 2013 03:54:32 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Subject: Re: [dm-crypt] passkey over network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoNqpLQZeuko for ; Mon, 1 Jul 2013 17:44:04 +0200 (CEST) Received: from v6.tansi.org (unknown [87.118.116.4]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 1 Jul 2013 17:44:04 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-164-92.dclient.hispeed.ch [84.74.164.92]) by v6.tansi.org (Postfix) with ESMTPA id DF45020DC250 for ; Mon, 1 Jul 2013 17:44:03 +0200 (CEST) Date: Mon, 1 Jul 2013 17:44:03 +0200 From: Arno Wagner Message-ID: <20130701154403.GB13190@tansi.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] passkey over network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kufPvCe1gDZ7 for ; Mon, 1 Jul 2013 18:57:03 +0200 (CEST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 1 Jul 2013 18:57:02 +0200 (CEST) Received: by mail-ie0-f172.google.com with SMTP id 16so10049631iea.3 for ; Mon, 01 Jul 2013 09:57:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20130701154403.GB13190@tansi.org> References: <20130701154403.GB13190@tansi.org> From: ".. ink .." Date: Mon, 1 Jul 2013 12:56:40 -0400 Message-ID: Content-Type: multipart/alternative; boundary=047d7b3a9684f5b57704e0761d0a Subject: Re: [dm-crypt] passkey over network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --047d7b3a9684f5b57704e0761d0a Content-Type: text/plain; charset=ISO-8859-1 > 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. > > if you have one static host that gets keys from one static server,then the passwordless ssh method seem obvious but its pointlessness will shortly be realized.To access the key from a different host machine,the private key must be sent to the different host and the server,through other means,must be informed of the new host and hence it seem pointless since the private key could instead be used as a passphrase to unlock the volume or to unlock a key protected keyfile. There is another reason why such a setup could be useful and that is convenience from centralization of keys. I dont manage my luks keys individually,i have them in kwallet and access them through it.I have a bunch of luks volumes and i dont need to remember their individual keys as all i need is the key to unlock kwallet. His use case could be the same,only he want to access a wallet that is not on a local machine,but on a remote one so that he could smoothly switch between devices he own and have access to his volumes keys through a single key. --047d7b3a9684f5b57704e0761d0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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.


if you have one s= tatic host that gets keys from one static server,then the passwordless ssh = method seem obvious but its pointlessness will shortly be realized.To acces= s the key from a different host machine,the private key must be sent to the= different host and the server,through other means,must be informed of the = new host and hence it seem pointless since the private key could instead be= used as a passphrase to unlock the volume or to unlock a key protected key= file.

There is another reason why such a setup could be useful and that is co= nvenience from centralization of keys.

I dont manage my luks keys in= dividually,i have them in kwallet and access them through it.I have a bunch= of luks volumes and i dont need to remember their individual keys as all i= need is the key to unlock kwallet.

His use case could be the same,only he want to access a wallet that is = not on a local machine,but on a remote one so that he could smoothly switch= between devices he own and have access to his volumes keys through a singl= e key.







--047d7b3a9684f5b57704e0761d0a-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID3tUKF1I8Yn for ; Mon, 1 Jul 2013 20:53:56 +0200 (CEST) Received: from v6.tansi.org (unknown [87.118.116.4]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 1 Jul 2013 20:53:55 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-164-92.dclient.hispeed.ch [84.74.164.92]) by v6.tansi.org (Postfix) with ESMTPA id 6570D20DC250 for ; Mon, 1 Jul 2013 20:53:55 +0200 (CEST) Date: Mon, 1 Jul 2013 20:53:54 +0200 From: Arno Wagner Message-ID: <20130701185354.GB15476@tansi.org> References: <20130701154403.GB13190@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] passkey over network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Mon, Jul 01, 2013 at 12:56:40PM -0400, .. ink .. wrote: > > 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. > > > > > if you have one static host that gets keys from one static server,then the > passwordless ssh method seem obvious but its pointlessness will shortly be > realized. To access the key from a different host machine,the private key > must be sent to the different host and the server,through other means,must > be informed of the new host and hence it seem pointless since the private > key could instead be used as a passphrase to unlock the volume or to unlock > a key protected keyfile. Well, yes. As I said, just as secure as a locally stored passphrase, i.e. not secure at all. ssh was just my first idea to get around the shorcommings of the webserver-based approach. But then I realized there is a far more fundamental problem. > There is another reason why such a setup could be useful and that is > convenience from centralization of keys. > > I dont manage my luks keys individually,i have them in kwallet and access > them through it.I have a bunch of luks volumes and i dont need to remember > their individual keys as all i need is the key to unlock kwallet. > > His use case could be the same,only he want to access a wallet that is not > on a local machine,but on a remote one so that he could smoothly switch > between devices he own and have access to his volumes keys through a single > key. Yes, but instead of a passphrase to unlock, he wants to use a device-supplied UUID (that hence is stored on the device on plain somewhere) and that is (as far as I can see at this time) basically the same as storing the passphrase locally in the first place as long as the remote server is available. If he would give a passphrase manually each time he requests a passphrase for a LUKS device, that would be something different. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfFFfeMYNhXG for ; Mon, 1 Jul 2013 21:41:25 +0200 (CEST) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 1 Jul 2013 21:41:24 +0200 (CEST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UtjyV-0007R7-2j for dm-crypt@saout.de; Mon, 01 Jul 2013 21:41:23 +0200 Received: from c-50-132-41-203.hsd1.wa.comcast.net ([50.132.41.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Jul 2013 21:41:23 +0200 Received: from eternaleye by c-50-132-41-203.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Jul 2013 21:41:23 +0200 From: Alex Elsayed Date: Mon, 01 Jul 2013 12:41:10 -0700 Message-ID: References: <20130701154403.GB13190@tansi.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Subject: Re: [dm-crypt] passkey over network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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.