Remote WSCA Operations¶

This flow describes various operations provided by the Remote WSCA, that are required for both issuance and presentation of credentials. Some of this functionality is reflected in the issuance and presentation flows of the blueprint, but not as cleanly separated as in this document. Furthermore, this page includes additional functionality not reflected in the blueprint.

Design Decisions¶

In the Remote WSCA Operation process, the WI uses the established two-factor authentication from the registration process to request a certain operation from the Remote WSCA. The Remote WSCA forwards key-related operations to the Remote WSCD and forwards the results to the WI.

The WI begins the Remote WSCA Operation by requesting a challenge from the Remote WSCA, this challenge protects the process against replay attacks. The WI creates an operation request and authenticates the request as a JSON Web Signature (JWS) in JSON serialization using two signatures, one for each authentication factor. It sends the authenticated request alongside the account identifier to the Remote WSCA.

The Remote WSCA verifies the authenticated request using the data corresponding to the account identifier. The validation sequence begins by verifying the challenge for replay detection, continues with the possession factor and concludes with the PIN, to avoid any denial attacks potentially blocking user accounts. The PIN verification and its retry counter are managed by the Remote WSCA. After verifying the authenticity of the operation request, the Remote WSCA forwards key-related operations to the Remote WSCD or handles any user management operations itself. An overview of supported operations is given in , the detailed API will be published at a later stage.

The WSCA API queries the WSCD (HSM) using PKCS#11 requests to create keys and sign data. The WSCD does not store all the private keys (e.g. rwscd_rt_prvk and rwscd_pid_device_prvk) in its internal storage, as the volume of expected keys will exceed its capacity.

In the key creation process, the WSCA queries the WSCD to generate private keys and export them as wrapped keys (rwscd_wrapped_key), which are encrypted and authenticated with the WSCD's master key and only usable from within the WSCD. The WSCA itself binds the wrapped keys to the WI's account id (rwsca_account_id) after successful two-factor authentication by using authenticated encryption to export the authenticated wrapped key (rwsca_bound_wrapped_key) to the WI.

In the signing process, the WI authenticates towards the WSCA with two-factor authentication and provides the authenticated wrapped key (rwsca_bound_wrapped_key). The WSCA verifies the binding of the authenticated wrapped key (rwsca_bound_wrapped_key) to the WI's account (rwsca_account_id) and only then forwards the signing operation to the WSCD using the wrapped key. The WSCD performs the signing request using the wrapped key and returns the signature to the WSCA, which forwards it to the WI.

Data Flow¶

This section described the data flow of the Remote WSCA Operations in a sequence diagram and a more detailed table. Artifacts in italics are further explained in the data register chapter

Sequence Diagram¶

Detailed Description¶

No	Description
001	The WI determines if its most recent mdvm_token is still valid. If the mdvm_token is not up-to-date, the WI may fetch a fresh one from the MDVM endpoint using the renewal flow for either Android or iOS.
002 - 004	The WI requests a challenge from the RWSCA challenge endpoint using an HTTP POST request, the request is unauthenticated. The RWSCA generates a JSON structure containing a random nonce and a timestamp of the current time and MACs it using a symmetric key (rwsca_mac_symk) as a JSON Web Token (JWT), the resulting structure is the rwsca_auth_challenge. The RWSCA responds to the WI with the rwsca_auth_challenge in the HTTP payload. The WI uses the challenge as a transparent string and does not evaluate the JWT claims. The RWSCA does not store the challenge after creation, thus the operation is stateless.
005	The WI generates the operation (wi_rwsca_operation_request) that shall be performed by the Remote WSCA. The supported operations are specified in the operations section.
006 - 007	The WI requests and receives the RWSCA PIN (user_rwsca_pin) from the user.
008	The WI derives the cryptographic key pair (wi_rwsca_pin_prvk and wi_rwsca_pin_pubk) which is used as the knowledge factor of the two-factor authentication to authorize the operation to the RWSCA. The WI must use HKDF to derive wi_rwsca_pin_prvk from user_rwsca_pin and wi_rwsca_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_rwsca_pin must be deleted from memory as soon as the wi_rwsca_pin_prvk is derived.
009	The WI computes a proof of possession by signing the payload of rwsca_account_id for identification, rwsca_auth_challenge for freshness and to enable replay protection, the mdvm_token and the requested operation wi_rwsca_operation_request with: the possession factor wi_mdvm_auth_prvk the knowledge factor wi_rwsca_pin_prvk and encodes it as a JSON Web Signature (JWS) in JSON Serialization. The resulting structure is called wi_rwsca_auth_pop. The proof of possession is signing the public keys and the wi_rwsca_operation_request to bind both authentication factors and the requested operation together.
010	The WI requests the RWSCA to perform the operation by sending the proof of possession (wi_rwsca_auth_pop) for the two-factor authentication including the requested operation wi_rwsca_operation_request to be performed. The request is authenticated.
011	The RWSCA verifies the rwsca_auth_challenge included in the wi_rwsca_auth_pop by verifying the MAC using rwsca_mac_symk and validating that the timestamp is within a valid time interval of 0 minute to +5 minutes. This step ensures replay protection beyond the valid time interval of the challenge.
012	The RWSCA fetches the public keys for the possession factor wi_mdvm_auth_pubk and the knowledge factor wi_rwsca_pin_pubk from the database using the provided account identifier rwsca_account_id included in wi_rwsca_auth_pop.
013 - 015	The RWSCA validates the security posture of the WI by verifying the mdvm_token with mdvm_attestation_pubk and checks that it is still valid. The RWSCA has a trusted, out-of-band mechanism towards the MDVM to fetch the valid mdvm_attestation_pubk. The RWSCA verifies the first signature of the received proof of possession (wi_rwsca_auth_pop) for the WI's possession factor using wi_mdvm_auth_pubk from the mdvm_token. Lastly, the RWSCA verifies that the used key wi_mdvm_auth_pubk is the same in wi_rwsca_auth_pop and in the database. This verification must be performed before the PIN validation to prevent denial of service or malicious locking for specific accounts. The database lookup is not subject to prevention of distributed denial of service attacks, as these attacks need to be mitigated further up in the infrastructure layer.
016 - 018	The RWSCA fetches the retry counter rwsca_pin_retry_counter from the database using the provided account identifier rwsca_account_id, validate that the retry counter has not exceeded retry limit and decreases the retry counter. All the operations related to the PIN retry counter must happen in a single database transaction, i.e. the operation must fail if the rwsca_pin_retry_counter is already at 0 and it must be prevented that multiple concurrent requests allow to circumvent these checks for more tries than intended, see cryptography chapter for details. The RWSCA then verifies the second signature of the proof of possession wi_rwsca_auth_pop using the public key wi_rwsca_pin_pubk from the database. If the verification is successful, the rwsca_pin_retry_counter must be reset to the initial value (maximum retries).
019	The RWSCA requests cryptographic operation to the RWSCD based on the wi_rwsca_operation_request as described in the operations section. Some operations may not involve the HSM, e.g. changing the RWSCA PIN.
020	The RWSCA responds with the return value of operation (rwsca_operation_result).

Authenticated Remote WSCA Operations¶

This section describes the wi_rwsca_operation_request and rwsca_operation_result offered by the Remote WSCA. The "Create Key" and "Sign Data" operations fulfill the definition of "wallet cryptographic operations" as defined by CIR (EU) 2024/2979. All operations are synchronous, stateless and require user authentication.

Operation	Description
Create Keys	Create one or more cryptographic keys in the HSM and optionally a WTE, e.g. for PID device binding keys or for refresh token keys.
Sign Data	Sign data with a cryptographic key stored in the HSM, e.g. for creating proof of possessions for PID presentation or refresh token usage.
Change PIN	Change the RWSCA PIN used as the knowledge factor for authentication.
Delete Account	Delete all data that is stored or related to a wallet instance.
Supported Algorithms	Provide a list of all supported cryptographic algorithms, user for negotiation with PID and EAA Providers.

Note: The Delete Key operation is not part of the Remote WSCA, as the WI itself can delete rwsca_bound_wrapped_key to enforce delete the key.

Create Key¶

Sign data¶

Remote WSCA Challenge JWT¶

Defined in Remote WSCA Registration

Proof of possession JWS in JSON Serialization¶

The wi_rwsca_auth_pop is a two factor authentication of the Wallet App, that creates a proof of the wi_mdvm_auth_prvk and the wi_rwsca_pin_prvk over the rwsca_auth_challenge.

The wi_rwsca_auth_pop contains:

JOSE Header typ as recommended by JWT BCP
JOSE Header alg indicating ECDSA NIST P-256
JWT Claim aud referencing the URL of the Remote WSCA
JWT Claim rwsca_auth_challenge containing the serialized rwsca_auth_challenge
JWT Claim wi_rwsca_op_id identifying the wi_rwsca_operation_request
additional JWT claims needed for wi_rwsca_operation_request arguments

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

Below is a non-normative example of a wi_rwsca_auth_pop:

Protected headers:

{
  "typ": "wi-rwsca-auth-pop+jose+json",
  "alg": "ES256"
}

Payload:

{
  "aud": "https://wallet-provider-backend.eudi-wallet.de",
  "rwsca_auth_challenge": "eyJ0eXAiOiJyd3NjZC1hdXRoLWNoYWxsZW5nZStqd3QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3MzgzMTQ4NzYsIm5vbmNlIjoiMGRmOGQ2OTMtODUzOS00NGRkLThjMjItMTk1NDYyODZiNjQ4IiwiaWF0IjoxNzM4MzExMjc2fQ.RIcCxQglW04Z8Tw0xH1erUx2Qbbppgv-0P-84Qh3MiE",
  "rwsca_op_id": "SIGN",
  "rwsca_bound_wrapped_key": "...", 
  "wi_rwsca_digest_hash": "0fafdefcad0023807f98aad159f42eba57279517444f5e0f138299cce367362f"
}

Signed by wi_mdvm_auth_prvk and wi_rwsca_pin_prvk

Complete JWS example:

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

Wallet Trust Evidence¶

The WTE (rwsca_rt_wte or rwsca_pid_device_wte) is a signed attestation made by the Remote WSCA that attest the validity of the cryptographic keys it manages. The Wallet Trust Evidence (WTE) is then used by the Wallet Instance towards Issuers. The WTE reuses the key attestation as described in OpenID4VCI Annex D.

It's JWT Header contains:

alg: A digital signature algorithm identifier that signed the key attestation
typ: key-attestation+jwt
x5c: The X.509 Certificate chain of the Remote WSCA using rwscd_wte_auth_prvk / rwscd_wte_auth_pubk

It's JWT payload contains:

iat: Integer for the time at which the key attestation was issued using the syntax defined in [RFC7519].
exp: Integer for the time at which the key attestation and the key it is attesting expire, using the syntax defined in [RFC7519].
attested_keys: Array containing the created keys rwscd_pid_device_pubk[]
key_storage: Array containing the value iso_18045_high if our Remote WSCD meets the assurance level.
user_authentication: Array containing the value iso_18045_high if our Remote WSCA meets the assurance level.
nonce: an optional nonce provided by the Issuer as c_nonce from the Nonce Endpoint and send by the Wallet to the Remote WSCA through the Secure Area interface
status: not used yet until we implement revocation chaining

Below is a non-normative example of a rwsca_rt_wte or rwsca_pid_device_wte:

Headers:

{
  "typ": "key-attestation+jwt",
  "alg": "ES256",
  "x5c": ["MIIDQjCCA..."]
}

Payload

{
  "iat": 1516247022,
  "exp": 1541493724,
  "key_storage": [ "iso_18045_high" ],
  "user_authentication": [ "iso_18045_high" ],
  "nonce": "wKI4LT17ac15ES9bw8ac4",
  "attested_keys": [
    {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    },
    {
      "kty": "EC",
      "crv": "P-256",
      "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
      "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
    }
  ]
}

Signed by rwscd_wte_auth_prvk