mirror of
https://sharelatex.tu-darmstadt.de/git/681e0e7a3a9c7c9c6b8bb298
synced 2025-12-07 13:18:00 +00:00
Update on Overleaf.
This commit is contained in:
@@ -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
|
||||
%
|
||||
|
||||
@@ -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")
|
||||
%
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user