Re: dropbear delayed startup
Hi, On 12.02.2013 23:49, Mike Mestnik wrote: As indicated, this happens after the connection and thus there can be plenty of entropy even in the daemon is started when there is not. You can even create or push entropy by pinging the host at irregular intervals or a verity of other activities. You can have the initrd hit random.org a few times. I don't doubt that there can be enough entropy. I still want to make sure there actually is enough. A really good solution can be employed if you have an HA setup, once past the point of loading the stored entropy, urandom can be securely served out to the other node over a local network or serial connection. Agreed, but this is more complicated than just restoring a seed-file. I'm not sure that having static entropy in an initrd would be good either. You wouldn't gain entropy, only randomness. I'd be concerned about using the same initrd image for more then 100 times or so. You could regenerate the initrd though, but this starts to fall into the category of custom solutions. A static seed is useless, I know that much. Regenerating the initrd is not necessary, as a second cpio archive containing the seedfile can just be appended to the original initrd archive (see http://www.kernel.org/doc/Documentation/early-userspace/buffer-format.txt). Some bootloaders even support the handing of multiple archive files as initrd (sys/extlinux for some time, grub from version 2.00). entropy_avail has to do with the number of bytes one can read from random. Values read from urandom are based off a 1k seed, knowing how much this seed has ever been populated is not exported nor is the number of times the current seed has been given out to users. I've been reading parts of drivers/char/random.c and I haven't seen what you are saying. Can you point me to your source? From my understanding entropy is collected in the input_pool and from there distributed to both the blocking and the nonblocking_pool (in a way that won't allow one to stave the other). entropy_avail gives an entropy estimation for the input_pool and is, thus, also important for urandom. Only a dropbear developer would be able to insist that urandom is only used when appropriate. Only you can prevent the re-generation of ssh host keys. dropbear is especially targetted for embedded devices. I assume that gathering enough randomness from /dev/random is especially hard for those devices. The dropbear changelog (https://matt.ucc.asn.au/dropbear/CHANGES) contains an entry regarding the switch from /dev/random to /dev/urandom at version 0.50: - Use /dev/urandom by default, since that's what everyone does anyway This is where the need for the kernel to export information on the viability of urandom would come into play. For example dropbear could kick out new connections if there was not yet enough seed data, after a few attempts there would be. Integrating mechanisms that will allow dropbear to check if enough entropy is available (and else trying to generate some) might be possible. However, I like to resort to well-known methods of ensuring good randomness. Restoring a seed-file and then using urandom fulfills that requirement. Since startup the system is constantly collecting entropy, network traffic sounds like the biggest source of entropy for your configuration. If this host is on a segment with a handful of windows machines then waiting a minute or two should generate more then enough entropy. I agree that waiting some time should solve the problem. However there is no way for me to know when enough time has passed and opening a connection is secure. Regards Lukas signature.asc Description: OpenPGP digital signature
dropbear delayed startup
Hi, I started using remote unlocking of encrypted filesystems within the initramdisk (as provided by the cryptsetup/dropbear packets) some time ago. However I am worried because of the potentially low entropy during the execution of the initramfs and dropbear using /dev/urandom as a source for randomness. /usr/share/doc/cryptsetup/README.remote.gz from my installed cryptsetup (2:1.4.3-4) states in the Issues section, that the ssh daemon (dropbear) might be delayed until enough entropy has been retrieved. I couldn't find any other references of dropbear delaying startup due to low entropy. In the dropbear code I could only find graceful handling of a blocking random source but no builtin delay mechanism. Can anyone confirm that dropbear does delay startup if the kernel is low on entropy? Thanks Lukas signature.asc Description: OpenPGP digital signature
Re: dropbear delayed startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lukas, cryptsetup does not encrypted filesystems, so you must be mistaken if you believe that you are remote unlocking of encrypted filesystems with cryptsetup. Be specific about your configuration, this is important in this case. Those looking for assistance are in no position to be determining what is and/or is not important. Are you perchance taking about fully encrypted systems as in: http://www.howtoforge.com/remotely-unlock-fully-encrypted-debian-squeeze What issue do you have, sounds like you are just generally concerned. You should direct concerns to the authors of the software you are concerned about, no many others would care or be in any position to answer. If you followed the above instructions it's possible that during the start of dropbear there is vary little entropy required/used until you auth over ssh. If you skipped the step where of saving host keys into your initrd, then this could be your issue as dropbear's initscripts should 'block' startup while entropy is collected. Is that the behavior you are seeing? If each startup is generating ssh host keys, that's vary bad and should be avoided. AUMK urandom is not delayed if there is no entropy available. Applications should not be looking there for entropy, that would be a bug in the application. I'm unfamiliar with a method for determining the entropy of bytes read from urandom, an interesting concept. Only a dropbear developer would be able to insist that urandom is only used when appropriate. Only you can prevent the re-generation of ssh host keys. On 02/12/13 10:55, Lukas Schwaighofer wrote: Hi, I started using remote unlocking of encrypted filesystems within the initramdisk (as provided by the cryptsetup/dropbear packets) some time ago. However I am worried because of the potentially low entropy during the execution of the initramfs and dropbear using /dev/urandom as a source for randomness. /usr/share/doc/cryptsetup/README.remote.gz from my installed cryptsetup (2:1.4.3-4) states in the Issues section, that the ssh daemon (dropbear) might be delayed until enough entropy has been retrieved. I couldn't find any other references of dropbear delaying startup due to low entropy. In the dropbear code I could only find graceful handling of a blocking random source but no builtin delay mechanism. Can anyone confirm that dropbear does delay startup if the kernel is low on entropy? Thanks Lukas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGqB8AAoJEOPRqa2O3KuK4JsP/jmboZHlnlIO4qEMvXpHVwSA 0EMWj59MSjDdMsDjOfylQoGs4f1IybxYPt/OhFM+ZWnAutchacpz7AM2nodvi7G/ TbqzHb3+YX6Ee3M4iVql7SAUBNTd4bv0xkG7tCoiZm5uaPC2UMtxajGy9q66vB49 TNp6R1MFCfU2l8ymSFMI5/IpBtkN4e+swy66rxuKl0POTw0Gh84YfElReRyJt+mM jC7zYmUJY4rmp5wSYUpTNaUfMNRnFXfWSpji4odDB48MQRumsbvOdAgl/xcGYB5Q GdPLJBY0VpzU2RBQfrl8ugyFYy935uUlmhlOn9hIkf1+hj33yzQ1o9z5Vbn6U32m YYxi2wJ3CRiPuhSi786xJZ3Z6ZQAwlt6y1G9YdbZyEwry0zT/lzkX1rkzgZfbXjC WlxBG4b+Bez3d6sbU/F4LEps5wrthy+EZazlICDFKTRYjzEWPRWPwxr4mJlgW4V2 Njb1Srjhv5h7YVDshRn/Uu4OqSO4uepV6GvrPGjhrhMSlzB3+FwRx3F2KIb1gaWW un7HmFm/WXOweeJoheTzntfqxsxD2OSHglICgR+Nr0xl9rm/GZW2zIVpD4NyoNVR tmNcoREvDiY+FwWOE4wf5rFZGGUrModFcUTv34CtSFcKd0bHogAvW/ED3Idip3l2 aD4WHj8/F0BEqo6I8qHL =xWXO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511aa082.6030...@mikemestnik.net
Re: dropbear delayed startup
Hello Mike, thanks for your answer. On 12.02.2013 21:05, Mike Mestnik wrote: cryptsetup does not encrypted filesystems, so you must be mistaken if you believe that you are remote unlocking of encrypted filesystems with cryptsetup. Be specific about your configuration, this is important in this case. Those looking for assistance are in no position to be determining what is and/or is not important. Sorry for not being clear about that. I was refering to the cryptsetup because /usr/share/initramfs-tools/scripts/local-top/cryptroot (which is part of the cryptsetup package) performs the unlocking within the initial ramdisk. Are you perchance taking about fully encrypted systems as in: http://www.howtoforge.com/remotely-unlock-fully-encrypted-debian-squeeze Yes. I have stopped talking about fully encrypted systems, because some people then assume I don't have an unencrypted boot partition (which I have). What issue do you have, sounds like you are just generally concerned. You should direct concerns to the authors of the software you are concerned about, no many others would care or be in any position to answer. Yes, I'm generally concerned on the impact of little entropy for the dropbear ssh server (if a Diffie–Hellman key exchange is performed and the secret of the low-entropy server can be guessed, the session key is compromised). The manpage of random in section 4 (man 4 random) has some recommendations about the using /dev/urandom. It states that using /dev/urandom for network encryption keys is fine after the seed file (which is saved across reboots and handled by /etc/init.d/urandom in debian) has been reloaded. This is not yet the case during execution of the initial ramdisk. I wrote a set of scripts that perform the reloading of a seed already in the initramdisk and before dropbear starts which solves my concerns. I posted to this list because I'm not sure if it's really an issue or if I'm just being overcautious. In case you agree this should be mitigated I'll happily share my work. Since my concern is specific to the integration into the initramdisk (which is not part of the upstream packages of either cryptsetup and dropbear afaik) I think this is the right place to ask. If you followed the above instructions it's possible that during the start of dropbear there is vary little entropy required/used until you auth over ssh. If you skipped the step where of saving host keys into your initrd, then this could be your issue as dropbear's initscripts should 'block' startup while entropy is collected. Is that the behavior you are seeing? If each startup is generating ssh host keys, that's vary bad and should be avoided. My host-keys are pre-generated and built into the initramdisk (this is taken care automatically by the dropbear package, at least in wheezy). The dropbear ssh server in the initramdisk is usable without any (noticable) delay, even without reapplying the seed first. AUMK urandom is not delayed if there is no entropy available. Applications should not be looking there for entropy, that would be a bug in the application. I'm unfamiliar with a method for determining the entropy of bytes read from urandom, an interesting concept. /dev/urandom is non-blocking while /dev/random is blocking. The amount of entropy currently available can be accessed using the proc-interface: # cat /proc/sys/kernel/random/entropy_avail However, I'm pretty sure dropbear does no such thing and as far as I can tell does not wait for entropy. Only a dropbear developer would be able to insist that urandom is only used when appropriate. Only you can prevent the re-generation of ssh host keys. dropbear is especially targetted for embedded devices. I assume that gathering enough randomness from /dev/random is especially hard for those devices. The dropbear changelog (https://matt.ucc.asn.au/dropbear/CHANGES) contains an entry regarding the switch from /dev/random to /dev/urandom at version 0.50: - Use /dev/urandom by default, since that's what everyone does anyway Sorry if my first E-Mail sounded like I want support for my setup (that's not the case). I wanted to get second opinions if little entropy and a running dropbear in the initramdisk is a problem. The matter seems important, because when using an encrypted root partition in wheezy, an installed dropbear package will automatically case dropbear to be started during the execution of the initramdisk. Regards Lukas signature.asc Description: OpenPGP digital signature
Re: dropbear delayed startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/12/13 15:11, Lukas Schwaighofer wrote: Hello Mike, thanks for your answer. On 12.02.2013 21:05, Mike Mestnik wrote: What issue do you have, sounds like you are just generally concerned. You should direct concerns to the authors of the software you are concerned about, no many others would care or be in any position to answer. Yes, I'm generally concerned on the impact of little entropy for the dropbear ssh server (if a Diffie–Hellman key exchange is performed and the secret of the low-entropy server can be guessed, the session key is compromised). As indicated, this happens after the connection and thus there can be plenty of entropy even in the daemon is started when there is not. You can even create or push entropy by pinging the host at irregular intervals or a verity of other activities. You can have the initrd hit random.org a few times. A really good solution can be employed if you have an HA setup, once past the point of loading the stored entropy, urandom can be securely served out to the other node over a local network or serial connection. The manpage of random in section 4 (man 4 random) has some recommendations about the using /dev/urandom. It states that using /dev/urandom for network encryption keys is fine after the seed file (which is saved across reboots and handled by /etc/init.d/urandom in debian) has been reloaded. This is not yet the case during execution of the initial ramdisk. I wrote a set of scripts that perform the reloading of a seed already in the initramdisk and before dropbear starts which solves my concerns. I posted to this list because I'm not sure if it's really an issue or if I'm just being overcautious. In case you agree this should be mitigated I'll happily share my work. Since my concern is specific to the integration into the initramdisk (which is not part of the upstream packages of either cryptsetup and dropbear afaik) I think this is the right place to ask. I'm not sure that having static entropy in an initrd would be good either. You wouldn't gain entropy, only randomness. I'd be concerned about using the same initrd image for more then 100 times or so. You could regenerate the initrd though, but this starts to fall into the category of custom solutions. If you followed the above instructions it's possible that during the start of dropbear there is vary little entropy required/used until you auth over ssh. If you skipped the step where of saving host keys into your initrd, then this could be your issue as dropbear's initscripts should 'block' startup while entropy is collected. Is that the behavior you are seeing? If each startup is generating ssh host keys, that's vary bad and should be avoided. My host-keys are pre-generated and built into the initramdisk (this is taken care automatically by the dropbear package, at least in wheezy). The dropbear ssh server in the initramdisk is usable without any (noticable) delay, even without reapplying the seed first. Unless you point out you are running testing, you may only get suggestions for stable. AUMK urandom is not delayed if there is no entropy available. Applications should not be looking there for entropy, that would be a bug in the application. I'm unfamiliar with a method for determining the entropy of bytes read from urandom, an interesting concept. /dev/urandom is non-blocking while /dev/random is blocking. The amount of entropy currently available can be accessed using the proc-interface: # cat /proc/sys/kernel/random/entropy_avail However, I'm pretty sure dropbear does no such thing and as far as I can tell does not wait for entropy. entropy_avail has to do with the number of bytes one can read from random. Values read from urandom are based off a 1k seed, knowing how much this seed has ever been populated is not exported nor is the number of times the current seed has been given out to users. An attacker with local access could conceivably read the contents of the seed as long as one could do so without triggering an event that would cause the kernel to build more entropy. Only a dropbear developer would be able to insist that urandom is only used when appropriate. Only you can prevent the re-generation of ssh host keys. dropbear is especially targetted for embedded devices. I assume that gathering enough randomness from /dev/random is especially hard for those devices. The dropbear changelog (https://matt.ucc.asn.au/dropbear/CHANGES) contains an entry regarding the switch from /dev/random to /dev/urandom at version 0.50: - Use /dev/urandom by default, since that's what everyone does anyway This is where the need for the kernel to export information on the viability of urandom would come into play. For example dropbear could kick out new connections if there was not yet enough seed data, after a few attempts there would be. Sorry if my first E-Mail
