Hi Mychaela,
Just a side note from me, addressing your wish to not use Python for SIM operations. I have been using srsLTE for about 5 years now, and about 3 years ago physical USIM support was added to it. Naturally it is a very thin layer, pretty much only supporting requesting 3G AUTH vectors from the card, however it is written in C or C++ (I can’t remember right now which). Maybe it is useful for you :).
Cheers, Domi
04.02.2021 dátummal, 13:42 időpontban Mychaela Falconia mychaela.falconia@gmail.com írta:
Hi Harald,
In theory, you should be able to remove the respective applications from most java based cards with the right credentials
For the "right credentials" part, I have a 10-pack of sysmoISIM-SJA2 cards which I bought with ADM keys included. The key material email from your webshop gives ADM1 and KI[CDK][123] for each card - are these the right credentials?
via SCP02. Did you try?
I am afraid the learning curve will probably be too steep for me to climb at this moment - but I am making a mental note to read up on SCP02, whatever it is, when and if I get the mental space for it.
sysmocom can certainly also provide such cards, should you have a related requirement.
What would be the MOQ and minimum order total cost for the following?:
- Application customization: either classic GSM only or classic GSM
plus USIM (TBD), but no ISIM;
- 1FF+2FF-only cut, with the 2FF piece being fully solid w/o 3FF or
4FF cuts;
- Custom printing.
It requires creating a card profile without ADF.USIM + ADF.ISIM, which certainly can be done.
Just how much control do you have over your cards? Your docs give the impression that your vendor/supplier more or less forced you into a new CardOS platform by declaring EOL on the one you had for SJS1, and the comments in your Python code for programming Ki/OPc/etc make it sound like these aspects were something you had to reverse-eng from what your vendor gave you, rather than something you actually designed yourselves. I mean, if your own team had actually designed the custom non-standard files for storing keys and algorithm selections, surely you would not have come up with the awkward design where you have to repeatedly store into each of SIM, USIM and ISIM, without making it clear at all whether or not these files are all linked or separate...
If you were to make a version without ADF.ISIM or without both ADF.ISIM and ADF.USIM, what would the architecture look like for storing Ki (or K/OPc) and algorithm selections?
I am also concerned about the following stanza in sysmo_isim_sja2.py:
sysmo_isimsja2_algorithms = ( (SYSMO_ISIMSJA2_ALGO_COMP12V1, 'COMP128v1'), (SYSMO_ISIMSJA2_ALGO_COMP12V2, 'COMP128v2'), (SYSMO_ISIMSJA2_ALGO_COMP12V3, 'XOR-2G'), (SYSMO_ISIMSJA2_ALGO_MILENAGE, 'MILENAGE'), (SYSMO_ISIMSJA2_ALGO_SHA1AKA , 'SHA1-AKA'), (SYSMO_ISIMSJA2_ALGO_XOR, 'XOR'), )
Why is SYSMO_ISIMSJA2_ALGO_COMP12V3 mapped to 'XOR-2G' and not 'COMP128v3'? Does sysmoISIM-SJA2 (and presumably any custom config based on your current SJA2 CardOS) actually support COMP128v3 or not? If it doesn't, one has to do Milenage even for a 2G-only network, which is certainly an extra cognitive burden...
One clear disadvantage of using SIM without USIM functionality even on a 2G radio network is that you can never use mutual authentication between network and phone (which is a pure protocol related aspect, so it could be implemented in any phone/baseband whose software can be modified - including FreeCalypso.
Yes, I have thought about implementing USIM and 3G-style AKA support in FreeCalypso. But as my life circumstances stand currently, I don't know if I will live long enough to bring FC to a point where it would be a practically usable phone handset (whether on new or pre-existing Calypso hw), one that can actually replace historical phones with solid blob firmwares for everyday use - and in the absence of handset functionality which I could use with an end user hat on, I see no point in expending major effort to add new big functionality to what is essentially a toy (current AT-command-controlled FC modem).
M~