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. |
