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

Sat May 25 06:43:25 EDT 2019

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

>
> > 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/bb5530e4082446aac3a3d69780cd4dbfa4520013
>
> 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 ?

Regards
Etienne

>
> > I haven't had time to read all the papers from Stephan Muller, but I
> > don't know how safe & tested Jitter RNG is on ALL architectures
>
> I've based urngd on Jitter NPTRNG simply because Stephan did amazing work with
> testing[3] and analysis of embedded CPUs as well. I couldn't say the same
> about other solutions I've considered, like haveged for example. Bonus points
> for being in the kernel since 2015, which makes me quite confident, that it
> should work somehow on everything kernel runs on.
>
> > For example this comment doesn't inspire me
> > https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4dbfa4520013#diff-8e0798e05c8dca3aa9007504c87cee73R125
> > > If random_get_entropy does not return a value (which is possible on,
> > > for example, MIPS), invoke __getnstimeofday
> > > hoping that there are timers we can work with.
>
>  (That's exactly why I took the liberty and added Stephan to the Cc: list of this
>   email, so he could provide his input on this matters or other matters)
>
> To me it just shows, that the implementation isn't naive and went through some
> rounds of testing which apparently spotted some corner cases on some CPUs,
> like for example this one:
>
>     F.31 MIPS 4KEc V4.8 (T-Com Speedport W701V)
>
>     ...
>
>     Figure 120
>
>     ...
>
>     the Shannon Entropy concludes that the CPU execution time jitter on this CPU
>     is too small. The reason for that is the coarse counter which increments in
>     multiples of 1,000.
>
> --> However, the good news is that on this CPU, the jent_entropy_init(3) call
>     would fail, informing the caller about to not use the CPU Jitter random number
>     generator.
>
> So urngd with Jitter NPTRNG should hopefully provide good enough entropy or
> none at all.
>
> 1. https://patchwork.ozlabs.org/patch/1056981/#2113014
> 2. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n231
> 3. http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html (Section F.)
>
> -- ynezz

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