Re: dm-crypt crypt_status reports key?

[Fruhwirth Clemens]

On Wed, 2005-02-02 at 20:05 -0800, Matt Mackall wrote:

> Dunno here, seems that having one tool that gave the kernel a key named
> "foo" and then telling dm-crypt to use key "foo" is probably not a bad
> way to go. Then we don't have stuff like "echo <key> | dmsetup create"
> and the like and the key-handling smarts can all be put in one
> separate place.
> 
> Getting from here to there might be interesting though. Perhaps we can
> teach dm-crypt to understand keys of the form "keyname:<foo>"? in
> addition to raw keys to keep compatibility. Might even be possible to
> push this down into crypt_decode_key() (or a smarter variant of same).

Way too complicated. This is a crypto project, why does nobody think of
crypto to solve the problem :). Here's the idea:

Keys are handed to dm-crypt regularly the first time. But when dm-crypt
hands keys back to user space, it uses some sort of blinding to make the
keys meaningless for user space. 

That can easily be done by generating a kernel internal secret after
boot, and then before handing out the keys to user space, XOR-ing the
kernel secret into the key. When these keys are handed back from user
space to the kernel, the process is reversed. 

That's an effective blinding mechanism. The kernel has to remember
nothing but a single secret. No special out-of-band setup of "keyname:"
tokens, no additional management for these tokens and blinded key
becomes useless after reboot.

Of course, the blinded keys need to be distinguished from regular keys.
I propose to prepend "!" to the keys handed back to the user space, so
we have "!<hex..key>", and add a simple conditional post processing to
crypt_decode_key.

Of course, one can use encryption instead of XOR-ing with the kernel
secret as blinding mechanism, as the kernel secret can easily be
recovered by setting up a all-zero key. But the main intend of this
approach is to protect against incompetent roots and user space
programs, so I think this XOR OTP is sufficient, and further, trivially
to implement. (Actually it's a Multi Time Pad.)

-- 
Fruhwirth Clemens <clemens@xxxxxxxxxxxxx>  http://clemens.endorphin.org

Attachment: signature.asc
Description: This is a digitally signed message part