prng change feedback

[Neels Hofmeyr]

Hey RS,

thanks for your excellent input on P/RNG!

There's a lot in it, let me first off sprinkle a few remarks...

On Thu, Oct 05, 2017 at 09:56:51AM +0000, ringsignature at riseup.net wrote:
> system RNG is properly seeded at boot, getrandom() should not block at
> any later point in the system's lifetime.

What about an attacker firing endless events that cause us to generate new
TMSIs and ends up exhausting the entropy pool? AFAIK that's a real possibility?

> As an aside: If for some reason there is no cryptographically secure
> hardware RNG on the OpenBSC system, one wonders if it might be of
> interest to use the available RF interfaces as part of a design for such
> an RNG. There would be concerns about adversarial control of inputs, of
> course.

It might well be possible to use RF noise as entropy, but the HLR that is
generating the RAND bytes is layers away from the BTS and its antenna. If all
run on the same small integrated box, somehow getting RF noise from the DSP and
feeding entropy to the system which in turn gets used on the other end by the
HLR is a possibility, but not really when the HLR is, as by the usual GSM
design, in a central location serving numerous cells.


Would be interesting to run a few tests on how quickly we can end up in entropy
exhaustion. Using getrandom() always would be the easiest and safest. Saying
that we prefer to be quick rather than secure sounds wrong indeed. But if we
practically block because of too little entropy, then we annoy lab / testing
setups that don't care about security, and we provide a DoS attack vector.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171005/a079a24a/attachment.bin>