This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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. > 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 at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)