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