Securing the European Digital Identity Wallet with Apps

APPROACHES TO SECURING THE EUDI WALLET

• Risk terminology and approaches

  Organizations responsible for the development of EUDI wallets will already have their own general in-house approach to protecting the many assets for which they are stakeholders. This approach likely includes various risk management and threat management techniques to be used depending on the type of asset and its status.

  For example, a physical safe containing millions of Euros will face different threats and vulnerabilities than the intangible reputation of an organization's brand. Therefore, when treating the associated risks of these two assets, the organization would use different approaches.

  The EUDI wallet is designed to control access to verified, sensitive personal information, and provide a means of identifying and authenticating the owner of the wallet for the purposes of interacting with financial services, medical institutions, government agencies and other similar third parties. The value contained in these EUDI wallets, along with their use in authentication to third-party services, is attractive to threat actors.

  Further, large-scale deployment is the goal and any EU citizen will be able to install and use the EUDI wallet. Ultimately, the ambition is to have the EUDI wallet on hundreds of millions of unmanaged mobile phones, tablets and other devices. Each device type will have a different set of vulnerabilities that will evolve over time, so the EUDI wallet will likely be under constant across multiple fronts.When discussing potential strategies for securely deploying an EUDI wallet, this white paper will use risk management terms as defined by ENISA⁷ and NIST⁸ for consistency.

  

  Figure 3: Risk Management Terms, as defined by ENISA

  For existing assets with known vulnerabilities, a risk-based assessment may be most appropriate to identify, evaluate and prioritize risks to be treated. Figure 3 depicts 'risk' in terms of a 'threat', 'asset' and 'vulnerability'.

  When designing a new asset (in this case the EUDI wallet), the wallet has not been developed and therefore the vulnerabilities inherent to the asset, have not been identified. Further, it will almost certainly be a design-criteria to minimize the vulnerabilities. Therefore it may be more appropriate to use a model focused on identifying the 'attack surface' of the asset in order to implement appropriate security controls. This paper uses the NIST definition of 'attack surface⁹.

  Here are many terms used to define a 'security measure' to protect the attack surface, whether protection is against a known risk or not. These terms include 'control', 'mitigation', 'risk control' and 'countermeasure'. Since risks evolve over time as the threat landscape changes, new vulnerabilities are discovered and the asset is developed, these terms will be generalized as synonyms and use them interchangeably. Finally, the term 'vulnerability' can also refer to an 'absence of an effective control against a known risk'.

  

  Figure 4: Attack Surface' as defined by NIST

   

• Risk Assessment

  When protecting an existing asset with known threats and established vulnerabilities, a risk assessment may be the most appropriate technique to enhance the security of the asset.

  Figure 5 - Representative Risk Management Process

  Context/Triggers

  In this case, the context for a risk assessment would likely be an existing EUDI wallet deployment and would include current threats and the known vulnerabilities. The actual assessment could be triggered by a change to threat landscape, the identification of new vulnerabilities, a planned enhancement of the wallet, or a scheduled / ad hoc review.

  Identify Risks

  The first stage for the responsible parties is to identify the current and potential future risks associated with the EUDI wallet. Analyze Risks Analysis of these identified risks involves assigning a probability of each of them occurring, and the associated impact. When considering the probability of a risk occurring, the Common Vulnerability Scoring System¹⁰ is useful and commonly useful tool to quantify a vulnerability in terms of ease of exploit, size of attack surface, level of access required to exploit the vulnerability and the impact of exploit.

  Analyze Risks

  Analysis also considers existing controls or processes that are designed to minimize the risks. This stage of the risk assessment process is usually specific to the organization and is possibly based on, amongst other things, a mix of statistical analysis, empirical data, expert advice and modelling. The output could be a risk rating (such as high, medium and low), it could be expressed in impact (monetary, technical, operational and societal). As ENISA states: "....the specification of the risk level is not unique. Impact and likelihood may be expressed or combined differently, according to the type of risk and the scope and objective of the Risk Management process"¹¹.

  Evaluate and Treat Risks

  The organization can then evaluate which of these remaining risks to address and with which priority. For each residual risk, the organization will decide whether to:

  1. Improve, or optimize controls in the environment to further reduce the risk;
  2. Transfer the risk to another entity, such as insuring against the risk occurring or contracting another entity to treat the risk. It is worth noting that, even when transferring the risk, the organization is still responsible for the actual risk;
  3. Decide to avoid the risk entirely. In the case of the EUDI wallet, an example of risk avoidance could be the removal of a fully automated identity proofing process from the wallet. The removal of this process would also remove the associated risks of false positives in the identification proofing;
  4. Retain or accept the risk for a period of time. Risk retention/acceptance could be an appropriate response to a risk with a low likelihood of occurring and a minimal impact in the event it does occur. However it would be entirely inappropriate if the risk related to identity theft or data leakage.

• Threat Modelling

  For a new development where the vulnerabilities inherent to the asset have not been identified, threat modelling may be a more appropriate methodology and allows the developer to focus on the entire attack surface when developing and deploying security controls, and not just the risks.

  Figure 6: Representative Risk Management Process

  Figure 6 also includes a feedback loop since the:

  1. Features and/or the inherent value of the asset, in this case the EUDI wallet, may change over time;
  2. Threat landscape will change based on geopolitical, social, environmental factors;
  3. Discovery of vulnerabilities in technology, people and processes is an ongoing process;
  4. Risks inherent in the asset today can influence the EUDI wallet's features, threats and discovered vulnerabilities tomorrow.

  Context/Triggers

  Threat modelling likely precedes the initial development of a EUDI wallet but could also be triggered by an enhancement to the wallet, a change to the threat landscape or a scheduled / ad hoc review. The context in modelling will be the planned functionality of the wallet and the entire wallet eco-system.

  Identify and Categorize Applicable Threats

  The first stages of threat modelling typically involve identifying the attack surface of the wallet. In practice, and taking into consideration that NIST defines an attack surface in terms of a system, "...he boundary, a system element, or an environment...",an effective way to achieve this is to deconstruct the wallet into multiple component parts that support the functionality. In essence you would break the EUDI wallet down into the functionalities and interfaces of the EUDI wallet similarly to Figure 2. Using knowledge of the applicable threats to the EUDI wallet and typical attack vectors, the organization can then either develop or choose one of several available threat models in order to categorize these threats.

  Analyze and Evaluate Threats

  During the analysis and evaluation of threats, the organization can then prioritize and group threats to devise a strategy to protect their EUDI wallet and ensure appropriate countermeasures (security controls) can be designed into the solution. The three types of security control are:

  1. Preventive - designed to prevent an attack or minimize the likely success of an attack;
  2. Detective - designed to notify in realtime or near-real-time of an attack; 
  3. Corrective - (once notified) designed to restore the asset to normal operations following and attack.

  Implement Security Controls

  In practice, the overall security design of the EUDI wallet willrequire a blend of these types of security control to be implemented. Given the modular nature of the EUDI wallet and the interface, these security controls will be reused frequently. For example, preventing access to sensitive information is a common requirement across all functionalities and interfaces of the EUDI wallet (Figure 2); as is ensuring the runtime integrity of each component. These controls will likely require the implementation of security tools, monitoring tools and processes.

  Validate Controls and Identify Vulnerabilities

  During the development phase of the wallet, there should be testing of the wallet to validate the effectiveness of these implemented controls and identify any vulnerabilities. The ideal outcome of this methodology is an EUDI wallet with minimal known vulnerabilities over its entire attack surface, not just in the areas of known risk. In doing so, this provides additional assurance that the wallet will be more resilient to as yet unknown threats and attack vectors.

INTRODUCING THE CRYPTOMATHIC MOBILE APP SECURITY CORE

Cryptomathic Mobile App Security Core (MASC)20 is a security software development kit (SDK) for the EUDI wallet, elD 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. It enables app developers to focus on developing excellent business applications while leaving the specialist security critical parts to MASC.

Protecting applications in a hostile environment is a cat-and-mouse game with attackers. Released over 10 years ago, MASC stays ahead by providing an evolutionary security framework through regular defense mechanism refinement and updates and randomized protections, disrupting the business model of fraudsters attempting to exploit the protection of targets long-term. MASC features multiple layers of security, including: libraries for security protocols, TLS authentication with pinned certificates and third-party libraries integrated for malware detection and device fingerprinting.

MASC offers technology for reverse engineering resistance, jailbreak / root detection and secure configuration and operation of generic mobile apps. To provide 360-degree protection, there are additional mechanisms for obfuscation, anti-tamper and anti-debug, as well as a reporting scheme allowing for live monitoring and dynamic analysis of the current threat landscape. A central part of MASC is the ability to provide the application with secure storage and independent cryptographic functions. The storage builds on and extends key stores offered by the device or OS and can be used to protect critical cryptographic keys, for instance application keys or communication keys for entities like the backend services

• How MASC Helps in Following the ENISA Guidelines

  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 server side, 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. MASC supports the implementation of 44 of these 47 security measures (94%)²¹, as detailed in Figure 14.

  Figure 14: MASC support for relevant ENISA Security Measures (relevant to Mobile App Security solutions)

   

• How MASC Helps in Following the OWASP MAS (based onMASVS v1.5)

  OWASP Mobile Application Security Verification Standard (MASVS) as detailed in Section 7.2 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. MASC can support the implementation of 49 of these 52 requirements (94%)²³, as detailed in Figure 15.

  Figure 15: MASC support for relevant OWASP MAS Requirements (relevant to Mobile App Security solutions)