PSD2: Creating a Secure Execution Environment for Mobile Banking Apps

The revised Payment Services Directive, also known as PSD2, pays a lot of attention to the security of mobile banking apps, mobile payment apps, mobile wallets, and other apps that offer payment functionality.

The most important requirements related to mobile app security are present in Article 9 of the final Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC), an addendum to PSD2. This article requires financial institutions (FIs), which use mobile devices to authenticate the payer or financial transactions, to “mitigate risks resulting from the mobile device being compromised”. The article lists a number of mitigating measures that FIs should adopt, including the “use of separated secure execution environments” on the mobile device, as well as mechanisms to detect and defend against alterations of the mobile device.

These mitigating measures in the final RTS are quite vague. However they apply to mobile banking apps and other apps with payment functionality, as the authentication mechanism of such apps relies on the mobile device. As a consequence, mobile banking apps need to run inside secure execution environments and be protected against alteration of their functionality.

In this article we explore the mobile app security requirements of PSD2 in more detail, and discuss how banks can make sure that their mobile apps comply with these requirements.

White Paper

Mobile App Shielding: How to Reduce Fraud, Save Money, and Protect Revenue

Discover how app shielding with runtime-protection is key to developing a secure, resilient mobile banking app.

Download Now

What Is a Secure Execution Environment?

The final RTS states that financial institutions must use secure execution environments to protect mobile apps. However, the final RTS does not define what a secure execution environment actually is, or how it could be implemented. The RTS does not provide this level of detail in order to be future-proof and technology-independent, which are reasons that make sense. However, it also leaves FIs, who need to implement a secure execution environment in practice, in the dark about what such an execution environment should look like. Similarly, it provides limited guidance to national competent authorities, who need to decide whether a certain financial institution’s approach towards mobile app security actually meets the requirements of the final RTS.

Let us therefore first try to come up with a useful definition of “secure execution environment” (SEE). In the world of trustworthy computing, an SEE is typically defined as an integrity-protected processing environment, consisting of processing, memory, and storage capabilities. As such the SEE is isolated from the “normal” processing environment of the mobile device, and it ensures that mobile apps can be executed without interference from other processes or mobile apps (e.g. malware) residing on the same device.

Such SEEs can be realized using hardware architectures such as ARM TrustZone or those based on GlobalPlatform’s Trusted Execution Environment (TEE) specification. However, as of today adoption of such hardware-based security architectures is low.

The good news is, the definition of SEE in the RTS clearly allows SEEs that do not rely on hardware security mechanisms. An early draft version of the RTS stated that the “secure execution environment” could be built using software-only security mechanisms, and that it does not have to rely on hardware-based security mechanisms. Earlier versions of the RTS used the wording “trusted execution environment” rather than “secure execution environment”, but this was changed in order to stress that non-hardware mechanisms suffice as well.

A more pragmatic definition of SEE could therefore be as follows: an SEE is an execution environment that provides protection against known attacks against mobile apps. This approach looks at attacks that banks encounter in the field today, and considers an execution environment secure if it provides reasonable protection against these attacks. As such, the definition of secure execution environment evolves over time as the threat landscape for mobile banking apps evolves.

Currently, the most important mobile banking security threats that we observe are:

• Overlay attacks: Malware on the mobile device displays a window on top of the genuine banking app that closely resembles the banking app. The malware aims to capture the user’s banking credentials (e.g. username, PIN). Common Android malware families such as Marcher and BankBot are known for such attacks.
• Code injection or hooking: Malware attempts to alter the functionality of a mobile banking app. For instance, the app could be modified to log the PIN code of the user, or to manipulate the beneficiary of a financial transaction. Hooking frameworks such as Frida and Xposed are freely available to fraudsters for this.
• Keylogging: Malware on the mobile device intercepts keystrokes or gestures in order to steal sensitive data such as PINs.
• Interception of SMS messages: SMS messages are intercepted with authentication codes using malware on the user’s phone. This is a popular feature of many Android mobile malware families nowadays.

How to Create a Secure Execution Environment

In order to create a secure execution environment for mobile banking apps, we recommend protecting them using application shielding technology, also referred to as Runtime Application Self-Protection or RASP security. This technology protects a mobile app against several types of run-time threats. As such it creates a virtual secure execution environment for the app, allowing them to be executed even on untrustworthy mobile devices.

Application shielding protects mobile apps using a combination of preventive, detective and reactive approaches. It prevents run-time threats, for instance, by obfuscating code to make reverse engineering more difficult. It detects attacks at run-time, such as attempts to tamper with the app or run the app inside an emulator. Finally, it can react to run-time attacks in different ways, such as alerting the bank’s server-side risk engines, or even shutting down the app.

Learn more about how to identify and block malware attacks in real-time with this white paper:
https://www.onespan.com/solutions/invisible-mobile-banking-channel-security

This article, authored by Frederik Mennes, Senior Manager Market & Security Strategy at the OneSpan Security Competence Center, first appeared 06/2018 in German on IT Finanzmagazin.