Remote WSCD Registration

This flow describes the Remote WSCD registration process as part of the broader wallet activation as introduced here.

Design Decisions

In the Remote WSCD Registration process, the Wallet Instance (WI) establishes a two-factor authentication based on a hardware-bound key pair and a PIN. The Remote WSCD responds with a Remote WSCD account identifier and stores it alongside the corresponding public keys in its database.

The Wallet Instance begins the Remote WSCD Registration by requesting a challenge from the Remote WSCD, this challenge protects the process against replay attacks. The Wallet Instance generates a hardware-bound key pair on the mobile device and transmits the public key to the Remote WSCD. This key acts as a possession factor for two-factor authentication.

For the second authentication factor, the Wallet Instance asks the user for an initial RWSCD-PIN. As the PIN management on most mobile devices is not able to achieve LoA high, the RWSCD-PIN and its retry counter are managed on the Remote WSCD. As the Remote WSCD must not know the RWSCD-PIN itself, a cryptographic key is derived from the PIN. Neither the RWSCD-PIN nor the PIN-derived key are stored persistently on the Wallet Instance. More details can be found in the document Cryptography

The Remote WSCD does not need to store any session data or state related to a specific Wallet Instance during the registration process. Instead, the process relies on cryptographically signed ("self-contained") challenges to verify the authenticity of the Wallet Instance.

ToDo

• integrate mobile device vulnerability management
• add chapter about wallet lifecycle
• add Android key attestations for wi_wia_priv
• add rate limiting/replay attack detection based on rwscd_auth_challenge

Data Flow

This section describes the data flow of the Remote WSCD Registration in a sequence diagram and a more detailed table. Artifacts in italics are further explained in the data register of the decomposition chapter.

Sequence Diagram

Detailed Description

No	Description
001	The Wallet Instance (WI) requests the Remote WSCD (RWSCD) to generate a challenge (rwscd_auth_challenge). The request is unauthenticated and state-less.
002	The RWSCD generates a structure containing a random nonce and and a timestamp of the current time and MACs it using a symmetric key (rwscd_mac_symk) as a JSON Web Token (JWT). The resulting structure is called the challenge (rwscd_auth_challenge). The key and nonce must have sufficient security properties, information on algorithms and key lengths can be found in the cryptography chapter.
003	The WB responds with the challenge (rwscd_auth_challenge) to the WI. The WI must use the challenge as a transparent string and not evaluate the JWT claims.
004	The WI generates a new hardware-bound key pair (wi_rwscd_auth_prvk and wi_rwscd_auth_pubk) which is used as the possession factor of the two-factor authentication to the RWSCD for subsequent requests. The WI must leverage the most secure, local key storage available, i.e. a Secure Element, StrongBox, SecureEnclave or TEE. See cryptography chapter for details on crypto parameters
005	The WI requests a RWSCD-PIN (user_rwscd_pin) from the user.
006	The WI receives the initial RWSCD-PIN (user_rwscd_pin) entered by the user and validates that the Wallet PIN matches the PIN security requirements. In particular, it matches the PIN input against a blocklist of trivial, repetitive patterns.
007	The WI generates a cryptographic, random salt (wi_rwscd_pin_salt), that will be used for the key derivation of the RWSCD-PIN. The salt expands the low-entropy Wallet PIN into a high-entropy cryptographic key. The salt must have sufficiently secure randomness and at least 128 bits of length. The salt is stored encrypted for the long-term, as it is required to regenerate the knowledge authentication factor together with the PIN.
008	The WI derives the cryptographic key pair (wi_rwscd_pin_prvk and wi_rwscd_pin_pubk) which is used as the knowledge factor of the two-factor authentication to the RWSCD for subsequent requests. The WI must use HKDF to derive wi_rwscd_pin_prvk from user_rwscd_pin and wi_rwscd_pin_salt, see PIN derivation. This key pair is never stored in the WI, but must be deleted after its intended usage, see PIN caching for details. The user_rwscd_pin must be deleted from memory as soon as the wi_rwscd_pin_prvk is derived.
009	The WI computes a proof of possession by signing the rwscd_auth_challenge for replay protection, and both public keys wi_rwscd_auth_pubk and wi_rwscd_pin_pubk once with the newly generated wi_rwscd_auth_prvk (the actual possession factor) and once with the wi_rwscd_pin_prvk (the knowledge factor) using ECDSA with SHA-256. The payload and both signatures are encoded as a JSON Web Signature (JWS) in JSON Serialization. The resulting structure is called wi_rwscd_register_pop. The proof of possession cross-signs each public key to bind both authentication factors together.
010	The WI requests the RWSCD to perform the registration and sends the proof of possession for the two-factor authentication (wi_rwscd_register_pop). The request is unauthenticated (as RWSCD does not know the WI yet at registration) and state-less.
011	The RWSCD verifies the self-contained rwscd_auth_challenge using its symmetric key (rwscd_mac_symk) and validating that the timestamp is within a valid time interval of 0 minute to +5 minutes.
012	The RWSCD verifies the possession factor of the proof of possession (wi_rwscd_register_pop) by verifying the first signature using the included wi_rwscd_auth_pubk with ECDSA.
013	The RWSCD verifies the knowledge factor of the proof of possession (wi_rwscd_register_pop) by verifying the second signature using the included wi_rwscd_pin_pubk with ECDSA.
014	The RWSCD optionally initializes and sets up the account with the Remote Key Management Service (RKP) Provider.
015	The RWSCD generates a unique Remote WSCD account identifier rwscd_account_id and stores the combination of rwscd_account_id, wi_rwscd_auth_pubk, wi_rwscd_pin_pubk, and an initial retry counter for the PIN in its database to register the new account.
016	The RWSCD responds with the generated Remote WSCD account identifier rwscd_account_id to the WI.
017	The WI stores the received Remote WSCD account identifier rwscd_account_id.

Remote WSCD Challenge JWT

The rwscd_auth_challenge encapsulates a verifiable challenge, that is generated and verified by the Remote WSCD. As the producer and consumer is the Remote WSCD, a MAC key rwscd_mac_symk is used for efficiency.

The rwscd_auth_challenge contains: - JOSE Header typ: as recommended by JWT BCP - JOSE Header alg: indicating HMAC-SHA256 as MAC algorithm - JWT Claim nonce: containing at least 128 bits of random - JWT Claim iat current time, indicating the issuance date

Below is a non-normative example of a rwscd_auth_challenge:

Header

{
  "typ": "wi-rwscd-auth-pop+jwt",
  "alg": "HS256"
}

Payload

{
  "nonce": "564edacb-ad81-420c-a74e-6cfbaa713d48",
  "iat": 1726214250
}

Signed by rwscd_mac_symk

Proof of possession JWS in JSON Serialization

The wi_rwscd_register_pop is a dual-authentication factor of the Wallet App, that creates a proof of the wi_rwscd_auth_prvk and the wi_rwscd_pin_prvk over the rwscd_auth_challenge.

The wi_rwscd_register_pop contains: - JOSE Header typ as recommended by JWT BCP - JOSE Header alg indicating ECDSA NIST P-256 - JOSE Header wi_rwscd_auth_pubk containing the serialized wi_rwscd_auth_pubk - JOSE Header wi_rwscd_pin_pubk containing the serialized wi_rwscd_pin_pubk - JWT Claim rwscd_auth_challenge containing the serialized rwscd_auth_challenge - JWT Claim aud referencing the URL of the Remote WSCD

Note: There is no jti parameter for potential enhanced replay protection, as we can reuse the rwscd_auth_challenge for this purpose. There is also no iat or exp parameter, because the rwscd_auth_challenge already includes a trusted timestamp. There is also no iat or exp parameter, which is added by the WI, because the rwscd_auth_challenge already includes a trusted timestamp.

Below is a non-normative example of a wi_rwscd_register_pop:

Protected headers:

{
  "typ": "wi-rwscd-register-pop+jose+json",
  "alg": "ES256",
  "wi_rwscd_auth_pubk": {
    "kty": "EC",
    "crv": "P-256",
    "x": "W01hRxCicJTneWe2-e9vXFk8GNiQpCf3NcU16xxnNVM",
    "y": "ZKN0Cy6Zzb9hBni7BKKzynK2DibeWgXe2BwXizp0KIQ"
  },
  "wi_rwscd_pin_pubk": {
    "kty": "EC",
    "crv": "P-256",
    "x": "mT3LI0y2LBP1mxbkHQhVrdi633qQEUJCyib1ot62flI",
    "y": "mVNKt_c8BV1vTK20ParZL5uQzDfPo_ZZXa5udKVsGao"
  }
}

Payload:

{
  "rwscd_auth_challenge": "eyJ0eXAiOiJyd3NjZC1hdXRoLWNoYWxsZW5nZStqd3QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3MzgzMTQ4NzYsIm5vbmNlIjoiMGRmOGQ2OTMtODUzOS00NGRkLThjMjItMTk1NDYyODZiNjQ4IiwiaWF0IjoxNzM4MzExMjc2fQ.RIcCxQglW04Z8Tw0xH1erUx2Qbbppgv-0P-84Qh3MiE",
  "aud": "https://wallet-provider-backend.eudi-wallet.de"
}

Signed by wi_rwscd_auth_prvk and wi_rwscd_pin_prvk

Complete JWS example:

{
  "payload"    : "SGVsbG8sIHdvcmxkIQ",
  "signatures" : [
    {
      "protected" : "eyJraWQiOiIxIiwiYWxnIjoiUlMyNTYifQ",
      "signature" : "XAwNAgj-Dw5CBeWG4_6LwQyJrQaAGVJmtqkl21QcIxedNV8Ft0he02eU8Ih60jjNe5FbQxrgfA84JA0isb7NkdczEW_kfX9Fknh-tdypyymrPTsP9bhLKUYfQ7nglWgVf1tukFqkAVZOLdfV7ri9we_bqZblM0pD5ysbu6hjhkLbXSSe_ZD0QfKmJFDaIHWBlB2Z0BeqSmyGQTbO6ZpmxXzICz0ANqTsCrJe6TU2CE6i1mDm0arL12VdcqO9JjD7iQkWppfD3kmRCGsSk3jdJpyWUDCYSKlPVaJJElaffwYjIBevCgfMHFO8ALwpUJc_cFcwBsyalo25JzUSzBNaXg"
    },
    {
      "protected" : "eyJraWQiOiIyIiwiYWxnIjoiRVMyNTYifQ",
      "signature" : "ckfVpM4ECSrhDGitxe5smT-z65t3C238JyrHkJw3kiOAunPTRYzHD50wzvNGXG45nUlwl7Ybg8GPlOCNyJeonw"
    }
  ]
}