Mobile Device Vulnerability Management for Android

This flow describes the process of an Android Wallet Instance (WI) registering at the Mobile Device Vulnerability Management (MDVM) endpoint as described in the mobile devices chapter.

Data Flow

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.

MDVM Registration

Detailed Description

No	Description
001	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 JWT as an opaque 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 Android Build API to assess it's device class utilizing Build.VERSION.RELEASE, Build.VERSION.SECURITY_PATCH, Build.MODEL, Build.PRODUCT, Build.HARDWARE, Build.ID. The WI encodes this software-attested information as wi_device_class.
006	The WI computes a challenge that is used for both Android key attestation and Play Integrity. Therefore, the WI generates wi_platform_attestation_challenge by calculating the SHA-256 Hash of the mdvm_auth_challenge. It is necessary to hash the backend-provided challenge, as the self-contained challenge may exceed the size limitations of the platform attestation challenges.
007	The WI creates an authentication factor by: generating a hardware-backed key pair (wi_mdvm_auth_prvk, wi_mdvm_auth_pubk) with PURPOSE_SIGN and a key attestation wi_android_key_attestation utilizing wi_platform_attestation_challenge for setAttestationChallenge. ensuring the most secure, local key store available is used, i.e. a StrongBox is preferred over a TEE making sure the key has sufficient security levels, information on algorithms and key lengths can be found in the cryptography chapter. requesting the wi_android_key_attestation, which is a X.509 certificate chain attesting to wi_mdvm_auth_pubk in its leaf certificate.
008 - 009	The WI creates an app attestation by: utilizing the Android Play integrity API from the user device (UD) to generate the app attestation pap_playintegrity_attestation using the wi_platform_attestation_challenge. By providing wi_platform_attestation_challenge, the app attestation is bound to this particular registration request and thus it is ensured that pap_playintegrity_attestation and wi_android_key_attestation belong 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. 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. The PAP signs the app attestation pap_playintegrity_attestation using pap_attestation_auth_prvk and returns it to the WI. The detailed contents and format of the Android Play Integrity verdict token are described in the app attestation guideline and the MDVM signals.
010	The WI generates a proof of possession by signing the following content with the newly generated wi_mdvm_auth_prvk: the mdvm_auth_challenge that was used for wi_platform_attestation_challenge the version of the device and the software wi_device_class the wi_android_key_attestation (which includes wi_mdvm_auth_pubk and mdvm_auth_challenge) the optional Play Integrity verdict pap_playintegrity_attestation . The message is encoded as a JSON Web Token (JWT), the resulting structure is called wi_mdvm_register_pop.
011	The WI requests to register by sending the wi_mdvm_register_pop to the MDVM's registration endpoint. The request is authenticated.
012 - 017	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. generating the wi_platform_attestation_challenge from the mdvm_challenge, equivalent to the Step 006 performed by the WI verifying the wi_android_key_attestation for wi_mdvm_auth_pubk and wi_platform_attestation_challenge according to the guideline(tbd) extracting and validating the key attestation signals according to MDVM signals verifying checking the attestation keys used to sign wi_android_key_attestation against the database of leaked PAP keys verifying the signature of wi_mdvm_register_pop using the wi_mdvm_auth_pubk proven by the key attestation The MDVM has now established a proven authentication factor with the WI.
018	The MDVM verifies the pap_playintegrity_attestation by: verifying the Android Play integrity verdict pap_playintegrity_attestation using pap_attestation_auth_pubk as described in the app attestation guideline extracting and validating the app attestation signals according to MDVM signals
019 - 021	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 "attestationIdModel", "attestationIdProduct", "attestationIdDevice", "osVersion" and "osPatchLevel" from wi_android_key_attestation 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.
022	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 wi_mdvm_auth_pubk as a knowledge factor to authenticate the WI the WI's device class
023	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.
024	The MDVM responds to the WI by sending the identifier mdvm_wi_id and the initial mdvm_token.

Renewal of MDVM Token

Detailed Description

No	Description
001	See registration step 001.
002 - 004	See registration steps 002- 004.
005	See registration step 005.
006	See registration step 006.
007	A new key pair The new key pair (wi_mdvm_reattest_prvk, wi_mdvm_reattest_pubk) is generated, equivalent to (wi_mdvm_auth_prvk, wi_mdvm_auth_pubk) in registration step 007. The new key pair (wi_mdvm_reattest_prvk, wi_mdvm_reattest_pubk) is needed, because key attestations cannot be re-generated for existing keys, only while creating new keys. Hence, this is a throw-away key and the WI may delete the key after Step 010.
008 - 009	See registration steps 008- 009.
010	The WI generates a proof of possession by multi-signing the following content with both the newly generated wi_mdvm_reattest_prvk and the existing key from registration wi_mdvm_auth_prvk: the WI's account identifier mdvm_wi_id the mdvm_auth_challenge that was used for wi_platform_attestation_challenge the version of the device and the software wi_device_class the wi_android_key_attestation for the throw away key(which includes wi_mdvm_reattest_pubk and mdvm_auth_challenge) the optional Play Integrity verdict pap_playintegrity_attestation Signing the message with both keys gives the assurance that the fresh MDVM signals attested to wi_mdvm_reattest_prvk belong to the WI's account mdvm_wi_id bound to wi_mdvm_auth_prvk. The message is encoded as a JSON Web Token (JWT), the resulting structure is called wi_mdvm_auth_pop.
011	The WI requests renew the MDVM token by sending the wi_mdvm_auth_pop to the MDVM's renewal endpoint. The request is authenticated.
012 - 019	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 corresponding to mdvm_wi_id verifying the signature of wi_mdvm_auth_pop using the wi_mdvm_auth_pubk from its data base generating the wi_platform_attestation_challenge from the mdvm_challenge, equivalent to the Step 006 performed by the WI verifying the wi_android_key_attestation for wi_mdvm_reattest_pubk and wi_platform_attestation_challenge according to the guideline(tbd) extracting and validating the key attestation signals according to MDVM signals verifying checking the attestation keys used to sign wi_android_key_attestation against the database of leaked PAP keys verifying wi_mdvm_auth_pop using the wi_mdvm_reattest_pubk from the key attestation The MDVM has now received and verified updated MDVM signals for the WI.
020	See registration step 018, using wi_mdvm_auth_pop instead of wi_mdvm_register_pop.
021 - 024	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 "attestationIdModel", "attestationIdProduct", "attestationIdDevice", "osVersion" and "osPatchLevel" from wi_android_key_attestation 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.
025	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.
026	The MDVM responds to the WI by sending the updated mdvm_token.