[OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter

[Stephan Müller]

Am Samstag, 25. Mai 2019, 12:43:25 CEST schrieb Etienne Champetier:

Hi Etienne,

> Hi Petr,
> 
> Just to be clear i'm 100% in favor of your effort to have random pool
> init done fast on all devices,
> and your solution, based on Stephan awsome work, seems really good
> I just want to be sure we don't make some devices worse / are not
> missing something
> 
> Le mar. 21 mai 2019 à 16:55, Petr Štetiar <ynezz at true.cz> a écrit :
> > Etienne Champetier <champetier.etienne at gmail.com> [2019-05-21 14:55:42]:
> > 
> > Hi,
> > 
> > > > First, simply writing to /dev/urandom does not increase the kernel's
> > > > entropy count, this casuses processes obtaining randomness to block.
> > > > Particularly processes using OpenSSL's RAND_bytes() will block until
> > > > the
> > > > kernel emits 'random: crng init done'. This can take upwards of twenty
> > > > minutes.
> > > 
> > > 20 minutes seems excessive, isn't one of the process blocking boot ?
> > 
> > please note, that this is time as measured by kernel (I know it's
> > userspace
> > starving the kernel entropy pool, but still). I've personally measured 18
> > minutes on my Apalis board (imx6)[1].
> > 
> >  i.mx6 (Freescale i.MX6 Quad/DualLite)
> >  
> >   [    3.281637] random: fast init done
> >   [ 1120.394672] random: crng init done (yeah, 18 minutes)
> 
> I'm not saying it's not happening, I'm wondering if the boot process
> is not blocked early by a process stuck on getrandom()
> and then nothing runs on router so no entropy is produced, so the
> process continue to be stuck

Well, some libraries still use /dev/urandom and are not blocked. Besides, if 
you use systemd that initializes the system, it uses /dev/urandom. Compile 
your kernels with CONFIG_WARN_ALL_UNSEEDED_RANDOM, you will see kernel reports 
which processes seed from /dev/urandom even while it is not fully provided 
with entropy.
> 
> > > One of the issue is that if you try to generate a new seed, you are
> > > just reading a hash of the seed you injected seconds earlier with
> > > maybe few new bits of entropy
> > 
> > Exactly, that's why it's recommended[2] to save it during EVERY shutdown,
> > so it's different EVERY boot.
> 
> I know and I'm in favour of it, but proper shutdown is not always a
> thing on router, that is why I went with getrandom() at the time
> 
> >  * Ensuring unpredictability at system startup
> >  * ============================================
> >  *
> >  * When any operating system starts up, it will go through a sequence
> >  * of actions that are fairly predictable by an adversary, especially
> >  * if the start-up does not involve interaction with a human operator.
> >  * This reduces the actual number of bits of unpredictability in the
> >  * entropy pool below the value in entropy_count.  In order to
> >  * counteract this effect, it helps to carry information in the
> >  * entropy pool across shut-downs and start-ups.
> >  
> >  [...]
> >  
> >  * Even with complete knowledge of the start-up activities, predicting the
> >  * state of the entropy pool requires knowledge of the previous history of
> >  the * system.
> > 
> > We're making it easier for the potential adversary, aren't we? We're
> > currently feeding static urandom.seed file (generated during first boot)
> > to kernel every other boot, in some cases it might result in the same
> > file for the lifetime of the device. I really miss any randomness in
> > this.
> 
> Starting on second boot, we are sure each router state is different,
> but each boot are pretty similar I agree
> 
> > > Just for the record, this is the default setting,
> > 
> > I know, that's why I'm proposing removal from the default ath79 images,
> > because I think, that it's wrong. Should the user ever need urandom-seed,
> > then it's just one opkg install away.
> > 
> > > you can change your config to generate a new one at each boot
> > 
> > I know, but who does it? I expect best possible secure configuration by
> > default.
> > 
> > > (the worry was that we would wear off the flash too fast)
> > 
> > I understand the drawbacks, that's why I think, that it doesn't make much
> > sense to use it, if it's not good enough to be used in default/shipped
> > configuration.
> > 
> > > why not use jitterentropy RNG that is in kernel since 4.2 ?
> > > https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4db
> > > fa4520013> 
> > I started experiments with kmod-crypto-rng package which already contains
> > jitterentropy, drbg, krng and rng kernel modules, but it didn't improved
> > the long booting times for me on ath79.  Other reason was size of this
> > kernel module(s) as they provide much more functionality of course.
> 
> I think before anyone merge this (I'm not a core dev), we need to
> explain why your user space version and the kernel module version
> behave differently
> Is the kernel module underestimating entropy ? Is you user space
> version over estimating entropy ?

Again, the in kernel version is *only* used for seeding the in-kernel DRBG 
(unfortunately). This DRBG and the in-kernel Jitter RNG has no relationship 
with /dev/random or /dev/urandom or getrandom. You could call the in-kernel 
DRBG with AF_ALG like libkcapi allows you to do [1].

If you are interested, I wrote a complete replacement implementation of the 
current /dev/random or /dev/urandom available at [2]. It uses the in-kernel 
Jitter RNG, it has pluggable PRNGs and other logic relevant for, say, FIPS 
140-2. This implementation would not require you to have your separate user 
space entropy daemon that is discussed here. Yet, this code was rejected.

[1] http://www.chronox.de/libkcapi.html

[2] http://www.chronox.de/lrng.html

Ciao
Stephan



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel