From laforge at osmocom.org  Tue Feb  2 18:38:07 2021
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 2 Feb 2021 19:38:07 +0100
Subject: WIP / RFC for pysim 'next generation;' aka pysim-shell
In-Reply-To: <X/jif2C1BF3RfY9w@nataraja>
References: <X/jif2C1BF3RfY9w@nataraja>
Message-ID: <YBmcD/DJ9pNdF5GS@nataraja>

On Fri, Jan 08, 2021 at 11:53:51PM +0100, Harald Welte wrote:
> You can see the very first prototype in the laforge/shell branch of pysim.git

Just a quick update: During past weeks I've been on and off spending a
bit of time to bring this idea further along.  It's already quite mature
now.

* many bugs have been fixed

* SW1/SW2 are now parsed into human readable strings

* many file specific encoders/decoders added

* return to 'SELECT" command is now parsed into json:

----------------------------------------------------------------------
pySIM-shell (MF)> select ADF.ISIM
{
    "file_descriptor": {
        "shareable": true,
        "file_type": "df",
        "structure": "no_info_given"
    },
    "file_identifier": "FF01",
    "df_name": "A0000000871004FFFFFFFF8907090000",
    "proprietary_info": {
        "uicc_characteristics": "71",
        "available_memory": 101640
    },
    "life_cycle_status_int": "operational_activated"
    "security_attrib_compact": "00",
    "pin_status_template_do": "900170830101830181830
}
pySIM-shell (MF/ADF.ISIM)> select EF.P-CSCF
{
    "file_descriptor": {
        "shareable": true,
        "file_type": "working_ef",
        "structure": "linear_fixed",
        "record_len": 0,
        "num_of_rec": 0
    },
    "file_identifier": "6F09",
    "proprietary_info": {
        "proprietary_D0": "20",
        "proprietary_D2": "0F"
    },
    "life_cycle_status_int": "operational_activated"
    "security_attrib_ref_expanded": "6F0603",
    "file_size": 1024,
    "short_file_id": ""
}
----------------------------------------------------------------------

It's already reached a state where it can be used to perform useful
tasks.  Be warned: It's still very early and nothing has been tested
with cards other than sysmoISIM-SJA2 at this point.

I think within the next weeks I'll probably try to clean up the patches
and get the current state merged to master.  There's still a lot of work
to be done, including:

* option for storing per-ICCID ADM keys in some config file, so you don't have
  to enter them over and over again when frequently changing with the
  same cards
* bulk read / write commands to read/write all records within one file
* decide on some general rules on how to strucure the JSON output, such
  as including the file path and record number in some metadata?
* automatically pad filss/records with fff to their size as determined
  from the card
* ability to select/read/write arbitrary FID, e.g. for non-standard proprietary
  files that are not part of the ETSI/3GPP specs

Regards,
	Harald
-- 
- 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)


From merlin.chlosta+simtrace at rub.de  Thu Feb  4 14:00:53 2021
From: merlin.chlosta+simtrace at rub.de (merlin.chlosta+simtrace at rub.de)
Date: Thu, 4 Feb 2021 15:00:53 +0100
Subject: remsim: SIM inventory, mapping by IMSI
Message-ID: <5F9AEAB4-0035-443F-8960-500084382105@rub.de>

Hi everybody,

we try to use remsim for sharing SIMs across teams (multiple locations). We already set up the basic SIM sharing in a VPN.

From a usability perspective, we?d like to have something like a SIM inventory and select SIMs by ICCID/IMSI rather than slots. We drafted some over-the-top service with a simple web application. pySim reads available cards, sends them to the service and generates a config for bankd. Kinda works, not really nice though. So before going much further, we?d like to ask:

* is there something similar already?
* are there similar features planned, like
  * automatically reading ICCID, IMSI and sharing them through remsim service directly?
  * mapping by card properties (IMSI/ICCID) instead of slot maps?

We found it challenging to preserve the mappings across reboots, as PCSC indices change. We might just use remsim wrong, so any thoughts and feedback welcome. Besides, do you see any major blockers? Like? sharing across locations doesn?t really make sense if plugging-in-and-out is required, and we?re not sure if e.g. connection issues would require that.

Happy for any thoughts!
Merlin

From laforge at osmocom.org  Sat Feb  6 09:02:13 2021
From: laforge at osmocom.org (Harald Welte)
Date: Sat, 6 Feb 2021 10:02:13 +0100
Subject: remsim: SIM inventory, mapping by IMSI
In-Reply-To: <5F9AEAB4-0035-443F-8960-500084382105@rub.de>
References: <5F9AEAB4-0035-443F-8960-500084382105@rub.de>
Message-ID: <YB5bFclhyQI/lwVF@nataraja>

Hi Merlin,

On Thu, Feb 04, 2021 at 03:00:53PM +0100, merlin.chlosta+simtrace at rub.de wrote:

> we try to use remsim for sharing SIMs across teams (multiple
> locations). We already set up the basic SIM sharing in a VPN.

Great to hear, and thanks for sharing your experience.

> From a usability perspective, we?d like to have something like a SIM
> inventory and select SIMs by ICCID/IMSI rather than slots. 

This has been raised before, but unfortunately nobody has yet
contributed in that area.  See https://osmocom.org/issues/3886 from
two years ago.

The initial design idea was to not interfere on a protocol layer with
the cards, to make sure it will work for any type of smart card, not
just SIM cards (EF.IMSI) or ETSI UICC compliant cards (EF.ICCID).

However, I do see the usability improvements to have ICCID and/or IMSI
available.  It should be possible to make this completly optional, so
you could enable it if you wanted, or disable it if you have a
non-SIM/UICC use case.

It should be implemented with the following approach:
* remsim-bankd reads EF.ICCD and/or EF.IMSI at start-up (or card
  insertion) from every card, before the slots are used by clients
* RSPRO is extended for a new, optional "CardIdentityIndication" or the
  like, containing those values, reported unilaterally from remsim-bankd
  to remsim-server
* remsim-server information model is extended to keep the last
  IMSI+ICCID ever received for any bankd+slot tuple
* RSRES JSON extended to report IMSI+ICCID whenever it lists slots

One could also think of implementing this in a generic way, i.e. not
have new explicit fields for IMSI + ICCID in the ASN.1 definitions and
the code base, but introduce some kind of general "named attributes" whihc
remsim-bankd can pass to the remsim-server.   This way it would also
work for any other identifiers users might want for other types of smart
cards in the future.  All that would be needed is to add the generation
of this new "named attribute" on the bankd side.  The protocol and the
server would then not have to change for any new/future attributes
communicated that way.

Unfortunately any mechanism requires one fundamental change to how bankd works
today, see https://osmocom.org/issues/3884 - but it's also "just" some
work, no big challenge there...

> We drafted some over-the-top service with a simple web application.
> pySim reads available cards, sends them to the service and generates a
> config for bankd. Kinda works, not really nice though. 

Indeed, it should be fully integrated.

> * is there something similar already?

unfortunately not.  However, libosmosim (part of libosmocore.git)
already contains everything needed in terms of C language library
routines to perform the respective SELECT + READ BINARY commands on the
cards.  So at least that part doesn't have to be re-invented.

> * are there similar features planned, like
>   * automatically reading ICCID, IMSI and sharing them through remsim service directly?
>   * mapping by card properties (IMSI/ICCID) instead of slot maps?

The second step would go one step further beyond what I described above
(merely exposing the information, but not making it a selector).  I
haven't yet thought on implication to RSRES interface.  I guess the
best approach there would be to make a proposal either here or in
readmine as a feature request.  In any case, we need to stay backwards
compatible, so selection by additional keys such as IMSI or ICCID must
be an optional addition.

> We found it challenging to preserve the mappings across reboots, as
> PCSC indices change.

Are you referring to indicies for slots within one reader (like OCTSIM
or the ACR 5-slot reader)?  I haven't seen those change at all.

Or are you referring to indicies for the actual readers? In that case,
the recently merged
https://git.osmocom.org/osmo-remsim/commit/?id=753c8aa87a2c4ad25a50230d07b183ae7194373e
should be of interest to you - it introduces regex matching for PCSC
reader/slot names to remsim-bankd.

> Like? sharing across locations doesn?t really make sense if
> plugging-in-and-out is required, and we?re not sure if e.g. connection
> issues would require that.

I'm not sure what exactly you are asking here, maybe you could elaborate
a bit.

Regards,
	Harald
-- 
- 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)