randomness of identifiers

historical

Dear all,

Max has been pushing https://gerrit.osmocom.org/#/c/1526 for quite some
time, but there was still no conclusion in its review.

I guess after more than 8 months in limbo, it's about time we decide how
to move ahead with this.

In general, we *want* secure/safe identifiers like TMSIs that are not
easy to predict by an attacker.  Using rand() or some other
pseudo-random generator with a predictible seed like the time of the
process start is probably not the best choice here.

Using the rather strong entropy pool of /dev/urandom or getrandom()
is apparently not a good choice either: We can exhaust the entropy pool
at whch point we would have to  block/wait, which we of course cannot in
our architecture.

So what do we do?  I think we first have to differentiate on the type of
randomness needed.  Is it a random identifier like TMSI? Is it a random
challenge used in cryptographic authentication?  Is it random data used
for a key?  Those require different levels of randomness.

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?

For random challenges in authentiation I would probably go for
direct use of urandom / getrandom().  If the entropy is exhausted, the
quality of the random numbers will get lower, but getrandom() will
always return up t 256 bytes.

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 do you guys think?  Is there somebody on this list more
cryptographically qualified to give us proper guidance?  If you know
somebody skilled who might want to help but is not on this list, would
you invite them to join this discussion?

-- 
- 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)