Update on Overleaf.

This commit is contained in:
nb72soza Bittner
2025-06-28 15:59:50 +00:00
committed by node
parent fd72eda0ac
commit 5483c20352
2 changed files with 40 additions and 4 deletions

View File

@@ -5,4 +5,13 @@
%************************************************
\glsresetall % Resets all acronyms to not used
\lipsum[6]
% potential exploitation options for the certificate reuse
% profile installation sabotage / Supply chain attack
% persistent trust manipulation / downgrade attack
% mitigations for certificate reuse bug
% flush any cryptographic context on failed rsp session
% stricter session isolation
% limitations of esim security research
%

View File

@@ -116,6 +116,8 @@
% experiments were conducted with a HID OMNIKEY 3121 USB smart card reader
% esims were inserted into the sysmocom SIM card adapter to adapt the 2FF eSIM to full-size
% adapter was inserted into smart card reader
% profile used for regular consumer cards: "LPA:1$rsp.truphone.com$QR-G-5C-1LS-1W1Z9P7"
% profile used with the sysmoeuicc due to this having the GSMA test certificate installed: "LPA:1$smdpp.test.rsp.sysmocom.de$TS48v5_SAIP2.1B_NoBERTLV"
% differences in execution time
% depends on chip speed and how likely the esim accepts mutated apdus -> more branches -> more apdus
@@ -162,8 +164,6 @@
% adjusting the specific tags to make it decodable shows that there is now differenence to a successfully decoded AuthenticateServerResponse apdu apart from the euiccSignature1, serverChallenge and transactionId. All of which are supposed to be different
% still interisting that the response data was malformed
% successful mutations
% get_euicc_info_1 truncation
@@ -262,6 +262,33 @@
%
% "The Server (the entity providing the function, e.g., SM-DP+) SHALL be authenticated first by the Client (the entity requesting the function). Authentication SHALL include the verification of a Server Certificate chain ending at an eSIM CA RootCA Certificate (section 4.5.2)." from RSP
% test if we can exploit this: provision a valid profile from my own non GSMA accredited smdp+ server using the osmo-smdpp server included in pysim
% we modify the server in way that it ignores checks that its own hostname is the subject of the CERT.DPauth.ECDSA Certificate
% we run the initial AuthenticateServerRequest using a valid profile and applying mutation that fails to prepare the esim
% before sending the second AuthenticateServerRequest, we switch out the subjectPublicKeyInfo for our own controlled publicKey
% as explained in section (cref to background section) the euicc uses the server provided certificates public key to perform the ECDH Key agreement
% this results in a shared session key that is used for encrypting and authenticating further communication
% esim happily accepts the public provided by use -> does not check if signature is still valid nor checks the certificate chain if the certificate is signed by GSMA root CA
% doing the same experiment but using our own profile to perform the initial authenticateServerRequest -> check if the esim uses the certificate from the first failed authentication for further communication
% 1. Perform failed mutation with our own profile and smdpp server
% 2. Use valid profile with valid smdpp server but use truncation mutation to cutoff the signature and some extensions
% results in an unkown error -> suggests that the euicc uses the certificate from the first failed authenticateServerRequest
% persistency accross power cycles
% steps similar to previous test
% 1. provision valid profile from valid smdpp with bitflip -> failed authenticateServerRequest
% 2. remove esim from adapter card, wait 5 seconds and reinsert
% 3. provision valid profile from valid smdpp with truncation -> signature is removed -> successful installation
% Cross-Session certificate resuse is still possible after power cycle of the esim
% check if possible when using different valid profiles on same smdpp
% use "LPA:1$rsp.truphone.com$QR-G-5C-1LS-1W1Z9P7" activation code for initial provisioning with bitflip
% use "LPA:1$rsp.truphone.com$QRF-SPEEDTEST" activation code for truncated provisioning
% successfull mutual authentication aswell as profile binding and download
% successful provisioning
% both provisionings used the same certificate
% Could not test with different certificates -> no available profiles with production GSMA cert (other available one is "LPA:1$rsp-eu.redteamobile.com$5901981126831169" but smdp refuses due to "campaign resource pool is empty")
%