WIP / RFC for pysim 'next generation;' aka pysim-shell

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at osmocom.org
Sat Feb 6 12:37:50 UTC 2021


Hi Mychaela,

On Thu, Feb 04, 2021 at 04:42:35AM -0800, Mychaela Falconia wrote:
> > 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?

yes, please see the user manual on which keys to use for authentication
via SCP02 (par as global platform)

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

There's a nice command line tool called GlobalPlatformPro (written In java)
available from https://github.com/martinpaljak/GlobalPlatformPro

Using it you can authenticate using SCP02 and then perform JavaCard application
management on the card.

I've never tried the "-delete" option for any of the ISIM/USIM applications,
but it does look rather easy to try, if you are interested in that kind of thing.

Please note, once you deleted it, there is likely no way to recover, as
sysmocom cannot distribute third-party card applications in installable form.

> > 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?:

MOQ for custom production batches at the factory is 1000 units.

We can also re-program white or sysmocom-printed cards at sysmocom, if
smaller batches are required (but that excludes custom printing).

> * Application customization: either classic GSM only or classic GSM
> plus USIM (TBD), but no ISIM;

I'd do that for free in your case.  But even if we'd charge, it's probably less
than 4 hours of work in total.

> * 1FF+2FF-only cut, with the 2FF piece being fully solid w/o 3FF or
> 4FF cuts;

No extra cost associated with that.

> * Custom printing.

This is likely going to be the most significant factor.  Printing for any
batch below 10k cards has a significant price tag associated.

I would prefer to keep the discussions on the osmocom lists of technical
nature; feel free to contact sales at sysmocom.de for commercial information.

> Just how much control do you have over your cards?

We control the configuration/profile/personalization process to the last bit,
but not the CardOS.  We can choose the OS and version, but we cannot modify the
OS code.

> 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

Well, so is life in the technology industry.  Both hardware (in this
case the Samsung chip used) and software / OS go end-of-life for a
variety of reasons.   We've been able to source the old chips + OS for
many years before, so I'm not complaining.

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

sysmocom did not have to reverse-engineer the SJS1 nor SJA2 cards.

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

I disagree.  This was a deliberate design decision for the SJA2 cards,
in order to ensure maximum flexibility.  If you link/share those files,
then all applications must always share the same key material and
algorithm.  However, I can very well imagine legitimate use cases
where you want to use different key materials for the IMS/VoLTE
authentication than the key material used for the underlying radio
network.

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

if it's just SIM, then there's only one set of keys configured in
DF.SYSTEM.

If you want USIM and/or ISIM, those keys can either be shared or
different.

> 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'?  

That is a question to Philipp (Cc) who is the main author and
maintainer of that program.  IT does look *very* strange to me, too :)

> Does sysmoISIM-SJA2 (and presumably any custom config
> based on your current SJA2 CardOS) actually support COMP128v3 or not?

They should support it for sure, though I don't think anyone has tried so far.
If you have the ADM1 keys, you are happy to try.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list