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 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.
>
I hope my pointers are helpful to you in the future.
> 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.
>
Starting is not the same as handling connections. I don't believe
when dropbear is started has any bearing outside of automatically
generated hostkeys, which sounds like that's not applicable here.
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.
> Regards Lukas
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQIcBAEBAgAGBQJRGscGAAoJEOPRqa2O3KuKwicQAMfZfS9Wg2K4vW+XB9mV7ClN
FoQ5udI/Nd+jros4+eTXU5KwusAd6mZ4dpnuDh+okaypkIhWVDDVDB3Ne010+wgX
+U+tMxyqUn9m9FgPesxGinNLRK/AQQ+jWLTEgLzVhGLwHfX1bTEUV4uAgWJcjAUb
9OL26PQKIPfmTe8j4LsnKlDySlILwkRdhLqgW0MdE+gU+Cb0jhbEgqWdpxVWy51L
vu/yhupJ/g9PG5MLgHb3HaLluAUChvw9psxLFwEXze20X4SG1R0vTLDE2uY+Uh8c
QDx86DM0uWGVVQkcpK3AfFLMfLM0C/gD6gIQUVqYxFwnBpGUzAfzyL7YRSk5MLsS
GDA/hZbjKyHIpTPXu9lW5IvIzhxJ37i/0+M+AR3V4MpJDWP1N/GftWRSuiwaHXV6
UgUpAVvyINe21Ovz1R/ZNYpJVtIlq7VTqUZc5p8eS2SvgFWA4PkBjiX0Cj1Pbw08
jcHr6oHPZLEb+JP+m3xnaPVguOmnj0r8iU8RWxkEXmKptapeYoAwExkzfu9tLn0t
bNIZy6gLzm19x+xdnE8rrHtElJcfAjll6q/CXxGx+IViyE4wGA53gPjWPkJDw4Nm
9MTufcjSac+GrUj7uWeXDpWUr9NbN4/KG7/XlC8b7k33azA24tX0pOG0IP1PAGLX
w7e+htWzpNeLaY1AIeEB
=0Gkx
-----END PGP SIGNATURE-----
Reply to: