RE: OpenBSC Digest, Vol 35, Issue 30

-- - Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 2 Date: Thu, 28 Sep 2017 07:15:01 +0800 From: Harald Welte laforge@gnumonks.org To: Neels Hofmeyr nhofmeyr@sysmocom.de Cc: openbsc@lists.osmocom.org Subject: Re: randomness of identifiers Message-ID: 20170927231501.zyqrali3onodi4iw@nataraja Content-Type: text/plain; charset=us-ascii 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@gnumonks.org http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 3 Date: Thu, 28 Sep 2017 06:52:28 +0800 From: Harald Welte laforge@gnumonks.org To: Kathryn Heckman exuberant.kathryn.heckman@gmail.com Cc: "openbsc@lists.osmocom.org" openbsc@lists.osmocom.org Subject: Re: Retrieve OP from OPc and Ki Message-ID: 20170927225228.u4udbuhk2fyebrl5@nataraja Content-Type: text/plain; charset=us-ascii Hi Kathryn, On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote: > Is there any way to retrieve the value of OP from OPc and Ki? No, that defeats the entire purpose of having card-individual OPc values. If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether. Regards, Harald -- - Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 4 Date: Thu, 28 Sep 2017 06:50:03 +0800 From: Harald Welte laforge@gnumonks.org To: Neels Hofmeyr nhofmeyr@sysmocom.de Cc: Holger Freyther holger@freyther.de, openbsc@lists.osmocom.org Subject: Re: ctrl interface: GET a variable with parameter Message-ID: 20170927225003.ix4qgulake4gugyu@nataraja Content-Type: text/plain; charset="us-ascii" Hi Neels, On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote: > Also we do have a concept of nesting CTRL nodes separated by dots in > the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup(). correct. > I notice though that we do still have open doors for a lot of nonsense > being sent to it without proper validation or error messages. > > GET 42 existing-variable.trailing.names.ignored more nonsense > following being ignored > > in effect is identical to: > > GET 42 existing-variable > > So we should probably enforce that there is no ignored nonsense... I agree. > Should we also enforce a numeric command ID? I'm not following here. Where would that numeric command ID comning from? > GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command this is also not intended, I'm quite sure. > Going back to the OsmoHLR CTRL commands -- they are implemented in a > way that doesn't match the CTRL interface ways. Let's collapse them. > > SET enable-ps <IMSI> > SET disable-ps <IMSI> > SET status-ps <IMSI> indeed, this is not proper. > SET subscriber.by-imsi.123456789098765.ps-enabled 1 > SET subscriber.by-imsi.123456789098765.ps-enabled 0 > GET subscriber.by-imsi.123456789098765.ps-enabled makes a lot of sense to me. > We can also expand this later to things like > > GET subscriber.by-imsi.123456789098765.status > SET subscriber.by-imsi.123456789098765.msisdn 2345 > GET subscriber.by-msisdn.2342.status > SET subscriber.by-msisdn.2342.ps-enabled 0 > GET subscriber.by-imei.987654321234565.imsi looks good! > We could leave the enable-ps, disable-ps, status-ps commands in place > in case anyone is using it yet. I assume no-one is though. I don't think we need to keep compatibility at this point. -- - Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)