view 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
line wrap: on
line source

Thoughts on card (re)formatting
===============================

ETSI and 3GPP specs give many more degrees of freedom to SIM card issuers than
just the content of various EFs: the card issuer gets to decide which DFs and
EFs will be present vs. which ones won't be present at all, and for many EFs
the size (allocated space) is variable per the specs and up to the card issuer.
In the case of record-based EFs, both the record size and the number of records
are often left up to card issuers to tune as desired.

In the Mother's opinion, a truly programmable SIM would be one where every
downstream owner of each card (not just the initial factory or the party putting
up big bucks for a large custom production run) can do a full reformat: erase
the file system and then create whatever tree of DFs and EFs she desires, with
full control over each file's allocated size, structure and access conditions.

The problem, however, is that the people who work with big bucks and who control
SIM card manufacturing have taken away our community's ability to freely
reformat our programmable SIMs downstream of the factory.  To the best of our
knowledge, there has only ever been one SIM card model in the entire history of
Osmocom community that supported downstream reformatting, and this model was
sysmoSIM-GR1:

https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM

But Grcard company no longer sells that original card model, and for their new
card model (GrcardSIM2, branded sysmoSIM-GR2 or FCSIM1) there is no published
documentation for how to erase the card file system and recreate it differently.
We can only guess that this ability probably exists, but Grcard people are
refusing to disclose the secret knowledge of how to do it unless we pay them
some ginormous sum of money.

The current offering from Sysmocom (sysmoISIM-SJA2) does not fare any better in
this regard.  These cards are natively UICC, and in the world of UICC there
exist partially standarized commands for creating and deleting files, defined in
ETSI TS 102 222.  However, these commands are only partially standardized: the
ETSI spec gives the general principles and the command structure, but many of
the details as to exactly what needs to be put into the TLV structure fed to the
CREATE FILE command in order for that command to succeed constitute proprietary
knowledge.  Our experiments with this CREATE FILE command on sysmoISIM-SJA2 were
unsuccessful.  The only way how the file structure of Sysmocom cards would
become truly editable by end users would be if Sysmocom were to publish at least
one fully worked-out example of a real CREATE FILE command that creates some
dummy non-standard file just to prove it working, followed by a working example
of a DELETE FILE command that deletes this newly created file, restoring the
card to its original state.  However, we reason that Sysmocom would probably be
willing to do this support work only if someone paid them for it on an hourly
support basis, or ordered a large custom batch of cards from them and required
this support knowledge as part of that deal - and we (FreeCalypso) are not
currently in a position to pursue either of those two routes.