A High-Level-of-Assurance EUDI Wallet with a Remote WSCD Supporting Biometrics and Passkeys

A High-Level-of-Assurance EUDI Wallet with a Remote WSCD Supporting Biometrics and Passkeys Claudia Franco, Carlos Lancha, Daniel Flores, Rosario Arjona and Iluminada Baturone Instituto de Microelectrónica de Sevilla (IMSE-CNM), University of Seville-CSIC, Seville, Spain [email protected], [email protected], [email protected], [email protected], [email protected] Abstract. The European Digital Identity (EUDI) Wallet is a user-controlled digital environment that is being developed to be used by all citizens of the European Union. The Architecture and Reference Framework (ARF) of the EUDI Wallet is a set of specifications designed to ensure their interoperability and security. Among specifications, a Wallet Secure Cryptographic Device (WSCD) with a high level of assurance (LoA) must be used. A high LoA is achieved through the multi-factor authentication of the Wallet User and the use of secure hardware for implementing the needed cryptographic and biometric algorithms. Also, EUDI Wallets should include a functionality to generate and manage user-chosen pseudonyms, to authenticate Users when accessing online services. This paper describes a high-LoA EUDI Wallet using a remote WSCD, which is the most inclusive, user-friendly and scalable type of WSCD. User authentication is done through something you know (a password), something you have (a smartphone), and who you are (with facial biometrics). As secure hardware for the remote WSCD, we use an Intel SGX enclave. The WSCD allows the generation and management of Passkeys, which are a kind of pseudonyms following the W3C WebAuthn specification. A demonstrator has been developed using a Samsung Galaxy A52 as User device with the Wallet Instance, and a laptop with an Intel® Core ™ i7-10750H at 2.60GHz and 16GB RAM with Ubuntu 20.04.6 LTS, Intel SGX1 and disabled hyper-threading to implement the remote WSCD. The experimental results show that the WSCD needs 128MB of RAM and takes 374.2 ms to be bound to a User, 375.2 ms to authenticate the User and create a new Passkey, and 373.8 ms to authenticate the User and sign with an already existing Passkey. Keywords: Digital Identity Wallets, Multifactor Authentication, Biometrics, Hardware Secure Module, Intel SGX, Passkeys. 1 Introduction The European Digital Identity (EUDI) Wallet is a secure, user-controlled digital environment that will enable Users to manage and present their Person Identification Data (PID) and attestation of attributes to public and private services in the European Union 2 F. Author and S. Author (EU) [1]. The Wallet Unit obtains PID/attestation of attributes from PID/attestation providers. The Relying Parties are entities such as businesses, government agencies, or service providers that need to authenticate Users securely. The Wallet can be used to register the User to different Relying Parties and/or present PID/attestations to said Relying Parties. Member States will have to offer their citizens a Wallet solution, and public and private services will be mandated to recognize the Wallet as a valid identification method [2]. The Architecture and Reference Framework (ARF) explains the architecture of the EUDI Wallet ecosystem and all its components, as well as how these components interact with each other. The goal of ARF is to create uniform conditions for the implementation of the EUDI Wallet throughout Europe [1]. One of the conditions is that the Wallet must achieve a high Level of Assurance (LoA), which refers to the degree of confidence in the claimed identity of a person [3]. A high LoA is achieved, among other factors, by using secure hardware for key management, sensitive data and cryptographic functions and implementing multi-factor authentication [4], which means using more than one factor when authenticating the User. The different authentication factors are what the User has (device possession), what the User knows (password) and who the User is (biometrics). The high-level architecture of the EUDI Wallet is shown in Fig. 1. The Wallet Unit is formed by: the Wallet Instance, that is, the App or browser running inside the User device (which is typically a mobile phone); the Wallet Secure Cryptographic Device (WSCD), that is, a secure hardware element that stores cryptographic keys, sensitive data and performs cryptographic functions in a secure environment; the Wallet Secure Cryptographic Application, that is, an application that manages the functions inside the WSCD and connects the WSCD with the Wallet Instance; and the Wallet Provider Backend, responsible for offering support to Users, performing maintenance and issuing Wallet Unit Attestations that define the properties of that specific Wallet solution [1]. The Wallet Provider is also responsible for attesting the correctness of the WSCD Fig. 1. High-level architecture of the EUDI Wallet Wallet Instance Wallet Secure Cryptographic Application WSCD Wallet Provider Backend Relying Party User Presentation Secure Cryptographic Interface Wallet Unit Attestation, Maintenance User Interface Wallet Unit User Device Contribution Title (shortened if too long) 3 and ensuring that all users have access to a WSCD secure enough to achieve a high LoA. The ARF considers several WSCD architectures: native, local internal, local external and remote [1]. A native WSCD is hardware belonging to the User device, such as processors with ARM TrustZone or the iPhone’s Secure Enclave. A local internal WSCD is hardware within a User device, such as an eSE (embedded Secure Element) or SIM card. A local external WSCD is a device outside the User device but connected by a short-ranged connection like NFC or Bluetooth. A remote WSCD is generally achieved by a Hardware Secure Module (HSM) in a remote server. Also, a hybrid model combining different types is also accepted as a solution. A WSCD should be scalable (easily deployed and implemented), inclusive (accessible to Users with old or low-end smartphones), and user-friendly (comfortably integrated into the User experience) [5]. Native WSCDs are very user-friendly because they are already integrated into the device, but they are not scalable or inclusive. A study [6] on the Italian market revealed that only 10.5% of mobile phones had a certified native solution secure enough for the EUDI Wallet requirements. Local internal WSCDs are not easily scalable because the development of applications for them is restricted and controlled by the device manufacturer or issuer [7]. Local external solutions can be problematic regarding user-friendliness since they require Users to buy and carry a new secure token, such as a smart card or a USB key. Hence, we focus in this paper on remote WSCDs, because they are inclusive (they do not depend on the User device hardware), easy to use (they do not change the interface between the User and the Wallet), and easily scalable, as they are a cloud-based service. Relying Parties should not be able to identify the User unless it is necessary for their services. One of the functionalities of the Wallet established on the ARF is the generation and use of pseudonyms for authentication [1]. Pseudonyms avoid malicious Relying Parties from tracking the interactions of a User with multiple Relying Parties, which could lead to an identification of the User. The WebAuthn API for Public Key Credentials by W3C [8] defines the technical specifications for Passkeys, which are a type of pseudonyms. Passkeys are public-private key pairs created when registering a User into a new service and used for authentication. During the registration phase, the User generates a new key pair, stores it in a secure device and sends the public key to the Relying Party. In the authentication phase, the Relying Party sends a challenge to the User, who uses the private key stored at registration to sign the challenge and sends it back to the Relying Party. If the Relying Party verifies the signature correctly with the public key saved at registration, the User is considered authenticated. The secure device used to manage the User’s Passkeys is called an authenticator by the WebAuthn API. Before the introduction of Passkeys and pseudonyms in the ARF, the use of FIDO Authenticators (authenticators manufactured or certified by the FIDO Alliance) were already proposed as a solution for the EUDI Wallet [9]. The FIDO Alliance also published a whitepaper on the use of FIDO Authenticators and WebAuthn in the Wallet [10]. FIDO Authenticators are mostly native or local internal or external [11]. In the context of the EUDI Wallet, the authenticator is the WSCD. Before using a Passkey saved on the WSCD, the WSCD needs to authenticate the User [1]. 4 F. Author and S. Author In this paper we present the implementation of a high-LoA EUDI Wallet with a remote WSCD, following the specifications of the ARF. The WSCD, exploiting the hardware security of the Intel SGX Trusted Execution Environment, authenticates the User by device possession, password knowledge, and facial biometrics. Hence, the User’s identity is securely linked to their digital Wallet, which is known as User binding. Also, the WSCD generates and manages Passkeys securely, allowing the User registration and authentication in several Relying Parties, without revealing their identity. We constructed an example implementation using an Android phone, a Relying Party server and an Intel SGX enclave running on a desktop. The experimental results obtained show that it is a feasible solution. The paper is structured as follows. In Section 2 the necessary background about Passkeys and Intel SGX is introduced. Section 3 explains the implementation proposed, describing the protocols between the Wallet Instance and the WSCD for User binding and between the Wallet Unit and the Relying Parties for User registration and authentication using Passkeys. Section 4 presents the demonstrator constructed and the experimental results. Finally, Section 5 concludes our work. 2 Background 2.1 WebAuthn API for Public Key Credentials The WebAuthn API for Public Key Credentials [8] defines the use and lifecycle of Passkeys. Four different parties are defined. Following the nomenclature used in the ARF [1], the parties are: • Relying Party Server: the Relying Party that wishes to offer a service for which it needs to authenticate the User. • Relying Party Client: program that runs in the Client of the User (at the User device) and communicates with the Relying Party Server. • Client: the client that the User uses to interact with the Relying Party client and with the Authenticator. In the EUDI Wallet, this is part of the Wallet Instance at the User device. • Authenticator: secure environment or device controlled by the User to create, store and manage Passkeys. In the EUDI Wallet, it is the WSCD. The WebAuthn API establishes a model defining the responsibilities or actions of every party, without defining how the Authenticator and Client must communicate. The WebAuthn API defines multiple IDs that are necessary so that the protocol works: • Relying Party ID (RP ID): a unique identifier for the Relying Party. The Authenticator will learn which Relying Party is asking for authentication and if a Passkey exists for said Relying Party. • Credential ID: a unique identifier for each Passkey. Contribution Title (shortened if too long) 5 • User ID: a unique identifier for each User and Relying Party, assigned by the Relying Party and provided to the Authenticator. The Authenticator will keep track of the User IDs for each Relying Party. • User Name: an alias assigned to a specific User ID. It allows the User to easily decide which Passkey to use. To ensure that the Authenticator has created and saved the Passkeys during registration, an attestation of the attributes of the Authenticator can be included. In the WebAuthn API there are multiple types of attestations mentioned: • Basic Attestation: the Authenticator stores an Attestation key pair and employs it to sign every newly created public Passkey. A certificate on the Attestation key is included in every registration. To avoid tracking by malicious Relying Parties, multiple Authenticators should have the same attestation keys (for example, the same models by a certain manufacturer would have the same attestation keys and certificates). • Attestation CA: the Authenticator stores a master key pair and uses them to communicate with a Certification Authority (CA). This CA would issue certificates on multiple attestation key pairs. A malicious Relying Party could partially track the movements of the Passkeys that used the same attestation key. • Anonymization CA: same as the Attestation CA but the CA certificates a new Attestation key pair every time a Passkey is generated. Only the CA that certifies the Authenticator could track the User movements. • Self Attestation: the attestation is signed with the private key of the new Passkey pair. This does not give any guarantees to the Relying Party that a valid Authenticator is being used. • No Attestation: no attestation is presented. This does not give any guarantees either to the Relying Party. Given the security properties of the EUDI Wallet, Self Attestation and No Attestation are not valid options for the WSCD. 2.2 Intel SGX Intel SGX (Software Guard Extensions) is a Trusted Execution Environment (TEE) included in some Intel processors. It creates secure containers called enclaves that provide integrity and confidentiality to all code and data inside, protecting its contents from the rest of the server/desktop [12]. A measurement hash of all the code and data loaded into the enclave during its creation is calculated and used for future identification/attestation of the enclave. Two secrets are embedded into the processor using efuses, a type of One Time Programmable (OTP) memory. These secrets are used together with the enclave measurement hash to derive unique Enclave Sealing Keys (𝑘𝑆𝑒𝑎𝑙) for each enclave. Attestation of the platform and code is performed to ensure a remote party that it is communicating with the correct enclave. An attestation report containing the enclave’s measurement hash is signed with an SGX Attestation Key and sent to the remote party. 6 F. Author and S. Author The SGX Attestation Key is verified by a chain of certificates, including an Intel signature [12]. To securely communicate with the enclave and send private data, a Transport Layer Security (TLS) handshake can be performed [13]. TLS is an industry standard for secure communications. TLS allows for the authentication of one or both parties by exchanging X.509 certificates that include the public TLS key of one party and are signed by a Certification Authority [13]. It protects the integrity and confidentiality of the data by establishing a common symmetric session key between the two parties with a protocol called TLS handshake. Enclaves can perform a TLS with a remote party for secure loading of secret information. Fig. 2 shows an overview of a TLS handshake between a remote party and an enclave. First, the remote party sends a “ClientHello” which includes a random nonce. The server answers with a “ServerHello” (similar to the ClientHello) and its X.509 certificate. The remote party encrypts a secret with the public key (𝑇𝐿𝑆𝑝𝑘) included in the certificate and sends it to the server. The enclave is the only party that can decrypt said secret. Lastly, both enclave and remote party compute a session key (𝐾) from both random nonces and the last sent secret. All future messages in the session will be sent encrypted with 𝐾 [13]. RA-TLS [13] is a type of TLS that includes the attestation report of an enclave in the X.509 certificate. The attestation report includes the public TLS key which ensures to the other party that the keys were created inside the enclave. To verify an attestation report, Intel offers quote libraries [14] which are not compatible with some architectures of mobile processors. Although several vulnerabilites of Intel SGX security have been discovered throughout the years [15], such as side-channel attacks that extract private data by studying timing information, power consumption, instruction counts, etc., several measures have also been given to avoid them, such as disabling hyper-threading on the Fig. 2. TLS handshake between an enclave and a remote party Contribution Title (shortened if too long) 7 processor, using memory safe languages, updating Intel SGX microcode (that provides patches to certain attacks) and using external libraries with no known vulnerabilites. 3 Proposed scheme We propose the use of an enclave to host remote WSCDs in a remote server. The enclave has an Enclave Sealing key (𝑘𝑆𝑒𝑎𝑙) from which the WSCD of the User would derive a unique Sealing key (𝑊𝑘𝑆𝑒𝑎𝑙), ensuring that no User can access another User’s WSCD. The private data saved on the WSCD, such as the Passkeys (𝑃𝐴𝑆𝑆𝑝𝑘, 𝑃𝐴𝑆𝑆𝑠𝑘) or enrolment data, are encrypted with the WSCD Sealing key and saved in the longterm memory of the remote server. A multi-factor authentication scheme is used by the WSCD to authenticate the User before doing any cryptographic operation. The authentication is based on what the User knows (a password), what the User has (a secret key stored inside the mobile device) and who the User is (face biometrics). Once the WSCD authenticates the User, the User can employ the EUDI Wallet to enroll/authenticate in a Relying Party using the Passkeys created and stored at the WSCD. The Wallet Provider is responsible for attesting the WSCD (as indicated in the EUDI Wallet ARF). Since the User mobile device cannot verify an Intel attestation report, we propose that the Wallet Provider acts as a Certification Authority and provides the enclave with a signed TLS certificate. A secure communication channel is established between the Wallet Instance at the User device and the remote WSCD by a TLS handshake. Sensitive data are sent to the Table 1. Keys used on the WSCD Key Key Function Enclave Sealing Key (𝑘𝑆𝑒𝑎𝑙) Sealing key of the Intel SGX Enclave based on the enclave measurement hash. WSCD Sealing Key (𝑊𝑘𝑆𝑒𝑎𝑙) Sealing key of a specific WSCD, derived from the Enclave Sealing Key and the User secret. SGX Attestation Key Pair (𝑆𝐺𝑋𝐴𝑇𝑇𝑝𝑘, 𝑆𝐺𝑋𝐴𝑇𝑇𝑠𝑘) Attestation Key Pair used for attesting the enclave and certified by Intel. Enclave TLS Key Pair (𝑇𝐿𝑆𝑝𝑘, 𝑇𝐿𝑆𝑠𝑘) Key Pair generated inside the enclave and used to establish a secure communication channel with the User. Ephemeral session Key (𝐾,𝐾𝑅𝑃) Keys established by the TLS handshake to establish a secure communication channel. Passkey Attestation Key Pair (𝐴𝑇𝑇𝑝𝑘, 𝐴𝑇𝑇𝑠𝑘) Attestation Key Pair used for attesting the WSCD to Relying Parties and certified by the Wallet Provider. Passkey (𝑃𝐴𝑆𝑆𝑝𝑘, 𝑃𝐴𝑆𝑆𝑠𝑘) Key pair used to authenticate a User to a Relying Party. 8 F. Author and S. Author enclave encrypted with the ephemeral session key (𝐾) and decrypted inside. Since all the data inside an enclave is confidential, the enclave can handle it as plaintext without the remote server seeing or learning any information. The authentication information (such as the face image, the password or the mobile device secret) is deleted at the end of the protocol. Since the enclave cannot deviate from the code loaded at creation, it cannot act maliciously and save any private information. The Wallet Provider also signs a certificate for the Passkey Attestation Keys (𝐴𝑇𝑇𝑝𝑘, 𝐴𝑇𝑇𝑠𝑘) created inside the enclave. Since multiple WSCDs are handled by the same enclave, the Attestation is based on Basic Attestation. These Attestation Keys are different from the SGX Attestation Key mentioned in Section 2; while SGX Attestation Keys are certified by Intel, our Attestation Keys are certified by the Wallet Provider (because they attest the WSCDs of the provided wallets). Table 1 shows the keys used on the WSCD. 3.1 User Binding When initiating the Wallet, the User needs to establish multiple authentication factors with the WSCD for future multi-factor authentication. We show in Fig. 3 the binding process between the User through the Wallet Instance (inside the User device) and the WSCD. First, a secure communication channel is established between them with a TLS handshake. In the process, the WSCD presents a certificate signed by the Wallet Provider to prove its identity. A secure session key 𝐾 is established and the following communications are encrypted with said symmetric key 𝐾. Then, a new 𝑊𝑎𝑙𝑙𝑒𝑡 𝐼𝐷 is generated inside the WSCD. The User device takes a sample of the User face (𝑠𝑎𝑚𝑝𝑙𝑒𝐸) for biometric authentication, introduces a password which is hashed (ℎ𝑝𝑎𝑠𝑠𝐸) for what the User knows, and presents a secret key stored inside the device for possession authentication (𝑠𝑒𝑐𝑟𝑒𝑡𝐸). Fig. 3. Protocol between the Wallet Instance and the WSCD for User binding Contribution Title (shortened if too long) 9 The three factors are encrypted with 𝐾 and sent to the WSCD. Inside the enclave, the three factors are decrypted and used to create the enrolment data as follows: 1. The 𝑠𝑒𝑐𝑟𝑒𝑡𝐸 and the Enclave Sealing Key 𝑘𝑆𝑒𝑎𝑙 are used to derive a unique sealing key for the User WSCD, 𝑊𝑘𝑆𝑒𝑎𝑙. 2. The binary biometric embeddings are extracted from the face sample 𝑏𝑖𝑜𝐸← 𝐹𝑒𝑎𝑡𝑢𝑟𝑒𝐸𝑥𝑡𝑟𝑎𝑐𝑡𝑖𝑜𝑛(𝑠𝑎𝑚𝑝𝑙𝑒𝐸). Details about this process are given in Section 4. 3. The password hash and the binary biometric embeddings are XORed to create the enrolment data 𝑚𝑓𝐸← ℎ𝑝𝑎𝑠𝑠𝐸⊕𝑏𝑖𝑜𝐸. 4. The enrolment data are symmetrically encrypted with the enclave’s sealing key as 𝑚𝑓𝐸 ←𝐴𝐸𝑆. 𝐸𝑛𝑐𝑊𝑘𝑆𝑒𝑎𝑙(𝑚𝑓𝐸). We employ the AES algorithm. The 𝑊𝑎𝑙𝑙𝑒𝑡 𝐼𝐷 is sent to the Wallet Instance where it is stored. The WSCD stores the 𝑊𝑎𝑙𝑙𝑒𝑡 𝐼𝐷 and the encrypted enrolment data 𝑚𝑓𝐸  and deletes all other information: 𝑠𝑎𝑚𝑝𝑙𝑒𝐸,ℎ𝑝𝑎𝑠𝑠𝐸, 𝑠𝑒𝑐𝑟𝑒𝑡𝐸, 𝑊𝑘𝑆𝑒𝑎𝑙,𝑏𝑖𝑜𝐸, 𝑚𝑓𝐸. 3.2 User Registration at a Relying Party When registering for a new Relying Party service, a new Passkey needs to be generated. Fig. 4 shows the User registration process with a Relying Party. First, a secure communication channel is established between the Wallet Instance and the Relying Party; we assume the protocol used is TLS and a session key 𝐾′𝑅𝑃 is established to encrypt the communications. The Wallet Instance asks to register with a new 𝑈𝑠𝑒𝑟 𝑁𝑎𝑚𝑒 and Passkey. The Relying Party generates a challenge (𝐶ℎ) and a 𝑈𝑠𝑒𝑟 𝐼𝐷 and sends them to the Wallet Instance with its Relying Party ID (𝑅𝑃 𝐼𝐷). Then, the Wallet Instance verifies that the received RP ID corresponds to the RP HTTPS Origin. This ensures no registration/authentication data is communicated to a wrong RP. To use the WSCD as an Authenticator, the User must be authenticated by the WSCD. Before sending any private data, the Wallet Instance and the WSCD create a secure communication channel using TLS and establish a new ephemeral session key 𝐾′. The Wallet Instance acquires a face sample (𝑠𝑎𝑚𝑝𝑙𝑒𝐴), performs the password hash (ℎ𝑝𝑎𝑠𝑠𝐴) and acquires the secret key stored in the device (𝑠𝑒𝑐𝑟𝑒𝑡𝐴) and sends them to the WSCD with the 𝑊𝑎𝑙𝑙𝑒𝑡 𝐼𝐷 encrypted with 𝐾′. The Wallet Instance also sends the necessary data for creating the Passkey: 𝑈𝑠𝑒𝑟 𝐼𝐷,𝑅𝑃 𝐼𝐷, 𝐶ℎ and the 𝑈𝑠𝑒𝑟 𝑁𝑎𝑚𝑒. The WSCD calculates the multifactor authentication data (𝑚𝑓 𝐴) to compare it with the enrolment data (𝑚𝑓𝐸). First, the WSCD Sealing Key (𝑊𝑘𝑆𝑒𝑎𝑙) is derived again using the secret 𝑠𝑒𝑐𝑟𝑒𝑡𝐴 and the Enclave Sealing Key (𝑘𝑆𝑒𝑎𝑙). Then, the authentication data 𝑚𝑓 𝐴 are calculated as 𝑚𝑓 𝐴← ℎ𝑝𝑎𝑠𝑠𝐴⊕𝑏𝑖𝑜𝐴. The enrolment data are decrypted as 𝑚𝑓𝐸←𝐴𝐸𝑆. 𝐷𝑒𝑐𝑊𝑘𝑆𝑒𝑎𝑙(𝑚𝑓𝐸 ). To compare the enrolment and authentication data, their Hamming Distance 𝑑𝑖𝑠 is calculated by XORing them and calculating the Hamming Weight (number of 1s) of the result: 𝑑𝑖𝑠 ← 16 F. Author and S. Author blocks. The signing method for the challenges and attestation was ECDSA with a 256bit curve as defined by FIPS 186-4 [24]. In Table 2, we present the execution times for User binding, registration and authentication at the WSCD and at the Relying Party, and the total execution time which includes communication times. These results prove that the operations can be executed at reasonable times. Table 3 shows execution times for the main operations considered inside the enclave. Compared to the execution times of these operations outside the enclave, it can be determined that the addition of the enclave does not imply much cost. Lastly, Table 4 shows the communication overhead in bytes between the different parties without including the necessary bytes for the regular TLS handshakes; the face images 𝑠𝑎𝑚𝑝𝑙𝑒𝐸 and 𝑠𝑎𝑚𝑝𝑙𝑒𝐴 are 307200 bytes each. This proves that the information required is minimal, even between the Wallet Instance and the WSCD. With Intel SGX1, the WSCD enclave needs 128 MB of RAM to be executed properly. In Intel SGX2 processors, the enclaves can have a maximum SGX RAM (Enclave Page Cache) of 512 GB [25], allowing the parallel execution of around 4000 enclaves at the same time. 5 Conclusions and future work Among the Wallet Secure Cryptographic Devices (WSCDs) considered by the Architecture and Reference Framework (ARF) of the European Digital Identity (EUDI) Wallet, we propose the use of a remote WSCD since it is the most inclusive, userfriendly and scalable. Its implementation is done with an Intel SGX enclave that provides integrity and confidentiality to all the cryptographic and biometric code and data processed by it, including the generation and management of Passkeys, which are a kind of pseudonyms defined by the W3C WebAuthn specifications. The paper describes the steps of the multifactor User authentication between the Wallet Instance and the WSCD for User binding. Also, the steps between the Wallet and a Relying Party offering an on-line service are described for User registration and authentication using Passkeys. The proposal has been tested with a demonstrator that uses the EUDI Wallet Android reference application offered by the official GitHub Organization of the European Digital Identity project. A Samsung Galaxy A52 was used as User device with the Wallet Instance and two servers were employed, one running on Intel SGX1 to act as the remote WSCD and the other acting as a simulated Relying Party. The execution Table 4. Communication overhead (in bytes) RP → WI WI → RP WI → WSCD WSCD → WI User binding - - 307280 8 User Registration 48 489 307336 489 User Authentication 40 89 307328 89 Contribution Title (shortened if too long) 17 times at the WSCD for User binding, registration and authentication at the Relying Party are 374.2, 375.2 and 373.8 ms, respectively. The RAM employed by the WSCD is 128 MB. The communication overhead between the Wallet instance and the remote WSCD for User binding, registration and authentication are 307.288, 307.825 and 307.417 kB, respectively, from which 307.200 kB correspond to the sample image for face recognition. When binding the Wallet Unit to the User, saving the secret and/or password in a distributed backup system could be selected by the User. In the case of the User Device being lost or the password being forgotten, the distributed backup system would allow the User to recover its Wallet Unit. The development and distribution of this backup system is a future line of work. Another future development is the inclusion of solutions for countering presentation and injection attacks to the face authentication [26]. Acknowledgements. This research was conducted thanks to Grants PDC2023– 145873-I00, CPP2022–009796, and PID2023-150809OB-I00 funded by MICIU/AEI/10.13039/ 501100011033 and the European Union NextGenerationEU/PRTR, thanks to the LICORICE Project with Grant Agreement No. 101168311 under the EU Horizon Europe, and thanks to the grant USECHIP (TSI-069100-2023001) funded by the Secretary of State for Telecommunications and Digital Infrastructure, Ministry for Digital Transformation and Civil Service and by the European Union – Next Generation EU/PRTR. References 1. European Digital Identity Wallet Architecture and Reference Framework. 2025. https://eudigital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/, last accessed: 2025/06/03 2. European Digital Identity (EUDI) Regulation. https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation, last accessed: 2025/06/03 3. European Commission. eID Documentation: eIDAS Levels of Assurance, https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eIDAS+Levels+of+Assurance, last accessed: 2025/06/03 4. Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015 on setting out minimum technical specifications and procedures for assurance levels for electronic identification means pursuant to Article 8(3) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market, http://data.europa.eu/eli/reg_impl/2015/1502/oj 2015, last accessed: 2025/05/14 5. Ubiqu. The 4 main Wallet Secure Cryptographic Device/Application options compared. https://ubiqu.com/the-4-main-wallet-secure-cryptographic-device-application-optionscompared/, last accessed: 2025/04/02 6. Ansaroudi, Z.E., Sciarretta, G., De Maria, A., Ranise, S.: Navigating secure storage requirements for EUDI Wallets: a review paper. EURASIP Journal on Information Security 2025(2) (2025) 7. GlobalPlaform. Card Specification Version 2.3.1. GlobalPlatform, (2018). 18 F. Author and S. Author 8. Web Authentication: An API for accessing Public Key Credentials Level 2 W3C Recommendation, 8 April 2021, https://www.w3.org/TR/webauthn-2/#sctn-intro, last accessed: 2025/05/15 9. Fehrensen, B., Hiltgen, A., Lindemann, R.: Fido Core for Eid-Wallets, https://ssrn.com/abstract=5009534, last accessed: 2025/06/03 10. Elfors, S.: FIDO Alliance White Paper: Using FIDO for the EUDI Wallet. (2023) 11. Domingues, P., Frade, M., Negrao, M.: Digital Forensic Artifacts of FIDO2 Passkeys in Windows 11. In: Proceedings of the 19th International Conference on Availability, Reliability and Security (ARES '24). Association for Computing Machinery, New York, NY, USA, Article 34, 1–10. (2024) 12. Costan, V., Devadas, S.: Intel SGX Explained. IACR Cryptol. ePrint Arch., 2016, 86 (2016). 13. Thomas Knauth et al.: Integrating Intel SGX Remote Attestation with Transport Layer Security. Intel Labs. https://arxiv.org/pdf/1801.05863, last accessed: 2025/06/03 14. Intel® Software Guard Extensions (Intel® SGX) Data Center Attestation Primitives: ECDSA Quote Library API, (2022) https://www.intel.com/content/www/us/en/content-details/734437/intel-software-guard-extensions-intel-sgx-data-center-attestation-primitivesecdsa-quote-library-api.html , last accessed: 2025/04/25 15. Kisand, A., Randmets, J.: An Overview of Vulnerabilities and Mitigations of Intel SGX and Intel TDX Applications. Cybernetica research report D-2-116 v1.4 (2025), https://cyber.ee/uploads/report_2025_sgx_19b89d79ed.pdf, last accessed: 2025/06/11 16. EUDI Android Wallet reference application, https://github.com/eu-digital-identity-wallet/eudi-app-android-wallet-ui, last accessed: 2025/04/28 17. Tsai, C., Porter, D. E., Vij, M.: Graphene-SGX: A Practical Library OS for Unmodified Applications on SGX. In: 2017 USENIX Annual Technical Conference, USENIX Association, CA, USA, (2017). 18. Flores, D.: Analysis of the European digital identity wallet reference implementation and integration of a multifaction authentication solution. Computer Sciencer Engineering Bachelor’s Thesis, University of Seville (2025). 19. Google AI for Developers. Face detection guide, https://ai.google.dev/edge/mediapipe/solutions/vision/face_detector, last accessed: 2025/05/05 20. Facenet, https://github.com/davidsandberg/facenet, last accessed 2025/01/10 21. Lim, M. H., Teoh, A. B. J.: A Novel Encoding Scheme for Effective Biometric Discretization: Linearly Separable Subcode. In: IEEE Transactions on Pattern Analysis and Machine Intelligence, 35(2), 300-313 (2013). 22. Jang, J., Kim, H.: Performance Measures. In: Li, S.Z., Jain, A.K. (eds) Encyclopedia of Biometrics. Springer, Boston, MA. (2015) 23. Arjona, R., Franco, C., Román, R., Baturone, I.: Combining CRYSTALS-Kyber Homomorphic Encryption with Garbled Circuits for Biometric Authentication. In: International Conference of the Biometrics Special Interest Group (BIOSIG), pp. 1-5, (2024). 24. FIPS 186-4 Digital Signature Standard (DSS) (2013), https://doi.org/10.6028/NIST.FIPS.186-4, last accessed 2025/04/25 25. Intel® Processors Supporting Intel® SGX, https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions-processors.html, last accessed: 2025/04/29 26. Encina, M.: Study and realization of biometric systems implemented in smartphones and robust against presentation attacks. Computer Sciencer Engineering Bachelor’s Thesis, University of Seville (2025).