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
- encapsulate Android/iOS-specific mechanisms to the MDVM endpoints, WB and RWSCA 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
not using Android device-specific attestation key ("parent key" or "intermediate key") to associate all keys to a particular device, as it may not be sufficiently well supported across the Android ecosystem
- we may re-consider this if we have better insight and resources to test this

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_prvk / wi_mdvm_auth_pubk key pair and attests to an expiry time. WB and RWSCA 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: containing a key identifier for mdvm_attestation_pubk
JWT Claim iss containing a URN to represent the current deployment environment, e.g. dev/staging/prod
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:

{
  "iss" "urn:german-national-wallet:wallet-backend:sandbox",
  "exp": 1726214250,
  "cnf": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
}

Signed by mdvm_attestation_prvk

Challenge JWT¶

Defined in Wallet Registration.

Proof of possessions¶

The wi_mdvm_auth_pop is a proof of possession encoded as an HTTP Message Signature. The signature includes the HTTP path and all assets mentioned in the sequence diagrams (e.g. mdvm_auth_challenge, mdvm_wi_id, ...), signed as either a JSON structure in the HTTP body or in HTTP header. The signed HTTP path component serves as an identifier for either MDVM registration or renewal.

The proof of possession also serves to assert the possession factor using the wi_mdvm_auth_prvk.

Additional details on proof of possessions using HTTP Message signatures, will be added in a dedicated section.