Resources to Help You Develop and Test EUDI Wallet App Security

Itemizing the potential risks of the European Digital Identity (EUDl) Wallet scheme is a complex task that involves assessing the attack surface of the digital wallet app across various platforms, as well as the backend infrastructure, processes, and organizations involved. To provide support, the ENISA and OWASP mobile app guidelines offer useful resources for a secure development lifecycle of digital wallets, as outlined in this article.

We also introduce how Cryptomathic's Mobile App Security Core helps address the majority of the ENISA and OWASP security recommendations.

ENISA Smartphone Guidelines

Irrespective of whether an organization performed a risk assessment or threat modeling to arrive at its final approach to securing the digital wallet, ENISA’s published Smartphone Guidelines Tool is a useful resource against which organizations can reconcile the coverage and comprehensiveness of their security controls.

The guidelines provide recommendations for 152 security measures which are grouped into 13 domains, as listed below:

1. Correct handling of runtime code interpretation to prevent the introduction of deliberately malformed inputs to the app in order to alter its operational behavior or to leak information.
2. Secure data integration with third-party code to minimize the risks associated with using third-party code in the mobile app. Such risks include deliberate or inadvertent direct access to the app itself or user data, or the introduction of a vulnerability into an otherwise secure application.
3. Protection of the application from clientside injections to protect the mobile app from malicious attacks from sensors and other apps installed on the device, as well as third-party services that the device interacts with.
4. Secure handling of authentication and authorization factors on the device to protect credentials that are used to obtain access to mobile backend services and other services and accounts owned by the user.
5. Identification and protection of sensitive data on the mobile device to protect sensitive data such as personal user data and business-critical data stored on the device against extraction, for example in the event of device loss or theft.
6. In-transit protection of sensitive data to prevent the interception and modification of data passing through shared channels including Wi-Fi, cellular networking technologies, Bluetooth, and Near Field Communication (NFC).
7. Device and application integrity to protect the app both from and when operating in an insecure manner where its integrity may be compromised which undermines the security and privacy controls implemented in the mobile application.
8. Secure software distribution to implement best practices for distributing the software via mobile app stores including security updates.
9. Consent and privacy protection to minimize the likelihood of unintentional disclosure of personal or private information; and to ensure that user consent is provided for data collection, sharing, and usage that takes place on the application.
10. Correct implementation of user authentication, authorization, and session management to protect the mechanisms, secrets and data that are used to authenticate and authorize the user from unauthorized access in the event of sharing, loss or theft of a mobile device. These protections should cover the device when the application is dormant as well as in use.
11. Protection of paid resources to protect the device from possible abuse of access to phone calls, SMS, roaming data, NFC payments, and third-party payment systems.
12. Security of the backend services and the platform server and APIs to prevent unauthorized access to backend APIs and services either directly or via unauthorized connections through the mobile application itself.
13. Correct usage of biometric sensors and secure hardware to enforce best practices when enabling biometric sensors to be used in authentication mechanisms.

OWASP^® Mobile App Security guides

Another comprehensive and frequently updated resource comes from OWASP Mobile Application Security project. This includes three core components:

• OWASP Mobile Application Security Verification Standard (MASVS) – Defines a mobile app security model and lists generic security requirements for mobile apps. To be used during planning and architecture design stages of the mobile app. These requirements map to the OWASP Mobile Application Security (MAS) Checklist.
• OWASP Mobile Application Security Testing Guide (MASTG) – Contains a test methodology for verifying the implemented security controls. Includes actual test cases for iOS, Android as well test cases that are common across platforms. Test cases map to the OWASP MAS Checklist.
• OWASP Mobile Application Security (MAS) Checklist – Maps the security requirements in the MASVS to test cases in the MASTG to allow reconciliation of tests performed against to security.

The MASVS defines two security verification levels, Standard Security (MASVS L1) and Defense-inDepth (MASVS L2) which includes and adds to the Standard Security requirements. It is interesting to note that one of the requirements of MASVS L2 is that a threat model must exist.

An additional verification level called Resiliency Against Reverse Engineering and Tampering (MASVS R) is complementary to MASVS L1 and L2and is designed to ensure that the “app has state-of-the-art security, and is also resilient against specific, clearly defined client-side attacks, such as tampering, modding, or reverse engineering to extract sensitive code or data.”

As you would expect the verification guide states that MASVS L2 and MASVS R be applied to “All mobile apps that, by design, need to store sensitive data on the mobile device, and at the same time must support a wide range of devices and operating system versions. In this case, resiliency controls can be used as a defense-in-depth measure to increase the effort for attackers aiming to extract the sensitive data”. This description can be applied to an EUDI wallet.

In total, there are 84 requirements within the following 8 categories for MASVS L2 + R which can assist through the development lifecycle of the EUDI wallet:

1. Architecture, Design and Threat Modeling Requirements: to ensure that security has been explicitly addressed when planning the architecture of the mobile app, and that the functional and security roles of all components are known.
2. Data Storage and Privacy Requirements: to protect against exposure of sensitive data to other apps running on the same device, to cloud storage, backups, keyboard caches etc., either unintentionally or through attack.
3. Cryptography Requirements: to ensure cryptographic best practices are applied within the app.
4. Authentication and Session Management Requirements: to ensure best practices are applied within the app to user accounts and session management, either when the app is active or dormant.
5. Network Communication Requirements: to protect the communication between the app and back-end services.
6. Platform Interaction Requirements: to ensure that the app uses platform APIs and standard components in a secure manner and interact with other apps securely.
7. Code Quality and Build Setting Requirements: to ensure that basic and easy to implement security coding practices are followed in developing the app.
8. Resilience Requirements (MASVS R): to increase the app’s resilience against reverse engineering, tampering and specific client-side attacks.

How Cryptomathic MASC helps in following the ENISA Guidelines

As noted, the ENISA Smartphone Guidelines Tool suggests a total of 152 security measures to address the challenges and threats discussed thus far. Some of these measures are to be taken care of serverside, while others are to be implemented within the app itself; and of those, 47 security measures are relevant to the mobile app security solution space.

Cryptomathic's Mobile App Security Core (MASC) supports the implementation of 44 of these 47 security measures (94%), as detailed in the table below.

The three ENISA Security Measures not covered by MASC are:

(*) “Make reverse engineering harder: Obfuscate code. Encrypt data to further obfuscate application logic.” The MASC code and the control and data flows are heavily obfuscated in production builds. However, it does not obfuscate a mobile app’s native code. Our customers use third-party obfuscation services integrated with their development pipeline.

(**) “Audit communication mechanisms to check for unintended leaks (eg image metadata).” Similarly, our customers choose to use third-party static analysis tools integrated with their development pipeline.

(***) “Database files that contain sensitive data (e.g., iOS WebView caches) must be manually removed from the file system. Deleting records using the database API will not necessarily lead to complete data removal from database structure.” Apple actively discourages third-party management of Web View and while MASC has limited support, customers tend not to implement it due to the associated complexity. MASC does support Web View management on Android.

How MASC helps in following the OWASP MAS

OWASP Mobile Application Security Verification Standard (MASVS), as detailed above, suggests a total of 84 security requirements to address the challenges and threats discussed thus far. Of these, 52 security requirements are relevant to the mobile app security solution space.

Cryptomathic MASC can support the implementation of 49 of these 52 requirements (94%), as detailed in the table below.

The three OWASP MAS requirements not covered by MASC are:

(*) “All security controls have a centralized implementation.” While the security controls are located within the MASC library, the design strategy is to deliberately decentralize controls across the library to make it harder to hook or patch them out.

(**) “The app protects itself against screen overlay attacks. (Android only)” Screen overlay protection is outside the control of MASC. MASC detects screen mirroring and allows whitelisting of accessibility providers and 3rd party keyboards on Android.

(***) “Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via dynamic analysis.” The MASC code and the control and data flows are heavily obfuscated in production builds. However, it does not obfuscate a mobile app’s native code. Our customers use third-party obfuscation services integrated with their development pipeline.

Cryptomathic's Mobile App Security Core (MASC)

Cryptomathic's Mobile App Security Core (MASC) is a security software development kit (SDK) for the EUDI wallet, eID apps, mobile banking apps etc., comprising of multiple layers of mutually reinforcing mobile app security components that are provided with a simple, easy-to-use API. 

As shown, MASC helps solve the majority of the ENISA and OWASP security recommendations to enable app developers to focus on developing excellent business applications while leaving the specialist security-critical parts to MASC.

For more in-depth insights, download the white paper "The European Digital Identity Wallet: Implementing Best-Practice Security for a High-Risk Asset".

Contact us to hear how Cryptomathic can help your organization protect its EUDI wallet or read more about our Mobile App Security Core solution.