Re: [PATCH] 90crypt: keys on external devices support

["Amadeusz Żołnowski" <aidecoe-2qtfh70TtYba5EbDDlwbIw@public.gmane.org>]

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

You're fast! :-)


Excerpts from Mr Dash Four's message of Wed Oct 20 16:06:32 +0200 2010:
> > Next thing is give possibility to put keys inside initramfs.
> >   
> I don't think this is such a good idea as having the crypto keys
> reside in the same place as the kernel would completely defeats the
> purpose of using crypto devices.

It does not.  You can have kernel and initramfs on removable media.  You
have this media secure and don't need separate media for keys.  It's
even more secure than having kernel and initramfs on harddrive because
it protects you from case when someone replaces your initramfs to stole
the key (e.g. sends to some remote machine).

And of course keys inside initramfs will be optional extra solution.


> > If you'd like to write support for smartcard, I'd be glad to see it
> > as a separate module.  Don't hesitate to post your progress on ml
> > for our review.
> >   
> I am not sure it would be as a separate module though (may be, at a
> later stage) - for now I'll try to use the existing module/framework
> in place and extend its functionality, hence why I posted some of my
> ideas late last night to canvass an opinion - from what I can gather,
> as you and Harald are the two main contributors to the crypto side of
> dracut it is good to know what you think?
> 
> The way I see it simplifying the various kernel parameters
> (particularly those designed to deal with luks-related partitions) is
> the way forward.
> 
> The one issue I am facing right now before I can even begin coding
> smartcard support in dracut is that I am not at all clear how it deals
> with the various dependencies when I ask a program to be installed
> (using the '-I' option) as 'pkcs11-tool' for example, would need at
> least 2 more executables available (with half-a-dozen other .ko
> library files) and at least two configuration files present and
> available at the time of execution.
> 
> The configuration files present another challenge in itself - most
> (default) settings work in about 90% of all cases, but for the rest
> these settings have to be changed (card reader types, various
> attributes set etc) and for that there are two options: either 1)
> create initrd image which is tailored to a specific configuration (and
> therefore these configuration files are embedded, so to speak, into
> the initrd image itself); or 2) take these configuration files out of
> the initrd altogether and make them available in the /boot
> directory/partition (in /boot/dracut for example!) when dracut is
> instantiated (hence why I asked in my previous post does dracut have
> at least 'read' access to that directory/partition)?

I hope I've answered to your concerns above in previous e-mail.


> One other thing I forgot to mention in my last post that with the
> proposed parameter changes there is a third possible scenario with the
> password authentication, in which case, the format of the parameter in
> the kernel would simply be:
> 
> c) rd.luks.<luks_uuid>[=]

You don't have to specify anything for password scenario. root=<dev> is
just enough.  Have you tried using crypt module?
-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]