Hi Markus, the problem with linux is: everyone seems to try to use LUKS these days. LUKS has one good thing: a metadata header inside the partition, so you can detect "ah, this is an encrypted partition" and it can contain information about it etc. this is good.
LUKS also contains an indirection layer for the password. instead hashing your password and using that as key, they - as far as I know - encrypt the partition with a key generated from random bytes, which is much better. and in the meta data part before the real encrypted part, there is some information how you can go from a passphrase to towards the real encryption key. like a special value, that could be xor'ed with you hashed passphrase to create the real encryption key. of course no xor, but a real secure and sophisticated mechanism, but you get the idea: the bridge data, so that with the passphrase you can get the real encrypted key. also this middle step is great, because it allowes several passphrases to co-exist. so you could have several users, each with their own secret passphrase and any of them could "unlock" the partition, but noone knows the other persons secret passphrase. great. and they have a special mechanism to make password/phrase guessing much harder (huge data blob, finding the real encryption key is much harder than hashing a few passwords/phrases with a salt and see if it works). all good so far. but last time I looked - many years ago - there was no support for smart cards in the design. I think some people use smart cards as "smart container for bytes" (so they store the pass phrase or bytes of the key or something like that on the card and use the pin protection mechanism to secure them). when I looked at smart cards for hard disk encryption, I used some middle mechanism too: my key was a few bytes from /dev/random, and I never wrote it on disk. the basic idea for me was: * disable swap, work on a pure ram disk * get some random bytes as key, setup encrypted partitions with those, use them for installation etc. * create an rsa key * save the rsa key: a) as file encrypted with a passphrase (on a plain partition) b) store it on a smart card * encrypt the random bytes used as partition key with the rsa key, store them on the plain boot partition too. so when the system boots, it will a) bios loads grub loads kernel+module, the initramfs loads the (password protected) rsa private key from the boot partition and the (rsa key encrypted) random bytes/partition key. the script will ask me for the passphrase to use the rsa key and use it to decrypt that blob containing the partition key. then the partition key is used to setup the filesystem so it can continue booting. of course the passphrase for the rsa key is never written to disk nor kept in ram, nor is the private key ever written to disk nor kept in ram, and the encrypted blob is read, decrypted, converted to hex, used to unlock the encrypted partition, and then all traces (environment variables/files in tmpfs) are erased, so no traces are left either. of course root on system with the encrypted partition unlocked can always lookup the decryption key, there is no security against that (LUKS doesn't help here either I guess, but with dm-crypt it is plain trivial). I also configured the system to use no swap at all, till the encrypted partition is unlocked, and then use an encrypted swap partition for security reasons too. also I moved the code to setup the encrypted partitions (filesystem and swap) before the resume code from software suspend. that way the normal linux software suspend will work as expected - check if the swap contains a suspend image and if so restore it and continue all applications in the state they had before suspend). b) the same thing, but access a smart card with the rsa key to decrypt the "binary blob" used as encryption key for the partitions. notes: you can have two "binary blobs", one for each partition. but that is no improvement security wise, I think. you can also combine a) and b) - use smart card decryption and have a fallback mechanism for the file. (hmm, maybe allow using a usb memory stick with a file as alternative to the smart card?) you can keep a copy of the files in your /boot partition somewhere as copy. there is the possibility that someone modifies them to include a trojan horse. maybe TCPA can help there, but except that I see little what you can do against that. maybe move your /boot partitoin to a usb stick? you can have the "encrypted blob" files (and the password-protected rsa private key file) either in /boot as plain files, or inside your "initramfs" or both. I wrote a guide for installing ubuntu with the a) method here: https://help.ubuntu.com/community/EncryptedFilesystemUsingDm-CryptOnDapper that guide was for ubuntu dapper, but I think little has changed, so it should still work well more or less. much would be easier these days, as the ubuntu has prequesites for many issues - e.g. writing a module name into /etc/modules should be enough so it is loaded during boot. no need to put modprobe commands somewhere. also ubuntu has a mechanism so you can tell it "please include /usr/bin/foo in the initramfs" and you don't need to worry about shared libraries etc. the problem is only these things are distribution specific, and not very well documented (at least with ubuntu it was that way 3 years ago, and I doubt it is much different on other distributions). part of the guide is a "manual installation guide", because I didn't know how to integrate properly in the ubuntu installer. not sure if the ubuntu installer is documented and costumizeable these days. I had plans to release a cd image with a modified ubuntu installer, but never got around to implement it properly. it should be easy to add openct+opensc to the guide with a) so you can use a smart card instead. you need /var/run/openct, openct-control and ifdhandler, pkcs15-crypt and udev configured so it will run openct if a usb crypto token is attached. the problem is not normal boot, that can be covered in a few lines of code and those extra files. the question is rather software suspend: what can I exactly do during initramfs stage, before the resume is triggered? developers tell me to do as little as possible, but a smart card decryption would require usb communication and starting (and later stopping) a few daemons. in my tests I hade no issues here, but I couldn't get detailed information on what is ok, and what could lead to problems either. I admit my implementation has two major drawbacks: * no header in the encrypted partition telling me "this is an encrypted partition" (plus algorithms etc.) that would be nice, and it could host the content of the encrypted "blob" file and an encrypted rsa private key too. maybe LUKS could be used for that these days? * scripts instead of a tool. most people want a tool with a man page, and not need to know the internals. I prefer the scripts, because they show *me* clearly what is going on. but for user acceptance a tool would be much better. Alon mentioned: > Look also into [1]. > [1] http://wiki.tuxonice.net/EncryptedSwapAndRoot hmm. looks interesting, here is my quick review: * normal suspend worked fine for me, so unless tuxonice has a degression or a different interface, the suspend mechanism in your kernel shouldn't matter. (but I must admit, I haven't looked into the suspend evolution too close in the last few years, but I saw the flame-war on linux-kernel about different camps with different ideas, so I guess my knowledge is out-dated.) * loop-aes? sorry, but loop devices have inherent problems, even if nearly noone triggers them, and I see no reason to not use the modern dm-crypt in general. given the "discussion" I read about loop-aes once, I rather not use it, it gave me some bad feeling. * aespipe? ok,for "on the fly" decryption, but I never had that as a goal. * compile static apps? oh, ok, I know many people like their initramfs static, but I think it is a waste of ram, doubles complexity, wastes cpu cycles, and like to point out, that even 200MB+ initramfs files work great for me (build with glibc, sometimes containing even all the /usr/share/doc files if I was too lazy to strip them down - any initramfs file works great for me, if the machine has twice as much ram as least. and I find building huge initramfs with debootstrap soo much easier...) (but this is personal taste as you can see) * initrd_util? not sure what it exactly does, but I prefer using the distributions initramfs tools, only adding a few lines of shell code and extra files, and not replace the whole initramfs (which I fear this does) (ah, later the whole content is shown, so this indead seams to have the goal of "creating a new initramfs" / not modifying the one your distribution creates/ships. * one key per partition looks fine. but 2925 files and then uuencoded and than encrypted with gpg? strange, and I distrust what I don't understand. on the other hand I hope the plain openssl rsa key encryption I implemented in my scripts is secure, only a real crypto expert can tell. * pkcs11-data looks like it is the tool to write data to a smart card as pin protected file. you can use pkcs15-init for that as well. well, pkcs15- init can maybe not work in such a pipe construct, but if you have neither swap nor real filesystems (only ramfs/tmpfs), then using a temp file is fine too. * setup: they read the unencrypted parition, and encrypt it on a fly. all data lost if you have a power failure during that. that is ok for me, such operations are difficult. I instead expected people to install on a new blank machine, while this assumes an already installed machine to be converted. both is valid. * in ubuntu /etc/modules is a file, in this example it needs to be a directory, so watch out. * the example uses pcscd, that is fine with me. openct or pcsc-lite plus driver should both be fine. * "boot-digest-mark"? ok, you can have checksums of your /boot partition somewhere (or simply a 100% copy) and validate them after boot. but a good trojan could maybe still hide (although would need to be much more intelligent) (ah, more documentation on this below, good!) * the example covers splash screens. true, forgot that, you need to turn them off (in ubuntu edit /boot/grub/menu.lst and rerun update-grub). * ah, later dm-crypt support was added. good! also several suspend modes. * supports both pcscd and openct, nice. * how does it support usb smart card readers/token plugged in after boot up? I don't see udev, hal or hotplug. maybe I miss something? busybox does this? * ansi colors :) (I'm a black/white fan, but thats personal prefernce again) * I dislike long and complex shell scripts, but I guess mine is no better than this one. I think with that "shell scripts are write only", perl/python or a tool in c would maybe be better? (personal preference again) so this links helps gentoo users a lot I guess. but either way, I think distributions should offer full disk encryption in the normal install process, and neither will help much to reach that goal. debian seems to have LUKS in their text installer (ubuntu as well), but LUKS has no smart card support to my knowledge. either way: what is the benefit? an encrypted laptop is good. I combined "something I have" with "something I know" to protect the data. if you add a smart card, then it is "two things I have" plus "something I know", so maybe not that much improvement in security. on the other hand it is much better to "have" a smart card plus "know" one pin, than to know many different passwords (disk encryptuion, user login, browser wallet, web site passwords and so on), and implementing universal authentication with smart cards looks right to me (if done properly). good night! Regards, Andreas _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
