Mobile Device Vulnerability Management Flows¶

Design Decision¶

stateful MDVM endpoint because:
- plausibility checks
- using iOS DeviceCheck attestation for every MDVM check likely are affected into rate limits imposed by Apple
- using iOS DeviceCheck assertion is the only way to use attested hardware-backed keys to re-identify the wallet instance, but is inherently stateful
- using iOS DeviceCheck assertion allows us to validate the usage counter
- using Android device-specific attestation key to sign all other Android KeyMint keys allows us to associate all keys to a particular device
- encapsulate Android/iOS-specific mechanisms to the MDVM endpoints, WB and RWSCD should have the same code path for Android/iOS
state-less design does not match with iOS device check attestation/assertion strategy
issuing short-lived tokens to avoid backend-to-backend calls that may impact scalability and performance

Flows¶

The sequence diagrams for registering and issuance/renewal of an MDVM token is divided by WI operating system:

MDVM Token¶

The mdvm_token is an assertion by the MDVM about the security posture of the device. It is bound to a wi_mdvm_auth_priv / wi_mdvm_auth_pubk key pair and attests to an expiry time. WB and RWSCD must fetch the valid mdvm_attestation_pubk out-of-band.

The mdvm_token contains:

JOSE Header typ as recommended by JWT BCP
JOSE Header alg indicating ECDSA NIST P-256
JOSE Header kid: A key identifier for mdvm_attestation_pubk
JWT Claim exp containing the expiry time of the MDVM token
JWT Claim cnf containing the serialized wi_mdvm_auth_pubk

Below is a non-normative example of a mdvm_token:

Protected headers:

{
  "typ": "mdvm-token-jwt",
  "alg": "ES256",
  "kid": 1
}

Payload:

{
  "exp": 1726214250,
  "cnf": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
}

Signed by mdvm_attestation_prvk

Challenge JWT¶

Defined in Wallet Registration.