remsim: SIM inventory, mapping by IMSI

historical

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)