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 <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
