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