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