Dear Sebastien, On Fri, Mar 12, 2010 at 12:51:47AM +0100, Sébastien Lorquet wrote: the reply-to needs no 'fixing'. if you want to reply to the list, you have to use the 'reply to all' feature of your mail client ;) you might find http://www.unicom.com/pw/reply-to-harmful.html amusing :) -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

(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

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?

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?