This flow describes the process of an iOS Wallet Instance (WI) registering at the Mobile Device Vulnerability Management (MDVM) endpoint as described in the mobile devices chapter.
This section describes the data flow of the MDVM Registration in a sequence diagram and a more detailed table. Artifacts in italics are further explained in the data register chapter.
The Wallet Instance contains a Runtime Application Self-Protection (RASP), that locally monitors the device for rooting and emulation, and the app for hooking, re-packaging and tampering. See MDVM chapter for details.
002 - 004
The WI requests a challenge from the MDVM challenge endpoint using an HTTP POST request. The MDVM generates a JSON structure containing a random nonce and a timestamp of the current time and MACs it using a symmetric key (mdvm_mac_symk) as a JSON Web Token (JWT), the resulting structure is the mdvm_auth_challenge. The MDVM responds to the WI with the mdvm_auth_challenge in the HTTP payload. The WI uses the challenge as a transparent string and does not evaluate the JWT claims. The MDVM does not store the challenge after creation, thus the operation is stateless.
005
The WI queries information from the iOS APIs to assess it's device class utilizing:
. The WI encodes this software-attested information as wi_device_class.
006
The WI generates a hardware-backed key pair (wi_mdvm_auth_prvk, wi_mdvm_auth_pubk) using the Secure Enclave API. The WI must use the hardware-backed keys from the Secure Enclave by setting kSecAttrTokenID: kSecAttrTokenIDSecureEnclave and the key must have sufficient security, information on algorithms and key lengths can be found in the cryptography chapter.
007 - 010
The WI creates an app attestation by:
computing a hash from the newly generated wi_mdvm_auth_pubk and the challenge mdvm_auth_challenge to generate a challenge for the app attestation wi_app_attest_challenge
utilizing the DC DeviceCheck attestKey API to generate a hardware-bound cryptographic key pair (wi_devicecheck_prvk, wi_devicecheck_pubk) and request the attestation pap_devicecheck_attestation using the wi_app_attest_challenge. By providing wi_app_attest_challenge, the app attestation is bound to this particular public key, which will work as a possession factor towards the WB and RWSCD and it belongs to the same device, that was asserted during app attestation. The detailed contents and format for the request are described in the app attestation guideline.
receiving the app attestation pap_devicecheck_attestation signed with pap_attestation_auth_prvk by the PAP, that attests to the key pair (wi_devicecheck_prvk, wi_devicecheck_pubk). The detailed contents and format of the DC DeviceCheck AppAttest attestation are described in the app attestation guideline and the MDVM signals.
utilizing the DC DeviceCheck generateAssertion API to generate the assertion wi_devicecheck_assertion by signing the wi_app_attest_challenge with wi_devicecheck_prvk. This call does not require communication to the PAP.
If the WI can't reach the PAP services, it should carefully retry connection with exponential back-off to avoid rate limiting by the PAP.
011
The WI generates a proof of possession by signing the following content with the newly generated wi_mdvm_auth_prvk:
the version of the device and the software wi_device_class
the wi_mdvm_auth_pubk
the DC DeviceCheck AppAttest attestation pap_devicecheck_attestation
the DC DeviceCheck AppAttest assertion wi_devicecheck_assertion
. The message is encoded as a JSON Web Token (JWT), the resulting structure is called wi_mdvm_register_pop.
012
The WI requests to register by sending the wi_mdvm_register_pop to the MDVM's registration endpoint. The request is authenticated.
013 - 018
The MDVM verifies the wi_mdvm_register_pop by:
verifying mdvm_auth_challenge using its symmetric key (mdvm_mac_symk) and validating that the timestamp is within a valid time interval of 0 minute to +5 minutes.
verifying the signature of wi_mdvm_register_pop using the contained wi_mdvm_auth_pubk
computing a hash from the transmitted wi_mdvm_auth_pubk and the challenge mdvm_auth_challenge to generate a challenge for the app attestation wi_app_attest_challenge, this is the same as WI in Step 007
verifying the pap_devicecheck_attestation using the PAP's pap_attestation_auth_pubk according to the app attestation guideline and verifying the MDVM signals
extracting the wi_devicecheck_pubk from the pap_devicecheck_attestation
checking the signing key corresponding to pap_attestation_auth_pubk used to sign pap_devicecheck_attestation against the database of leaked PAP keys
The MDVM has now established a possession factor (wi_mdvm_auth_prvk, wi_mdvm_auth_pubk) with the WI, that can also be used by WB and RWSCD.
019 - 020
The MDVM collects and compares the sources to assess a device class for the WI using
the software-attested wi_device_class from the wi_mdvm_register_pop
The MDVM then uses the device class to check against the database of vulnerable mobile devices for known problematic device classes, such as Remote-Code-Execution or vulnerabilities of the HKS.
021
The MDVM has completed all validation steps and decides that the security posture of the WI is sufficient. The MDVM creates an account for the WI and stores:
the identifier mdvm_wi_id
the iOS DeviceCheck assertion key wi_devicecheck_pubk
the wi_mdvm_auth_pubk as a knowledge factor to authenticate the WI
the WI's device class
022
The MDVM issues an initial token mdvm_token that asserts the security posture of the WI. Therefore, the MDVM creates an MDVM token by signing wi_mdvm_auth_pubk and the expiry time with it's signing key mdvm_attestation_prvk.
023
The MDVM responds to the WI by sending the identifier mdvm_wi_id and the initial mdvm_token.
computing a hash from the MDVM account identifier mdvm_wi_id, the challenge mdvm_auth_challenge and the device class information wi_device_class to generate a challenge for the app attestation wi_app_attest_challenge
utilizing the DC DeviceCheck generateAssertion API to generate the assertion wi_devicecheck_assertion by signing the wi_app_attest_challenge with wi_devicecheck_prvk. This call does not require communication to the PAP.
008
The WI generates a proof of possession by signing the following content with the existing wi_mdvm_auth_prvk:
MDVM account identifier mdvm_wi_id
the challenge mdvm_auth_challenge
the version of the device and the software wi_device_class
the DC DeviceCheck AppAttest attestation pap_devicecheck_attestation
the DC DeviceCheck AppAttest assertion wi_devicecheck_assertion
. The message is encoded as a JSON Web Token (JWT), the resulting structure is called wi_mdvm_register_pop.
009
The WI requests renew the MDVM token by sending the wi_mdvm_auth_pop to the MDVM's renewal endpoint. The request is authenticated.
011 - 014
The MDVM verifies the wi_mdvm_auth_pop by:
verifying mdvm_auth_challenge using its symmetric key (mdvm_mac_symk) and validating that the timestamp is within a valid time interval of 0 minute to +5 minutes.
looking up wi_mdvm_auth_pubk and wi_devicecheck_pubk corresponding to mdvm_wi_id
verifying the signature of wi_mdvm_auth_pop using the wi_mdvm_auth_pubk from its data base
computing a hash from the transmitted wi_mdvm_auth_pubk and mdvm_auth_challenge to generate a challenge for the app attestation wi_app_attest_challenge, this is the same as WI in Step 006
The MDVM has now proven the existing possession factor (wi_mdvm_auth_prvk, wi_mdvm_auth_pubk) with the WI.
015 - 017
The MDVM collects and compares the sources to assess a device class for the WI using
the software-attested wi_device_class from the wi_mdvm_auth_pop
The MDVM checks these values against stores device class values for this WI from the database and makes plausibility checks to assess that changes in the device class and other MDVM signals seem natural. The MDVM then uses the device class to check against the database of vulnerable mobile devices for known problematic device classes, such as Remote-Code-Execution or vulnerabilities of the HKS.
018
The MDVM issues an updated mdvm_token that re-asserts the security posture of the WI. Therefore, the MDVM creates an MDVM token by signing wi_mdvm_auth_pubk and the expiry time with it's signing key mdvm_attestation_prvk.
019
The MDVM responds to the WI by sending the updated mdvm_token.