Sim

[Sylvain Munaut]

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