The crypt-swap method, as described in the given URL, may be flawed. Some facts: * The swap should be encrypted with a random key at bootup. * That random key is read from /dev/urandom * /dev/urandom is NOT guaranteed to give out random data, if the entropy pool is empty, it wil give out pseudo-random, predictable, data. * At bootup without user interaction (quite typical, even in desktops) there is little or no entropy availible at bootup. * some random-data is transported over shutdown-startup phases using the /var/run/random-seed file * That random-seed file is only used AFTER the crypt-swap is setup Conclusion: the "random" key is read from an (almost) empty entropy pool and hence predictable. Solutions: * read key-material from /dev/random: can take a long time to gather enough entropy. * make sure the random-generator is initialized BEFORE the swap is encrypted Practical: I've tested this, and have NOT been able to reproduce this. I did 3 powerdown-powerup's and found 3 different keys. I did another 3, this time with the network disconnected, and found again 3 different keys. (hence UNCONFIRMED) However, on the forum, there are reports that it DID happen (http://forums.gentoo.org/viewtopic.php?p=3340523#3340523) system info: Portage 2.0.54-r2 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.6-r3, 2.6.15-gentoo-r1-barabas-012 i686) ================================================================= System uname: 2.6.15-gentoo-r1-barabas-012 i686 Pentium III (Katmai) Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-Os -march=pentium3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=pentium3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 acl alsa apache2 apm avi berkdb bitmap-fonts bzip2 cli crypt cups curl doc dri eds emboss encode examples expat foomaticdb gd gdbm gif gpm gstreamer imlib iproute2 ipv6 isdnlog jpeg ldap libg++ libwww lm_sensors mad maildir mikmod motif mp3 mpeg ncurses nls nptl nptlonly ogg oggvorbis pam pcre pdflib perl png pppd python quicktime quotas readline reflection rrdtool sdl session snmp spell spl ssl tcpd threads tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales utf8 vorbis xml2 xmms xorg zlib userland_GNU kernel_linux elibc_glibc" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
Todo list: 1. looking into reordering random intialisation is a good start. 2. benchmarking the randomness of data at that time of boot. 3. seeing if /dev/random will halt boot because of lack of randomness. Any and all benchmarks welcome.
(In reply to comment #1) > 3. seeing if /dev/random will halt boot because of lack of randomness. /me notes that our kernels seem to have notorious issues w/ entropy. Search bugzilla for the 'cannot (re)start apache' bugs. Using /dev/random seems like a bad idea to me, unless we are able to ensure that there's enough entropy available in a reasonable time. Starting some randomness-gathering daemon (like sys-apps/clrngd, media-sound/audio-entropyd or media-video/video-entropyd) before before crypting the swap seems like a good idea).
(In reply to comment #1) > Todo list: > 2. benchmarking the randomness of data at that time of boot. My tests show that there is some: since I got 3 different keys, there must be at least 1.58 bits of entropy. I'm not sure how to measure it accuratly, but if anyone can give a method to do so, I'll be glad to do it. > 3. seeing if /dev/random will halt boot because of lack of randomness. I tried this a long time ago. I tried to do encrypted swap from within the initrd, and it blocked for 10+ minutes, after which I got bored and hit the keyboard.
(In reply to comment #1) > Todo list: > 2. benchmarking the randomness of data at that time of boot. I don't know if it's sane to do so, but I tried this: I added the following line, just before cryptsetup is called dd if=/dev/random of=/root/blabla bs=32 count=1 The command ran, but for a reason I don't know yet, dd only returned 21 bytes. I SUPPOSE that this means there was only 21 bytes of entropy availible, and the kernel returned the read() call with too less data, which dd didn't notice.
> (In reply to comment #1) > > 3. seeing if /dev/random will halt boot because of lack of randomness. > .... Tavis mentioned the same thing. Idea dropped. > Starting some randomness-gathering daemon (like sys-apps/clrngd, > media-sound/audio-entropyd or media-video/video-entropyd) before before > crypting the swap seems like a good idea). Or buying a motherboard with on board random generator support that the linux kernel supports. (HW_RANDOM: Intel/AMD/VIA HW Random Number Generator) > 1.58 bits of entropy Really bad - round it to 2 and you have about 2^2 to choose from. alphabet ciphers have a little more that 1 bit and are easy to break. Other suggestions have been: 1. Like dropbear (small ssh program) set a 3 second alarm read from random cancel the alarm take that and xor it with a bit of urandom. You only need to sample a few bytes from the real random. 2. - get the random initialed with the previous seed as soon as possible - make the swap initialization as late as possible in the boot process. - wipe/shred the random seed after random initialization (journal filesystem will maintain record) Another thought that I probably won't impliement is to swapoff and re-initialize the swap partition periodically (check there is spare memory first). Best bet - buy a hardware random device the linux supports.
Regarding the forum post (by me) linked to in the description: I only noticed that the /etc/init.d/urandom script responsible for the initialization of /dev/urandom is run after crypt-swap is setup - I did not notice swap being encrypted with the same key, as the description seems to imply. However, the issue here is not whether the key remains the same across boots, but whether the key is predictable. To me it seems quite obvious that a recently booted machine with an uninitialized entropy pool will not have enough entropy to create a decent random key for encryption. My opinion is that the initialization of urandom should be done as early as possible, and certainly before doing anything remotely associated with cryptography. I'll try benchmarking the entropy by checking the value in /proc/sys/kernel/random/entropy_avail just before crypt-swap is initialized. My guess is that it is not enough.
Okay, I did a quick test on the subject. I modified /lib/rcscripts/addons/dm-crypt-start.sh to save the amount of current available entropy from /proc/sys/kernel/random/entropy_avail to a file just before calling cryptsetup (line 38). Here's the results (in bits) of a series of test runs with no user interaction to provide entropy and one crypt-swap partition: 170 166 180 144 159 179 182 So it seems we don't have sufficient entropy to create a random 256 bit AES key for example. While 144 bits still might be enough to keep /them/ busy for a while, the flawed boot order does seem to considerably weaken crypt-swap. If someone agrees, bump the status to NEW. Is there anything preventing changing the startup order so that the random number generator is initialized before crypt-swap is run? At least the partition the random seed is on has to be mounted before the RNG can be initialized. Of course in most setups swap is not necessary early on, so crypt-swap probably could be postponed until entropy is sufficient.
(In reply to comment #7) I didn't know that /proc file... but I did some tests on it. On my desktop, while I'm typing this (not exactly an inactive period) entropy stays below 200 bits as well. with values around 130-190. I can get that number up by typing a lot (up to 350 if I type faster, with lots of mistakes to correct with backspace), or by moving the mouse (1000+) I also notice that the number leaks away quite fast, down to ~150 bits, and then stays constant. I'm not an expert on this, but I'm wondering if this number is usable for this, since even on a highly interactive machine, it's <200.
150 bits translating to a password of alphanumeric (is approximately 5 bits ( log2(36)) is a 30 character password. fairly substantial but it could be better.
I'm no expert on the art of RNGs either, but afaik the entropy_avail should be the best bet on how much entropy there is in the in-kernel entropy pool. On my desktop box it usually saturates on ~3500 bits if I keep moving the mouse around (the size of the entropy pool is 4096 bits). Without user activity, it quickly falls down to around 150, which probably corresponds to the entropy the RNG gets from hard disk seek times, interrupts and such minus the amount that gets used on network packet sequences and such. I believe the moral of the story is that if you want truly random keys, you provide the kernel with enough entropy to do it's job - the machine cannot really create lots of randomness on its own without a hardware RNG. If I'm not terribly wrong, some apps like gnupg make sure there is enough entropy to generate a truly random key before attempting to do so. Around 150 bits of entropy is still quite a random key, and brute-forcing that is probably nearly as impractical as brute-forcing a 256 bit key (and even deciphering the pseudo-random part is probably quite a feat) - however, if this weakness can be eliminated by simply reordering the boot sequence, I think it should be done. Who are we to say that '150 bits ought to be enough for anyone?' :)
I still plan on making the randomness better. My calculation was off too upper and lower case means log2(62) ~ 6 which means 25 character passwords. Considering: Initialing random seed early and wiping it. (make working back from a powered down machine harder though journaling file systems will have the seed somewhere). reordering swap to late as possible. CCing Roy, baselayout guru, for input.
Roy's looking into moving swapon from rc and putting it solely into localmount I'm looking at /etc/init.d/urandom Thinking the rm /var/run/urandom-seen shouldn't be there. Overwriting is better as its more likely i think to wipe the file. The overwrite of the new seed from /dev/urandom consumes a bit of early entropy. It preserved a good /dev/urandom the machine as poorly shutdown though. Ideas how to settle this welcome.
why was the swapon removed from /sbin/rc ? if the stuff in /etc/fstab is using crypto swap, then the devices wont be ready to be swapped on at that point, so it isnt like you're fixing anything the very early swapon is useful for low memory systems
(In reply to comment #13) > why was the swapon removed from /sbin/rc ? if the stuff in /etc/fstab is using > the very early swapon is useful for low memory systems Well, even if you think that removing it from /sbin/rc isn't valid for an encrypted then it sure is valid for bug #47932. Also, swapon would get called in localmount very soon afterwards anyway, so it's not like much is done in between that's going to require vast memory.
> Well, even if you think that removing it from /sbin/rc isn't valid for an > encrypted it isnt a valid reason > then it sure is valid for bug #47932. that is a valid reason
Any progress made on this yet?
(In reply to comment #16) > Any progress made on this yet? I've been very overwhelmed with other stuff. I won't have time for at least a few weeks.
OK. I wish to solve this one. It is the one i got in inheritance. Roy, we need to start urandom before mounting filesystems as read/write. I think the simplest solution is to split urandom into two separate services, urandom and urandom-persistence. The first runs at early stage, without filesystem modification. The second runs after localmount and persist the urandom at start an stop. What do you think? I guess all is in baselayout domain.
except urandom relies on /var which you cant assume has been mounted until after localmount
(In reply to comment #19) > except urandom relies on /var which you cant assume has been mounted until > after localmount Right. It should be moved to another location. We can allow it to be configurable, and defaults to / or /root, any other suggestion?
where it is now is the correct location it can be made configurable via conf.d, but the default location will remain the same
(In reply to comment #21) > where it is now is the correct location > > it can be made configurable via conf.d, but the default location will remain > the same > We cannot put the default in /var as this service will be split into two, the first one will run before localmount. Both need to access the file, so we have to find somewhere else to put it.
no, the default configuration is fine (and correct) for the majority of users out there for those who are paranoid and wish to use crypto swap, then they will need to modify the default configuration file so that urandom as a hole is run before localmount i see this as a pure documentation issue (once the path is moved into a conf.d file for users to modify)
OK. I don't care one way or another. Do you want me to do this? (I mean split the service into two), or baselayout will handle this one?
why does it need to be split into two if the path is configurable ? the init.d script is part of baselayout so the baselayout guys will be committing the change
It has to be split into two because when it runs before localmount the filesystem is readonly so it can read the old seed, but cannot write the new seed. After localmount we need to write the new seed. Have you thought of a better idea?
before localmount, after checkroot ... that means anything on the root partition is writable, so when customizing the conf.d, you have to select a location that lives on the root partition
OK. Great! Thanks! Reassigning to base-system.
urandom seed file can now be customized
(In reply to comment #29) > urandom seed file can now be customized Where? And when will the change hit Portage?
whenever a new baselayout release is made
(In reply to comment #31) > whenever a new baselayout release is made 3 months later and I'm still waiting for this fix in baselayout-1, and my machine's swap is still poorly secured. ;) ChangeLog indicates all the release activity has been focused on baselayout-2. :(
And we have rc versions in portage - nothing stopping you from installing it.
(In reply to comment #33) > And we have rc versions in portage - nothing stopping you from installing it. Upgrading to baselayout-2 at this point would be too risky. I'll wait a few months until most of the kinks are worked out. Couldn't you guys just roll a new baselayout-1 release? May was the last, and I see several improvements other than this bugfix have been committed since then.
This is a security issue so it's far past time that baselayout-1 was pushed with the committed fixes. There are certainly valid reasons not to release a security-related fix that's been sitting in SVN for weeks. Not having the time because you're focusing on a successor project is one (you're free to do with your dev time as you wish), but using that as a cover for deliberately withholding the fix so as to passively force users to test the successor (which is still a toy, not a viable substitute for the original) is simply wrong, especially when those users' production boxes are at stake. What reasons do you claim, Roy? It would probably not take much longer than 2 minutes to roll a new baselayout-1 release and end this longstanding bug for *all* users, not just those currently willing to migrate to baselayout-2.
Resolved fixed? I'm using baselayout-2 and the issue is still there. I don't see how changing urandom_seed path can resolve this bug ... /etc/init.d/urandom still depends on localmount ... I'm using initrd for dmraid.
