Mobile devices are at the heart of banks’ digital strategies – both as an authentication channel and as a means to secure other communication channels.
In parallel, the PSD2 regulation is fast approaching in Europe. So how does PSD2 govern the use of mobile devices? Does it require special security measures to protect these devices?
The Regulatory Technical Standards (RTS) – which define how PSD2 is to be implemented – do indeed accept the use of mobile devices without requiring hardware companions, so long as the RTS security principles are fulfilled.
The compliance of mobile authentication solutions will depend on how banks or software developers implement them, and the RTS are setting high expectations. Specialized mobile-security vendors can cope with these expectations, but in-house developers will find them harder to meet.
So, what, exactly, is required?
The RTS list various security requirements that apply to multi-purpose devices such as tablets and mobile phones. These requirements cover:
- Data Protection: Banks must ensure that confidential data are either encrypted or not stored on the device, and that access to such data requires Strong Customer Authentication (SCA). For example, a specific password or a PIN code to unlock the user’s mobile.
- Secure Communication: Banks must ensure that all communication with/from the device is necessary, is encrypted, and only occurs with legitimate and authenticated sources. This requirement can be achieved with a Secure Channel to provide end-to-end security.
- Separate environment: PSD2 and RTS require a separate environment to protect data and software. This can be achieved through technologies such as Runtime Application Self Protection (RASP), which includes Jailbreak and Root detection features to control the application’s execution and prevent real-time attacks, and independent secure areas to store the application’s sensitive data.
- Device and software integrity: Another main requirement of the RTS related to mobile devices is the need for the system to implement defense mechanisms to make sure that the “device has not been altered by the payer or by a third party”. This is enforced by technologies such as:
- Strong obfuscation: the minimum security measure to protect a product against reverse engineering to make its code more difficult to analyze by the attacker, encrypting parts of the code which are then decrypted at runtime
- Jailbreak / Root detection: end users may access certain device resources that are normally inaccessible or apply personal configurations. Detecting that the device environment has been altered, even if it was done consciously by the payer, is a crucial element of security.
- Anti-debug: the aim is to slow down hackers in their attempts to create malware.
- Anti-tampering: Anti-tampering consists of detecting that the mobile application has been modified (binary or at run time) and preventing it from continuing to operate, as this may lead to malicious code execution.
So, what must banks do if they offer mobile solutions for eBanking and authentication? They must ask themselves if they have taken all aspects of security into account, including those that are specific to mobile banking. This means that they must make sure that:
- Authentication data is stored and processed in specific secure environments, ensuring isolation from the standard mobile OS.
- Confidential data are not stored, or are encrypted
- Accessing such data requires SCA
- They have enforced measures against data duplication
- Communication is encrypted
- Servers communicating with mobile devices must be authenticated
- Only the legitimate mobile device can receive or send authentication-related data.
Mobile devices will continue to be at the heart of banks’ digital transformation even after the September 2019 deadline – but special security requirements will apply. And banks will probably need expert help to meet these requirements.
If you want to know more about how mobile devices can be used in the context of PSD2, visit our website where you can read more and download several whitepapers on the topic. And as always, feel free to ask questions in the comments below.
