I'm trying to wrap my head around SGP.02-v4.0 - Remote Provisioning Architecture for Embedded UICC Technical Specification and specifically ES3.UpdateConnectivityParameters function.
The puzzling thing is that figure 29 in section 3.14 shows that SM-SR sends only one MT-SMS to eUICC after ES3.UpdateConnectivityParameters received. I understand that actual connectivity parameters in the form of the ES8.UpdateConnectivityParametersSCP03 command are sent in SCP03 tunnel.
Commands sent using SCP03 require that two commands are sent to eUICC first (INITIALIZE UPDATE
and EXTERNAL AUTHENTICATION
as described in GlobalPlatform Card Specification 2.2.1 section D.1.2). I understand it that these two commands cannot be sent in one MT-SMS as in order to send the second one the result from the first one is required.
So it means that actual execution of the ES3.UpdateConnectivityParameters function requires at least three messages over ES5.
This section from Secure Channel Protocol '03' – Public Release v1.1.1 adds to this confusion:
The Secure Channel is used to personalize cards at Issuance and during Post-Issuance. The mode of the Secure Channel Protocol which uses pseudo-random card challenges allows the offline preparation of personalization scripts while the card is not present and the processing of these scripts on the card without an online connection to the entity that prepared the scripts
I initially interpret edit that all three commands (INITIALIZE UPDATE
, EXTERNAL AUTHENTICATION
and ES8.UpdateConnectivityParametersSCP03) can be sent in one OTA message. But now when asking this question I see that it may mean a message over ES3 (between SM-DP and SM-SR) not over ES5 as I initially thought.
Is my understanding that the figure in SGP.02 is a simplified explanation and it does not show all OTA messages send to and from eUICC (specifically those required to establish SCP03)?
I have not looked up if your assumption of using SCP03 here is true, assume they are using it:
The pseudo-random card challenges allows to execute both commands in one message. Because like the name suggest it is no real random but random calculated from a known value. The known value is the sequence counter. It can be read out from the card and must be known and in sync and incremented by both parties.