[Toybox] You've seen the /dev/random shenanigans, right?

[Pete Bentley]

> +Pete Bentley as the other person who might be interested in this stuff.
(because of prng_seeder, which is what boringssl-based stuff uses, but
which might also care about us not calling the ioctl()?)

I don't think we care, anything using libcrypto (including Toybox) on
Android should be largely insulated from any urandom quirks.

libcrypto only draws entropy to seed an internal NIST approved DRBG, one
per thread, each of which is re-seeded every 'n' draws (I don't remember
'n' offhand).

If the device has a working /dev/hw_random then prng_seeder will be running
and client libcrypto processes get their seeding data from it.  prng_seeder
reads and conditions data from /dev/hw_random and uses that to seed its own
internal DRBG every 'n' draws.

If prng_seeder is not running then libcrypto gets its seeding data via
getrandom() from the urandom source, and will block until the entropy pool
is initialised. (Which is why we needed to move boringssl_self_test later
in init in order to prevent boot delays on low end devices with no
hw_random).

So I think our only concern here is if the device has no hw_random and can
somehow end up initialising urandom deterministically.



On Wed, 20 Sept 2023 at 12:16, Rob Landley <rob at landley.net> wrote:

> On 9/19/23 14:44, enh wrote:
> >> And I just noticed because somebody mentioned Android involvement. (I
> still try
> >> to check that mailing list twice/month for anything of obvious
> interest.)
> >>
> >> http://lists.busybox.net/pipermail/busybox/2023-September/090471.html
> >
> > (i think they were just talking about the busybox-for-android
> configuration?)
>
> I dunno what's AOSP and what's vendor mods off the top of my head. :)
>
> >> Might not matter on systems with a hardware random number generator
> with a
> >> kernel driver hooked up to it, but it breaks the embedded world. (Then
> again the
> >> embedded linux projects I've seen recently have been reverting _back_
> to the 2.6
> >> kernel...)
> >
> > yeah, our high- and mid-end devices usually have a hw rng, but the
> > lowest of the low-end devices don't even necessarily have an rtc that
> > survives reboots. (i've definitely helped weaken CTS tests a few times
> > to allow this kind of thing.)
>
> That last board I banged on in that category was pre-pandemic, but the
> solution
> at the time involved:
>
> A) ifconfig -a > /dev/random in the boot scripts to get the mac addresses
> in
> there so it was at least per-board unique. (No, the kernel driver didn't
> do this.)
>
> B) dd-ing 32 bytes of random data into flash and back between boots,
>
> C) Never use /dev/random, use /dev/urandom to avoid blocking because "I'll
> use
> your data but it doesn't COUNT" did not, in fact, help.
>
> The result produced different keys each board and each boot, which was the
> proximate goal. (We were just trying to 80/20 the paranoia: state actors
> would
> just rip them out and strap extra hardware on or do something clever with
> a yagi
> antenna.)
>
> > A more insidious problem, perhaps, is that a seed written to the RNG
> > before it initializes will not actually be used until after the pool
> > is initialized properly; "you might write in a perfectly good seed to
> > /dev/urandom, but what you read out for the subsequent seed may be
> > complete deterministic crap", Donenfeld said. The data that gets
>
> That's the annoying bit. Even with the above boot dance, your initial
> session
> keys are then crap during the wake-up call.
>
> I don't claim to be an expert here, I'm just going "oh goddess, they're
> kicking
> THIS anthill again..."
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20230920/ee38e624/attachment-0001.htm>