Skip to content

Is WSCD and WSCA described in European Digital Identity Wallet (EUDIW) ARF equivalent to SSCD?

This article examines the relationship between WSCD & WSCA (mentioned in ARF of EUDIW) and SSCD and is organized into the following sections:

  1. Wallets in eIDAS 2
  2. SSCDs and Protection Profiles
  3. ARFv1.4.0
  4. WSCD and WSCA
  5. Different WSCDs for use with EUDIW
  6. Conclusion

1. Wallets in eIDAS 2

eIDAS 2 (2024/1183) has been passed by European Parliament, to replace eIDAS (910/2014) and introduce European Digital Identity Wallets (EDIW or EUDIW). These wallets will need to be made available for end-users in European countries by 2026.

eIDAS 2 (2024/1183) final text states that SSCDs certified as Qualified (QSCD) in one Member State shall be recognized, respectively, as QSCD in all other Member States of the EU. Moreover, EUDIW should:

  • be able to rely upon “external secure elements” for the protection of the cryptographic material and other sensitive data
  • benefit from tamper-proof secure elements, to comply with the security requirements of wallet. As such reliance will allow Wallets users to create and use QES; and

It also states that Secure signature creation devices (SSCDs) of which the conformity has been determined in accordance with Article 3(4) of Directive 1999/93/EC shall continue to be considered to be QSCD under eIDAS 2 Regulation till 21 May 2027.

Note: QSCD is a Qualified SSCD which has been audited according to EU standards and according to eIDAS standards, only Qualified Trust Service Providers (QTSPs) can offer QSCD service at level of assurance High. Non audited SSCD can be provided by other entities apart from QTSP.

*eIDAS 2 mandates use of Wallet will remain completely up to citizens, however MS should guarantee availability of wallet to anyone who wants it. 

2. SSCDs and Protection Profiles

SSCD stands for Secure Signature Creation Device. It is a specialized hardware or software component designed to securely store private cryptographic keys and perform cryptographic operations. Such as creating digital signatures or doing strong customer authentication. SSCDs are crucial for ensuring the integrity and authenticity of digital signatures. By keeping private keys isolated and protected within a secure environment, they prevent unauthorized access and misuse.

SOG-IS stands for Senior Officials Group – Information Systems Security, which is a group of senior officials from EU member states. Group plays crucial role in developing and maintaining security standards for identity systems across the EU.

SOG-IS has been instrumental in defining the security requirements for SSCDs through Protection Profiles (PPs). These PPs are used to evaluate and certify SSCDs, ensuring they meet the highest security standards. Similarly it works with other organizations like CEN (European Committee for Standardization) and ETSI (European Telecommunications Standards Institute) to develop and harmonize security standards for information systems.

Examples of SSCDs and their Protection Profile include:

  • SIM/eSIM cards: UICC/eUICC can run a JAVA card applet that can use SIM/eSIM environment to generate keys and store it and create digital signatures. For example, Methics Alauda applet is being used in UICC/eUICC in Switzerland and Armenia. Both SSCDs for Mobile ID services. Protection profile for SIM based SSCD are: CEN EN 419 211- 2:2014 and CEN EN 419 211-4:2013.
    Protection profile for eSIM based SSCD are: SGP.25 eUICC PP and SIM PP when applicable.
  • Hardware Security Modules (HSMs): Dedicated appliances designed for high-security cryptographic operations, often used in enterprise environments. Certified as eIDAS remote signing based on two Protection profiles, one for Signature Activation module like Kiuru SAM that is CEN EN 419 241-2 and one for HSM that is CEN EN 419 221-5.
  • Hardware tokens: Physical devices like smart cards or USB dongles that store private keys and perform cryptographic operations.

Methics wrote a blog 2 years ago when only limited information about eIDAS 2 and Identity Wallets, we argued due to various technical limitations, Local and Remote implementation as viable options to implement EUDI Wallet app on Smartphone with QSCD/SSCD.

3. Wallet’s ARF

Though now eIDAS2 regulation officially passed and adopted, experts have been long working to define Architectural Reference Framework (ARF) for the digital identity wallets. Guidelines listed in ARF paves the way for Large Scale Pilots to test and validate wallets. Provide implementation mechanisms for European member states to adopt and lastly keeping the discussion open allows outside contributors to provide insights.

As now, ARF version 1.4 is released, it has given insights into the core component of these identity wallets, which is how wallet apps needs to act as a QSCD. It also introduces a new set of acronyms and concepts, some of which may seem familiar to those acquainted with existing digital identity standards.

ARF defines terms like Wallet Instance (WI). It is a software (mobile app) which is installed on a user device, which is part of an EUDI Wallet Solution and belongs to and is controlled by the user. Wallet Instance interacts directly interacts with the WSCD / WSCA to securely manage cryptographic assets and execute cryptographic functions, ensuring a high level of assurance for authentication.

Topic 16 of Annex 2 of ARFv1.4 lists requirements for Wallets to produce Qualified Electronic Signatures. One requirement states that Wallet Providers SHALL ensure that a Wallet Instance is able to create the signature value of the document or data to be signed either using a local or a remote signing application.

As its a developing doc other related topics such as, Developing an EUDI Wallet Architecture Based on Secure Element, or on External Token, or on Remote HSM. That brings into question, what is WSCD and WSCA?

4. WSCD and WSCA

ARF defines Wallet Secure Cryptographic Device a.k.a WSCD as a trusted hardware providing a secure environment and storage for cryptographic assets (such as keys) and for running the WSCA. This includes the keystore but also the environment where the security-critical functions are executed. The WSCD is tamper-proof and duplication-proof. ARF goes on to identify atleast four different WSCDs which can be used to provide same level of security.

Wallet Secure Cryptographic Application a.k.a WSCA is a secure application running on wallet secure cryptographic devices (WSCDs). One WSCA is associated with one WI, where application will manages assets, such as keys, for this specific user’s WI.

This communication between WI and WSCA or WSCD happens though a Secure Cryptographic Interface (SCI).  ARF says this interface is specifically designed for managing cryptographic assets and executing cryptographic functions.

Figure below from ARF provides an overview of the architecture of the EUDI Wallet ecosystem and its components. Circled areas are additional as we will discuss those to explain SSCD, WSCA and WSCD.

EUDIW Architecture – Figure 2 from EUDIW ARFv1.4.0

In the picture above, encircled A, B & C are different interfaces ARF describes for the first time.

ARF defines SCI as “Secure Cryptographic Interface (SCI) enables the Wallet Instance to communicate with the Wallet Secure Cryptographic Application (WSCA). This interface is specifically designed for managing cryptographic assets and executing cryptographic functions.”

If we focus on marked as “A” and “B” in the figure above, SCI, or interface to connect mobile app like WI to talks with SSCD has been building upon ENISA Guidelines partially. But “B” is something which is a link when combining WSCA+WSCD acts like a SSCD.

ENISA states in Digital Identity Standards report (June 2023) mentions that “The harmonized interfaces that allow direct access to the internal and external mobile device cryptographic security that the mobile-apps can use to perform cryptographic security functions are an essential and instrumental function.” Building upon this foundation Methics team has been building MUSAP with support of NGI Trustchain and EU Horizon 2020 funding.

However there is not much information on B & C, i.e. WSCA/WSCD interface and QES interface. Though eIDAS Remote Signing is a standardized implementation which can be audited and evaluated, but different vendors have different mechanisms for their implementation of Remote Signing solution.

In this case, “C”, RSI remote signing interface can be CSC API implemented by QTSPs offering remote signing? or it will be something new, remains to be seen.

But this work by A, B, & C interfaces circled in image above is arried out by MUSAP itself, so mobile apps can use it as plug nay play. We hope MUSAP is used by LSPs to enable SCI, RSI and WSCA/WSCD interface to talk with WSCDs.

Image below from our blog related to MUSAP, illustrates MUSAP as a harmonized interface that allows access to cryptographic operations. Similar task which SCI, RSI and WSCA/WSCD interface is producing. Similar to what Methics has developed as an Open-source library under NGI Trustchain project, called MUSAP.

As MUSAP acts an intermediary layer that simplifies the integration of various Secure Signature Creation Devices (SSCDs) into mobile apps or in this context, Wallet Instance (WI). Currently MUSAP is being used by some Wallet companies for building EUDIW prototype independently to rely on different technologies to act as a WSCD and WSCA.

5. Different WSCDs for Wallets

ARF goes on to identify atleast four different WSCDs which can be used to provide same level of security. They are:

  1. Remote WSCD: Where WSCD is situated remotely, separate from the user’s mobile phone.
  2. Local External WSCD: an external WSCD that is connected to, or interacts with, the User’s mobile phone to provide cryptographic functions.
  3. Local WSCD: an internal WSCD integrated directly within the User’s mobile phone. This includes solutions like eSIM and eSE.
    • For eSIM -> WSCA (e.g., a Java Card applet) might be deployed by the Wallet Provider.
    • For eSE -> Native mobile solutions, such as StrongBox (Google) and SecureEnclave (Apple), in which access to the WSCD is facilitated via the operating system of the user mobile.
  4. Hybrid architecture: Which can combine two or more of above mentioned WSCDs.

So in principal we can say that the WSCD is the secure and hard to get in vault of the EUDIW. And WSCA is the intelligent brain that operates the WSCD. Both these work to ensure protection the most sensitive components of your digital identity, i.e. your private key.

That brings us to a questions these WSCDs and WSCAs have been defined? When SOG-IS has published protection profiles for secure implementation of a SSCD and EU maintains a QSCD list?

Technically we can say that a combined WSCD (Wallet Secure Cryptographic Device) and WSCA (Wallet Secure Cryptographic Application) essentially fulfills the role of a SSCD (Secure Signature Creation Device).

However, there’s a one clear distinction. The term SSCD is used more generally in eIDAS and can encompass a broader range of devices and implementations. The WSCD/WSCA model, on the other hand, is specific to the EUDIW architecture only.

So ARF writers tried to add WSCD+ WSCA model to provide detailed and structured breakdown of the SSCD concept used for mobile apps. It separates the hardware aspect (WSCD) from the software aspect (WSCA).

The EUDIW framework builds upon the concept of SSCDs by further defining their components as WSCD (Wallet Secure Cryptographic Device) for the hardware aspect and WSCA (Wallet Secure Cryptographic Application) for the software aspect.

At the moment of writing this version of the ARF, it is not fully clear how many WSCDs will support the cryptographic functionalities necessary to generate a proof of association. Therefore, the creation of a proof of association in a WSCA is recommended (SHOULD), not required (SHALL). In this way, once a Wallet Instance has access to a WSCD/WSCA that supports the required cryptographic functionalities, proofs of association can be used as described in this Topic.

Furthermore, WSCD + WSCA separation and difference aligns with the growing trend towards decentralized identity, where individuals have greater control over their digital credentials. By using a secure WSCD and WSCA, users can confidently manage their digital identities, knowing that their private keys are protected and their cryptographic operations are tamper-proof. Similarly having multiple EUDIW architecture options can be implemented through a secure component API as MUSAP which acts as a SCI.

6. Conclusion

  • WSCD is the secure hardware component, while WSCA is the software running on it.
  • Separation of QSCD(SSCD) into a signature creation application and device provides viability to general public on operations of PKI.
  • To implement Wallet as a signature creation application SOG-IS protection profiles will be considered.
  • As eIDAS 2 provisions current SSCDs in market to be able to use with Wallets till 2027 paves a way for eIDAS2 and Identity Wallets to use existing identity schemes.
  • This framework ensures strong security and user control over private keys, and let them choose which WSCD they trust more.
  • Similarly commonly known SSCD concept is split into WSCD which is a carrier and WSCA is working around proof of association.
Publish Date: 11th July 2024

Written and Edited by: Ammar Bukhari & Jarmo Miettinen

MUSAP is a NGI TRUSTCHAIN funded project aiming to deliver an Open-Source Unified Signature API Library. MUSAP github repository can be viewed Here. This project has received funding from the European Union’s Horizon 2020 research and innovation program through the NGI TRUSTCHAIN program under cascade funding agreement No. 101093274. One main usecase of MUSAP is to interface multiple SSCD technologies with end-user apps like EUDIW. Methics will offer a bridge between traditional PKI and W3C decentralized identity projects to provide identity and signing services. Feel free to get in touch with us if you want to discuss the presented model of MUSAP or have some other queries related to Digital Identity.


References

  1. eIDAS 2 (2024/1183) regulation:
  2. EUDIW ARFv1.4.0: https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/arf/
  3. Digital Identity with MUSAP: A library for EUDI Wallets, eIDAS and Identity apps: https://www.methics.fi/digital-identity-with-musap-a-library-for-eidas-eudi-wallets-and-identity-apps/
  4. Eurosmart position paper on https://www.eurosmart.com/wp-content/uploads/2023/01/Eurosmart_positionpaper_level_High_eIDAS_Final_public.pdf
  5. SOG-IS Protection Profiles-
  6. SSCD Wikipedia: https://en.wikipedia.org/wiki/Secure_signature_creation_device