Sim

historical

Hi,

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>