Skip to main content

With PSD2 on the horizon, can open banking really be secured?

(Image credit: Image source: Shutterstock/MaximP)

With the revised Payment Service Directive, better known as PSD2, set to become law on 18th January 2018, next year may see one of the biggest shake ups in the financial sector in recent history. The scope of the directive’s mandate around data accessibility are aimed at reinventing banking and payments as we know it, ushering in a new era of “open banking” where customers have unprecedented freedom in how they access financial services.

Few industries guard their customers as closely as the banking world, so PSD2’s vision of customers being able to access account services from different providers – and even from non-financial providers such as social media – was always going to be a source of contention. However, aside from the expected (and perhaps intentional) period of uncertainty as the major players seek to preserve their market shares and identities in the open banking era, the directive has also been a cause for concern for more practical reasons.

As with many regulations in the financial world and beyond, much of PSD2 focuses on what must be done, but does not set out the details of how its mandate will be achieved – particularly in terms of technical requirements.

Secure connections

One of the most pressing concerns is security, and particularly the way banking services will be opening themselves up to non-financial third parties. Financial institutions have always been subject to some of the strictest regulations when it comes to protecting their customer’s data, but the third party services, such as social media platforms, are far less scrutinised and controlled. The mismatch between the way the banks and third parties have been required to handle security means it will certainly take some time for everyone to be working to the same standard – and we are very likely to see some major security incidents before this happens.

Further to this general inequality, there are no set rules on how financial service providers must go about connecting with and authenticating third parties, or ensuring that the process is kept secure and is not open to exploitation by cyber criminals.

In response to this uncertainty, the European Banking Authority (EBA) published a set of guidelines in July on how banks should handle third party access to customer data. The guidelines include requiring third parties to provide an explanation of how breaches will be detected and addressed, as well as clarifying their procedure for monitoring, handling and following up on security incidents or security-related complaints from customers. While not actually binding in law, these guidelines should still go some way to helping the banks unite in the way they handle PSD2.

However, there is still a distinct lack of guidance or standardisation on the technical side of how the interconnectivity of PSD2 should be achieved and secured.

The role of the API

One thing that is certain is that the process will rely heavily on Application Programming Interfaces, or APIs, essentially a set of instructions or routines to complete a specific task, or interact with another system. APIs can be used perform tasks such as retrieving data or initiating other processes, and multiple APIs can be combined to complete complex functions, making them extremely versatile. This capability has had a transformative effect on software development, enabling organisations to plug APIs into their software rather than writing every aspect from scratch.

APIs have also become the go-to way for applications from different developers to connect and work together, and developers routinely offer software development kits (SDKs) that grant access to data and functions. In most cases, each developer will provide their own unique APIs for different functionality - Twitter for example provides an SDK called TweetComposer, which allows other applications to access a Twitter account and post content.

While this varied approach has been extremely successful in most fields, it stands at odds with the heavily regulated and standardised way that banks and other financial services are expected to operate. While there are some de facto API standards, such as OAuth and REST, that are widely used in software development, there is no de jure standard set out for use with banking applications. This means that each individual bank will be able to pick their own approach to deciding how to deal with connectivity and authentication, with each creating their own SDKs in isolation from each other.

As a result, any third party platform hoping to offer financial services will potentially have to deal with dozens of completely different methods, creating a new adapter for each one. As well as creating a major headache for these third party developers, the confusion would also be passed on to end-users, as they may find that their preferred platform only supports some banks.

The potential weakness of APIs

Aside from the lack of unity on how SDKs should be created, issued and managed, the use of APIs in general also come with their own unique risks. The principal weakness is the simple authentication that is widely used by most API Management Solutions to confirm that the client app on a device is genuine and has been authorised to utilise server assets. This is usually done with a simple challenge-response exchange, as the client app tries to connect to the API server. A cryptographic operation is generally used for this, which means that the mobile client will most often contain a key for an asymmetric cipher such as RSA or ECC.

If a cyber criminal breaks through an app’s security and decompiles its code, they can potentially root out the encryption keys. Once this has been achieved, attackers can use them to trick the system into recognising them as a legitimate client and enabling them to access anything the API was authorised to connect with. There have been multiple examples of potential weakness being exploited.

In March for example, attackers were able to use a third party app called Twitter Counter to access thousands of accounts around the world, including high profile accounts such as UNICEF and BBC North America. The attackers used the hijacked accounts to tweet anti-Dutch derogatory messages as part of a dispute between the Netherlands and Turkey, including Nazi imagery. Luckily for those involved, the damage was limited to some embarrassment and confusion. The same attack method could be used to gain authorisation to an app that has access to financial details and the ability to make payments, allowing a cyber criminal to quickly clean out the victim’s bank account. If the application has permission to access backend systems, an attacker could even potentially use the API to attack the bank’s systems directly.

The most effective way of preventing an attacker from exploiting an API in this way is to ensure they cannot access the cryptographic keys it uses to authenticate itself. Code obfuscation for example renders code into an unusable scramble, while hiding text encodings and encryption will also make it much more difficult for an attacker to exploit the code.

Attackers will usually download an application into a sandbox environment where it can be repeatedly probed for weaknesses – a method which mobile apps are particularly susceptible to as soon as they’ve been made available for public download. Developers can also deploy debugger detection measures which will detect if the application has been executed in a debugging environment rather than on a real device. Checksums can also be hidden within the code, triggering an alert if the code is altered during runtime.

A united front

Banks and other financial institutions have a well-founded reputation as leaders in security, and the majority already deploy these techniques and others to protect their applications and keep their users safe from attack. However, the vast majority of applications are much less stringent with their security, which means the banks will have to be extremely cautious if they are to trust any third party with access to their customer’s data, as well as core services like making payments.

Adding to this, PSD2 makes it clear is that banks are ultimately responsible for the ownership, safety and confidentiality of their customers’ account data. Any security incident suffered by an authorised third party will have major financial and regulatory repercussions for the bank – particularly with even more stringent data protection laws such as the EU General Data Protection Regulation also on the horizon.

While we can expect the banks to take this potential new threat very seriously, the current lack of specific legal guidelines about how applications should be secured as part of PSD2 means that it will again be a case of each one working in isolation. Given that interconnectivity and freedom is the main aim of PSD2, we would instead recommend the industry to work together on creating a mutual standard for authenticating third parties and creating and securing APIs.

Creating new standards is always a very time consuming process - particularly when there are so many moving parts and different technical factors to consider - which means we can’t expect to see anything emerge in time for PSD2 to come into law in January 2018. However, we urge the industry to work together on creating a united approach over the next year as they work on their own solutions. While it is certain that the era of open banking will be a major change for the industry, a standardised approach will help it to be a positive one rather than a potential disaster.

Andrew Whaley, VP Engineering, Arxan Technologies
Image source: Shutterstock/MaximP

Andrew Whaley is VP Engineering at Arxan Technologies - the trusted provider of application protection and management solutions.