(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
Dear Sebastien,
On Fri, Mar 12, 2010 at 12:51:47AM +0100, Sébastien Lorquet wrote:
(sorry dexter , this was intended for the list - someone has to fix the reply-to address of this group)
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 :)
"It may be impossible to reply to the author of a message once the Reply-Toheader is munged."
OK, that single one is sufficient to understand. :-)
Using "reply to all" in gmail puts the list address in CC and replies to the list author directly.
I just have to remember that if(mailinglist) { replytoall(); } else { normalreply(); }
:-) and thanks
On Fri, Mar 12, 2010 at 7:04 PM, Harald Welte laforge@gnumonks.org wrote:
Dear Sebastien,
On Fri, Mar 12, 2010 at 12:51:47AM +0100, Sébastien Lorquet wrote:
(sorry dexter , this was intended for the list - someone has to fix the reply-to address of this group)
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@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Friday 12 March 2010 19:04:55 Harald Welte 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 :)
Or shameless advertising of software. KMail supports "L" for reply to list.
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@gmail.comwrote:
(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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Sébastien
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?
No idea, but they backup a lot stuff, like last used ARFCNs and so on.
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.
I think it is stored in a file, but the read access will be disabled, but you are right, the spec does not specify an EF:KI or anything semilar.
You could try to select all files 0000 to FFFF maybe you find something undocumentated ;-)
"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?
No, that should be absolutely no problem - no phone will ever do a select to this file ;-)
Regards. Philipp
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
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@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
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?
I wasn't sure that there _was_ a way to force renegotication (the network is master, the MS is slave). So I just re-read the GSM 04.08 (well, the relevant section, not all of it :) and apparently key_seq = 0x7 is a special value saying 'No key available' so that should work.
Sylvain
baseband-devel@lists.osmocom.org
-
dexter -
Harald Welte -
Holger Freyther -
Sylvain Munaut -
Sébastien Lorquet