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

Tue May 21 10:55:02 EDT 2019

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.

> 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 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