Sim

historical

Hi all,

I can now create binary files, read and write them. Working on record based
files now. Next task is implementing the real SIM commands.

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?

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.

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?

Security is not implemented in the current applet yet. We'll have the
ability to read protect any file, if required, but that's not in my
priorities for the moment.

Regards
Sebastien.

On Fri, Mar 12, 2010 at 12:51 AM, Sébastien Lorquet <squalyl at gmail.com>wrote:

> (sorry dexter , this was intended for the list - someone has to fix the
> reply-to address of this group)
>
>
> Hi all,
>
> Tonight I worked on the sim implementation with javacard. I will update
> this thread with my progress.
>
> A few minutes ago, I completed the most important parts selection and
> creation code, that allows me to create any directory structure on the card.
> There is no security yet, only the highway to what is necessary. Side roads
> will be added later.
>
> My implementation has a Master File (MF) and the possibility to create
> directories (Dedicated Files, DF) like in any unix file system. File
> identifiers are 2 bytes long (Long identifier or LID). The MF is the tree
> root, with LID 0x3F00, and DFs can be nested to "any" level.
>
> I have a command to select directories, then create directories inside.
> this is the equivalence of :
> cd / (select MF)
> cd ..  (select parent DF)
> cd <dir> (select a file with its LID, be it the parent, a brother or a
> child)
> mkdir <dir> (create DF)
>
> Everything related to this is described in ISO7816-4 (creation in
> ISO7816-9).
>
> You'll be happy (or not) to find BER-TLV encoded data here, too.
>
> I'm now focusing on having a ISO7816-4 compliant card applet whose code is
> separated from the filesystem implementation. This way, I'll be able to
> quickly switch from the ISO7816-4 commands to the TS 11.11 apdu commands.
> This is only a matter of what information is returned from the SELECT FILE
> apdu, and what selection modes are supported.
>
> In the coming day I'll focus on data file (EF) implementation, along with
> the READ and UPDATE commands.
> Select commands allowing content browsing are planned too (select
> first/next child)
>
> The current code is not in the global git yet, I prefer keeping it in my
> personal SVN until the first release. However if anyone is interested in
> looking at the code, I can provide access to it.
> Let me say this is quite specific code that will not be usable by everyone.
> You need skills in javacard, globalplatform and smart cards in general.
>
> Regards
> Sebastien
>
> PS: Guess the format of the current "Card FAT" :-)
>
> idx   ty sf lid  fch  nxt  par
> 0000: 01 00 3F00 0001 FFFF FFFF
> 0001: 01 00 2000 0002 0003 0000
> 0002: 01 00 3000 FFFF 0004 0001
> 0003: 01 00 4000 FFFF FFFF 0000
> 0004: 01 00 5000 FFFF FFFF 0001
>
> OK, that was easy, just a list of entries forming a tree with "next"
> "child" and "parent" links. data files have a corresponding data block at
> the same index in another list.
>
> I can nest just everything I want, and create any number of files (well,
> atm 256, that is configurable, and the max file size is 32kB, that is fixed
> by the max array size in javacard - signed short ) until the card is full.
>
> tree corresponding to the list (index:file id):
> 0000:3F00
> +--- 0001:2000
> |    +--- 0002:3000
> |    +--- 0004:5000
> +--- 0003:4000
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100315/5fe4d4c8/attachment.htm>