squalyl at gmail.com
Mon Mar 15 23:09:46 UTC 2010
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?
On Mon, Mar 15, 2010 at 11:29 PM, Sylvain Munaut <246tnt at gmail.com> wrote:
> > I'm also reading the TS 11.11 spec and noticed the EF.Kc file
> > It is named "high activity" file. How high is this activity related to
> > files? Should it require wear leveling? I can do that using a log
> > 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
> > must be saved. This value is generated from the RUN GSM ALGORITHM
> > 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?
> > 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
> > 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel