PSD2: what does it change for banking mobile apps security?

With PSD2 new regulations, mobile banking applications are no longer a mirror of bank web applications, but provide a set of dedicated, additional services. With new functions added, such as strong customer authentication, cybersecurity has become more important because there is more to protect and there is more at stake. Security protection can be implemented at different levels of the system. It is sometimes necessary, some other times a best practice, to add protections in the mobile application. Banking applications cannot really avoid having an extra layer of protections to mitigate the risk of software tampering. Ideally, assuring the security goes hand in hand with functional quality assurance. Software testing can now embrace efficient ways to realize integration of automated and dynamic security testing into the development and deployment process. This will lead to a better functional and security quality assurance without compromising the time to market.

May 2021 marks the start of a new era for transaction security in Europe, thanks to the PSD2, Payment Services Directive, impulsed by the European Commission. PSD2 paves the way for more open banking, involving different parties. One of the main requirements concerns the mandate of Strong Customer Authentication (SCA).

These recent changes have a strong impact on the security of mobile applications. Are you prepared for it?

What is Strong Customer Authentication?

SCA allows increasing the security of any transaction by having an authentication of the customer by his banks using at least two factors of authentication.

SCA simply means that a bank shall enforce two independent factors for authentication, e.g.

• The user knows something, such as a secret PIN code or passphrase,
• The user owns something, such as a mobile phone, a payment card,
• The user is something, such as a biometry feature.

There are many ways to implement the requirements and PSD2 regulation leaves it to the financial institutions to show compliance with the directive.

For day-to-day operations, what is the impact?

For card-present transactions when shopping in-store for instance, the requirement is already met when a PIN verification is involved. Indeed, the customer combines the fact to hold a payment device together with the knowledge of the secret PIN code.

For card-not-present transactions when shopping online, the situation is different. Online payments are particularly of concern. In that case, PSD2 requires extra verification. Usually, 3-D Secure is the most frequent solution.

Behind this word, we are now used to having this kind of page:

Personally, I no longer own any device reader provided by my bank. With such a device, it was possible to have a strong authentication using my banking card (I own it) together with my PIN code (I know it) like a card-present transaction. A typical device looks like this:

I don’t know for you, but it is not convenient, simply because I seldomly had the small device reader with me. Because it is impossible to imagine making it a strict requirement and it discourages nomadic customers like myself from spending my money, most banks have released a new mobile authentication application for SCA as an independent second factor.

Can your banking mobile app be your SCA partner?

In response to the PSD2 requirements and bank customer needs, most European banks have released mobile apps replacing the additional device. It significantly changes the user experience when performing online payments transactions.

Indeed, it is reasonable to assume that I always have a mobile phone with me. When purchasing online or validating a specific transaction related to my account, a notification pops up on my application, and I simply must confirm the request and then authenticate myself with my fingerprint. With the mandates impulsed by PSD2, compliance can be achieved by pairing the application with the mobile (I own it) and leveraging biometric authentication (I am it) or password verification (I know it).

The mobile device, together with the banking mobile application, becomes THE companion to undertake transactions, wherever they have been initiated: from the same mobile or from any other device. It is therefore critical in your payment transactions’ security.

Interestingly, new services were added to the mobile application. It intends to improve the digital user experience with the bank. One crispy example concerns the ability to display the PIN code of my banking cards, both professional and personal. This feature is not available on all banks, but it shows the new trend to offer more convenience. After authentication, I have access to all my banking cards in a trolley.

An additional authentication, but the same fingerprint verification, is required to display the secret PIN code. It is displayed for a few seconds after becoming blurred like this:

Having worked in the finance industry for so many years, I was surprised to see this service. Indeed, the PIN code was considered as a critical asset that shall be kept confidential by the cardholder. This can be easily explained by the fact that banks felt covered in case of fraud. Indeed, a malevolent payment with a card-present PIN transaction could mostly be explained by the wrong usage of the cardholder. With such new features, the liability may certainly shift.

In short, the PSD2 directive resulted in:

• A new user experience for validating online payments. This is leveraging a mobile application since a mobile phone is conveniently available to many of us at any time.
• Banks took the opportunity not only to use the mobile for SCA, but to open the mobile application to a range of new services, with the aim to improve our user experience. Unfortunately, some of these services increase the attack surface.

New services, new security paradigm?

Each new service enlarges the attack surface and may open the door to a new cyber threat. Indeed, we can imagine many different ways to get compromised, such as a malevolent authentication, or illegal access to a payment validation or a PIN code. Shifting sensitive operations to mobile applications calls for hardening the system.

Note that mobile applications usually do not work in isolation, so it is important to consider the mobile application as one component of a system. A mobile system is typically composed of three main parts:

• the mobile platform. It provides many resources necessary for the mobile application, particularly security resources to manage sensitive operations such as secure storage or user authentication.
• the back-end system. The degree of required connectivity is a strong factor for its usage. In other words, how does the mobile application behave when no network is available.
• the mobile application is a central piece since it manages the users and their interactions. It makes the bridge between the user, the back-end, and the mobile platform.

Any considerations on mobile app security must encompass these different pieces. Otherwise, the risk is to wrongly calibrate the protections and therefore poorly manage the risk.

> Mobile Platforms Security

One of the biggest challenges is certainly the variety of mobile resources, including the platforms and the versions of the operating systems (Android & iOS are both concerned). As a result, it is difficult to achieve the same security level regardless of the mobile resource.

As a result, some mobile app issuers choose to constrain the service to the presence of a security resource, such as a TEE (Trusted Execution Environment) or a Secure Element. Others choose to mandate the most recent operating systems. This is always done to the detriment of the user's acceptance to a certain extent.

The fact is that mobile platforms and operating systems provide an increasing number of services to secure operations, e.g. the Android keystore or the iOS keychain. These features offer a secure way to manage cryptographic operations and prevent a secret key from being leaked.

The mobile device is typically leveraged for user authentication based on biometric systems, like face or fingerprint recognition. Although there is still a variety of platforms and technologies, the security of these operations can be deemed trustworthy.

> Back-end Security

Backend systems allow for many verifications. It is possible to monitor the activity dynamically, and particularly how the users use the mobile service and what kind of operations they do. Suspicious or inappropriate behavior can therefore be detected. Typically, Artificial Intelligence algorithms offer an ideal way to spot any unusual activity and allow risk management on the corresponding user accounts. A back-end system may decide to respond to anomalies e.g. by interruption of service.

In short, the back-end seems to be an ideal place to host security controls, since verification can take into account the context of the usage. Putting all the security verification in the back-end may be an option in some use cases. But this appears illusory for many other use cases, where sensitive operations, such as customer authentication, is managed by the mobile or when part of the service can operate offline.

> Mobile Application Security

Therefore, mobile applications often play an important role and contribute significantly to the service and system security?

At eShard, we believe that security must be implemented in depth. It means that all layers should integrate security protections. And they have to be adapted according to the perceived risks/expected threats and the trust in the technologies on which they rely.

For mobile applications, the question is about in-app protections. We are talking about: code obfuscation or Runtime Application Security Protections (aka RASP). Their purpose is to make static or dynamic reverse engineering difficult. Without them, the binary can easily be analyzed. The code can be recovered from the binary and tampered with, allowing many attack techniques, such as code injection, code understanding, or code tampering.

How do you MASTer your mobile app protections?

Some apps make the choice of not incorporating in-app protections. Does that mean they are vulnerable? The answer is “not necessarily”. It is all about risk management.

Security has to be designed at the system level. It is indeed necessary to implement verifications in the back-end together with the right usage of the mobile platform. But is it enough?

In-app protections do not prevent attacks. However, they strongly mitigate the code exposure to reverse engineering and constitute an extra security layer. It appears necessary when sensitive operations are performed by the application code. In the case of banking apps, for instance, this use of a secure keypad when managed by the application is critical. It is also important to consider any data in transit, including the personally identifiable information (PII). The bank statement as well as the data related to an account, such as the nature of a mortgage, may directly affect anyone’s privacy.

Beyond this, all interactions with the back-end system are present in the mobile application. Even if the code does not directly handle any sensitive data or operation, the understanding of these interactions may already give clues to an adversary. Indeed, a direct exposure of the code shows the API and the data exchanged with the back-end. It is always a good practice to make this access harder.

This is also true for any code leveraging mobile platform features. Cryptographic operations for instance could be accessed easily if in-app protections are not enabled. This gives the adversary the knowledge of the cryptographic protocols and how the secret keys are managed.

By design, it is highly recommended to implement secure operations by assuming a scenario in which the attacker has access to the binary code and full control to the execution environment internals, which allows him tracing, reversing, hooking, alteration, injection etc. As a consequence, a mobile application shall assume a compromised, untrustworthy platform on which it should hardly rely, and therefore shall protect itself.

Therefore, risk management may likely mitigate the risk by making the access to the code and its data difficult. Sophisticated software attacks are powerful when a code can be tampered with. Adopting a multi layers protection would embrace the concept of defense in-depth. This is also highly recommended by leading organizations, such as OWASP, with the Resiliency (R) layer.

We observed that many banking applications have adopted this good practice. One of the best-in-class countries is certainly Singapore and some other South-East Asian countries where 30% of the apps detect a rooted phone and react accordingly:

When implementing security, think feature

Functional and security are too often considered as two different worlds. In my opinion, this is a mistake. Security protections are part of the code and should be qualified as any other functional feature.

Agile development will search for a quality assessment (QA) integrated into their CI/CD (Continuous Integration/Continuous Development) process. The question should be: which QA process can be implemented for validating security protections?

Obviously, this requires being in the right conditions for the testing. Qualifying RASP protections typically requires putting the device into the condition of an attack. For instance, it is necessary to come up with different ways to root a device for qualifying the code, in order to check if the device is safe.

Different options are available to the product owners:

• Do nothing, at least for some releases of the app. This is costless and quick to implement 😁.

When the QA process is too burdensome for every release, this quickly becomes the fallback solution. In modern development, this option is barely acceptable. Indeed, any coding feature should be validated, at least to avoid regression. Otherwise, how to feel comfortable about the mobile application facing an intrusion on the field? In terms of QA, it should not be an option at all to leave detailed testing of security protections, not even parts of it.

• Code review is a bit the choice by default for developers in lack of an alternative testing environment. This is better than nothing and may help to spot security bugs. This can be done at the code level, but not at the binary level. It means that the coverage is not comprehensive, since it will not check the final code in action or it will not involve all tooling involved during the code binary creation. In terms of QA, I would say this is a last resort option when no testing platform is available.

• Penetration testing is only manageable by human inspection. The right level of assurance can be achieved assuming that the pentester keeps an approach of validation and not a hacking approach.

Indeed, pentesting usually aims at stressing an application and investigating its resistance against an attacker. We believe that validation of protection remains very succinct if such an approach is embraced because it requires manually and methodically covering the different attack techniques for each change and release. Incorporating manual penetration testing into an agile development process is necessarily tedious and barely bearable. Some will target regular verifications, but not all releases will be verified.

However, in-depth penetration tests are an indispensable element of a real-world risk assessment, as they simulate real-life attackers with all their human intelligence and creativeness to break a system and gain access to its assets. A penetration test allow us to look at the big picture which is a strength and a burden at the same time.

This means that the QA for security protections in mobile applications is open. And this, in the light of an increasing number of mobile applications requiring such protections. Particularly when a regulation such as PSD2 imposes more security features.

What is eShard vision on Mobile Application Security Testing?

This explains why at eShard, we have developed a dedicated MAST (Mobile Application Security Testing) automation platform called esChecker. The aim is to offer the opportunity to include validation of security protections into a QA process for.

esChecker SaaS can be integrated into a CI/CD and systematise non-regression testing of all mobile application (Android or iOS) releases. esChecker APIs and built-in integration facilitate the usage with CI top players such as CircleCI, Bitrise, CodeMagic, Jenkins, and many more.

The ambition is to consider security protections like any other code feature and make sure that risk managers strengthen trust in the released mobile applications. Regression testing should not be an option.

With esChecker, a risk management policy could now include regular (e.g. after an update or monthly) automated security testing of mobile app protections as a baseline. In-depth penetration testing shall be conducted complementary, e.g. annually or after a significant change of the mobile app.

Both mutually enforcing security testing approaches allow maintaining a high level of security and avoiding regression of security, so that customers can use the mobile app with trust and confidence.

A free test on your mobile app leveraging eShard MAST can be done on request.