prng change feedback

historical

Hello,

On 2017-10-06 01:11, Harald Welte wrote:
> Hi RS,
> 
> On Thu, Oct 05, 2017 at 05:20:21AM -0700, ringsignature at riseup.net wrote:
>> On 2017-10-05 11:09, Neels Hofmeyr wrote:
>> > 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?
>>
>> Could you quantify that? What is the process by which an attacker would
>> be able to cause new TMSI generation? Does it require interactivity from
>> them or can they simply flood OpenBSC with a packet that triggers a the
>> creation of a TMSI? If such a flood is possible, that suggests a
>> security problem at the least and a possible entropy problem.
> 
> Well, it probably depends on the interface the attacker has access to
> (Radio/Backhaul/...) and hence the threat model.
> 
> A TMSI is allocated at many possible transactions, but all of them
> [should, in a sane implementation!] require authentication first, so it
> requires interactivity and is not just a simple flood.
> 

That is reasonable. I wonder how much entropy that entire process start
to finish will use in any given authentication process? That's I
suppose, a GSM (and other related protocols) research question rather
than an OpenBSC specific question.

>> How much random data does OpenBSC currently use in a given period of
>> time, say one day?
> 
> I think for all practical installations outside of an attack scenario
> that we know of, it's very little.

That is what I'd expect - I'd also expect in the cases where it is used,
it is probably a contributory process with inputs from all communicating
peers.

> 
>> What are the system requirements for OpenBSC with regard to a hardware
>> rng or manual seeding?
> 
> We don't publish hardware requirements.

If I may humbly suggest, it may be worth suggesting that users ensure
that it is their responsibility to have a good RNG source for the Linux
kernel. There are probably a few situations where entropy failure is
catastrophic. The generation of K_i seems to be an obvious failure,
though there are probably other interesting failures where a badly
behaving handset might be able to force the the network side to compute
over a value that is unsafe in some manner. Again, some research which
is out of scope but hopefully helpful to someone reading along...

> 
>> Does OpenBSC only run on Linux or BSD systems with the getrandom()
>> interface?
> 
> We don't officially support or build test on anything but Ubuntu >=
> 16.04, Debian >= 8 and FreeBSD >= 10.3.  We of course don't know what
> people decide to run the code on, in the end.

There is a python issue [0] which explains in detail many choices that
the python project has made and why with regard to supporting os.random.
There is also an excellent "Entropy-supplying system calls" overview
page on Wikipedia [1] that is worth reviewing.

On my Debian stable machine, my glibc does not appear to have
getrandom() while my kernel does have the syscall for getrandom(). On
FreeBSD to test if the machine is properly seeded one may check the
kern.random.sys.seeded sysctl and then subsequent calls to [2]
read_random() or read_random_uio() [3] may be functionally similar.
FreeBSD appears to define those functions such that if there isn't a
DEV_RANDOM, the functions simply return 0. It appears OpenBSD supplies a
getentropy() function on their system.

getentropy() is documented on Debian as a wrapper around getrandom():

  DESCRIPTION
       The  getentropy() function writes length bytes of high-quality
random data to the buffer starting at the loca‐
       tion pointed to by buffer.  The maximum permitted value for the
length argument is 256.

       A successful call to getentropy() always returns the requested
number of bytes of entropy.

It may make sense as a matter of portability to first look for the
syscall for getrandom(), getrandom(), getentropy(), and finally a
compile failure, in that order? I'm not sure, though whatever is
selected should be logged.

> 
>> Does OpenBSC store random seed data between boots?
> 
> Not our code.  That's a task of the OS, no?

I know that modern systems are supposed to handle this functionality. It
should be a task taken care of by the OS, of course. I believe both
officially supported platforms do handle this exact issue which is
reasonable.

Happy Hacking,
RS

[0] https://bugs.python.org/issue27266
[1] https://en.wikipedia.org/wiki/Entropy-supplying_system_calls
[2] https://svnweb.freebsd.org/base?view=revision&revision=286839
[3]
https://svnweb.freebsd.org/base/head/sys/sys/random.h?view=markup&pathrev=286839