Skip to main content

NL-CS-WSCA: Protection Profile for WSCA in a remote HSM architecture

NL-CS-WSCA: Protection Profile for WSCA in a remote HSM architecture

Download PDF (3.2 MB, 72 pages)Read the full text59 requirements
Cover page of the document, as printed
Document referenceNL-WSCA
VersionRC1.1
StatusRelease Candidate
Date29/10/2026
Document typeProtection Profile for WSCA in a remote HSM architecture
Parent frameworkNL-CS (parts1/2/3/4)
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetEuropean Digital Identity Wallets
Primary audienceScheme Owners, Evaluation Laboratories; CABs, EUDI Wallet providers
Secondary audienceEUDI Wallet ecosystem stakeholders
Assurance levelHigh/High
How to read this page

This page summarises the document. Every statement points to the section and page of the authoritative PDF it comes from: click a reference such as §6.1, p. 10 to open that page. If this summary and the PDF differ, the PDF applies.

What this document is​

This Protection Profile (PP) applies to the WSCA-BE (the Wallet Secure Cryptographic Application running on Wallet Provider backend infrastructure) as a standalone Target of Evaluation (TOE) for Common Criteria evaluation under the EUCC scheme established by Commission Implementing Regulation (EU) 2024/482 (Background, p. 4). A certificate of conformity issued against this PP may serve as an assurance input for national wallet certification schemes pursuant to Article 4 of Commission Implementing Regulation (EU) 2024/2981 (Background, p. 4). The PP is developed based on Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183 (eIDAS 2.0) and Commission Implementing Regulation (EU) 2024/2981 (Background, p. 4). It defines the security problem (assets, threats, OSPs, assumptions), security objectives, security functional requirements and security assurance requirements for this TOE (§3–§7, p. 21–50).

Scope and object of certification​

  • TOE definition: the TOE is the WSCA deployed in the wallet provider's back-end infrastructure ("WSCA-BE (TOE)"); it operates as an authenticated remote signing service that verifies the user's identity and authorisation, validates the wallet instance key binding, and instructs the WSCD-HSM to generate signing keys and to sign data submitted by the Wallet Instance (§1.2, p. 7).
  • TOE type: an application (WSCA) on a dedicated hardened backend server; Article 2(4) of CIR (EU) 2024/2981 defines the WSCA as "an application that manages critical assets by being linked to and using the cryptographic and non-cryptographic functions provided by the WSCD" (Background, p. 4); (§1.2.5, p. 10).
  • The TOE manages the full lifecycle of Attested key pairs (and optionally WIA device-binding key pairs), but the attested private keys never leave the security context of the WSCD-HSM; all cryptographic operations are handled by the WSCD-HSM (§1.2, p. 7).
  • TOE boundary: the WSCA-BE does NOT include the WSCD-HSM hardware or firmware, the Wallet Instance application or device, the log server, the Internet-facing gateway or load balancer, or any wallet provider backend services other than the WSCA-BE module itself (§1.2.6, p. 12).
  • Required non-TOE hardware/software: WSCD-HSM (following CEN EN PP 419 221-5 or an equivalent PP); Hardened Server (hardened against remote side-channel and microarchitectural attacks); Gateway Server (at least DDoS protection, intrusion detection, antivirus and firewall); Database (external storage of TOE assets); Log Server (environment ensures log data is not deleted); Wallet Provider Backend; Wallet Instance (certified according to (EU) 2024/2981); Reliable Time Source (§1.2.5.1, p. 10–11).
  • "Remote HSM architecture" (what is where): the WSCA executes on Wallet Provider backend infrastructure (WSCA-BE), the WSCD is implemented as a certified remote HSM that manages the critical private keys of the Wallet Unit (the attested keys for the KA and, if applicable, the WIA device-binding key pair), and the Wallet Instance additionally holds a device-resident key in hardware-backed storage (e.g. a Secure Element or platform-provided hardware-backed keystore) that serves as the possession-based authentication factor for remote authentication to the WSCA/WSCD (Background, p. 4).
  • The WSCA-BE runs on a dedicated hardened server that runs no other services, positioned behind gateway servers that manage and filter all external communications to the Wallet Provider backend and the Wallet Instance; the WSCA is expected to use an external database to store the Authentication Reference Data (ARD); every security-relevant action is an audit log entry, cryptographically tied to wallet units and transactions, transmitted to an external log server (§1.2.5, p. 10).
  • The WSCA-BE, hardened server, WSCD, Gateway server, external databases, log servers and their connections shall operate in a protected environment that limits physical access to the TOE to authorised privileged users (§1.2.5, p. 10).
  • TOE major security features: secure communication; Remote User Authentication (RUAP, ARD enrolment and management, transaction-bound UAE verification, PIN reset using a PUK, per-key authentication data held by the Wallet Instance); Wallet Provider authentication and role-based authorisation; cryptographic key management (delegating private-key protection and operations to the WSCD-HSM); WSCD-HSM access-control protection; attestation support (evidence binding attested public keys to WSCA/WSCD-generated keys for KA/WIA); protected cryptographic operations; multi-tenant isolation; security audit; self protection (self testing, secure initialisation, preserving a secure state) (§1.2.6, p. 11–12).
  • The TOE requires a secure and certified WSCD and a secured underlying server and secure operational environment as defined by the objectives in chapter 4 (Background, p. 4).

Figures​

  • Figure 1 — "The wallet Unit in the Wallet Ecosystem" (§1.2.1, p. 8): a dotted-outline "Wallet Unit" box contains (left) a "Secure Environment" box holding "Wallet Provider Infrastructure" with "WSCD-HSM" connected by a two-way arrow to "WSCA-BE (TOE)", and (right) a "User Device" box holding "Wallet Instance" connected to a "Key store". Two-way arrows connect WSCA-BE to the Wallet Instance and to the "Wallet Provider Backend" (outside the Wallet Unit, at the top); the Wallet Instance is also connected to the Wallet Provider Backend, to the "User", to "PID / Attestation Providers" and to "Relying Party" (both outside the Wallet Unit); the User is also connected to the Wallet Provider Backend (Figure 1, p. 8).
  • Figure 2 — "TOE deployment boundary" (§1.2.5, p. 10): a dashed "Secure Environment" contains "Wallet Provider Infrastructure", in which the "WSCA-BE (TOE)" box contains the modules "HSM client library", "Auth Protocol", "Service API", "Database API" and "Audit log library". Outside the TOE but inside the Secure Environment are "WSCD-HSM (out of the TOE scope)", "Gateway server (out of the TOE scope)", "Database (out of the TOE scope)", "Log server (out of the TOE scope)" and "Hardened Server (out of the TOE scope)" beneath the TOE. Two-way arrows connect the WSCD-HSM with the WSCA-BE, the Database API module with the Database and the Audit log library module with the Log server. A line from the "Wallet Provider Backend" (outside the Secure Environment) runs through the Gateway server box to an arrow into the WSCA-BE, and a two-way arrow drawn across the Gateway server box connects the Auth Protocol module with the "Wallet Instance" (outside the Secure Environment) (Figure 2, p. 10).
  • Component levelling diagrams: FAU_STG_EXT with components 1, 2, 3 (§5.1, p. 32); FIA_UAE_EXT with components 1 and 2 (§5.2, p. 33).

Who it applies to​

  • Scheme Owners, Evaluation Laboratories, CABs and EUDI Wallet providers are the primary audience; EUDI Wallet ecosystem stakeholders are the secondary audience (cover table, p. 2).
  • ST author: must claim strict conformance when claiming this PP (§2.4, p. 20); must model key generation, distribution, derivation and cryptographic operations implemented by the TOE itself (WSCD-implemented mechanisms are out of scope of these SFRs and the WSCD ST shall be referenced) (§6.3, App. Notes 4–7, p. 37–38); must claim FCS_RBG.1 (plus FCS_DRB.2 or FCS_DRB.3) if the server OS CSPRNG rather than the HSM DRBG is used (§6.3.6, App. Note 8, p. 38); is not expected to reproduce §1.3 in the ST (§1.3, p. 12). Security Targets shall provide evaluation evidence that the assumptions are satisfied in the specific deployment (§3.5, p. 26).
  • Evaluator: ATE_IND.2 calls for evaluator-performed independent tests with emphasis on FCS_EXT_UAE evidence verification and FDP_ACF.1 multi-tenant access control; the AVA_VAN.5 notes state what the vulnerability analysis shall include, items (a)–(f) (§7, Table 8, p. 50).
  • TOE developer: shall operate a vulnerability management process compliant with EN ISO/IEC 30111:2019 and Article 5 of (EU) 2024/2981 (§3.4, OSP.VULN_MGMT, p. 25); (§4.2, OE.VULNERABILITY_MANAGEMENT, p. 30).
  • Wallet Provider (S.WalletProvider): wallet provider backend application that communicates with the TOE through a mutually authenticated channel and requests operations (§3.2, p. 23); issues and signs WIA and KA after authenticating the attested public keys (§1.3.2.3, p. 15); shall ensure that TOE software updates are cryptographically signed, that the deployment pipeline verifies signatures before installation and that an SBOM is maintained for each deployed version (§4.2, OE.SECURE_UPDATE, p. 31); shall protect the public part of AST.WSCA_WSCD_Signing_Key_Pair and the complete signing key chain used to issue the KA and WIA, verify the authenticity of attested public keys received from the WSCA-BE before including them in a KA or WIA, and require identity re-verification before reset or migration (§4.2, OE.TRUSTED_WALLET_PROVIDER, p. 31); restricts admissible ARD (§4.2, OE.RESISTANT_ARD, p. 30); must revoke the Wallet Unit on User request, PID Provider request, or a security breach (§1.3.6, p. 19).
  • Wallet Instance (S.WalletInstance): wallet application that requests operations on the TOE (§3.2, p. 23); is assumed to derive UAE cryptographically from a PIN-derived knowledge-based factor and a possession-based factor and to generate and use the required keys within the secure keystore, and the app is assumed to be from an official app store and/or authenticated in a secure way; the wallet shall only run on secure devices and shall be certified according to (EU) 2024/2981 (§3.5, A.UAE_and_ARD, p. 26); (§4.2, OE.GENUINE_WALLET_INSTANCE, p. 31).
  • Wallet User (S.WalletUser): end user who must be authenticated before any cryptographic action with their keys; does not manage or use keys directly; all communication is mediated by the S.WalletInstance; each S.WalletUser has exactly one S.WalletInstance (§3.2, p. 23); will not disclose authentication factors (§4.2, OE.TRUSTED_WALLET_USER, p. 31).
  • Administrators: assumed trusted and trained; the TOE is not expected to defend against a malicious Administrator (§4.2, OE.TRUSTED_ADMIN, p. 31). The "technical administrator" is not a user role of the TOE; it maintains the operative environment including the underlying server (§6.1.6, App. Note 1, p. 36).
  • WSCD-HSM: must be certified against EN 419 221-5 or an equivalent PP, protecting private keys at least per the "assigned key" definition (§3.4, OSP.WSCD_CERT, p. 25); (§4.2, OE.HSM_CERT, p. 30).
  • PID/Attestation Providers and Relying Parties: only indirectly connected to the TOE via the Wallet Instance; no assumptions on them are expected in this PP. For the Access Certificate Infrastructure / Trust Infrastructure, Table 15 states that keys in the WSCA/WSCD are not part of it and that no assumptions on it are expected in this PP (Annex B.3, Table 15, p. 71).

Contents​

  • Front matter: cover, cover table, history of changes; "Background" (legal basis and Remote HSM architecture), "Terminology" (RUAP, ARD, UAE), "Relationship to Other Standards and Schemes" — p.1–5 (p. 1–5); Table of Contents (p. 6).
  • 1 Introduction — PP reference identification, TOE overview (ecosystem, components, interactions, deployment boundary, non-TOE hardware/software, security features) and an informative description of the Wallet Unit lifecycle and cryptographic trust relationships — p.7 (§1, p. 7–19).
  • 2 Conformance Claims — CC conformance claim, package claim, PP claim, conformance statement and rationale — p.20 (§2, p. 20).
  • 3 Security Problem Definition — assets (Table 1), subjects (Table 2), threats (Table 3), OSPs (Table 4), assumptions (Table 5) — p.21 (§3, p. 21–27).
  • 4 Security Objectives — objectives for the TOE (Table 6) and for the operational environment (Table 7) — p.28 (§4, p. 28–31).
  • 5 Extended components definition — FAU_STG_EXT (protected audit event storage) and FIA_UAE_EXT (authentication protocol with transaction binding) — p.32 (§5, p. 32–34).
  • 6 Security Functional Requirements — SFRs in classes FAU, FCO, FCS, FDP, FIA, FMT, FPT, FTP — p.35 (§6, p. 35–48).
  • 7 Security Assurance Requirements — EAL4+ package with architecture-specific evaluation notes (Table 8) — p.49 (§7, p. 49–50).
  • 8 Requirement Objective and Dependency Rationale — objectives traceability (Table 9), SFR rationale (Table 10), dependency rationale (Table 11), SAR rationale — p.51 (§8, p. 51–65).
  • Annex A (informative) Mapping to (EU) 2024/2981 Risk Register — maps risks R1–R14 of the Annex I risk register to the SPD (Table 12) — p.66 (Annex A, p. 66–67). Read
  • Annex B (informative) Completeness Analysis of the Security Problem Definition — coverage of TOE security functionality (Table 13), critical assets (Table 14) and operational environment (Table 15) — p.68 (Annex B, p. 68–72). Read

Key points​

  • Conformance: CC:2022 Revision 1 including latest errata, Parts 1–5; "CC Part 2 extended and CC Part 3 Conformant" (§2.1, p. 20).
  • Package claim: EAL 4 augmented with AVA_VAN.5, ALC_DVS.2 and ALC_FLR.3 (§2.2, p. 20); (§7, p. 49).
  • The PP claims no conformance to other PPs and requires strict conformance of any ST or PP that claims conformance to it (§2.3–§2.4, p. 20).
  • All threats assume HIGH attack potential against the WSCA-BE, "consistent with EAL4 augmented with AVA_VAN.5 and the requirements of (EU) 2024/2981" (§3.3, p. 24).
  • Rationale for the assurance level: EAL4+ is required because the product "is intended to withstand sophisticated attacks"; ALC_DVS.2 replaces ALC_DVS.1; ALC_FLR.3 has no dependencies; AVA_VAN.5 because the TOE "shall be highly resistant to any kind of penetration attacks" (§8.4, p. 65).
  • RUAP: every PIN verification is a live and fresh interaction between the Wallet Instance and the WSCA; the Wallet Instance demonstrates UAE derived from a knowledge-based factor (derived from the PIN) and a possession-based factor; UAE is verified against ARD shared during enrolment (Terminology, p. 4). RUAP shall meet Level of Assurance High of CIR (EU) 2015/1502 (at least two factors from different categories; resistance to guessing, eavesdropping, replay and manipulation with high attack potential) (§1.3.2.2, p. 14).
  • WSCA/WSCD-level user authentication is required at a minimum for: initial generation of KAs and WIA; user approval of selective disclosure to a Relying Party; deleting a PID/attestation and attested keys; requesting issuance of a new PID or Attestation (§1.3.2.2, p. 14).
  • Before invoking any WSCD-HSM operation the WSCA-BE shall verify UAE that is (a) bound to the user's registered ARD, (b) bound to the transaction context, (c) within its validity window, (d) not previously used, with (e) resilience against tampering or PIN (or PUK) brute force; requests lacking valid evidence are rejected and logged (§4.1, OT.USER_AUTH, p. 28).
  • FIA_UAE_EXT.1 as instantiated: challenge of at least 128 bits of entropy from an RBG meeting FCS_RBG.1; transaction context includes challenge, user identity, requested operation and wallet user identifier, associated with the session; evidence must show both the possession-based and the PIN-derived knowledge-based factor were verified; validity period is an ST assignment (§6.5.11, p. 43). FIA_UAE_EXT.2 requires a nonce registry and denial of evidence referring to unissued, already-used or expired challenges (§6.5.12, p. 43).
  • After a defined number of unsuccessful wallet-user authentication attempts the TSF shall lock the wallet user and notify the wallet user via an out-of-band notification channel (applies to attempts for the same Wallet Instance) (§6.5.1, p. 40).
  • Private keys of wallet users are generated within and never exported from the WSCD-HSM; the WSCA-BE holds only opaque key handles and stores only a minimum of private/symmetric keys (session keys and secure channel authentication data) (§4.1, OT.KEY_PROTECT, p. 28).
  • The WSCA-BE shall use the WSCA/WSCD signing key only for signing the public key of key pairs generated within the WSCD-HSM "and bind it to the wallet user" (§4.1, OT.KEY_ISOLATION, p. 28).
  • Per-key authorisation data is generated by the WSCD-HSM at key generation, sent to the wallet instance and provided with each operation; it is a TOE asset to be protected during use and securely deleted when no longer needed (§4.1, OT.KEY_ISOLATION, p. 28); (§3.1, AST.WSCD_HSM_Access_Credentials, p. 23).
  • If ARD is stored in an external database, the TOE shall first verify its authenticity and integrity and shall not rely solely on the database (§3.1, AST.Authentication_Reference_Data, p. 21). ARD shall be constructed so that the knowledge-based factor cannot be verified without a secret held by the WSCA-BE or the WSCD (§4.2, OE.RESISTANT_ARD, p. 30).
  • Mutually authenticated secure channels are required between the TOE and the Wallet Instance, the WSCD and the Wallet Provider; each transaction identifier is bound to AST.Wallet_Instance_Authentication_Data (§4.1, OT.WSCA_SECURE_CHANNEL / OT.WSCD_SECURE_CHANNEL / OT.WALLET_PROVIDER_SECURE_CHANNEL, p. 29).
  • The channel to the WSCD-HSM shall identify the HSM via its hardware attestation certificate, protect against replay of HSM commands, detect modification of HSM responses, and the TSF shall refuse HSM responses that fail integrity verification (§6.8.1, App. Note 13, p. 46).
  • Audit: a cryptographically protected, tamper-evident record for each security-relevant event (wallet user identifier, HSM key handle, relying party identifier where applicable, UAE reference, outcome and potential threats); evidence of origin and receipt verifiable by the Wallet Provider; Wallet Provider actions logged (§4.1, OT.AUDIT, p. 29). The TSF shall reject remote API requests from Wallet Instances when local audit storage is full (§6.1.4, FAU_STG_EXT.1.5, p. 36).
  • The WSCA-BE shall refuse to start if its binary or configuration has been modified since the last integrity baseline; WSCD-HSM Access Credentials shall not be stored in plaintext (§4.1, OT.SELF_PROT, p. 29); on initialisation errors the TOE is halted (§6.7.6, FPT_INI.1.3, p. 46).
  • Credential management and HSM operations are transactional: complete fully (including HSM confirmation and audit record) or roll back with an audit record of the failure (§6.7.4, App. Note 12, p. 45).
  • Keys and key material, including per-key authorisation data, are destroyed when no longer needed and on revocation, deprovisioning, factory reset or authorised deletion (§6.3.4, FCS_CKM.6.1, p. 37); (§3.4, OSP.SECURE_ERASURE, p. 26).
  • Management functions: for the Wallet Provider — TOE self-identification of version and configuration, TOE maintenance, audit data review, Factory Reset, deletion or reset of user authentication data; for the Wallet User — modifying user authentication data, PIN reset using PUK, Wallet Instance Migration (§6.6.2, p. 44). Roles maintained: Wallet User, Wallet Instance, Wallet Provider (§6.6.1, p. 43).
  • Cryptography: only algorithms mandated by applicable implementing acts or approved under the ECCG Agreed Cryptographic Mechanisms (ACM); a mechanism not yet in ACM requires a security assessment and documented justification and shall be replaced or updated when an applicable ECCG mechanism becomes available (§3.4, OSP.CRYPTO_STANDARDS, p. 25).
  • The WIA technical validity period shall be less than 24 hours (§1.3.2.3.2, p. 15) (informative section (§1.3, p. 12)).
  • The infrastructure hosting the WSCA-BE is operated under policies including physical access control, privileged access management and change management; "Provider's conformity with these requirements are in-scope of the national certification scheme under TR 5" (§3.4, OSP.INFRA_SEC, p. 25).
  • Annex A states coverage gaps that "require additional wallet-system controls": validation of the complete identity issuance process (R2), attribute authenticity and issuer validation (R3), availability/backup/recovery (R8), binding to the complete transaction context (R10), denial of service/resource exhaustion/component failure or recovery (R13), correlation/tracking of users (R14); for R1 coverage is limited to the WSCA backend (Annex A, Table 12, p. 66–67).

Assets (Table 1, 13 assets) (§3.1, p. 21–23)​

  • AST.Channel_Authentication_Key_Pair — key pair (private key protected by the WSCD-HSM) authenticating the WSCA(TOE)/WSCD to the Wallet Instance (confidentiality of private key, integrity, authenticity) (p. 21).
  • AST.Wallet_Instance_Authentication_Data — Wallet Instance counterpart used to establish the secure channel (integrity, authenticity) (p. 21).
  • AST.Channel_Authentication_Session_ Key — session key of the mutually authenticated TOE–Wallet Instance channel (confidentiality, integrity, authenticity) (p. 21).
  • AST.Authentication_Reference_Data — ARD managed by the TOE to verify UAE during RUAP (integrity, authenticity; confidentiality "must be ensured to avoid PIN (or PUK) verification outside the TOE") (p. 21).
  • AST.Wallet_Provider_Authentication_Data — data used by the TOE to authenticate a Wallet Provider (p. 21).
  • AST.Attested_Key_Pairs — PID/ATT_PRIV_KEY and PID/ATT_PUB_KEY generated in the WSCD-HSM and managed by the TOE; private keys never exported; public parts added to the KA (p. 22).
  • AST.WIA_Device_Binding_Key_Pair — generated in the WSCD-HSM and managed by the TOE; the key pair may be managed by the WSCA/WSCD or by the Wallet Instance, and WIA_KEY_PRIV is only considered an asset for the TOE if the WSCA manages the key (p. 22).
  • AST.WSCA_WSCD_Signing_Key_Pair — WSCA/D_PRIV_KEY and WSCA/D_PUB_KEY generated in the WSCD-HSM; public part securely shared with the Wallet Provider (p. 22).
  • AST.WSCA_BE_Software_And_Configuration_Data — TOE software and configuration, at risk from server-side compromise, insider threat and supply chain attacks (integrity, authenticity) (p. 22).
  • AST.WSCD_HSM_Access_Credentials — credentials used by the TOE to authenticate to the WSCD-HSM, including per-key authorisation data (p. 23).
  • AST.Wrapped_Key_Blobs — key blobs including private keys whose confidentiality is protected by the WSCD-HSM (integrity, authenticity) (p. 23).
  • AST.User_Data — at least S.WalletUser identifiers, PIN (or PUK) retry counter and user binding information to other assets (integrity, authenticity) (p. 23).
  • AST.Audit_Records — cryptographically protected tamper-evident audit record per security-relevant event (integrity, authenticity) (p. 23).

Subjects (Table 2, 3 subjects): S.WalletProvider, S.WalletInstance, S.WalletUser (§3.2, p. 23).​

Threats (Table 3, 15 threats) (§3.3, p. 24–25)​

  • T.WSCA_FW_TAMPER — attacker who compromises the TOE (software vulnerability, insider, supply chain) invokes WSCD-HSM signing operations on behalf of a victim without knowledge or consent (p. 24).
  • T.WSCA_ATTESTATION_TAMPER — attacker submits for signing a public key not generated in the WSCD-HSM for the authenticated user, so an attacker-controlled key ends up in a KA or WIA (p. 24).
  • T.WSCA_DATA_TAMPER — modification of TOE software/configuration via server-side exploitation, subverting access controls, suppressing audit or accessing HSM access credentials (p. 24).
  • T.WSCA_NET_ATTACK — active network attacks on the Wallet Instance–WSCA-BE channel, including compromise of channel keys/authentication data (p. 24).
  • T.REMOTE_AUTH_VUL — exploiting a RUAP vulnerability (forged UAE, broken session binding) to trigger signing without consent; at least guessing, eavesdropping, replay, manipulation or PIN/PUK brute force to be considered (p. 24).
  • T.WALLET_ORACLE — capturing a valid RUAP interaction (including enrolment ARD) and brute-forcing the PIN using the Wallet Instance without involvement of the TOE (p. 24).
  • T.WSCD_NET_ATTACK — active network attacks on the WSCD–WSCA-BE channel, including compromise of HSM access credentials (p. 24).
  • T.MULTI_TENANT — circumventing user isolation to use another user's keys (p. 24).
  • T.KEY_EXTRACT — abusing the WSCD-HSM client interface with the access credentials to extract HSM-stored private keys (p. 24).
  • T.DERIVE — deriving a private key, e.g. from the public key or wrapped key blobs (p. 25).
  • T.WSCA_USER_DATA_TAMPER — tampering with user data or wrapped key blobs to gain access to another user's private keys (p. 25).
  • T.PROVIDER_IMPERSONATION — forging or stealing Wallet Provider authentication data to impersonate a Wallet Provider (p. 25).
  • T.PROVIDER_NET_ATTACK — impersonating a Wallet Provider by attacking the Wallet Provider–WSCA channel (p. 25).
  • T.SIDE_CHANNEL — a co-tenant on shared infrastructure exploits side channels in WSCA-BE processing to infer credential information (p. 25).
  • T.AUDIT_TAMPER — suppression, modification, deletion or wrong attribution of audit records (p. 25).

Organisational Security Policies (Table 4, 9 OSPs) (§3.4, p. 25–26)​

  • OSP.CRYPTO_STANDARDS — mandated or ECCG ACM-approved cryptography only (with a justified-exception procedure) (p. 25).
  • OSP.VULN_MGMT — developer vulnerability management per EN ISO/IEC 30111:2019 and Article 5 of (EU) 2024/2981 (p. 25).
  • OSP.INFRA_SEC — hosting infrastructure operated under physical access control, privileged access management and change management processes appropriate for managing credentials at the eIDAS level of assurance high (p. 25).
  • OSP.WSCD_CERT — WSCD-HSM certified against EN 419 221-5 or equivalent; keys protected at least per the "assigned key" definition (p. 25).
  • OSP.KEY_ISOLATION — each user's private keys inside the WSCD-HSM and bound to the user's identity; misuse only possible by compromising the access credentials or the WSCD-HSM (p. 26).
  • OSP.AUDIT — tamper-evident, cryptographically protected audit records attributable to user and transaction; evidence of origin and receipt verifiable by S.WalletProvider (p. 26).
  • OSP.TOE_AUTHENTICATION — TOE uniquely identifies itself, its version and configuration, and authenticates itself to the user (p. 26).
  • OSP.SECURE_ERASURE — critical assets erased on revocation, deprovisioning, factory reset and authorised deletion (p. 26).
  • OSP.MIGRATION — an authenticated Wallet User may migrate to a new wallet instance (p. 26).

Assumptions (Table 5, 8 assumptions) (§3.5, p. 26–27)​

  • A.UAE_and_ARD — Wallet Instance derives UAE from PIN-derived and possession factors (PUK to reset); UAE/ARD preserve both factors; external verification meets CIR (EU) 2015/1502 Annex sections 2.2.1 and 3.1 at level high; keys in the secure keystore; app from an official app store and/or securely authenticated; secure devices only; Wallet Instance certified per (EU) 2024/2981 (p. 26).
  • A.PHYSICAL_PROTECTION — TOE physically protected; the PP contains no physical tamper or physical attack (power/EM analysis) requirements (p. 26).
  • A.TRUSTED_ADMIN — Administrators trusted and trained (p. 27).
  • A.TRUSTED_WALLET_USER — S.WalletUser will not disclose their proof of knowledge (p. 27).
  • A.TRUSTED_WALLET_PROVIDER — S.WalletProvider trained, trusted, does not disclose its authentication data and restricts admissible ARD (p. 27).
  • A.AUDIT_LOG_SERVER — audit log server in the TOE environment; log data not deleted (p. 27).
  • A.DATABASE — external databases for TOE assets located in the secure environment (p. 27).
  • A.GATEWAY — Internet-facing gateways (excluded from TOE scope) provide at least DDoS protection, intrusion detection, antivirus and firewall (p. 27).

Security objectives for the TOE (Table 6, 14 objectives) (§4.1, p. 28–29)​

OT.KEY_PROTECT, OT.KEY_ISOLATION, OT.SECURE_DELETION, OT.USER_AUTH, OT.PROVIDER_AUTH, OT.API_CONTROL (users only operate on own resources; per-key authorisation data with each key operation), OT.WSCA_SECURE_CHANNEL, OT.WSCD_SECURE_CHANNEL, OT.WALLET_PROVIDER_SECURE_CHANNEL, OT.MULTI_TENANT (User A cannot access credentials, keys or records of User B), OT.AUDIT, OT.SELF_PROT, OT.PROTECTED_STORAGE (integrity/authenticity of all user data incl. data outside the WSCD; confidentiality of session keys and non-WSCD private keys; secure deletion of temporary data), OT.AUTHENTICATION (§4.1, p. 28–29).

Security objectives for the operational environment (Table 7, 13 objectives) (§4.2, p. 30–31)​

OE.UAE_and_ARD, OE.RESISTANT_ARD, OE.HSM_CERT, OE.INFRA_SEC (incl. separation of duties, intrusion detection, change management, reliable time source, hardened least-privilege server; databases, gateways and audit log server part of the secure environment), OE.ISOLATION (TOE process isolated from other workloads), OE.PHYSICAL_PROTECTION (incl. hardware hardened against remote side-channel and microarchitectural attacks), OE.VULNERABILITY_MANAGEMENT, OE.GENUINE_WALLET_INSTANCE, OE.SECURE_UPDATE, OE.TRUSTED_ADMIN, OE.TRUSTED_WALLET_USER, OE.TRUSTED_WALLET_PROVIDER, OE.AUDIT_LOG_SERVER (§4.2, p. 30–31).

Process​

The document describes the Wallet Unit lifecycle in §1.3, which it labels "of informative nature"; the ST author is not expected to reproduce it (§1.3, p. 12).

  1. Installation — Wallet Instance distributed preferably through an official OS distribution channel; otherwise the Wallet Provider provides an authenticity/integrity check mechanism (§1.3.1, p. 12). The Wallet Instance establishes secure channels with the Wallet Provider and the WSCA/WSCD (§1.3.1.1, p. 12) and sends initial technical and security-posture data to the Wallet Provider (§1.3.1.2, p. 12–13).
  2. Activation (Wallet Provider, User, Wallet Instance) — creation of a Wallet Provider user account associated with the Wallet Instance; registration of two user authentication mechanisms (OS-level user authentication and WSCA/WSCD-level RUAP); initial generation and issuance of WIA and KA (§1.3.2, p. 13–14).
  3. KA/WIA generation (User via Wallet Instance, WSCA/WSCD, Wallet Provider) — after WSCA/WSCD-level user authentication the WSCA/WSCD generates attested keys; attested public keys (and the WIA public key) are signed by WSCA/D_PRIV_KEY so that the Wallet Provider can authenticate them; the Wallet Provider signs the KA with WP_SIG_PRIV1 and the WIA with WP_SIG_PRIV2 (§1.3.2.3, p. 15–16).
  4. Issuance (PID/Attestation Provider, Wallet Instance, WSCA/WSCD) — the Wallet Instance authenticates the Provider via Access and Registration Certificates; the Provider verifies WIA and KA signatures, validity and revocation status and requests proof-of-possession via nonce signing; for a device-bound credential the Provider binds it to one of the public keys in the KA; the credential is sent via the OpenID4VCI Credential Response (§1.3.3, p. 16–17).
  5. Disclosure (Wallet Instance, User, Relying Party, WSCA/WSCD) — the Wallet Instance authenticates the RP, authenticates the user, obtains explicit approval and signs the transaction-bound presentation through the WSCD/WSCA; the RP verifies it (§1.3.4, p. 18–19).
  6. Migration — via a protected Migration Object that excludes WIA, KA and private keys (§1.3.5, p. 19).
  7. Revocation/Deletion (Wallet Provider, Wallet Unit) — revocation via status index positions in WIAs/KAs; secure deletion of Wallet Unit contents and request to WSCA/WSCD to delete related cryptographic assets (§1.3.6, p. 19).

Requirements in this document​

All 59 entries are listed one by one, with their text and PDF page, on the NL-CS-WSCA requirements page. You can also search them together with all other requirements.

  • NL documents: parent framework NL-CS (parts 1/2/3/4) (cover table, p. 2); related documents NL-WSCA-conditions and NL-WI (-conditions) (cover table, p. 2); "national certification scheme under TR 5" for the Provider's infrastructure conformity (§3.4, OSP.INFRA_SEC, p. 25).
  • Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183 (eIDAS 2.0) — basis of the PP (Background, p. 4); (Relationship, p. 5).
  • CIR (EU) 2024/2981 (certification of EUDI Wallets) — basis; Article 2(4) WSCA definition; Article 4 (certificate as assurance input for national schemes); Article 5 (vulnerability management); Annex I risk register (Annex A mapping); Wallet Instance certification (Background, p. 4); (§3.4, p. 25); (§3.5, p. 26); (Annex A, p. 66).
  • CIR (EU) 2024/482 (EUCC) — certification scheme for the CC evaluation (Background, p. 4); (Relationship, p. 5).
  • CIR (EU) 2024/2979 (core functionality and integrity), 2024/2982 (protocols and interfaces), 2024/2977 (PID and EAA), 2026/1731 (updated standards and specifications), 2025/848 (wallet-relying party registration), 2025/849 (list of certified wallets) — framework documents (Relationship, p. 5).
  • CIR (EU) 2015/1502 (assurance levels) — LoA High for RUAP; Annex sections 2.2.1 and 3.1 for external verification (Relationship, p. 5); (§1.3.2.2, p. 14); (§3.5, p. 26). Cover also cites "EU Regulation 2019/881" for the evaluation assurance level (cover table, p. 2).
  • ARF (EUDI Wallet Architecture and Reference Framework) — terminology and technical reference (Terminology, p. 4); (Relationship, p. 5).
  • ECCG Agreed Cryptographic Mechanisms (ACM) — permitted cryptography (Relationship, p. 5); (§3.4, p. 25).
  • Common Criteria CC:2022 Revision 1 Parts 1–5 / ISO/IEC 15408:2022 — conformance (§1.1, p. 7); (§2.1, p. 20).
  • EN 419 221-5:2018 (Protection Profiles for TSP Cryptographic Modules – Part 5) — certification of the WSCD-HSM, "assigned key" definition (Relationship, p. 5); (§3.4, p. 25); (§4.2, p. 30).
  • EN ISO/IEC 30111:2019 — vulnerability management (§3.4, p. 25); (§4.2, p. 30).
  • collaborative Protection Profile for Network Devices, version 4.0, 2025-11-25 — inspiration for FAU_STG_EXT (§5.1, p. 32).
  • OpenID4VCI, SD-JWT VC, ISO/IEC 18013-5 — issuance and credential formats described in the informative lifecycle (§1.3.3, p. 16–18).
  • Applicable ETSI, ISO/IEC and IETF standards referenced by the ARF (Relationship, p. 5).

Notes on this draft​

Sources​