Cryptography¶
Description of the cryptographic methods for achieving the security objectives, in particular the key management and the configuration of the cryptographic methods.
Identification Means, Authentication Means, and 2FA¶
Electronic identification means is defined by eIDAS Regulation (EU) No 2024/1183 as “a material and/or immaterial unit containing person identification data and which is used for authentication for an online service or, where appropriate, for an offline service”. The identification means consists of a refresh token which contains the identity attributes in an PP-encrypted and PP-authenticated form, and several PID credentials which contain the identity attributes in a PP-authenticated form. The refresh token and PID credentials are each bound to an authentication means via a public/private key pair (rwscd_rt_pubk / rwscd_rt_prvk, rwscd_pid_device_pubk / rwscd_pid_device_prvk). Authenticity of the PID credentials is ensured via signing by the PP (pp_pid_auth_prvk). Authenticity of the refresh token is ensured via a method up to the PP.
The authentication means consists of the public/private key pairs (rwscd_rt_pubk / rwscd_rt_prvk, rwscd_pid_device_pubk / rwscd_pid_device_prvk) managed in a RWSCD and a 2FA that authenticates the user to their corresponding user account in the RWSCA and is used to unlock the creation of public/private key pairs for the user or unlock signing operations with the public/private key pairs for the user.
The 2FA consists of a possession factor in the form of a public/private key pair in a hardware-backed key store (wi_mdvm_auth_pubk/ wi_mdvm_auth_prvk) in the user's smartphone and a knowledge factor (user_rwsca_pin) that is entered via the WI and is used to derive a public/private key pair (wi_rwsca_pin_pubk/ wi_rwsca_pin_prvk) at runtime. The possession of both private keys is evaluated in the RWSCA (which is part of the WP) using proof of possessions.
Due to limited storage capacity inside the WSCD (HSM), the private keys rwscd_rt_prvk and rwscd_pid_device_prvk are encrypted by the WSCD with rwscd_master_key and bound to the rwsca_account_id by the WSCA by authenticated encryption using rwscd_aead_symk and stored as rwsca_bound_wrapped_key on the WI.
The following picture illustrates the relations between the various entities and their keys and artifacts:
Note: Not all keys and other assets in the table can be found in the graphic.
Cryptographic Key Algorithms and Lifecycle¶
The following table lists sensitive key assets, where each column describes:
- Name: asset name as listed in the data register and used throughout this document
- Algorithm: the cryptographic algorithm for signing/encryption/MAC
- acknowledges algorithms and curves listed in the Blueprint for the EUDI Wallet Ecosystem in Germany
- Generation: component as named in the decomposition, which generates the cryptographic key
- Access: components as named in the decomposition, which have access to the cryptographic key
- for symmetric keys: components share the key itself (by importing them from the component that generated the key)
- for private keys: components have access to private key operations (e.g. generation or signing) without having access to the key itself
- for public keys: components possess the key for verification, either shared through PKIs, trust lists, or directly
- Exchange: method for exchanging keys
- for symmetric keys: method for export and import of key material
- for public keys: method for sharing the public key material, e.g. PKI, trust list or out-of-band
- Lifetime: the amount of time that a key is deemed active and must be maintained by its component
- the lifetime is depending on the underlying token (e.g.
pp_refresh_tokenforrwscd_rt_prvk) and the rotation period (e.g.rwscd_aead_symklifetime depends on lifetime ofrwscd_rt_prvkand its own rotation period)
- the lifetime is depending on the underlying token (e.g.
- Rotation period: the amount of time after which the key is replaced (called "key rotation" or "roll-over") by a newly generated key.
- Usage: description of the key's primary use case
| Name | Algorithm | Generation | Access | Exchange | Lifetime | Rotation period | Usage |
|---|---|---|---|---|---|---|---|
| rwscd_master_key | AES256 | RWSCD (HSM) | RWSCD | - | 780 days | 30 days | encryption (wrapping) of user private keys for external storage at the WSCA |
| rwscd_aead_symk | AES256-GCM | RWSCD (HSM) | RWSCA (PKCS#11 with mTLS) | - | 780 days | 30 days | encryption (wrapping) of user private keys for external storage at the WI |
| rwscd_pin_symk | HMAC-SHA256 | RWSCD (HSM) | RWSCA (PKCS#11 with mTLS) | - | 60 day | 30 day | authenticate PIN session token |
| rwscd_challenge_symk | HMAC-SHA256 | RWSCD (HSM) | RWSCA (PKCS#11 with mTLS) | - | 60 day | 30 day | authenticate RWSCA challenges |
| wb_challenge_symk | HMAC-SHA256 | WB (HSM) | WB (PKCS#11 with mTLS) | - | 60 day | 30 day | authenticate WB challenges |
| mdvm_challenge_symk | HMAC-SHA256 | MDVM (HSM) | MDVM (PKCS#11 with mTLS) | - | 60 day | 30 day | authenticate MDVM challenges |
| wb_wia_auth_prvk | ECDSA-SHA256 with NIST P-256 | WB (HSM) | WB (PKCS#11 with mTLS) | - | depends on ecosystem PKI | depends on ecosystem PKI | signing Wallet Instance Attestation |
| wb_wia_auth_pubk | ECDSA-SHA256 with NIST P-256 | WB (HSM) | public | Trust list | depends on ecosystem PKI | depends on ecosystem PKI | verifying Wallet Instance Attestation |
| rwscd_wte_auth_prvk | ECDSA-SHA256 with NIST P-256 | RWSCD (HSM) | RWSCD, RWSCA (PKCS#11 with mTLS) | - | depends on ecosystem PKI | depends on ecosystem PKI | signing Wallet Trust Evidence |
| rwscd_wte_auth_pubk | ECDSA-SHA256 with NIST P-256 | RWSCD (HSM) | public | Trust list | depends on ecosystem PKI | depends on ecosystem PKI | verifying Wallet Trust Evidence |
| mdvm_attestation_prvk | ECDSA-SHA256 with NIST P-256 | MDVM (HSM) | MDVM (PKCS#11 with mTLS) | - | 180 days | 90 days | signing MDVM tokens |
| mdvm_attestation_pubk | ECDSA-SHA256 with NIST P-256 | MDVM (HSM) | RWSCA, WB, MDVM | out-of-band/manually | 180 days | 90 days | verifying MDVM tokens |
| wi_mdvm_auth_prvk | ECDSA-SHA256 with NIST P-256 | HKS | HKS | - | unlimited | - | signing proof-of-possession for possession factor of 2FA |
| wi_mdvm_auth_pubk | ECDSA-SHA256 with NIST P-256 | HKS | HKS, RWSCA, WB , MDVM | MDVM/RWSCA/WB API (TLS) within mdvm_token | unlimited | - | verifying proof-of-possession for possession factor of 2FA |
| wi_rwsca_pin_salt | random value with 128bits | WI | WI | - | unlimited | - | used as salt for derivation of wi_rwsca_pin_prvk from user_rwsca_pin |
| wi_rwsca_pin_prvk | ECDSA-SHA256 with NIST P-256 | WI | WI | - | < 10 seconds | - | signing proof-of-possession for knowledge factor of 2FA, exchanged for PIN session token |
| wi_rwsca_pin_pubk | ECDSA-SHA256 with NIST P-256 | WI | WI, RWSCA | RWSCA API (TLS) within wi_rwsca_auth_pop | unlimited | - | verifying proof-of-possession for knowledge factor of 2FA |
| wi_wia_prvk | ECDSA-SHA256 with NIST P-256 | HKS | HKS | - | one-time use, < 10 minutes | - | signing proof-of-possession for Wallet Instance Attestation |
| wi_wia_pubk | ECDSA-SHA256 with NIST P-256 | HKS | HKS, WB, PP | WB API/OpenID4VCI (TLS) within wb_wia | one-time use, < 10 minutes | - | verifying proof-of-possession for Wallet Instance Attestation |
| rwscd_rt_prvk | ECDSA-SHA256 with NIST P-256 | RWSCD (HSM) | RWSCA (PKCS#11 with mTLS), WI(2FA) | - | 720 days | < 720 days | signing proof-of-possession for refresh token, stored as rwsca_bound_wrapped_key at the WI |
| rwscd_rt_pubk | ECDSA-SHA256 with NIST P-256 | RWSCD (HSM) | WI, PP | OpenID4VCI (TLS) within rwsca_wte | 720 days | < 720 days | verifying proof-of-possession for refresh token, embedded within the pp_refresh_token |
| rwscd_pid_device_prvk | ECDSA-SHA256 with NIST P-256 | RWSCD (HSM) | RWSCA (PKCS#11 with mTLS), WI(2FA) | - | one-time use, 60 days | < 60 days | signing proof-of-possession for PID Credential, stored as rwsca_bound_wrapped_key at the WI |
| rwscd_pid_device_pubk | ECDSA-SHA256 with NIST P-256 | RWSCD (HSM) | WI, PP, RP | OpenID4VCI (TLS) within rwsca_wte, OpenID4VP (TLS) within pp_pid_credential | one-time use, 60 days | < 60 days | verifying proof-of-possession for PID Credential, embedded within the pp_pid_credential |
Token Lifecycle¶
The following table lists other sensitive assets, where each column describes:
- Name: asset name as listed in the data register and used throughout this document
- Generation: component as named in the decomposition, which generates the token
- Access: components as named in the decomposition, which have access to the token
- Exchange: method for exchanging tokens
- Lifetime: the amount of time that a key is deemed active and must be maintained by its component
- the lifetime is depending on the underlying token (e.g.
pp_refresh_tokenforrwscd_rt_prvk) and the rotation period (e.g.rwscd_aead_symklifetime depends on lifetime ofrwscd_rt_prvkand its own rotation period)
- the lifetime is depending on the underlying token (e.g.
- Rotation period: the amount of time after which the token is renewed/refreshed.
- Usage: description of the token's primary use case
| Name | Generation | Access | Exchange | Lifetime | Scope | Usage |
|---|---|---|---|---|---|---|
| rwsca_auth_challenge | RWSCA | RWSCA, WI | RWSCA API (TLS) | one-time use, 5 minutes | one RWSCA operation | preventing replay attacks |
| mdvm_auth_challenge | MDVM | MDVM, WI | MDVM API (TLS) | one-time use, 5 minutes | one MDVM operation | preventing replay attacks |
| wb_auth_challenge | WB | WB, WI | WB API (TLS) | one-time use, 5 minutes | one WB operation | preventing replay attacks |
| mdvm_token | MDVM | MDVM, WI, WB, RWSCA | MDVM API (TLS) | 24 hours | multiple RWSCA or WB operations | attesting security posture of the WI to RWSCA/WB |
| rwsca_pin_session_token | RWSCA | RWSCA, WI, PP | RWSCA API (TLS) | 5 minutes | multiple RWSCA operations | attesting knowledge factor authentication of the WI |
| wb_wia | WB | WB, WI, PP | WB API / OpenID4VCI (TLS) | one-time use, 10 minutes | one issuance | attesting authenticity, integrity and non-revocation of the WI to PP |
| wb_wia_status | WB | WB, WI, PP | WB API/OpenID4VCI (TLS) within wb_wia | 60 days | one issuer | revocation chaining |
| rwsca_wte | RWSCA | RWSCA, WI, PP | RWSCA API / OpenID4VCI (TLS) | one-time use, 10 minutes | one PID batch | attesting authenticity and integrity of keys in the RWSCA to PP |
| rwsca_wte_status | RWSCA | RWSCA, WI, PP | RWSCA API/OpenID4VCI (TLS) within rwsca_wte (TLS) | 720 days | one issuer | revocation chaining |
| rwscd_wrapped_key | RWSCD | RWSCD, RWSCA | PKCS#11 with mTLS | 60 / 720 days | one PID credential | wrapping rwscd_rt_prvk and rwscd_pid_device_prvk |
| rwsca_bound_wrapped_key | RWSCA | RWSCA, WI, PP | RWSCA API (TLS) | 60 / 720 days | one PID credential | wrapping rwscd_wrapped_key and binding to WI |
| pp_refresh_token | PP | RWSCA, WI, PP | OpenID4VCI (TLS) | 720 days | one PID | PID re-issuance |
| pp_access_token | PP | RWSCA, WI, PP | OpenID4VCI (TLS) | < 10 minutes | one PID batch | PID issuance and re-issuance |
| pp_pid_credential | PP | RWSCA, WI, PP | OpenID4VCI/OpenID4VP (TLS) | one-time use, 60 days | one PID credential | PID presentation |
Lifecycle Considerations and Dependencies¶
The lifecycle of assets has several interdependencies, that impact the lifetime and rotation periods of assets such as keys and tokens. In particular the following constraints exist:
- the wb_wia_status lifetime limits the lifetime of the pp_pid_credential due to revocation chaining requirements
- further requirements for the lifetime of the WIA and the underlying wb_wia_auth_prvk / wb_wia_auth_pubk may originate from ecosystem rules
- the rwsca_wte_status lifetime limits the lifetime of the pp_refresh_token and pp_pid_credential due to revocation chaining requirements
- further requirements for the lifetime of the WTE and the underlying rwscd_wte_auth_prvk / rwscd_wte_auth_pubk may originate from ecosystem rules
- the pp_refresh_token limits the lifetime pp_pid_credentials
- the lifetime of rwscd_wrapped_key and rwsca_bound_wrapped_key for the pp_refresh_token's private key depend on the lifetime of pp_refresh_token
- the lifetime of rwscd_wrapped_key and rwsca_bound_wrapped_key for the pp_pid_credential's private key depend on the lifetime of pp_pid_credential
- the lifetime of rwscd_master_key and rwscd_aead_symk depend on the lifetime of rwscd_wrapped_key and rwsca_bound_wrapped_key, as they are required to enable for the key unwrapping of these keys
- lifetime of 780 days = 720 days lifetime of rwscd_rt_prvk + 30 days rotation period + 30 days grace period
- the Wallet Provider backend internal artifacts and their underlying keys have no further dependencies:
- rwsca_auth_challenge, mdvm_auth_challenge and wb_auth_challenge are valid for only 5 minutes, their underlying symmetric keys are rotated every 30 days
- rwsca_pin_session_token is valid for 10 minutes, its underlying key is rotated every day
- mdvm_token is valid for 24 hours, the underlying key mdvm_attestation_prvk is rotated every 6 months to avoid additional internal PKI
In summary, lifetime of WIA and WTE limit the lifetime of PID credentials and their refresh token. In turn the maximum lifetime of PID credentials and their refresh token create requirements for the wrapping keys of the RWSCA/D.
Critical Assets¶
Critical assets according to CIR (EU) 2024/2979 are "assets within or in relation to a wallet unit of such extraordinary importance that where their availability, confidentiality or integrity are compromised, this would have a very serious, debilitating effect on the ability to rely on the wallet unit". With regard to the WSCD/WSCA, the primary example for such an event would be the impersonation with the PID. Under this consideration, compromising the availability, confidentiality or integrity of keys which directly can be used to authenticate as the holder of the PID could have such "very serious, debilitating effect on the ability to rely on the wallet unit", therefore the following artifacts of Remote WSCD are directly rated as critical assets:
- rwscd_rt_prvk
- rwscd_pid_device_prvk
There are additional assets managed within the WSCA and on the WI that are related to creation and usage of these direct critical assets, such as wi_mdvm_auth_prvk, wb_wia_auth_prvk or rwscd_wte_auth_prvk. Compromising a single additional asset alone is not sufficient to directly impersonate a PID or use critical keys for that impersonation. This opens up additional opportunities to prevent or hinder successful impersonation based on the compromise of a set of these additional assets. Since there are threat scenarios that target a set of additional assets and can lead to unauthorized use of critical assets, these are of course relevant to the overall security, but not as critical as the critical assets mentioned above.