1 Apr
2024
1 Apr
'24
10:14 p.m.
Hi James,
On Mon, Apr 01, 2024 at 10:03:34PM +0200, Harald Welte wrote:
The class_tables.c is correct:
* ETSI TS 102 221 Section 11.1.2.2 defines a STATUS command for CLA 8x
with INS F2 that does *not* have a command data section, and hence is 'case 2'
* GlobalPlatform (v2.2 Setion 11.4) also defines a GET STATUS command
with CLA 8x and INS F2 which *does* have a Lc + command data section
(the 'search criteria') and hence is 'case 4'
As the card is both an UICC and a GlobalPlatform card, it's not really
clear to me which of the two commands is executed. It's also not clear
to me how one is supposed to properly distinguish those situations.
Usually the CLA+INS combined are sufficient to know which instruction of
which spec is being processed, but it seems there is at least this one
case where it's not clear.
One likely would need to track higher-layer state like "what application
(if any) is currently selected on this logical channel" in order to know
if case 2 or case 4 applies.
As a quick hack, you could try the attached patch against libosmocore.
This is just a hack to see if we really have found the culprit. It
would only work if no other part of the communication uses the UICC F2
instruction at another time. It's far from a proper solution, but worth
a try.
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Based on some
earlier troubleshooting it appears to be related to eSIM (eUICC) functionality. This
particular card reports as an eSIM (side note: curiously, its EID is blank). When I use
old modem firmware that does not support eSIM capabilities, the card works just fine over
osmo-remsim. It is only when I upgrade the modem firmware to a version that supports eSIM
that this problem appears.
The 81f2400202 is a "GET STATUS" APDU. the '1' in 81 indicates it
happens on a logical channel, not directly on the raw APDU
It seems that both GlobalPlatform as well as ETSI TS 102 221 both specify a F2 command,
and both for CLA=8x
(first nibble 8, any lower bits).
Oddly enough, according to
https://gitea.osmocom.org/osmocom/libosmocore/src/branch/master/src/sim/cla…
the ISO 7816 "case" of
those two is different: TS 102 221 is marked as case '2' while GlobalPlatform is
marked as case '4'
The way how the uicc_sim_ins_case[] is sorted, the ETSI spec will be used first, and
hence case '2' is
assumed.
Those cases refer to ISO 7816-3 12.1.2, where
* case 2 means that there are no command bytes (Nc=0) but there are response bytes (Nr
> 0)
* case 4 measn that there is both Nc > 0 and Nr > 0
I will investigate this further; maybe there's a bug in class_tables.c, or if we
somehow have to work around