FreeCalypso > hg > fc-sim-tools
comparison doc/Formatting-thoughts @ 55:a754d4f117cf
doc/Formatting-thoughts: new article,
split from Sysmocom-SIM-notes and updated for Grcard situation
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 22 Mar 2021 21:28:32 +0000 |
parents | doc/Sysmocom-SIM-notes@da6e9d0b2ee6 |
children | 7c9a3130fb66 |
comparison
equal
deleted
inserted
replaced
54:812779459ddd | 55:a754d4f117cf |
---|---|
1 Thoughts on card (re)formatting | |
2 =============================== | |
3 | |
4 ETSI and 3GPP specs give many more degrees of freedom to SIM card issuers than | |
5 just the content of various EFs: the card issuer gets to decide which DFs and | |
6 EFs will be present vs. which ones won't be present at all, and for many EFs | |
7 the size (allocated space) is variable per the specs and up to the card issuer. | |
8 In the case of record-based EFs, both the record size and the number of records | |
9 are often left up to card issuers to tune as desired. | |
10 | |
11 In the Mother's opinion, a truly programmable SIM would be one where every | |
12 downstream owner of each card (not just the initial factory or the party putting | |
13 up big bucks for a large custom production run) can do a full reformat: erase | |
14 the file system and then create whatever tree of DFs and EFs she desires, with | |
15 full control over each file's allocated size, structure and access conditions. | |
16 | |
17 The problem, however, is that the people who work with big bucks and who control | |
18 SIM card manufacturing have taken away our community's ability to freely | |
19 reformat our programmable SIMs downstream of the factory. To the best of our | |
20 knowledge, there has only ever been one SIM card model in the entire history of | |
21 Osmocom community that supported downstream reformatting, and this model was | |
22 sysmoSIM-GR1: | |
23 | |
24 https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM | |
25 | |
26 But Grcard company no longer sells that original card model, and for their new | |
27 card model (GrcardSIM2, branded sysmoSIM-GR2 or FCSIM1) there is no published | |
28 documentation for how to erase the card file system and recreate it differently. | |
29 We can only guess that this ability probably exists, but Grcard people are | |
30 refusing to disclose the secret knowledge of how to do it unless we pay them | |
31 some ginormous sum of money. | |
32 | |
33 The current offering from Sysmocom (sysmoISIM-SJA2) does not fare any better in | |
34 this regard. These cards are natively UICC, and in the world of UICC there | |
35 exist partially standarized commands for creating and deleting files, defined in | |
36 ETSI TS 102 222. However, these commands are only partially standardized: the | |
37 ETSI spec gives the general principles and the command structure, but many of | |
38 the details as to exactly what needs to be put into the TLV structure fed to the | |
39 CREATE FILE command in order for that command to succeed constitute proprietary | |
40 knowledge. Our experiments with this CREATE FILE command on sysmoISIM-SJA2 were | |
41 unsuccessful. The only way how the file structure of Sysmocom cards would | |
42 become truly editable by end users would be if Sysmocom were to publish at least | |
43 one fully worked-out example of a real CREATE FILE command that creates some | |
44 dummy non-standard file just to prove it working, followed by a working example | |
45 of a DELETE FILE command that deletes this newly created file, restoring the | |
46 card to its original state. However, we reason that Sysmocom would probably be | |
47 willing to do this support work only if someone paid them for it on an hourly | |
48 support basis, or ordered a large custom batch of cards from them and required | |
49 this support knowledge as part of that deal - and we (FreeCalypso) are not | |
50 currently in a position to pursue either of those two routes. |