dexter has uploaded this change for review. ( https://gerrit.osmocom.org/c/onomondo-eim/+/43506?usp=email )

Change subject: esipa_asn1_handler: Add TODOs to address missing checks ......................................................................

esipa_asn1_handler: Add TODOs to address missing checks

The ASN.1 handler code lacks several checks that are required by SGP.32. Profile downloads will work fine, but we won't catch errors early.

Related: SYS#8100 Change-Id: I6174fba0760a0192d59db68a430b10ab7726bcb3 --- M src/esipa_asn1_handler.erl 1 file changed, 28 insertions(+), 4 deletions(-)

git pull ssh://gerrit.osmocom.org:29418/onomondo-eim refs/changes/06/43506/1

diff --git a/src/esipa_asn1_handler.erl b/src/esipa_asn1_handler.erl index f1be50a..0fc72e7 100644 --- a/src/esipa_asn1_handler.erl +++ b/src/esipa_asn1_handler.erl @@ -21,6 +21,10 @@ % initiateAuthenticationRequest. However the field is only missing in case the IPA capability minimizeEsipaBytes is % used. This is an optional feature that this eIM does not support, so we can expect euiccInfo1 to be always present.

+ % TODO: Popluate smdpAddress from Activation Code if missing: smdpAddress is declared as anan optional field in + % InitiateAuthenticationRequestEsipa. If the field is missing, we can retrieve it from the Activation Code that is + % stored in the download Order (see also SGP.32, section 3.2.3.2, step 8). + % setup ES9+ request message Es9Req = {initiateAuthenticationRequest, EsipaReq},

@@ -31,16 +35,20 @@ EsipaResp = case Es9Resp of {initiateAuthenticationOk, InitAuthOk} -> + % TODO: Verify serverAddress in serverSigned1: In case we ad to extract the smdpAddress from the + % Activation Code we should make sure that smdpAddress and serverAddress are equal. + % TODO: Verify SM-DP+ OID. An Activation Code may contain an SM-DP+ OID. Make sure that this OID + % matches the OID from the serverCertificate (see also SGP.32, section 3.2.3.2, step 10). TransactionId = maps:get(transactionId, InitAuthOk), mnesia_db_work:bind(Pid, TransactionId), % TODO: matchingId and ctxParams1 are not defined in the ES9+ InitiateAuthenticationResponse message. % However in ESipa those fields are optional fields and either one of it should be populated in case an % AC is used (which we do). This means we should populate those fields. The matchingId can be extracted % from the AC, which we have in the Order. If the IPAd supports eimCtxParams1Generation then it should - % be find if we would just add the matchingId field like so: maps:merge(InitAuthOk, #{matchingId => - % FIXME). Otherwise we would have to add a ctxParams1 field and populate it with the matchingId and the - % deviceInfo. The deviceInfo can be retrieved via an eUICC data request. - % (see GSMA SGP.32, section 3.1.2.3). + % be fine if we would just add the matchingId field like so: maps:merge(InitAuthOk, #{matchingId => + % MatchingId}). Otherwise we would have to add a ctxParams1 field and populate it with the matchingId + % and the deviceInfo. The deviceInfo can be retrieved via an eUICC data request. (see also GSMA SGP.32, + % section 3.2.3.2, step 11). InitAuthOkEsipa = #{ transactionId => maps:get(transactionId, InitAuthOk), serverSigned1 => maps:get(serverSigned1, InitAuthOk), @@ -102,6 +110,17 @@ fallbackAllowed => FallbackAllowed } ), + % TODO: Verify profileMetaData in case the IPAd is not able to verify the profileMetaData: At the + % moment we assume that the IPAd is able to verify the profileMetaData, but there may be IPAd + % implementations which cannot verify the profileMetaData (eimProfileMetadataVerification). In those + % cases the eIM is responsible to verify the profileMetaData, which is not implemnted yet (see also + % SGP.32, section 3.2.3.2, step 15 and 19). + % TODO: Implement compatibility Check: At the moment it is the responsibility of the REST API user to + % ensure that eIM and IPAd are compatible. Currently the REST API user must request the IpaCapabilities + % via an eUICC Data Request and know for himself what capability combinations will work with this eIM. + % To simplify this we should automate this process by requesting and caching the IpaCapabilities once, + % so that we the info withing reach when we need it (similar to how we cache signPubKey, see also + % mnesia_db_euicc.hrl). AuthenticateClientOkDPEsipa = AuthClntRespEs9#{ profileMetaData => StoreMetadataRequest }, @@ -296,6 +315,11 @@ % an activationCode (option a) It still lacks download triggers via SM-DS (option b) and downloads from % the default SM-DP+ (option c). See also GSMA SGP.32, section 3.2.3.2 ActivationCode = proplists:get_value(<<"activationCode">>, Download), + % TODO: Check the contents of ActivationCode. The eIM should check the provided Activation Code and stop + % the procedure in case the Activation Code is invalid. However, it should also be mentioned that The + % missing check only has a minor impact since an invalid Activation Code will be detected on the IPAd + % side, which will cause the procedure to stop as well. (see also SGP.32, section 3.2.3.2, step 1 and + % step 4). {profileDownloadTriggerRequest, #{ profileDownloadData => {activationCode, ActivationCode}, eimTransactionId => EimTransactionId