Hi,
I've just tested code I started at 26c3 but didn't get a chance to test and I updated my various branches.
Here's a little status :
sylvain/rrlp : This contains only changes to rrlp-ephemeris. Mostly fixes and more support to provide assistance data. Also asn1c patches to fix bugs and a script for people to generate their own test data.ubx from their receiver (to get up-to-date / local data).
sylvain/pending: Various things / fixes I made that I consider ready to be reviewed / merged. I tested it all on both my nanoBTS 139.
sylvain/encryption: The current state of my encryption support work. I rebased it and used the db structure you pushed for encryption. Everything but the last 3 patches are pre-work / preparation / fixes and are imho OK. The last 3 patches are the real implementation and I also think they're in pretty good shape. Tested and working here :) Limitations includes : No Kc re-use & No MT encryption yet.
sylvain/encryption_testing: More encryption work, based on sylvain/encryption but not done/ready. Only pushed so that people can have a peek ...
Cheers,
Sylvain
Hi Sylvain,
thanks again for all your work.
On Sun, Jan 03, 2010 at 12:27:04AM +0100, Sylvain Munaut wrote:
sylvain/rrlp : This contains only changes to rrlp-ephemeris. Mostly fixes and more support to provide assistance data. Also asn1c patches to fix bugs and a script for people to generate their own test data.ubx from their receiver (to get up-to-date / local data).
sylvain/pending: Various things / fixes I made that I consider ready to be reviewed / merged. I tested it all on both my nanoBTS 139.
Thanks, I've cherry-picked all I could right now.
I'll have to test the software activation related changes with my nanoBTS's and with the BS-11. I expect to do this later today.
As for the ebab9a9e (Differentiate paging success), I think this code needs to update 04_11.c and silent_call.c as well, i.e. all locations where PAGING_SUCCEEDED is is currently used.
sylvain/encryption: The current state of my encryption support work. I rebased it and used the db structure you pushed for encryption. Everything but the last 3 patches are pre-work / preparation / fixes and are imho OK. The last 3 patches are the real implementation and I also think they're in pretty good shape. Tested and working here :) Limitations includes : No Kc re-use & No MT encryption yet.
I disagree with removing the 'id' primary key for AuthTuples and AuthKeys.
Without that id we have it very hard to remove a single authtuple from the database manually, since we would have to provide the subscriber_id and some BLOB to select only a single entry. This is why I did not merge this particular commit.
All the others (minus the last three) inside the encryption branch should have been merged now.
It would be great if you can rebase those last three commits and your encryption_testing branch on current master and continue testing.
Regards,
Hi,
Thanks, I've cherry-picked all I could right now.
I'll have to test the software activation related changes with my nanoBTS's and with the BS-11. I expect to do this later today.
Great !
What about the rrlp branch ? They are only changes to rrlp-ephemeris and the .gitignore patch is especially useful to ignore the output of asn1c (without that git detects thousands of new files if you have built it :)
As for the ebab9a9e (Differentiate paging success), I think this code needs to update 04_11.c and silent_call.c as well, i.e. all locations where PAGING_SUCCEEDED is is currently used.
Mmm, I don't understand what you mean here.
in 04_11 & silent call, it's not the signal dispatch that's used but the call back specified when making the paging request. The advantage of the call back is that you can give contextual information and it's only called for that specific
It's true that for sms, we could just check every time a paging succeed if there are pending SMS ... But for silent_call & 04_08 MT calls I think the call back need to stay.
sylvain/encryption: The current state of my encryption support work. I rebased it and used the db structure you pushed for encryption.
Everything
but the last 3 patches are pre-work / preparation / fixes and are imho
OK.
The last 3 patches are the real implementation and I also think they're
in
pretty good shape. Tested and working here :) Limitations includes : No
Kc
re-use & No MT encryption yet.
I disagree with removing the 'id' primary key for AuthTuples and AuthKeys.
Without that id we have it very hard to remove a single authtuple from the database manually, since we would have to provide the subscriber_id and some BLOB to select only a single entry. This is why I did not merge this particular commit.
? In both table, you have :
subscriber_id NUMERIC UNIQUE NOT NULL,
since there is a UNIQUE, there can't be two entries for the same subscriber and so you can just delete by specifying the subscriber_id.
All the others (minus the last three) inside the encryption branch should have been merged now.
It would be great if you can rebase those last three commits and your encryption_testing branch on current master and continue testing.
Sure.
Cheers,
Sylvain
Hi Sylvain,
On Sun, Jan 03, 2010 at 11:22:25AM +0100, Sylvain Munaut wrote:
I'll have to test the software activation related changes with my nanoBTS's and with the BS-11. I expect to do this later today.
this still hasn't happened, I suppose I'll get around doing it today.
What about the rrlp branch ? They are only changes to rrlp-ephemeris and the .gitignore patch is especially useful to ignore the output of asn1c (without that git detects thousands of new files if you have built it :)
I have merged it right now. Feel free to commit directly to the master branch as long as you only touch rrlp-ephemeris code. After all, it's your code!
I just didn't want direct commit's to openbsc in the master branch. Thanks.
As for the ebab9a9e (Differentiate paging success), I think this code needs to update 04_11.c and silent_call.c as well, i.e. all locations where PAGING_SUCCEEDED is is currently used.
Mmm, I don't understand what you mean here.
It was my misunderstanding, sorry. I've applied it now.
I disagree with removing the 'id' primary key for AuthTuples and AuthKeys.
Without that id we have it very hard to remove a single authtuple from the database manually, since we would have to provide the subscriber_id and some BLOB to select only a single entry. This is why I did not merge this particular commit.
? In both table, you have :
subscriber_id NUMERIC UNIQUE NOT NULL,
since there is a UNIQUE, there can't be two entries for the same subscriber and so you can just delete by specifying the subscriber_id.
That's wrong then. subscriber_id should be unique for AuthInfo, but not for AuthTuples. We can (and should!) have multiple auth tuples for a subscriber and also think of a way how we can cycle through them (or randomly select one of them each time we need one)
Also, if subscriber_id is UNIQUE in AuthInfo, then we can remove the id there, like you proposed.
Hi,
That's wrong then. subscriber_id should be unique for AuthInfo, but not for
AuthTuples. We can (and should!) have multiple auth tuples for a subscriber and also think of a way how we can cycle through them (or randomly select one of them each time we need one)
AFAIK, the phone only keeps the data from last authentication ( Kc & key_seq ). When you send a CIPHER MODE COMMAND, it will use the last negotiated one, no choice there.
The "key sequence" parameter which is given by the network during the authentication is just there so that on the next channel opening, the MS can send it (in LOC UPD REQ / PAGING RESP / CM SERV REQ) and the network can compare it to the last key_seq it emitted for this subscriber. * If they match, the network 'knows' that the last negotiated Kc is still ok (with a 1/16 chance of being wrong ...) and doesn't need a new authentication. * If they don't match, it's probably that the GSM has roamed somewhere else at some point and the Kc in the phone and in the Network don't match, so they need to renegotiate a new one.
Keeping multiple AuthTuple for a subscriber would be useless since only the last one has usable data. And it's even easier if we only keep one because this way, to find the next "key sequence", we can just take the old stored one and increment it ...
Sylvain
Hi Sylvain,
On Thu, Jan 07, 2010 at 02:22:58PM +0100, Sylvain Munaut wrote:
AFAIK, the phone only keeps the data from last authentication ( Kc & key_seq ). When you send a CIPHER MODE COMMAND, it will use the last negotiated one, no choice there.
of course. I meant you can keep multiple of them so you can select one of them before doing an AUTH COMMAND
Keeping multiple AuthTuple for a subscriber would be useless since only the last one has usable data. And it's even easier if we only keep one because this way, to find the next "key sequence", we can just take the old stored one and increment it ...
The idea of the AuthTuple is as follows:
* you don't know the Ki of a SIM card * you still want to use authentication/encryption * so you send a couple of challenges to the SIM, remember the RAND and record the SRES + Kc that you get
now every time you want to authenticate that sim, you randomly select one of your known AuthTuples and send the recorded RAND, compare the SRES.
-
Harald Welte -
Sylvain Munaut