FreeCalypso > hg > fc-pcsc-tools
comparison doc/Sysmocom-SIM-notes @ 123:09a66626647d
doc/Sysmocom-SIM-notes article written
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 20 Feb 2021 04:11:48 +0000 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
122:c0cd0d4635bb | 123:09a66626647d |
---|---|
1 The present suite of tools (fc-simtool and fc-uicc-tool) is NOT a good fit for | |
2 programming sysmoUSIM-SJS1 and sysmoISIM-SJA2 cards made by Sysmocom and sold | |
3 in their webshop, because of the following combination of factors: | |
4 | |
5 1) These cards are primarily USIM/ISIM, with classic GSM 11.11 SIM support | |
6 regarded as "backward compatibility" - thus they have a lot of important | |
7 files under ADF.USIM and ADF.ISIM which are not accessible via the classic | |
8 GSM 11.11 SIM protocol. | |
9 | |
10 2) Our main feature-rich tool is fc-simtool, but this tool speaks only the | |
11 classic GSM 11.11 SIM protocol, hence it cannot access any of the USIM/ISIM | |
12 files. | |
13 | |
14 3) We have fc-uicc-tool which speaks the UICC protocol that is native to these | |
15 Sysmocom cards, but it is only a low-level debug tool, not a feature match | |
16 to fc-simtool. | |
17 | |
18 The proper long-term solution for our 2G-centric GSM community is to get our own | |
19 SIMs made, either by paying big bucks to Sysmocom to produce a run of custom | |
20 cards (presumably based on their current SJA2 platform) with USIM and ISIM | |
21 removed, leaving only the file system tree under MF that can be fully | |
22 manipulated via the classic SIM protocol, or preferably by resurrecting the | |
23 older Grcard SIM-only platform if possible - it may take a long time to find out | |
24 if the latter option is possible or not. But in the meantime, if someone needs | |
25 to program a SIM right now, when Sysmocom webshop cards are the only available | |
26 option, we do have limited support for programming these SIMs: | |
27 | |
28 * It is possible to authenticate with the ADM1 key from within fc-simtool on | |
29 both sysmoUSIM-SJS1 and sysmoISIM-SJA2, as explained below. | |
30 | |
31 * Once you have authenticated with ADM1, you can use fc-simtool admin write | |
32 commands (write-imsi, SDN phonebook write operations, manual update-bin-imm | |
33 on various small transparent EFs) just as if you were working with a Grcard | |
34 SIM. | |
35 | |
36 * You can also use fc-uicc-tool to access and program every file on Sysmocom | |
37 cards, including files under ADF.USIM and ADF.ISIM - but in this case you will | |
38 have to do everything manually in raw hex, with a hex data file for every | |
39 update-bin and update-rec command. | |
40 | |
41 Authenticating with ADM1 | |
42 ======================== | |
43 | |
44 The method for sending your ADM1 key to the card varies depending on whether | |
45 you are in an fc-simtool or fc-uicc-tool session, and whether your card is | |
46 sysmoUSIM-SJS1 or sysmoISIM-SJA2. There are 3 possibilities: | |
47 | |
48 * If you are in an fc-uicc-tool session with either type of card, the command | |
49 to authenticate with ADM1 is as follows: | |
50 | |
51 verify-pin 10 xxxxxxxx | |
52 | |
53 where xxxxxxxx are the 8 digits of the ADM1 secret code. There are no | |
54 restrictions as to when this command may be given in an fc-uicc-tool session. | |
55 | |
56 * If you are in an fc-simtool session with sysmoISIM-SJA2, the command becomes: | |
57 | |
58 verify-ext 10 xxxxxxxx | |
59 | |
60 There are no restrictions as to when this command may be given in an | |
61 fc-simtool session. | |
62 | |
63 * If you are in an fc-simtool session with sysmoUSIM-SJS1, the command becomes: | |
64 | |
65 verify-sjs1-adm1 xxxxxxxx | |
66 | |
67 Unlike the other two cases, this command must be issued at the very beginning | |
68 of your fc-simtool session, before any other commands. If you issue this | |
69 command later, after some GSM 11.11 SIM APDUs have already been exchanged, it | |
70 won't work. | |
71 | |
72 Changing the ADM1 PIN | |
73 ===================== | |
74 | |
75 Experiments show that when speaking the UICC protocol to the card, the standard | |
76 CHANGE PIN command does work on ADM1 on both sysmoUSIM-SJS1 and sysmoISIM-SJA2, | |
77 thus you can do the following in fc-uicc-tool: | |
78 | |
79 change-pin 10 old-ADM1 new-ADM1 | |
80 | |
81 However, given that Sysmocom already assigns individual per-card random ADM1 and | |
82 communicates these secret codes securely to webshop customers, there does not | |
83 seem to be any practical need for changing ADM1 further downstream. Thus our | |
84 recommendation is that if you are going to change your ADM1 PIN just to prove | |
85 that you can do it, you should then change it back to the original. | |
86 | |
87 We can only surmise that there probably exist some secret commands that can | |
88 reset PUK1 and PUK2 after you've authenticated with ADM1, but they will probably | |
89 remain forever proprietary to Sysmocom, especially given the lack of any | |
90 practical need for such downstream changing of PUK1/PUK2. | |
91 | |
92 Thoughts on card (re)formatting | |
93 =============================== | |
94 | |
95 ETSI and 3GPP specs give many more degrees of freedom to SIM card issuers than | |
96 just the content of various EFs: the card issuer gets to decide which DFs and | |
97 EFs will be present vs. which ones won't be present at all, and for many EFs | |
98 the size (allocated space) is variable per the specs and up to the card issuer. | |
99 In the case of record-based EFs, both the record size and the number of records | |
100 are often left up to card issuers to tune as desired. | |
101 | |
102 In the Mother's opinion, a truly programmable SIM would be one where every | |
103 downstream owner of each card (not just the initial factory or the party putting | |
104 up big bucks for a large custom production run) can do a full reformat: erase | |
105 the file system and then create whatever tree of DFs and EFs she desires, with | |
106 full control over each file's allocated size, structure and access conditions. | |
107 | |
108 In the case of Sysmocom webshop SIMs, we (FreeCalypso) are not aware of any | |
109 publicly available documents describing how to perform such a reformat - it | |
110 appears that Sysmocom keeps this knowledge proprietary. In contrast, the older | |
111 Grcard-based SIMs had some publicly documented commands for erasing the card | |
112 and creating new directories and files: | |
113 | |
114 https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM | |
115 | |
116 It remains to be seen whether we (FreeCalypso) can get new SIMs from Grcard | |
117 which are also freely formattable. | |
118 | |
119 MSISDN misprogramming on early sysmoUSIM-SJS1 cards | |
120 =================================================== | |
121 | |
122 Referring to the previous section regarding formatting degrees of freedom, | |
123 Sysmocom webshop cards have their EF_MSISDN file allocated as 6 records of 34 | |
124 bytes each. Record length of 34 bytes translates into 20 bytes of alpha tag | |
125 plus the required 14-byte structure at the end of each record. | |
126 | |
127 When Sysmocom made their early sysmoUSIM-SJS1 cards, they intended to program | |
128 the first record of EF_MSISDN as +882110xxxxx, where xxxxx are equal to the last | |
129 5 digits of their 901-70 IMSI and also to the last 5 content digits (before the | |
130 Luhn check digit) of their 8988211 ICCID. A correctly structured EF_MSISDN | |
131 phonebook record with a +882110xxxxx phone number would look like this, for the | |
132 record size of 34 bytes: | |
133 | |
134 00: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | |
135 10: FF FF FF FF 07 91 88 12 01 xx xx Fx FF FF FF FF | |
136 20: FF FF | |
137 | |
138 The first 20 bytes are all FF because that is the space reserved for the alpha | |
139 tag, then the phone number is encoded in 8 bytes as 07 91 88 12 01 xx xx Fx, | |
140 and the rest of the required 14-byte structure is filled with FF bytes. | |
141 However, the actual programming of this MSISDN record on early sysmoUSIM-SJS1 | |
142 cards (at least on the 10-pack I bought in 2017) looks like this: | |
143 | |
144 00: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | |
145 10: FF FF 07 91 88 12 01 xx xx Fx FF FF FF FF FF FF | |
146 20: FF FF | |
147 | |
148 The not-all-FF field of 8 bytes is written into the wrong location, two bytes | |
149 earlier than where it should be. When I saw this misprogramming early in the | |
150 course of developing fc-simtool, I finally understood why the AT+CNUM command | |
151 on a FreeCalypso modem with this SIM inserted reported a 10xxxxx number instead | |
152 of the +882110xxxxx listed in the sysmoUSIM manual. :-) | |
153 | |
154 When I saw this misprogramming, I also added a fix-sysmo-msisdn command to | |
155 fc-simtool: this command checks for this particular misprogramming, and if it | |
156 finds such, it rewrites the MSISDN record with the 8-byte phone number field | |
157 moved to its correct place. However, this fix-sysmo-msisdn command probably | |
158 won't get much use: the factory-programmed EF_MSISDN is now completely blank on | |
159 Sysmocom's current sysmoISIM-SJA2 cards, and also on the late sysmoUSIM-SJS1 | |
160 cards - or at least it is blank on the last-stock cards I bought in 2020-11. | |
161 EF_MSISDN is writable without needing ADM1 - it only needs CHV1. |