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/baseband-devel@lists.osmocom.org/.
Sébastien Lorquet squalyl at gmail.comHi, thank you all for this valuable input. Sylvain, if I evolve your algorithm, then I think we don't need to store anything in EEPROM. Just keep that in RAM and force a renegociation at MS boot. What do you think of that? Sebastien On Mon, Mar 15, 2010 at 11:29 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > I'm also reading the TS 11.11 spec and noticed the EF.Kc file > (/7F20/6F20). > > It is named "high activity" file. How high is this activity related to > other > > files? Should it require wear leveling? I can do that using a log > structure, > > if required. If this information is not required to be persistent, I can > > implement volatile files using RAM instead of EEPROM. > > > > However, I known nothing to the GSM protocol and don't understand why the > Kc > > must be saved. This value is generated from the RUN GSM ALGORITHM > command, > > isn't it? According to the spec, is the ME supposed to backup the last > > computed key or something like that? > > Yes you're supposed to store the last Kc (along with the key_sleq) and > other information stored as LOCI (LAC/ARFCN/... of the last cell). > Basically to avoid having to establish a new session key for each > call/exchange, the network can tell the ME to 'use the last session > key', and obviously that means that the session key should be known > ... > > The sequence is as follow : > - MS send last known key_seq to BTS > - BTS compares if that key_seq == last key_seq it has in its database > - If they match -> Don't establish a new session and tell MS to reuse > the last_kc > - If they don't match -> Need a new Kc, negotiate a new one. > > key_seq is 0...15 so if you just make up one, there is a 15/16 chances > that you'll make a new Kc and never need the old one. > So what you could do is : > - store the key_seq,kc in RAM only. > - store in EEPROM a random key_seq that you _know_ isn't the one in RAM. > - If at some point you get assigned a key with the key_seq that you > have in EEPROM, then write the EEPROM and change it. > - At card boot, copy the eprom key_seq -> RAM (with NUL Kc, doesn't > matter) and choose a new key_seq to store in EEPROM. > > This way, you're pretty sure that : > - While the card is ON, the key_seq and Kc couple match the one of > the network and all works fine > - When the card is rebooted, you have a key_seq where you're quite > sure that is _NOT_ the good one and therefore the network will force > renegotiation and it doesn't matter you don't have the last Kc. > > > However, I cannot find a file for the famous "cannot be read" Ki used as > > input to the RUN GSM ALG command. Is this key not stored in a SIM file? > Not > > documented in the spec? I think I will do that even if not specified. > > There is no file for Ki ... it's not supposed to be writable or > readable or anything so no need to specify one. The only way to access > it is through RUN GSM ALGORITHM. > > > At page 36 I can read about the Run Gsm alg command: > > This function is used during the procedure for authenticating the SIM to > a > > GSM network and to calculate a cipher key. > > The card runs the specified algorithms A3 and A8 using a 16 byte random > > number and the subscriber authentication key > > Ki, which is stored in the SIM. > > > > "stored in the SIM" means nothing special, so what's not forbidden is > > allowed. Ki will be in a file too. Does someone see a problem with this? > > Nope, that's the way most programmable SIM do it, they have a file > storing Ki that's sometimes read/write, sometimes write only (and CHV1 > protected of course). > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100316/77d8fbdc/attachment.htm>