view doc/Formatting-thoughts @ 93:6041c601304d

fcsim1-mkprov: revert OTA key addition It appears that GrcardSIM2 cards (which is what we got for FCSIM1) do not support OTA after all, contrary to what we were previously led to believe by some tech support emails from Grcard - apparently those support emails and OTA descriptions referred to some other card model(s).
author Mychaela Falconia <falcon@freecalypso.org>
date Wed, 21 Apr 2021 05:38:39 +0000
parents 7c9a3130fb66
children
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 standardized 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.