[dm-crypt] passkey over network

[dm-crypt] passkey over network

[Roberto Spadim]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 741 bytes --]

Re: [dm-crypt] passkey over network

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1964 bytes --]

Re: [dm-crypt] passkey over network

[Roberto Spadim]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2945 bytes --]

Re: [dm-crypt] passkey over network

[Arno Wagner]

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 <user@remote> "cat uuid_file_xxxx" | cryptsetup ...

with a password-less ssh setup. Or improve it, use
the UUID as user-name and make "cat <passwordfile>"
the login-shell. Then you just need
 
  ssh <UUID@remote | cryptswetup 

and users cannot log in, just echo the passphrase.
(For admin purposes you can still log into the remote
server as rtoot and do a su UUID which gives you a non-login
shell.)

This gives you the far better security level of ssh with
two-sided authentication, instead of the basically broken SSL
1-sided authentification with the basically broken PKI and
the risk that anybody that can obtain your UUID or use
a PHP vulnerability, webserver vulnerability or a vulnerability 
in your PHP code can get your passphrase. Also, anybody able to
replace your server (ip spoofing, DNS spoofing, ...) can
inject whatever they like into your client-side script with
the web-solution.

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

Re: [dm-crypt] passkey over network

[Alex Elsayed]

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.

Re: [dm-crypt] passkey over network

[Arno Wagner]

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

Re: [dm-crypt] passkey over network

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1996 bytes --]

Re: [dm-crypt] passkey over network

[Arno Wagner]

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

Re: [dm-crypt] passkey over network

[Alex Elsayed]

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.