Skip to content

Privacy and Security

To ensure a secure and privacy-preserving EUDI Wallet design, the core properties listed in the following are desirable. They are either intended by the eIDAS regulation or are based on general principles and good practices of privacy and security.

Architecture designs for the various Wallet functions (see Sections Wallet Function: PID Issuance and Presentation, Wallet Function: (Q)EAA Issuance and Presentation, and Wallet Function: Login) will vary in the degree to which they can fulfill these properties. Furthermore, not all properties are equally applicable for all functions and use cases. This shall be assessed during the consultation process and be taken into account when evaluating the different design options.

Privacy Requirements

For system design and comparison of different solutions options we consider the following core privacy properties:

Unobservability

Unobservability refers to the property where an adversary cannot discern any useful information about a communication or transaction. This ensures that sensitive data, such as message content, sender or receiver identity, or any other relevant information, remains hidden from unauthorized parties. In this context, neither Wallet Providers nor Issuers shall be able to track where a user uses their credentials or learn details concerning the attributes provided.

For Wallet providers, this implies that the Wallet must run on a device under the user's control; in practice, this usually means a native app on a smartphone. Backend (server) components of the Wallet provider, if used, must not be able to track where users present their credential or learn details concerning the attributes of transactions.

For Issuers, this implies that there must be no involvement of the Issuer in the presentation process (e.g., for ad-hoc issuance or revocation checks) unless it can be ensured that the Issuer cannot track where the user presents their credential or learn details concerning the attributes of the presentation.

Unlinkability

Unlinkability refers to the property that it cannot be distinguished whether two transactions are related to the same user or not.

Different definitions of unlinkability can be considered in this context (not all are equally applicable to all functions and use cases):

  • Outsider: An adversary that may observe or modify the transactions should not be able to link two transactions to the same user.
  • Relying Party: A Relying Party should not be able to link two presentation transactions to the same user (unless sufficiently identifying information is part of the presented credential).
  • Issuer: An Issuer should not be able to link two issuance transactions to the same user (unless the user provides sufficiently identifying information as part of its authentication).
  • Colluding Relying Parties: Two Relying Parties should not be able to link two presentation transactions to the same user by sharing the received presentations.
  • Colluding Issuers: Two Issuers should not be able to link two issuance transactions to the same user by sharing the received information during issuance (e.g. wallet attestations).
  • Colluding Relying Party and Issuer: An Issuer and a Relying Party should not be able to link an issuance and presentations session to the same user (unless the user provides sufficiently identifying information as part of their authentication to the issuer and as part of the presented credential).

Issuance and presentation protocols should support unlinkability and ensure that cryptographic keys and random numbers cannot be used as correlation identifiers, this also includes less obvious data fields such as timestamps or version numbers.

If a Relying Party requires to recognize a user across multiple transactions, it should use pseudonyms.

Data Minimization and Prevention of Overidentification

According to the principle of data minimization, Relying Parties shall only receive the data they need for the specific transaction. Various properties can help to achieve this:

  • Pseudonymity: Pseudonymity refers to the possibility of using a pseudonym when authenticating online or presenting credentials, unless the identification is required by law.
  • Selective Disclosure: Selective Disclosure is the property to disclose only selected attributes of a credential during the presentation. This means that the Wallet (with the user's consent) can present a selected subset of the data fields (claims) in a credential while other fields are not revealed to the Relying Party.
  • Enforced Disclosure Limitation: Enforced Disclosure Limitation means that the scope of data Relying Parties can request can be limited by having Relying Parties register the data fields they need for a specific type of transaction and that the limitation can be enforced by the Wallet.

The following mechanisms are not considered in this proposal:

  • Zero-Knowledge Proofs: Zero-knowledge proofs can be used to prove that a certain claim is true without revealing the actual value of the claim. For example, a user could prove that they are over 18 without revealing their exact date of birth. Zero-knowledge proofs are not supported by the credential formats chosen in the ARF and bring significant implementation and security challenges, especially as they are not in widespread use yet.
  • Optional Data in User Consent: Some user consent implementations allow users to select which data fields they want to disclose to a Relying Party, out of those requested by the RP. While this can be seen as a privacy feature, for users, however, it can be difficult to understand which data fields are really required by the RP and what the consequences are of not disclosing certain data fields. When users encounter errors and have to repeat steps in the transaction process, it can be expected that they would refrain from unselecting any data fields in the long run. Therefore, such an option could lead to overidentification in the long run as Relying Parties can exploit user fatigue. Consequently, it seems preferable to ensure (by technical means and data privacy laws) that Relying Parties only request the data they absolutely need and not support optional data in user consent screens.

Repudiation

Repudiation (or “plausible deniability”, since “repudiation” actually refers to a single act of dispute although commonly used as synonym for the general ability to deny transactions) refers to the property that one of the entities involved in an identification transaction can plausibly deny to a third party (i.e., a party not involved in the transaction) in having participated in the transaction after its completion, or can plausibly deny to a third party having provided certain data. The ability to deny the transaction towards third parties does not impact the reliability of the transaction towards the Relying Party involved. Below, two repudiation variants are considered.

  • Deniability of Data Authenticity: Deniability of Data Authenticity refers to the property that the authenticity of a credential and its attributes provided by the Issuer can be plausibly denied to a third party after a presentation. In this context, it is required that a Relying Party should not be able to prove to a third party the authenticity of a credential and the integrity of its attributes that it has previously verified.
  • User deniability: User deniability refers to the role of the user in a presentation transaction and the user's authentication of the presentation. In this context it is required that a Relying Party should not be able to prove to a third party that the user has presented a credential in context of an identification, where the Relying Party was previously involved as verifier.

Note on repudiation in relation to identification: General understanding of identification processes is their short-lived nature. Presenting one's ID to a verifier in the analogue world has the immediate outcome for both not being able to prove the affair to someone else, as long as the ID has not been copied. Repudiation would achieve the same feature for digital identities.

The importance of repudiation for digital identifications might not be obvious, its absence however reveals a string of implications. In case of data breaches with authenticated PID involved, plausible deniability to the public would become highly favorable to the persons affected, especially if the involved Relying Party could arouse social discomfort. Regarding long-term storage, data leaks are generally more a matter of time rather than probability, since this risk cannot be thoroughly eliminated. Data thieves would obviously have a preference for guaranteed genuine copies over unauthenticated PID.

In some use cases, where records need to be kept by law, a long-living, non-repudiable declaration of intent is required to be verified by some third party; however, the specific requirements encountered by these use cases must be scrutinized. Usually, these declarations differ from identifications, so other means like QES are likely to be more appropriate. In any case, if a Relying Party has the requirement to prove an identification to a third party, it is the responsibility of the Relying Party to document and certify the identification procedure to the third party.

From an academic point of view, there is a lack of studies that examine the value of repudiation in connection with identification transactions compared to the impact that already arises from the leak of the collected data itself (e.g., use-case specific data in the context of record-keeping requirements). The value of non-repudiation may be limited since the authenticity of leaked data can often be asserted by other means, e.g., by verifying samples of the data against publicly available data. In this context it should also be considered what influence the fulfillment of other requirements, such as unlinkability, could have on the impact of non-repudiation and to what extent the strict application of the GDPR could minimize the risk of amassing authenticated data at Relying Parties.

The repudiation requirement and the appropriateness of using authenticated PID is subject of ongoing discussions within the consultation process.

Data Confidentiality

Data confidentiality refers to the protection of data from unauthorized access. This "property" can be applied to data protection in transport, e.g., when sending sensitive data between two parties, to data protection in use, e.g., when processing the data, as well as to data protection at rest, e.g., when storing sensitive data. All three properties shall be fulfilled in a system which handles data with need for protection, e.g., PII or other sensitive information about a user. This applies to the described system of this architecture proposal, namely the wallet, as well, due to the PII inside, e.g., the PID. Which components are affected is currently out of scope, and shall be subject to a future, more in-depth, analysis of this matter.

Data Protection at Rest

The general requirement for confidentiality of data comes from the implementing acts, as well as the revised eIDAS regulation and the GDPR. For example, as outlined in the following places:

  • (revised) eIDAS Regulation (EU) 2024/1183: Art. 3 (42) "'European Digital Identity Wallet' means an electronic identification means which allows the user to securely store, manage and validate person identification data [...]"
  • CIR 2015/1502: 2.3.1 "Where person identification data is stored as part of the authentication mechanism, that information is secured in order to protect against loss and compromise, including offline analysis."
  • CIR 2015/1502: 2.4.6 "All media containing personal, cryptographic or other sensitive information are stored, transported and disposed of in a safe and secure manner."
  • CIR 2024/2979: Art. 2 (3) "'critical assets' means 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"

The first three examples give no doubt about the legal requirement of confidentiality, applying to at least those credentials containing PII that are used for the authentication, e.g., the PID batch credentials. As such, encrypting the batch credentials when stored on the device is a requirement we need to fulfill. What is still unclear however, are the associated (technical) risks that shall be mitigated by the encryption, namely what "level of protection" needs to be achieved.

For example, does the PID batch credential, or its corresponding encryption key, fall under the definition of the critical asset, whose compromise of confidentiality has a "very serious, debilitating effect"?

One example for critical assets are the user binding keys needed during authentication. If such keys were to be compromised, e.g., due to insecure storage in software or insufficient secure hardware, an attacker would be able to impersonate a user, as possession of such a key would enable them to proof towards another entity the corresponding identity bound to the key. Impersonation in the context of authentication would indeed have a "very serious, debilitating effect on the ability to rely on the wallet unit", as it cannot guarantee its purpose of authenticating a valid user, namely functioning as an eID means. As such, in order to mitigate such a risk, the user binding key must be stored in sufficiently secure hardware (e.g., as the implementing act on 5c requires, the secure hardware shall meet the evaluation assurance level 4+ AVA_VAN5, protecting against attackers with high attack potential).

However, the risk is different for the batch credential and corresponding encryption key: compromise of the batch credential itself does not allow for impersonation, as presentation itself is not possible without the user binding key, which, as we have just laid out, is sufficiently protected. Furthermore, the compromise of the encryption key would "only" allow for decryption of the batch credential. In contrast to the aforementioned risk, decryption of the batch credential does not have a "very serious, debilitating effect". E.g., the "plain-text" batch credential is ending up at the relying party after a successful transaction, and thus the goal of a presentation. As such it cannot be a factor for breaching the ability to rely on the wallet unit itself. Furthermore, the possibility of the data to end up at a malicious relying party or other (unauthenticated and unauthorized) party, is already part of a first risk "estimation". Of course, a future, more in-depth, risk assessment/analysis shall be carried out to further estimate the severity and likelihood of such a risk and the resulting necessary measures to protect against it (as well as other risks, such as unavailability/"denial of service" due to preventing the decryption of the credential, when, e.g., breaking the hardware and compromising/deleting the key, or similar). This includes the time "when to decrypt", and the underlying assumptions made on the device. However, as of yet, we do see neither the batch credential nor the encryption key as a critical asset. As such, the secure hardware storing the encryption key does not necessarily have to meet the same evaluation assurance level as the one for protecting the user binding key.

Options for Protection of PII

The analysis for the security requirements requires a risk-based analysis where the technical possibilities are evaluated based of the privacy risks according to the underlying data protection model. As a first step, the following options for protecting the PII are technically feasible, but need to be evaluated further regarding the protection they provide:

  1. Software Keys
  2. System Keystore
  3. System Keystore with Access Control
  4. Backend Encryption
  5. (Presentation Re-Keying)

A risk-based analysis in the future shall conduct which of the above options is possible to control the risks that were worked out. We will come back to this after such a risk analysis has been concluded (tbc).

For the below analysis of the options, we do not consider any app-level protections, such as root detection, system integrity checks or app attestations, as the data might be exfiltrated from a device without the app ever being opened by the attacker.

Software Keys

Encryption of the PII, namely the batch credential, is done with software keys managed by the wallet app. Although easy to implement and platform independent, it does not add any notable security.

System Keystore

Encryption of the PII is done with encryption keys managed by the platforms keystore mechanism. A wallet app requests the decryption of the data on start of the app without any user interaction, allowing it to show the decrypted PII directly to the user.

For those wallet solutions which rely on native hardware backed keystores, such as secure enclave on iOS or TEEs or Strongbox on Android, no additional access control may be insufficient:

Although they may achieve resistance against moderate attack potential (or even higher for some), the usage of the key is not sufficiently protected. I.e., the device unlock in addition with app identifiers may be circumvented on rooted systems. Access to the data is therefore effectively only secured by a single factor.

System Keystore with Access Control

Similarly to the previous option, encryption of the PII is done with encryption keys managed by the platforms keystore mechanism. However, additional access control is registered for the use of the encryption key. Such measures can be:

  • Device Unlock
  • Biometrics
  • PIN/Passphrase

In contrast to before, active user interaction would be required on decryption. The device unlock would utilize the same mechanism as upon unlocking the device, such as the PIN or biometrics, or whatever the user might have enrolled in their device. Alternatively, the key can be set up to require a biometric or knowledge factor different from the device unlock.

Similar mechanisms are utilized for, e.g., Indigo, utilizing Apple's Secure Enclave, for clearances comparable to moderate attack potential (similarly "VS NfD" by BSI). But although the hardware key storage (as in some Android Strongbox models) can possibly even achieve a higher level of "security", the second factor does generally not satisfy the requirements on higher levels of assurance.

Backend Encryption

Encryption of the PII is done with encryption keys managed in the secure hardware on the backend. Active user interaction for the authentication towards the backend is necessary for the key usage. In order to prevent the wallet backend to learn about the users identity through the PII, which would go against the untraceability/unlinkability requirement, a double encryption must be used:

\(enc(K_{Backend}, enc(K_{App}, PII))\)

The app encrypts the PII first, followed by the decryption of the resulting cyphertext by the backend. As such, when the backend receives the ciphertext for encryption, or when performing the decryption, the backend never learns about the plaintext, namely the PII of the user. Only after both sides have decrypted can the PII be viewed.

With usage of public key cryptography, the encryption can already be performed at the PID provider during issuance, using the corresponding public keys to not involve the backend for encryption.

As the backed and the authentication towards it is the same as used for the provision of the eID functionality of the wallet, we assume that the security guarantees are also the same. For Wallet architectures with the secure hardware in the backend, if they reach a level of assurance high, the protection of the encryption keys, and thus effectively of the PII, would achieve resistance against attackers with high attack potential.

It should be noted however, that the implementation costs are higher than for the previous options, as it additionally involves the backend (at least for the decryption).

Data Protection Requirements

Besides deciding which options for protecting the PII also protect against any security risks, it is also necessary to check for any privacy requirements which need to be fulfilled, and which privacy risks may arise otherwise (a risk analysis shall as such also cover any privacy risks as well). A final decision for an option may only be performed afterwards. This is tbc

Security Requirements

For system design and comparison of different solutions options we consider the following core security properties:

Level of Assurance (LoA)

Level of Assurance refers to the degree of confidence in the processes thus providing assurance that the user that uses a particular identity is in fact the user to which that identity was assigned. This property refers to the LoA of the eIDAS Regulation.

Unforgeability of Credentials

Unforgeability of credentials refers to the property that a credential can only be created by the legitimate Issuer and cannot be tampered by someone else. This property ensures the integrity and authenticity of a credential and its verification.

Freshness of Presentations

Freshness of presentations refers to the property that every presentation must be created anew for every verification. This property refers to the mechanisms used for binding a presentation to the presentation request of the Relying Party to prevent replay of presentations.

User Binding of presentations

User Binding refers to the property that credentials are under the sole control of the user. This property refers to the mechanism used for secure authentication of the user in the context of using the credential (e.g., by two-factor authentication linked with a cryptographic binding to the credential) to prevent unauthorized issuance or presentation of a credential. In the literature, this property is also described as holder binding.

Session Integrity

Session Integrity refers to the property that an attacker is not able to insert themselves into an authentication exchange between a Verifier and a Wallet or into an issuance process between a Wallet and an Issuer. This property requires mechanisms for binding communication to an authenticated session to prevent session hijacking.

Cryptographic algorithms

This section defines the cryptographic algorithms that should be used and are based on the recommendation of the BSI and SOG-IS.

Note: The Brainpool curves currently do not have identifiers in the IANA registry for JOSE. Since there are multiple algorithms for the issuer to sign a credential, the relying party and the wallet provider needs to implement all of them. The same applies for the key binding/presentation.

In a later version of this document, we will evaluate if we can reduce the number of algorithms to reduce complexity.