Hi, just few notes (I think most of the arguments were already mentioned). On 20.5.2013 16:56, Krzysztof Rutecki wrote: > Nice to see anybody involved. Under all of yours thoughts I have to say yes, yes, yes. Root sys admin > is the person we have to trust most. But still... Once you run encryption on main processor, you must trust superuser. It is nice we can limit sone attack vectors but the key will be always somewhere in memory (in dmcrypt case it is part of config ioctl structure.) Note, dmcrypt is not military technology with robust hw tamper resistant design, and it has some limits. Yes, we have kernel keyring, we can limit key transfer (and I agree that sending key in dm-ioctl message is stupid) but the problem is still there even if key is in some special keyring. > The idea behind it is to make using of crypto cards (HSM) easier and more natural. We where thinking > that token/card will be required only during disk initialization but still, we can clone master key > of mounted disk. So no future security enhance can be added to LUKS? I would like to have "LUKS2" where keyslots can be of different types - it can be handle to kernel keyring, it can be handle to some token. (IOW the key will be initialized not through dm-ioctl but through some other interface dependent of keyslot type.) But in the end, there will be still key somewhere in main CPU which run encryption. So yes, there will be some development which could help your project. > And last thing - we extend cryptsetup as it is more easy. We still have the same tool (under different > name: cryptsetup-pkcs11) and yes, we study library as well (cryptsetup.c is an interface between cli and > library). Better do not do that. I will not accept such patches upstream, it is against design architecture. libcryptsetup is much more powerful than cryptsetup (see e.g. cryptsetup-reencrypt tool). (and cryptsetup is VERY limited by backward CLI compatibility) If there is any function missing in libcryptsetup, let me know, I can help to provide that. And patches, as always, are welcome. But please try to not extend cryptsetup command with upstream incompatible extensions. Some more notes (Also see PAM PKCS11 login extensions etc) > What is working now is: > - key generation (as pass-phrase) using smartcard/token hardware RNG - you can already provide pre-generated key to cryp_format API call, what missing here? > - encrypt a backup of the key using certificate from token upon 'luksFormat' Do you know volume_key project? It seems to me that this is better place for key escrow functionality. https://fedorahosted.org/volume_key/ (You can ask author, he will be for sure interested in this.) > - decrypt key from file using privatekey from token upon 'luksOpen' So this is the core problem, for now, I would use some wrapper or simple tool based on libcryptsetup. Later it can be specific handler for new LUKS2 keyslot type. > Anyway, out job is quite advanced and will be finished. I will open source it and we will see. If anybody > have any suggestion related with dm-crypt and crypto cards/token over PKCS11 comments are welcome. Maybe > something interested can be added :) You approach is good for prototyping but for long term it would be nice to have some supportable code. I would definitely not recommend use such modified tool in production phase. (And if you will distrbute modified tool, you have to provide source code in all cases, it is GPL code. If it is github or Googlecode is cosmetic detail, it is just a tool :-) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
