Re: dm-crypt crypt_status reports key?

[Christophe Saout <christophe@saout.de>]

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

Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall:

> From looking at the dm_crypt code, it appears that it can be
> interrogated to report the current key. Some quick testing shows:
> 
> # dmsetup table /dev/mapper/volume1
> 0 2000000 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
> 
> Obviously, root can in principle recover this password from the
> running kernel but it seems silly to make it so easy.

I already tried that. It took me about five minutes using a shell, dd
and hexdump to get the key out of the running kernel...

> Moreover, it seems this facility exists to support some form of
> automated table storage (LVM?). As we don't want anyone/anything
> accidentally storing our passwords on disk in the clear, we probably
> shouldn't facilitate this. Perhaps we can stick something here like
> "<secret>" that the dm_crypt constructor can reject.

Yes, the reason is that the device-mapper supports on-the-fly
modifications of the device. cryptsetup has a command to resize the
mapping for example. It can do that without asking for the password
again. Features like this are the reason I'm doing this. Userspace tools
should be able to assume that they can use the result of a table status
command to create a new table with this information.

An alternativ would be to use some form of handle to point to the key
after it has been given to the kernel. But that would require some more
infrastructure.

I could imagine something like this:

Some kernel infrastructure for key management. It can hold keys which
are referenced by some form of handle. The keys are refcounted and wiped
if the reference count drops to zero.

If you want to create a dm-crypt mapping (or something else that uses
some form of cryptographic key) you create a new handle and assign the
key. Then you give the handle to dm-crypt which increments reference
count. When cryptsetup exits its reference to the key is dropped but the
key still has a reference from the active dm-crypt mapping. Later on
another application could then safely do something with that handle. As
long as an application or in-kernel user references the key it won't be
dropped so it's safe for a userspace application to play around with it.

BTW: The setkey command also seems to return the keys in use for IPSEC
connections.


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]