randomness of identifiers

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.org
Wed Sep 27 23:15:01 UTC 2017


Hi Neels,

On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
> On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
> > For TMSI allocation, my "cryptographic gut feeling"[tm] is that something
> > like rand() or any other pseudo-random generator of significantly large
> > period is sufficient *if* it is seeded by a non-predictable value.  So
> > something like seeding with getrandom() result should be fine?

> Might also make sense to periodically re-seed from /dev/urandom /
> getrandom(), like every 100 TMSIs, or based on a timeout might be
> easier to implement.

I would try to avoid any predictability here.  Having a fixed time
interval would be known to an attackers.  So if he was somehow able to
reduce/exhaust the entropy at the known time for re-seeding, it would be
bad.

Similar for "every 100 TMSIs", which is something under control of any
attacker as he can control the number of location updates via the public
radio interface [to some extent] and thus control the time at whcih
re-seeding is done.

Maybe I'm going overboard here, but I think if you want to re-seed, you
want to ideally do it at a non-predictable and non-controllable point in
time.  Like a random time interval ;)

> > For long-term stable key (Ki/Op) generation for provisioning SIM cards +
> > populating a HLR, I would certainly opt for using stronger randomness
> > sources.  However, I don't think we actually implement that anywhere, do
> > we?
> 
> what does openssh use for public/private keypair generation?

I'm not sure you can compare the requirements for generation of RSA
public/private keys with those for generation of symmetric keys. You can
find different recommendations in the literature.  But I guess that's
mainly due to the fact that people usually assume you have long-term
stable public/private keys and short-lived symmetric session keys.  In
our case, it's long-lived symmetric keys.

But as indicated, I think our focus is to find a proper solution for
generation of TMSIs and for random numbers used in authentication
challenges.  K/OPc pair generation is not supported in current Osmocom
tools anyway, as we presume the SIM cards already have sufficiently
random key material and those keys are entered into the HLR.

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)



More information about the OpenBSC mailing list