Arf Wallet Reqs

The European Digital Identity Regulation requires certification of Wallet Solutions to ensure conformity of the Wallet Solutions with functional, security, and privacy-related requirements, to achieve a high level of interoperability, security, and trustworthiness. Certification applies to the Wallet Solutions and the eID schemes under which they are provided; for ease of reading this chapter only refers to Wallet Solutions. Furthermore, the object of certification includes software components, hardware components (in cases where they are provided directly or indirectly by the Wallet Provider) and the processes that support the provision and operation of a Wallet Solution, such as Wallet Unit activation, see Section 6.5.3.

The aim is to harmonise the implementation of the requirements laid down by the [European Digital Identity Regulation] and avoid divergent approaches to the maximum extent possible. For this reason, the Commission requested ENISA to prepare a candidate European certification scheme under the Cybersecurity Act (CSA). As defining and adopting a dedicated, harmonised certification scheme for Wallet Solutions depends on agreements between Member States on detailed security requirements, on the availability of underlying certification schemes, and on established good practices in the Member States themselves, a transitory approach is foreseen by means of national certification schemes.

In other words, the certification approach for Wallet Solutions follows two phases. In the short-term, Member States provide national (transitory) certification schemes. In the medium term, a harmonised CSA scheme will be established. When the CSA-based scheme becomes available, it replaces the national schemes as for cybersecurity requirements. The schemes may continue to exist for functional requirements.

7.2. Certification of Wallet Solutions against national certification schemes

Until a dedicated Wallet Solution cybersecurity certification scheme under the CSA is available, the [European Digital Identity Regulation] requires Member States to establish national certification schemes. This will be done in time to make available the Wallet Solutions before the end of 2026. The Commission has adopted the CIR 2024/2981 to provide the main requirements on Member States for creation of national certification schemes. The CIR 2024/2981 and resulting national certification schemes are defined around a number of guiding principles:

First, the goal is to harmonise requirements to the extent possible. Member States are also encouraged to work together in the design and implementation of national schemes. Additionally, national schemes will leverage the use of relevant and existing certification schemes and standards for Wallet Solution certification and evaluation. Where available, relevant European CSA schemes must be used. Currently, only the Common Criteria-based European candidate cybersecurity certification EUCC scheme is available for the cybersecurity certification of ICT products, parts, or components for products. Upcoming CSA-based schemes include EUCS and EU5G. Additionally, other existing or upcoming schemes include schemes based on FITCEM (EN 17640), national schemes such as on remote identity verification, or other private schemes (e.g. for mobile devices and apps). For harmonisation of functional requirements, the Commission Implementing Regulations (CIRs) adopted under the European Digital Identity Regulation article 5(a) are referenced. For harmonisation of certification requirements, the ISO/IEC 17065 framework under Regulation [765/2008] is used, complemented by ISO/IEC 17067 on the definition of schemes.

Next, the CIR 2024/2981 refers to the composite nature of the Wallet Solutions as well as the potential different architectures in Member States, considering that the European Digital Identity Regulation is technology (and architecture) neutral. This means that a final ('top-level') certification of the Wallet Solution will yield a composite certificate, built on certification of separate components, such as EUCC certification. Wallet Solutions are always to be certified against assurance level High, as set out in the European Digital Identity Regulation as well as CIR (EU) 2015/1502. That assurance level has to be reached by the overall Wallet Solution. Under this Regulation, some components of the Wallet Solution may be certified at a lower assurance level, provided this is duly justified and without prejudice to the assurance level High reached by the overall Wallet Solution. For the use of assurance information from other certification schemes or sources, a dependency analysis will be performed.

Finally, in order to ensure a harmonised approach to cybersecurity and the assessment of the most critical risks that might affect the provision and operation of Wallet Units, a register of risks and threats is defined, see Section 7.4. The Risk Register contains high level risks and threats in relation to Wallet Solutions and the ecosystem, as well as detailed threat scenarios that will be taken into consideration when designing Wallet Solutions, independent of their specific architecture.

As a first step towards certification of Wallet Solutions under national schemes, Member States will assign a scheme owner, and design and roll out the scheme. As part of this process, Certification Bodies (CBs) will be accredited to carry out conformity assessments of Wallet Solutions against the requirements of the CIR 2024/2981 and the national scheme. Wallet Providers then request one or more designated CABs to assess and certify the conformity of their Wallet Solution. The CAB evaluates and certifies the conformity of the Wallet Solution if they meet the requirements.

The European Commission and ENISA support Member States in designing and implementing national certification schemes in the Cooperation Group.

7.3 Certification of Wallet Solutions against a dedicated CSA-based scheme

In parallel to the work described above, ENISA is requested to draft a dedicated European cybersecurity certification scheme for the Wallet Solutions under the CSA. Once available, this CSA-based scheme will replace the national transitory schemes mentioned above for the cybersecurity requirement it covers. This scheme will be based on available national schemes and harmonised requirements. It will identify any additional requirements relevant for cybersecurity. The scheme will further detail the cybersecurity requirements, identify and set normative standards, and define the target level of assurance or security for the relevant Wallet Solution components.

The work to develop the CSA-based scheme follows the milestones set out by the CSA and is supported by the Ad Hoc Working Group or 'AHWG'. This group is composed of selected experts from private organisations and industry, with extensive knowledge and experience in the areas of cybersecurity certification, digital wallets, electronic identification, and trust services. The first step is to have a candidate scheme ready for public consultation and submitted for feedback of the European Cybersecurity Certification Group or ECCG. The ECCG's opinion serves as advisory input to ensure the candidate scheme aligns to EU cybersecurity objectives, standards and regulatory requirements. Although the ECCG's opinion is not binding, it will hold significant influence, as it reflects the collective expertise of national cybersecurity authorities, aiming to harmonise cybersecurity certification practices across Member States. Based on this input, the candidate scheme might be updated further. After finalisation of the ECCG opinion, the scheme will be transformed into a new Implementing Regulation and adopted by comitology procedure.

Finally, ENISA is also asked to facilitate the transition from national certification schemes to the dedicated cybersecurity certification scheme under the CSA.

7.4 Risk-based approach and risk register

7.4.1 Introduction

This section details the approach to develop harmonised guidelines for the development of the transitory national certification schemes. In addition to the requirements set out in the European Digital Identity Regulation article 5c, cybersecurity risks and threats associated with the Wallet Solutions will be identified. Here, a risk-based approach is envisioned as the basis for certification by Member States, ensuring that the Wallet Solutions uphold confidentiality, availability, and strong safeguards for User privacy and data protection. This is inspired by known processes, such as for the General Data Protection Regulation (GDPR) and related Data Protection Impact Assessments (DPIA).

The risk-based approach sets out a common Risk Register that contains a comprehensive but non-exhaustive list of risks and threats related to the Wallet Solution. These risks and threats are architecture-agnostic and provide a benchmark overview of the most critical risks and threats to Wallet Solutions. By adopting this common set of risks and threats, national transitory certification schemes will achieve a baseline level of harmonisation.

The risk register will be applied by scheme owners, Wallet Providers, and Certification Bodies (CBs). When establishing their certification schemes, scheme owners will perform a risk assessment to refine and complement the risks and threats listed in the register with those specific to their architecture, and consider how the applicable risks and threats can be appropriately treated. Wallet Providers will complement the scheme's risk assessment to identify any risks and threats specific to their implementation and propose appropriate mitigation measures for evaluation by the certification body.

7.4.2 High-level risks and threats

The following is an excerpt from [Risk Register]. To keep in line with the continuously evolving threat landscape, the risk register will be maintained and regularly updated in collaboration with the Cooperation Group.

High-level risks and threats

R1 Creation or use of an existing electronic identity R2 Creation or use of a fake electronic identity R3 Creation or use of fake attributes R4 Identify theft R5 Data theft R6 Data disclosure R7 Data manipulation R8 Data loss R9 Unauthorised transaction R10 Transaction manipulation R11 Repudiation R12 Transaction data disclosure R13 Service disruption R14 Surveillance

System-related risks

SR1 Wholesale surveillance SR2 Reputational damage SR3 Legal non-compliance

Technical threats

TT1 Physical attacks

1.1 Theft 1.2 Information leakage 1.3 Tampering

TT2 Errors and misconfigurations

2.1 Errors made when managing an IT system 2.2 Application-level errors or usage errors 2.3 Development-time errors and system misconfigurations

TT3 Use of unreliable sources

3.1 Erroneous use or configuration of wallet components

TT4 Failure and outages

4.1 Failure or dysfunction of equipment, devices or systems 4.2 Loss of resources 4.3 Loss of support services

TT5 Malicious actions

5.1 Interception of information 5.2 Phishing and spoofing 5.3 Replay of messages 5.4 Brute-force attack 5.5 Software vulnerabilities 5.6 Supply chain attacks 5.7 Malware 5.8 Random number prediction

7.4.3 Risks and mitigation measures discussed in Chapter 6 of this ARF

7.4.3.1 Introduction

This section briefly discusses some of the risks that were considered when the trust model in Chapter 6 was created, together with the mitigations for these risks and the residual risks that remain after these mitigations. This section is not intended to be a comprehensive risk register for the EUDI Wallet ecosystem as a whole; for that register, see [Risk Register] and Section 7.4.2 above. This section is limited to the scope of the ARF, namely, the Wallet Unit and its interactions with other entities in the ecosystem, as depicted in Figure 12 in Chapter 6.

7.4.3.2 Risks and mitigation measures related to confidentiality, integrity, and authenticity

Within the EUDI Wallet ecosystem, many interactions take place between entities in which one entity requests another entity to perform a task. For example, a User may ask a PID Provider or an Attestation Provider to provide a PID or an attestation to a Wallet Unit, or a Relying Party may ask a User to present attributes from an attestation in their Wallet Unit. For any of these interactions, the following risks apply:

• An attacker could impersonate one of the interacting entities. Therefore, the receiver of a message must be able to verify the identity of the sender, and vice versa. In other words, mutual authentication is needed. This authentication can be performed because valid entities in the EUDI Wallet ecosystem are put on a Trusted List or List of Trusted Entities (loTE) by Member States. By verifying the signature over a message and verifying the associated public key certificates with a trust anchor included in a Trusted List or LoTE, the receiver of a message can be sure about the identity of the message's sender.
• Messages between entities could be intercepted, meaning that they could be read by an attacker. To mitigate this risk, messages must be encrypted to ensure confidentiality.
• Intercepted messages could be changed by an attacker. To mitigate this risk, messages must be authenticated, so that the receiver can verify that originate from the authenticated sender and were not changed.

7.4.3.3 Risks and mitigation measures related to tampering of cryptographic keys and sensitive data

The mechanisms for authentication and confidentiality described in the previous section rely on the security of cryptographic keys, especially private and secret keys. If an attacker can obtain, use, or tamper with these keys, these security mechanisms would break down. Therefore, all critical assets on Wallet Units are managed by dedicated secure applications (WSCAs), running on secure hardware (WSCDs), as described in Section 4.3. The security of WSCDs and WSCAs is ensured by means of an appropriate certification process.

Similar mitigation measures apply for all other entities in the EUDI Wallet ecosystem that use cryptographic keys, including Wallet Providers, PID Providers and Attestation Providers, Trusted List or LoTE Providers, Providers of registration certificates, and Access Certificate Authorities. Such parties will typically use a certified Hardware Security Module (HSM) for managing private and secret keys. For Relying Parties and Relying Party Instances, such measures are formally not required.

A WSCA/WSCD or keystore in a Wallet Unit may also be used to store other sensitive data except cryptographic keys. In particular, they could be used to store User attributes, in such a way that attackers, including malicious applications residing on the same User device as the Wallet Instance, cannot retrieve these attributes. This could be beneficial for User privacy.

7.4.3.4 Risks and mitigation measures related to authorisation

In certain cases, there is a risk that a legitimate entity within the EUDI Wallet ecosystem may attempt to perform actions beyond its authorised scope. This risk primarily affects two types of entities:

• First, an Attestation Provider may attempt to issue attestations for which it lacks the necessary authorisation. For example, an Attestation Provider that has not been officially designated by a Member State or another relevant authority to issue diplomas may still attempt to generate an attestation of the diploma type. Wallet Units can mitigate this risk by inspecting the registration certificate of the Attestation Provider, if available, before requesting that Attestation Provider to issue an attestation to the Wallet Unit. If no registration certificate is available, the Wallet Unit can query the relevant registry via an API to obtain the same information. This registry, maintained by a Member State Registrar, contains comprehensive information about each Attestation Provider, allowing the Wallet Unit to verify its legitimacy and ensure compliance with regulatory requirements. Relying Parties can similarly query the registry after receiving an attestation issued by a specific Attestation Provider, to verify that the Attestation Provider is registered for issuing that type of attestation.

• Second, a Relying Party in the EUDI Wallet ecosystem may attempt to request attributes from a Wallet Unit that it does not reasonably need for its use case. This risk is mitigated mainly by three measures:

  1. Selective Disclosure and User Control - The attestation formats and protocols specified in [ISO/IEC 18013-5] and [SD-JWT VC] (in combination with [OpenID4VP]) enable selective disclosure of attributes. This allows a Relying Party to specify which attributes within an attestation it wishes to receive while excluding others, a feature known as collection limitation. Additionally, selective disclosure ensures that the User retains control over their data, as they can approve or deny the presentation of requested attributes. More details on selective disclosure and User approval can be found in Section 6.6.3.5.
  2. Mandatory Relying Party Registration of Intended Requested Attributes - The [European Digital Identity Regulation] mandates that each Relying Party register the attributes it intends to request from Users. According to CIR 2024/2982, these registered attributes may be included in a Relying Party registration certificate, which the Wallet Unit uses to verify the legitimacy of the request and inform the User accordingly. If no registration certificate is available, the User can ask the Wallet Unit to verify the registered information about the Relying Party directly with the relevant Registrar. This transparency ensures that Users can make an informed decision about whether to approve or deny the presentation of the requested attributes. More details on this requirement can be found in Section 6.6.3.3.
  3. Attestation Provider Disclosure Policy Enforcement - The [European Digital Identity Regulation] also mandates that Attestation Providers can embed a disclosure policy within their attestations. This policy may include rules governing whether the Attestation Provider approves the presentation of this attestation to an authenticated Relying Party. The Wallet Unit evaluates this policy —if present— alongside authenticated data from the Relying Party, and informs the User of the outcome. This mechanism further supports the User in making a well-informed decision on whether to approve or deny attribute presentation. More information on disclosure policy enforcement can be found in Sections 6.6.2.7 and 6.6.3.4.

7.4.3.5 Risks and mitigation measures related to User privacy

7.4.3.5.1 Linkability

User privacy is a very important consideration in the design and implementation of the EUDI Wallet ecosystem. An important aspect of privacy is unlinkability. Unlinkability implies that, if a User presents attributes from an attestation multiple times, the receiving Relying Parties cannot link these separate presentations to conclude that they concern the same User.

Within the EUDI Wallet ecosystem, attributes are presented in electronic attestations containing unique, fixed elements such as hash values, salts, public keys, and signatures. Malicious Relying Parties could exploit these values to track Users by storing and comparing them across multiple transactions, identifying recurring patterns. This privacy threat, known as Relying Party linkability, can occur within a single Relying Party or among colluding entities. It can also occur when a third party attacks the systems of one or more Relying Parties, resulting in a data breach. For that reason, Relying Parties will discard the unique fixed elements in received attestations as soon as they no longer need these elements.

A similar privacy threat arises when colluding Relying Parties share the unique values they obtained from an attestation with a malicious PID Provider or Attestation Provider. This allow the PID Provider or Attestation Provider to track User activity across multiple services. This form of linkability is called Attestation Provider linkability.

This topic is discussed in more detail in the Discussion Paper for Topic A.

7.4.3.5.2 Mitigating Relying Party linkability

Regarding the mitigation of Relying Party linkability: A trustworthy PID Provider or Attestation Provider can mitigate Relying Party linkability fully by issuing multiple PIDs or attestations to the same User. Wallet Units can use these attestations as disposable (single-use) attestations, which ensures attestations can never be linked by Relying Parties. Topic 10 in Annex 2 calls this method A, 'once-only attestations', and requires Wallet Solutions to support this method. It also specifies how a PID Provider or Attestation Provider can indicate that they want a Wallet Unit to treat their PIDs or attestations in this way.

However, the 'once-only' approach increases issuance complexity and management overhead. Therefore, Topic 10 also mandates support for another solution, where PIDs and attestations are valid for a limited time only. This limits the amount of PIDs and attestations to be issued, but only partially mitigates Relying Party linkability. Topic 10 calls this method B, 'limited-time attestations'.

Furthermore, Topic 10 describes two other approaches, which are optionally supported by Wallet Solutions, namely:

• the Attestation Provider issues attestations in batches to the Wallet Unit. The Wallet Unit then uses the attestations from a batch in a random order, until it has presented all attestations in the batch once. Then it 'resets' the batch and starts using them again in a random order. Topic 10 calls this method C, 'rotating-batch attestations'.
• the Wallet Unit will present different attestations to different Relying Parties. However, in case a Relying Party requests attributes from this attestation multiple times, the Wallet Unit will present the same attestation to this Relying Party each time. Topic 10 calls this method D, 'Per-Relying Party attestations'.

Additionally, organisational and enforcement measures can help deter Relying Parties from colluding and tracking Users. In particular, Relying Parties found in violation will have their access certificates revoked, preventing them from further interactions with Wallet Units.

7.4.3.5.3 Zero-Knowledge Proofs

NOTE: Discussions on Zero-Knowledge Proofs (ZKPs) are ongoing. No specific ZKP has been selected to be supported by components in the EUDI Wallet ecosystem.

Unlike Relying Party linkability, Attestation Provider linkability cannot be fully eliminated when using attestation formats based on salted hashes. The only viable mitigation is to adopt Zero-Knowledge Proofs (ZKPs) as a verification mechanism instead of relying on salted-attribute hashes. A Zero-Knowledge Proof (ZKP) is a cryptographic protocol that allows one party (the prover) to convince another party (the verifier) that a given statement is true without revealing any additional information beyond the validity of the statement itself. This ensures that the verifier gains no knowledge about how the prover knows the statement to be true, thus preserving privacy while enabling trust.

However, the integration of ZKPs in the EUDI Wallet ecosystem is still under discussion and development, due to the complexity of implementing ZKP solutions in secure hardware and the lack of support in currently available secure hardware (WSCDs). As with Relying Party linkability, organisational and enforcement measures can help deter Attestation Providers from colluding and tracking Users. Additionally, many Attestation Providers are subject to regular audits, making it easier to detect collusion and tracking compared to Relying Parties.

Zero-Knowledge Proof (ZKP) mechanisms for verifying personal information are highly promising and essential for ensuring privacy in various use cases. They enable Users to prove statements such as "I am over 18" without disclosing any personal data, offering a robust solution for privacy-preserving authentication and verification.

One area of development is age verification, where the European Commission is actively exploring and testing ZKP-based solutions. The outcomes of this initiative could pave the way for the adoption of ZKPs within the EUDI Wallet ecosystem, further strengthening privacy protections in future implementations.

The Discussion Paper for Topic G (Zero-Knowledge Proofs) presents the (desired) privacy properties of Zero-Knowledge Proof schemes. It introduces the main families of Zero-Knowledge Proof schemes and gives an overview of representative solutions. Finally, it discusses topics related to the integration of Zero-Knowledge Proof schemes into the EUDI Wallet ecosystem.

High-level requirements for Zero-Knowledge Proofs to be used in the EUDI Wallet ecosystem are included in Topic 53 of Annex 2.