This is the second blog of our three part blog series, check out our first blog of the series here, link for third blog can be found here.
MUSAP project, worked on to create “Multiple SSCDs with Unified Signature API Library,” has been launched in Github. MUSAP is also running in a pilot in Mongolia to provide document signing service VSign.mn to SSCDs (i.e. Unitel Mobile ID on SIM cards & GSign as a remote signing app) to sign from.
This article will delve into following areas:
- Introduction
- Architecture
- MUSAP Library (native Android/iOS)
- MUSAP Link (docker)
- MUSAP Reference Implementations
- Use cases for MUSAP
- MUSAP being used by end-user apps
- Conclusion
1. Introduction
European Digital Identity Wallet (EDIW) security is based on asymmetric keys and qualified signatures and qualified signature creation devices. The need of a common (Qualified) SSCD interface for different Wallet implementations has been identified. ENISA Digital Identity Standards report (June 2023) mentions that “The harmonised interfaces that allow direct access to the internal and external mobile device cryptographic security that the apps (EDIW) can use to perform cryptographic security functions are an essential and instrumental function.” Image from our first blog illustrates MUSAP as a harmonized interface that allows access to cryptographic operations.
As MUSAP acts an intermediary layer that simplifies the integration of various Secure Signature Creation Devices (SSCDs) into smartphone applications allowing user multiple identities of different level of assurance (LoA). It addresses the complexities of SSCD technologies, offering a unified API Library for developers to use MUSAP in their Android or iOS applications.
MUSAP is a concrete effort to specify and develop a robust and unified API from the mobile signature app to the security anchor provided by secure signature creation devices (SSCDs). This is crucial for the provision of full interoperability and adoption of masses. As then user has multiple options to choose where they store their private keys.
While writing MUSAP specifications, Methics team took guidelines from Framework for Designing Cryptographic Key Management Systems (CKMS) outlined in NIST Special Publication 800-130 and eIDAS (910/2014). Specification document can be found here.
2. MUSAP Architecture
There are two MUSAP components:
- MUSAP Library → Client-side library for Android and iOS to be packages with end-user app
- MUSAP Link → A docker component deployed on server side of end-user app
Detailed joint architecture of MUSAP can be seen below:
In OC1 of NGI Trustchain project, Phone key store, Hardware Token, SIM based Mobile ID and eIDAS Remote Signing is interfaced with MUSAP. MUSAP never shares actual cryptographic keys of the SSCD with end-user-app. With user’s consent, only SSCD metadata is shared to the app.
MUSAP is designed with flexibility in mind, allowing developers to customize and extend its functionality according to specific project requirements. It is developed in a way which allows easy integration and offloads key management operations of end-user-app. End-user-apps call MUSAP api to call the library in phone. Later MUSAP Library is linked (initialized/enrolled) with Link through Coupling API. APIs in detail are listed in Specification and API repository.
2.1 MUSAP APIs
All our development efforts were focused on implementing this specification to create MUSAP Library and MUSAP Link which is utilizing 3 APIs which are generally called MP (Musap Project) APIs. They are:
- Native API (MUSAP API for Android or iOS) which can be used by end-user app to call MUSAP
- JSON API (Coupling API between MUSAP Library (Android/iOS) and Link) which can be used by end-user app to initialize MUSAP with server which is hosting Link.
- REST API (LINK API between Server/WebApp and MUSAP Link library) which can be used by server/WebApp to call MUSAP Link.
Image below illustrates different APIs in action.
3. MUSAP Library
To implement MUSAP in an end-user-app, developers can import MUSAP Android library or MUSAP iOS Library in their Android/iOS app projects. Defines what kind of SSCDs they want to support and its configurations. Library for Android and iOS use a similar project structure which is explained in the image below.
MUSAP library consists of the following main components (as illustrated in MUSAP architecture):
- Native API (MUSAP APIs)
- SSCD Interface(s)
- Metadata storage
Apart from using (native) library in the apps, End-user-app builders can use MUSAP Link Docker to provide server side connectivity to their apps.
4. MUSAP Link
The MUSAP Link establishes a connection between internet applications and the MUSAP library on a user’s smartphone. Additionally, each MUSAP link is seamlessly integrated with apps utilizing the MUSAP library. Serving as an essential component, MUSAP Link facilitates decentralized identity management. Decentralized Identity, or self-sovereign identity (SSI), is an emerging model for digital identity management, emphasizing user privacy and security. MUSAP Link offers a secure mechanism that eliminates the necessity for centralized identity management.
The MUSAP link server URL is configured on the MUSAP library to enable the connectivity between the link library and the library. MUSAP link provides:
- RESTful Integration: MUSAP Link provides a straightforward REST API for seamless integration with external web services.
- Push Notification Support: MUSAP Link provides simple push notification integration, supporting both APNs and FCM.
MUSAP Link server sends a push notification to smartphone which awakes the End-User App and MUSAP API. Next the MUSAP API requests MUSAP Link for the signature request data. Connection between MUSAP API and MUSAP Link is called as MUSAP Coupling API. Finally, MUSAP sends the signature request data to SSCD interfaced with end-user-app.
Moreover, it also supports the ETSI TS 102 204 API for integrating external SSCDs. Through ETSI standard MUSAP is able to talk to Methics products to enable Remote Signing (via eIDAS compliant Methics provided app based Solution) and Local Signing (via eIDAS compliant Methics provided SIM based solution).
For additional security there is a transport security layer between MUSAP library and MUSAP Link. When enabled, all message payloads between them are encrypted with AES-CBC-PKCS7 Padding cipher with a random IV. Messages also have a message authentication code to verify message integrity and authenticity. MUSAP library and MUSAP Link establish the encryption during enrollment.
The message payloads contain a nonce, and a timestamp. MUSAP Link rejects old messages (duration can be configured), and messages that have an already used nonce. Such mechanism prevent replay attacks on MUSAP Link, and ensures that each payload is unique.
MAC uses encrypt-then-mac scheme. MUSAP library encrypts the payload, and then calculates a HMACSha256 of the payload, user identifier, message type, and AES encryption IV. When MUSAP Link, or MUSAP library receives a message, it first checks if MAC is correct by comparing the calculated and received MACs. They reject messages with a wrong MAC. The MAC proves the authenticity of the message.
The image below shows a complete deployment scheme of MUSAP to enable multiple SSCDs for user to choose from.
Note: If the MUSAP library has a configured link library, the MUSAP library will automatically register itself on the link library when new keys are generated. This registration process establishes transport encryption, delivers push notification tokens and generates a unique identifier for the MUSAP library. This unique identifier can be entered by the user on the on-boarding page to allow request of signatures from MUSAP library.
5. MUSAP Reference Implementation
Apart from providing libraries and documentation, Methics team demonstrated use of MUSAP to build applications reference applications. During 9 months of OC1, we built following apps which uses MUSAP:
- Reference Demo app for Android: Repository implementing MUSAP demo Android app.
- Reference Demo app for iOS: Repository about implementing MUSAP demo iOS app.
Demo apps are tested and integrated with 4 keystores providing multiple LoA SSCDs and different SSCDs for end-user to use.
6. Use Cases for MUSAP
MUSAP provides unique use cases:
- Enable Type 1 (High) and Type 2 (Substantial) configurations of EDIW in one device
- Sign any data format (X.509, VC, DID, etc.)
- Support client-secret mode for DIDs and manage cryptographic operations
- Provide multiple sscds for end-users choose how they want to use their private key to sign/authn
- Handling Key Management methods and operations
6.1 MUSAP for EDIW (EUDIW)
According to ARF of EDIW, there will be two types of EDI Wallets, i.e Type 1 configuration Wallets and Type 2 configuration Wallets. These types of Wallet configurations Type 1 (according to eIDAS High LoA) and of Type 2 (according to eIDAS Substantial LoA) can be enabled in one device.
Note: Configurations are sets of specific rules and methods that define how the EUDI Wallet technology should be used to manage PID and (Q)EAA.
If EDIW itself or different variants of it uses MUSAP, multiple SSCDs (Substantial or High) can be interfaced with the app. If a Wallet has one key material for High and one for Substantial, it can be assumed user has identities of two different level of assurance. As in today’s world there are different SSCD/QSCD methods, MUSAP allows easy integration of those with end-user apps. MUSAP, supported by EU Cascade funding, facilitates the incorporation of two LoA SSCDs within end-user applications enhancing security and usability.
European Digital Identity Wallet and approved regulations, there is a requirement for both LoA configurations of the wallet.
Moreover, using MUSAP Library in EDIW app allows interfacing of existing eID schemes based on SIM, Remote Signing, HW token, ID cards (not in OC1 scope) etc. As eIDAS 2 dictates, EDIWs can benefit from tamper-proof secure elements to comply with the security requirements of identity wallets.
6.2 MUSAP for DIDs
According to DID foundation, when using client-secret mode for DIDs cryptographic operations can be outsourced to an external party. Here end-user apps using MUSAP can sign DIDs, support enabling of DID methods. Image below is from presentation of Methics partner Danubetech using MUSAP to sign their DIDs for enrollment.
6.3 MUSAP Signing Data Formats
MUSAP can sign using various signature algorithms that end-user application may need. It supports all SOG-IS agreed Cryptographic Mechanisms (Section 5.2). End-user app with MUSAP can support multiple signature formats, key algorithms, and signature algorithms provided by different SSCDs.
6.4 MUSAP Enables Multiple SSCDs
MUSAP allows end-user to choose how they sign documents or data. Meaning MUSAP can act sort of ‘certificate-selector’ or ‘SSCD-selector’. End user with MUSAP in their apps of use can have multiple options according to different LoA to sign or authenticate. MUSAP can allow end users to choose:
- different certificates or VCs, for example corporate or private certs
- different SSCD to sign and enter pin
MUSAP Demo video shows Methics team using MUSAP Android reference app to interface 4 keystores with end-user-app for the user to choose. Also MUSAP has allowed integration with existing identity systems.
6.5 MUSAP for Key Management Operations
Key management in smartphone apps (e.g ID wallet apps, or Signature Creation Applications, etc.) refers to the set of practices and processes involved in generating, storing, securing, and using cryptographic keys to manage and protect user’s private key, digital identities, and associated data. Key management is fundamental for handling cryptographic keys used in securing digital identities, transactions, and sensitive information. It plays a vital role in ensuring the security and integrity of the signer’s data. MUSAP allows app builders to leverage Native library for key management. For all app Users MUSAP library provides way to easily implement 2 key stores i.e Phone’s keystore and Yubikey.
7. MUSAP being used by end-user apps
During the OC1, team demonstrated that MUSAP can be used by other end-user-apps for their own use cases which involves interacting with SSCDs.
Two applications for different partner entities that are Danubetech Gmbh and VSign LLC were developed.
As mentioned in Section 6.2, Client-DID project utilized Divvy app to sign DIDs for their use case. Divvy is sent as an apk file to Client-DIDs. Danubetech team deployed MUSAP Link Docker on their environment and used Divvy app to sign DIDs.
VSign app has been uploaded on Play Store. Team conducted a pilot for over 1 month to see user demand in signing through different SSCDs. In 1 month over 1600 documents signed by users, who used Unitel Mobile ID to sign or sometimes GSign app to sign. Demo video explains the signing process and use of MUSAP in enabling two identities in one end-user-app.
8. Conclusion
In Methics opinion, acceptance of the European digital Identity Wallet and eIDAS 2, hinges on its user- friendliness, security, and how it provides LoA for specific use case (e.g Type 1 and Type 2 of EDIW configs). The feasibility of achieving widespread acceptance is closely tied to the system’s ease of use and its seamless operation on a global scale. MUSAP aims at easing easy implementation of EDIW by allowing both configs (LoA High and LoA Substantial) in one device and similarly many end-user apps can use MUSAP to easily interface key security.
MUSAP provides a standardized and simplified way for developers to request multiple LoA signatures, regardless of the programming language, SSCD platform, or technology used. This ensure consistency and interoperability across different systems. Especially as decentralized identity services become the main trend of identity services, MUSAP offers an interoperable route from centralized identities towards decentralized model. Using MUSAP traditional centralized systems like SIM based mobile ID can be enabled to provide authn/sign functionality as can be seen in this video demonstration.
Publish Date: 30th April 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.
Methics is positioned to support stakeholders responsible for making the EDIW a reality. As a global leader of open standard Mobile IDentity services, our products are delivering tech for strong authentication. Methics can integrate existing services and high level of assurance identity mechanisms to a new identity framework. We support digital identity over a wide variety of authentication mechanisms and security assertions. 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.