From: Alexander Dahl
> Sent: 02 May 2022 06:15
>
> Am Sat, Apr 30, 2022 at 03:12:11PM +0200 schrieb Denys Vlasenko:
> > Do you often pull power cords from machines you use for
> > somewhat important crypto operations, such as generating keys?
> > What are the chances that you also do it on a machine without RTC
> > clock (which would otherwise supply randomness
> > from the current time)?
>
> FWIW … busybox is often used in embedded systems, and from my personal
> 10y+ experience in that field, I can safely assure you: customers and
> users pull power chords all the time and at absolutely unpredictable
> times. Don't know if that's a real threat from a security point of
> view, but only looking at what developers do is not giving you the
> full picture.
The start of boot sequence is usually 'safe'.
Nothing external is likely to have access until towards the
end of it.
Someone with physical access can pull the power - but they
can do all sorts of other things as well.
The 'problem' is that systems with limited 'entropy' sources
need to carry over some 'randomness' between boots.
So you actually need to be updating the saved 'randomness'
every so often during normal running.
This is entirely different from initialising the PRNG
which should only be done one at boot time.
Now ideally the kernel would always 'stir' new entropy
into whatever it had before - so even giving is a few kb
of zeros wouldn't make things worse. But I suspect that
hasn't been the case.
Anyway while changing the saved randomness after loading
the PRNG is needed in case the power is cut not long after
the init scripts complete, it is much more useful to save
it at the end of the scripts (eg as an S99 script) when
there is a chance that some additional entropy has been
accrued.
Mild paranoia might be required when writing a normal file.
Although I suspect the safest is just to open the existing
file without O_TRUNC and rewrite exactly the same number of
bytes.
But what you really want to write is (probably) a
combination of the old saved value, the kernel entropy pool
and the kernel PRNG state.
(The latter two being hashes.)
But you need to do this without reloading the PRNG from the
entropy pool or feeding the old saved state into the entropy
pool.
I don't see how seedrng helps this operation, nor whether
the kernel code really lets it get suitable information.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
