ki in osmo-nitb's built-in HLR db

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/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Sun Dec 25 00:38:30 UTC 2016


Merry x-mas!

Just now I found a curious problem with the current osmo-nitb ciphering key.

I'm working on the new VLR, which will inherently fix this issue, but in the
course of that I recapped the current osmo-nitb's sequence of events for 2G
ciphering as it is on the openbsc master branch.

It so happens that I'm using a SIM card with a fabricated Ki value of hex:
  000102030405060708090a0b0c0d0e0f
i.e. starting with a zero byte.

I was able to store this in and retrieve from the hlr.sqlite3 db:

  sqlite> INSERT INTO "AuthKeys" VALUES(57,2,X'000102030405060708090A0B0C0D0E0F');
  sqlite> select hex(a3a8_ki) from AuthKeys;
  000102030405060708090A0B0C0D0E0F

So there were 16 bytes worth of BLOB in the Ki column for sure.

But in openbsc's db.c in db_get_authinfo_for_subscr(), I always got

  DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=0)

Curious, could it be the zero byte? Just to check, I put the zero byte further left:

  sqlite> select hex(a3a8_ki) from AuthKeys;
  hex(a3a8_ki)
  F00102030405060008090A0B0C0D0E
  ^ nonzero     ^^ zero

Now the log says:

  DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=5) f1 f3 f4 f5 f6 

That's even weirder. I was expecting a 7 byte BLOB, of
  f0 01 02 03 04 05 06
and not
  f1 f3 f4 f5 f6
... what on earth ...

It appears that we've so far always been unable to use Ki keys that contain a
zero byte, or apparently anything that's outside the 7bit ascii space ... ?

To be able to recap what the old osmo-nitb is doing (without going to fetch a
card reader from the office and reprogram the Ki on the SIM card), I fixed this
bug with this funny little hack: https://gerrit.osmocom.org/1504

Todo: are other BLOB values also affected? Is there a better way to fix?

Even though the new VLR is on its way, it might be good to get a fix like this
out in the meantime ... though it appears that no-one is using ciphering on 2G
anyway?

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161225/1aa4849b/attachment.bin>


More information about the OpenBSC mailing list