Hi RS,
On Thu, Oct 05, 2017 at 05:20:21AM -0700, ringsignature(a)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
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)