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

Tue May 21 15:29:42 EDT 2019

Am Dienstag, 21. Mai 2019, 16:55:02 CEST schrieb Petr Štetiar:

Hi Petr,

> 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)
> 
> > 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.
> 
>  * 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.

It is not correct to have a static seed file. But on the other hand, this seed 
file is intended to mix the entropy pool only. It is credited with no entropy.
> 
> > 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/bb5530e4082446aac3a3d69780cd4dbfa
> > 4520013
> 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.

The Jitter RNG is intended to be used in the environment where it is needed. 
Having multiple instances is even good for the entropy over all. Thus, I think 
using a user space copy is the right thing to do.
> 
> > 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.

Well, it survived a number of FIPS 140-2 validations and the associated 
entropy assessment requirements as well :-)
> 
> > For example this comment doesn't inspire me
> > https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4dbfa
> > 4520013#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)

The issue is that the Jitter RNG rests on the presence of a high-resolution 
timer.

The Jitter RNG implements a startup test that is intended to detect non-
appropriate timers. If it identifies such non-appropriate timers, the Jitter 
RNG will deactivate. Thus, the Jitter RNG always tries to reach a secure 
state.

The comment refers to the fact that I am looking for a high-resolution timer 
on all systems. On MIPS on one system I had some issues and the Jitter RNG 
deactivated.

Thus, take the comment simply as the search for the right source to ensure the 
Jitter RNG is enabled.
> 
> 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/dri
> vers/char/random.c#n231 3.
> http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html (Section F.)
> 
> -- ynezz

Ciao
Stephan

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