Conflict between eUICC access rules (ARA) and eSIM profile access rules

SIM Card Technology GSMA eSIM / eUICC
#1

I’m posting this here in the hope that it will attract interest by some of the people involved in the eSIM/eUICC related industry in order to resolve a problem that (I think) currently has no solution yet, and requires collaboration of MNOs/MVNOs, eUICC card issuers as well as potentially Smartphone OS vendors.

UICC Carrier Privileges + Android

So Android (since 5.1) has this mechanism called UICC Carrier Privileges which was originally designed so that a [pyhsical] USIM/UICC-card-issuing MNO/MVNO can distribute Android Apps which get elevated privileges to access interfaces that no ordinary app can access. For example: it enables an app to open a logical channel to the USIM/UICC and then exchange raw APDUs via that channel.

The way how this works is

  • a special card applet called ARA-M is installed on the UICC/USIM, identified by a well-known AID of A00000015141434C00
  • this applet contains Access Rules which in turn contain (in the case of Android) the hashes of the APK singer key of the card-issuing MNO/MVNO
  • when an APK is signed with a key whose digest matches one of the Access Rules in the ARA-M applet, it gets those elevated privileges / access to those normally restricted APIs.

This all worked fine for many years now, and is extensively used in cellular research and testing, for example to enable VoLTE/IMS on private PLMNs as described in the CoIMS wiki.

Problem arises with eSIM/eUICC

Now let’s see what happens with eUICCs, the physical chip used to host the virtualized SIM cards called eSIM profiles.

With eUICCs we now have potentially two competing parties that both want to use the ARA mechanism to get Carrier Privileges:

  1. the eUICC itself, for example to permit a third-party LPAd (Local Profile Assistant, that’s the name of the application that manages your eUICC and downloads/activates/deactivates/removes eSIM profiles on it)
  2. the currently active eSIM profile, where the MNO/MVNO that has issued it might still want to use the same UICC Carrier privilges just like in the prior situation with physical cards.

So if both the eUICC (ISD-R) and the eSIM profile (ISD-P) provide an ARA-M applet, the desired result should be that the access rules of both are somehow magically merged, and concurrently active.

The reality however shows that at least several implementations of eUICCs with pre-installed ARA-M applet (including the sysmoEUICC1-C2GsysmoEUICC1-C2G as well as [reportedly] the eSIM.me fail to install eSIM profiles that contain their own ARA-M applet. One prominent example of such an eSIM a profile is that of Vodafone Germany.

Solutions?

Sadly, as far s I can tell, no standards body has so far properly adressed how this should be resolved.

  • The GSMA eSIM RSP specifications say nothing about it, I could not find any statement on how AID conflichts between ISD-R (eUICC) and ISD-P (eSIM profile) should be resolved. They appear to ignore it.
  • The Google/Android/AOSP documentation doesn’t say anything specific about eUICCs in the context of UICC Carrier Privileges.
  • The SIMalliance (now TCA) doesn’t say anything about it
  • The GlobalPlatform also doesn’t really have a clear solution - other than that they vaguely describe a situation with ARA-M and ARA-C in their Global Platform Secure Element Access Control v1.1 Section 2.2, where the CardOS provides the ARA-M and the Profiles provide the ARA-C. However, they do not specify the ARA-M vs. ARA-C interface.

Workarounds?

  1. Android (since 7.0) alternatively adds support for reading access rules from the ARF (Access Rule File). It first tries to use the ARA-M at its well-known AID, and then falls back to selecting another AID (A000000063504B43532D3135) where it uses another mechanism to obtain acces rules.
    So the eUICC/ISD-R could use the ARF mechanism, while the eSIM Profile/ISD-P could bring an ARA-M applet.
    Disadvantage: the eUICC acess rules are effectively disabled as soon as an eSIM profile includes an ARA applet. So if you enable such an eSIM profile, your LPAd application suddenly can no longer talk to the eUICC anymore, and you can never switch to another profile :frowning:
  2. The eUICC could provide a combined ARA-M and ARA-C load file, which would be instantiated as ARA-M by the ISD-R and as ARA-C by the ISD-P. It would internally merge the access rules and expose the merged rules when the Smartphone/Android reads the access rules. This would require support for that from the eUICC manufacturer, and would require some kind of standardized load file that eSIM profile issuers (MNOs/MVNOs) would instantiate as their ARA-C.

Maybe there are other options I haven’t thought about yet? I’m most welcome to see what other people working in this area have to say about it. Let’s see if I can get anyone to comment/reply here…

1 Like
#2

In my reply, I would like to ask whether I have understood correctly that all eSim profiles containing an ARA-M applet (e.g. Vodafone Germany) cannot be installed on the eUICC cards mentioned (the usual ones available). Cause: The ARA-M applet of the profile conflicts with another ARA-M applet on the card.

1 Like
#3

Hi Chris,

So far this is the working explanation; I’m planning to do some more trial+error based investigations. But for sure I can confirm that

  • the Vodafone DE eSIM contains an ARA-M applet itself
  • the download fails as long as I have an ARA-M on the ISD-R of the eUICC
  • if I remove the ARA-M applet from the ISD-R (using Global Platform DELETE via SCP03 to the ISD-R, which we as eUICC issuer can do), then installation of the Vodafone DE eSIM succeeds

Somebody more versed in GlobalPlatform and JavaCards than I indicated that [as I understood] “in GP theory” it is not legal for an eSIM / ISD-P to bring its own ARA-M applet; Instead it would have to instantiate an ARA-M applet from the eUICC OS, which would then implicitly act as ARA-C towards the ARA-M of the ISD-R. Certainly this would seem to make sense looking at the specs, but …

  • there is no requirement for an eUICC OS to have a ARA-M package, so an eSIM profile (== ISD-P) cannot blindly assume it exists
  • there are at least some eUICC CardOS that support ARA-M but do not support ARA-C at all

So it all looks like a bit of a mess, and only close coordination between eUICC OS suppliers, GSMA, GlobalPlatform and Google(Android) might get us out cleanly…

2 Likes
#4

Hello everybody,

indeed the answer seems to be even more complicated. I got a response from my colleagues,
referring to GlobalPlatform SAM Configuration v1.0 | GPC_GUI_217 - GlobalPlatform Section 3.3.5 and 3.3.6.
(can be ordered for 0,00 USD)

There, for SAM contexts, you can see the ARA-M <-> ARA-C relationship. But: they also added
each SAM-scope can have it’s own ARA-M and the MNO-profiles are parallel to them.
So, basically they expect multiple ARA-Ms to coexist. I still have to ask them how they expected
to resolve this in a real-life scenario. Because the access control enforcer has to iterate through
those multiple ARA-Ms. Currently it is not capable doing so. They also confirmed “Android would
need a modification for this”.

The situation about ARA-Ms / ARA-Cs on other Secure Elements / eUICCs is highly dependent
on the configuration. Indeed it seems GSMA missed the point to clearly specifiy ARA-M / ARA-C
usage in MNO profiles.
What I can tell: environments exist where ARA-M is either a system package or installed in the
ISD(-R) and you’re not allowed to create your own ARA-M - but receive instructions how to perform
an install-for-install using the default load package AID and an applet AID derived from the SD AID
you get assigned. (a bit similar to creating a SD from the system package)

The internals of such an implementation are up to the implementer. One could use a service pattern
or a static package class to register and unregister the local ARA-C rule storage on init. An operating
system package is not needed for that, indeed such an implementation could be done as a regular
applet and installed in the ISD(-R).

One of the major suppliers of such an environment just moved their complete system, including the
developer front-end. I’ll try to get some hints from their current documentation as soon as possible.

There are still some options to experiment with, but basically it will either result in the MNOs ARA-M being ignored or a MNO-profile containing an ARA-M not being allowed to install, because of the
package and AID conflict.

All the best,
CK

2 Likes
#5

A small update:

For now, it seems all we can do is to offer to optionally remove the ARA-M from the ISD-R, which means that you loose the ability to use EasyEUICC or any other LPA on Android :frowning:

An unnamed expert in the industry stated this problem apparently has been brought up to the standardization body GlobalPlatform as early as 2019, but as it seems no solution has been specified so far (5 years later!).

1 Like