Hi RS,
On Thu, Oct 05, 2017 at 05:20:21AM -0700, ringsignature@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.
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.
What are the system requirements for OpenBSC with regard to a hardware rng or manual seeding?
We don't publish hardware requirements.
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.
Does OpenBSC store random seed data between boots?
Not our code. That's a task of the OS, no?
Regards, Harald