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.

To Do

• add rate limiting/replay attack detection based on mdvm_auth_challenge
• add more details how to validate which MDVM signals
• add more information how databases (leaked PAP keys, vulnerable device classes) are organized and used
• provide more details on KeyGenParameterSpec.Builder settings

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 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 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 - 007	The WI creates an authentication factor by: generating a hardware-backed parent attestation key pair (wi_mdvm_parent_prvk, wi_mdvm_parent_pubk) with PURPOSE_ATTEST_KEY that is subsequently used to sign all key attestations and thus binds all generated keys to the WI's device 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 mdvm_auth_challenge for setAttestationChallenge and wi_mdvm_parent_pubk for setAttestKeyAlias function to sign the key attestation. The WI must use the most secure, local key store available, i.e. a StrongBox is preferred over a TEE. The wi_android_key_attestation is a X.509 certificate chain attesting to wi_mdvm_auth_pubk in its leaf certificate. The key must have sufficient security, information on algorithms and key lengths can be found in the cryptography chapter.
008 - 010	The WI creates an app attestation by: computing a hash from the the newly generated wi_device_class and wi_android_key_attestation to generate a challenge wi_app_attest_challenge for the app attestation utilizing the Android Play integrity API from the user device (UD) to generate the app attestation pap_playintegrity_attestation using the wi_app_attest_challenge. By providing wi_app_attest_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.
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_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.
012	The WI requests to register by sending the wi_mdvm_register_pop to the MDVM's registration endpoint. The request is authenticated.
013 - 017	The MDVM verifies the wi_mdvm_register_pop by: extracting the contained **wi_device_class* , wi_android_key_attestation* and pap_playintegrity_attestation from wi_mdvm_register_pop verifying the wi_android_key_attestation for wi_mdvm_auth_pubk according to the guideline(tbd) extracting and validating the key attestation signals according to MDVM signals extracting and verifying mdvm_auth_challenge contained in wi_android_key_attestation using its symmetric key (mdvm_mac_symk) and validating that the timestamp is within a valid time interval of 0 minute to +5 minutes. 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: re-computing the wi_app_attest_challenge from the transmitted wi_mdvm_register_pop, just like the WI for the app attestation in Step 009 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 parent attestation signing key wi_mdvm_parent_pubk 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	The WI generates a new hardware-backed key pair (wi_mdvm_reattest_prvk, wi_mdvm_reattest_pubk) with a key attestation wi_android_key_attestation utilizing mdvm_auth_challenge for setAttestationChallenge and wi_mdvm_parent_pubk for setAttestKeyAlias function to sign the key attestation. Using the attestation signing key pair (wi_mdvm_parent_prvk, wi_mdvm_parent_pubk) from the registration process, let's the MDVM proof that both wi_mdvm_auth_pubk and wi_mdvm_reattest_pubk originate from the same device. The WI must use the same key store that was used for wi_mdvm_auth_priv. The key must have sufficient security, information on algorithms and key lengths can be found in the cryptography chapter. 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.
007 - 009	See registration steps 008- 010.
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 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 . 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: extracting and verifying mdvm_auth_challenge contained in wi_mdvm_auth_pop 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_mdvm_parent_pubk corresponding to mdvm_wi_id verifying the signature of wi_mdvm_auth_pop using the wi_mdvm_auth_pubk from its data base extracting the contained wi_android_key_attestation and wi_device_class from wi_mdvm_reattest_pop verifying the wi_android_key_attestation for wi_mdvm_reattest_pubk according to the guideline(tbd) extracting and validating the key attestation signals according to MDVM signals validating that the signing key for wi_android_key_attestation matches wi_mdvm_parent_pubk from the MDVM's database checking the attestation keys used to sign wi_android_key_attestation against the database of leaked PAP keys verifying wi_mdvm_reattest_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 019, using wi_mdvm_auth_pop instead of wi_mdvm_registration_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.