PSD2: How to Create 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 banks, 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 banks 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.

What is a secure execution environment?

As mentioned above the final RTS states that banks 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 banks, 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 bank’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.

Luckily the definition of SEE in the RTS clearly allows SEEs that do not rely on hardware security mechanisms. Indeed, 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 security threats that we observe against mobile banking apps are the following ones:

  • Overlay attacks, whereby malware on the mobile device displays a window on top of the genuine banking app that closely resembles the banking app. In this way the malware aims to capture the banking credentials (e.g. username, PIN) of the user. Common Android malware families such as Marcher and BankBot are known to perform such attacks.
  • Code injection or hooking, whereby a 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, whereby malware on the mobile device intercepts keystrokes or gestures in order to steal sensitive data such as PINs.
  • Interception of SMS messages containing 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 (RASP). 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.

Advertenties
Geplaatst in PSD2 | Tags: , , , , | Een reactie plaatsen

PSD2: How to Conveniently Perform Dynamic Linking for Batch Transactions

Dynamic linking of financial transactions is one of the most important requirements of the Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) under the revised Payment Services Directive (PSD2). The purpose of this requirement is to avoid man-in-the-middle attacks against online banking applications, whereby an adversary alters the details of a financial transaction in order to steal money.

As already discussed in a previous blog post, the dynamic linking requirement essentially requires a payer to authenticate a financial transaction by calculating an authentication code over certain transaction data (at least the amount and some information identifying the beneficiary, like an IBAN), so that the authentication code is linked to this data. This authentication code should be calculated using a digital signature algorithm (e.g. RSA, ECDSA) or MAC algorithm (e.g. CMAC, HMAC). In addition, the confidentiality and integrity of the transaction data should be protected throughout the authentication process. Finally the user should be aware of the transaction data that he authenticates. This latter requirement is often referred to as “What You See Is What You Sign” (WYSIWYS).

Dynamic linking for batch transactions

The above requirements apply to individual transactions. The dynamic linking requirement contains an additional clause that specifically applies to batch transactions (also referred to as envelope or bulk transactions), whereby a payer initiates multiple transactions at the same time.

More specifically, article 5.3(b) of the final RTS states that, for batch transactions, the authentication code must be specific to the total amount of money of all transactions combined as well as the various beneficiaries in the batch. From a cryptographic point of view the digital signature or MAC should therefore be calculated over the total amount as well as all beneficiary IDs.

The WYSIWYS requirement of dynamic linking, as explained above, also applies to batch transactions and poses a particular challenge, especially if the number of beneficiaries is large. Indeed in such cases it quickly becomes impractical to show all beneficiaries to the user for validation. In corporate environments, for instance, a batch may consists of hundreds or thousands of transactions, making it infeasible for the user to validate all beneficiaries. This is especially the case when using devices with smaller screens such as smart phones.

In such scenarios a combination of following approaches can be used to authenticate the entire batch:

  • Beneficiaries that have previously been added to a whitelist of trusted beneficiaries are not shown to the user. This is permitted under the exemption in Article 13 of the final RTS, which exempts trusted beneficiaries from the need to perform strong customer authentication.
  • Relying on the exemption for recurring transactions in Article 14 of the final RTS, beneficiaries from recurring transactions are also not shown to the user.
  • Only certain beneficiaries are shown to the user. For instance, only beneficiaries corresponding to transactions with the largest risk are shown to the user, or only randomly selected beneficiaries are shown.

The above approaches allow meeting the dynamic linking requirements for batch transactions and reduce the risk of fraudulent payments, while being practical for the payer or person in charge of approving the batch of transactions.

Geplaatst in PSD2 | Tags: , , | Een reactie plaatsen

PSD2: How to Perform Dynamic Linking in a Compliant, yet Convenient Way

One of the most discussed requirements of the final Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) under PSD2 is the requirement to perform so-called “dynamic linking” to authenticate a financial transaction.

The dynamic linking requirement has three parts. First, it requires a payer to authenticate a financial transaction by calculating an authentication code over certain transaction data (at least the amount and some information identifying the beneficiary), so that the authentication code is linked to this data. Second, the confidentiality and integrity of the transaction data should be protected throughout the authentication process. Third, the online banking should be aware of the transaction data that they authenticate. This latter requirement is often referred to as “What You See Is What You Sign” (WYSIWYS). This implies that merely showing a hash of the transaction data or a session identifier does not suffice.

The European legislators that drafted PSD2 introduced the dynamic linking requirement to counter man-in-the-middle attacks, whereby an adversary alters the details of a transaction after the payer authenticated the transaction. Such an attack could change a genuine transfer of 100 euro to a friend into a rogue transfer of 1000 euro to an imposter, without the genuine payer noticing. The WYSIWYS requirement intends to avoid social engineering attacks, whereby a payer is convinced to authenticate data they do not understand, and that later turns out to represent a fraudulent transaction. As such, PSD2 goes a step further than the EBA’s Final Guidelines on the Security of Internet Payments, which currently apply in most EU member states and do not require dynamic linking.

For banks, compliance with these PSD2 requirements raises several questions. How can a bank implement dynamic linking into its online or mobile banking application in such a way that it is convenient for the customer? Can SMS be used to implement dynamic linking? And what about batch transactions?

Let’s explore these topics further below.

Convenient Dynamic Linking

Consider the scenario where a user initiates a financial transaction via an online banking application running within the browser of their PC, using a dedicated hardware token or mobile banking app to authenticate the transaction.

One convenient way to implement dynamic linking relies on the usage of colored QR codes or Cronto codes. When the user wants to initiate a transaction, they:

  1. Enter the transaction data into the online banking application in the browser. Based on this transaction data, the banking server generates a color code, representing the encrypted transaction data, and displays this in the browser.
  2. Scan the color code using the camera of their hardware token or mobile device. The device decodes the color code, decrypts the transaction data, and shows the cleartext transaction data to the customer on-screen.
  3. Authenticate to their device (e.g. key in the device’s PIN), and it calculates the authentication code over the transaction data using a cryptographic key stored on the device.

This approach meets all dynamic linking requirements described above, and additionally does not require the user to manually enter transaction data onto the device, increasing inconvenience.

An alternative approach, only for mobile, consists of transferring the transaction data from the banking server to the mobile banking app using an encrypted push notification message. Here’s how it works:

  1. The user receives a push notification message on their phone.
  2. When they accept it, the mobile banking app opens and shows the transaction data to the user.
  3. The user authenticates using a fingerprint face scan, for example.
  4. The device calculates the authentication code over the transaction data.
  5. The mobile banking app sends the authentication code back to the customer via the Internet.

This approach also complies with the dynamic linking requirements, and does not require the user to manually enter any data onto the mobile device.

Batch Transactions

The dynamic linking requirement also applies to batch transactions or bulk payments, whereby multiple transactions to different beneficiaries are combined. More specifically, the final RTS states that, for batch transactions, the authentication code must be specific to the total amount of money of all transactions combined, as well as the various beneficiaries.

If the number of beneficiaries is large, it is impractical to show all of them to the user for validation. The following approaches can then be used to balance security and user convenience:

  1. Show the user the beneficiaries corresponding to transactions with the largest risk.
  2. Show the user randomly selected beneficiaries.
  3. Do not show the user any whitelisted beneficiaries.

In any case, it is good practice to include a hash of all transactions into the calculation of the authentication code in order to protect the integrity of all transactions.

Dynamic Linking using SMS?

There is also the question of whether dynamic linking could be implemented using SMS. In this case, the user would receive an SMS message containing the transaction data as well as the authentication code calculated over the transaction data.

Given the requirement to protect the confidentiality and integrity of the transaction data, this would imply the transaction data inside an SMS message needs to be encrypted. It is not clear how the message could then be decrypted on the mobile device without using a dedicated app. The need for a mobile app to process SMS messages undermines one of the primary benefits of SMS.

Summarizing, banks should approach PSD2 not merely from a compliance point of view, but consider how they can optimize the user experience by means of convenient strong authentication and dynamic linking procedures.

Geplaatst in PSD2 | Tags: , , , , | 1 reactie

Cryptocurrencies’ long road to mass adoption

Many of my latest blog posts discussed Strong Customer Authentication (SCA) under the forthcoming PSD2 regulation.

On a different topic, the online magazine IT Pro Portal recently published an article with some of my thoughts on the road to mass adoption of virtual currencies, such as Bitcoin. You can find the article here.

Geplaatst in Cryptocurrency | Tags: , | Een reactie plaatsen

PSD2: European Commission Provides Long-Awaited Update on RTS and Screen Scraping

Many European banks, banking associations and fintech companies are currently waiting for the Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) to be adopted by the European Commission and Parliament. These RTS define the technical requirements for the communication interfaces (APIs) that banks have to provide to Third Party Providers (TPPs) in the future, and specify how banks have to authenticate users when they access a payment account or initiate a payment.

The most recent evolution regarding the RTS dates back to June. At that time, the European Banking Authority (EBA) published its opinion about the European Commission’s proposed amendments to the EBA’s so-called final draft RTS. The EBA’s opinion showed diverging views between the EBA and Commission about the need for banks to provide a “fall-back” communication interface based on screen scraping in case a bank’s API-based interface would not be available or not functioning adequately. The EBA and financial institutions were not in favor of the need for such a fall-back interface. The Commission and TPPs, on the other hand, requested this to be incorporated into the RTS.

At The Berlin Group’s NextGenPSD2 conference, which took place in Berlin on 25 October, a representative of the European Commission provided a long-awaited update. Mr. Ralf Jacob discussed the timelines for the RTS and explained the approach regarding the communication interface.

Discussing The Berlin Group’s PSD2 API specifications in Deutsche Bank’s Atrium in Berlin

Regarding timelines, Mr. Jacob explained that the text of the RTS is ready, and that it is currently being translated. The RTS is expected to be published around 25 November. In order to become official the RTS needs to be published in the Official Journal of the European Union, which should happen in late February 2018. The RTS will go into effect 18 months later, in August 2019.

The Commission proposes to solve the catch-22 situation regarding the communication interface by not requiring banks to provide a fall-back interface based on screen scraping, if their API-based communication interface functions adequately. At first sight, the Commission seems to follow the approach proposed by the EBA and banks. However, the devil is in the details: the criteria to determine whether a certain API-based interface functions adequately will be defined by a new industry body consisting of representatives from both banks and TPPs. In this way, the Commission shifts the responsibility for defining criteria to the market participants, and ensures that TPPs will have a say on the quality of API-based interfaces which are to be provided by banks.All in all, the approach proposed by the Commission largely favors API-based interfaces, and tries to do away with the practice of screen scraping, which is long overdue.

The communication of the Commission at the NextGenPSD2 conference brings an end to several months of regulatory radio silence, and brings a new momentum to the PSD2 implementation process. It is now up to standards organizations, such as The Berlin Group, Open Banking UK and STET to finalise its API standards, and to banks to make decisions regarding their procedures for Strong Customer Authentication.

Geplaatst in PSD2 | Tags: , , , , | Een reactie plaatsen

PSD2: European Commission proposes amendments to final draft RTS on Strong Customer Authentication

On 23 February the European Banking Authority (EBA) proposed its final draft Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) under PSD2 to the European Commission (EC). On 24 May the Commission sent a letter to the EBA, stating its intent to amend the final draft RTS. The EBA published this letter as well as the amended RTS on its website.

The Commission proposes four amendments to the RTS. None of these amendments propose any significant changes to the core requirements of Strong Customer Authentication and Transaction Risk Analysis (TRA) as laid out in the EBA’s final draft RTS. In other words, the key requirements related to two-factor authentication, dynamic linking, replication protection for the possession element (e.g. mobile app), and application protection to ensure independence of the authentication elements, all remain untouched.

The amendments envisaged by the Commission relate to following four topics:

1. Independent security review of the SCA exemption based on TRA. Payment Service Providers (PSPs) will be required to have independent security auditors review their transaction risk methodology, their risk model and the reported payment fraud rates. The purpose of this amendment is to ensure objectivity in the application of the exemption from SCA based on TRA. It can be expected that PSPs will (partly) shift the responsibility to have their TRA processes reviewed to the vendors of TRA products.

2. New exemption from SCA for certain corporate payment processes. PSPs do not have to apply SCA to corporate payments if they are performed using certain processes or protocols that achieve a high level of security.

3. PSPs should report payment fraud directly to EBA. In addition to aggregated fraud data, PSPs should also provide data and reports about individual payment fraud cases to the EBA.

4. Contingency measures in case of unavailability or inadequate performance of the dedicated communication interface of banks. PSD2 mandates Account Servicing Payment Service Providers (better known as “banks”) to offer a dedicated communication interface to Third Party Providers (TPPs). For instance, banks must expose a dedicated interface (e.g. API) allowing TPPs to check the account balance of their users. The amendment from the Commission stipulates that, if the dedicated interface offered by a bank would not be available or would not be functioning adequately, then the bank must allow TPPs to use the regular, user-facing communication interface of the bank. In other words, TPPs are allowed to use so-called “direct access” or “screen scraping” to access a bank’s systems when they are unavailable or not performing adequately. This amendment, which to a certain extent addresses considerations from about 70 TPPs in their recent Manifesto for the impact of PSD2 on the future of European FinTech, has already met significant concerns from the European Banking Federation.

As a next step, the EBA will review the amendments proposed by the Commission. The EBA has until 5 July to give its opinion on the amended RTS. After 5 July, the Commission can adopt the final RTS, taking into account or disregarding the EBA’s opinion. Once the Commission has adopted the final RTS, it will be subject to scrutiny by the European Parliament and the Council of the European Union.

Geplaatst in Uncategorized | Een reactie plaatsen

PSD2: Which Strong Authentication and Risk Analysis Solutions comply with the EBA’s Final Draft RTS?

Introduction

On Thursday February 23rd, the European Banking Authority (EBA) published its long-awaited final draft Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) under the revised Payment Services Directive (PSD2).

In this blog post I analyze which strong authentication and transaction risk analysis solutions can comply with the requirements about SCA in the final draft RTS. I first provide some background about the history of the final draft RTS, and then discuss common authentication solutions that are used by many online banking and mobile banking applications today. Subsequently I present and discuss the most important requirements from the final draft RTS, and point out changes to the previous version of the draft RTS. Finally I explain which authentication solutions are most likely to meet the requirements of the final draft RTS.

 Background

In recent years, the security of electronic payments has more and more become the subject of supranational guidelines and regulations in Europe. The initiatives for these guidelines and regulations originated from the European financial regulators as well as the European Commission.

In 2013, the SecuRe Pay forum of the European Central Bank (ECB) published its Recommendations for the security of Internet payments, as well as its (draft) Recommendations for the security of mobile payments. The former set of recommendations was republished by the European Banking Authority as the Final guidelines on the security of Internet payments. These EBA guidelines are in effect since August 1st 2015 in most member states of the European Union. The latter set of recommendations was not further developed by the EBA.

In November 2015 the Council of the European Union adopted the Revised Payment Services Directive, also known as PSD2. One of the key elements of PSD2 consists of the need to perform strong authentication of users of electronic payment services. Article 98 of PSD2 tasks the European Banking Authority with the development of more detailed requirements regarding SCA. In line with this mandate, the EBA issued its proposal for the draft Regulatory Technical Standards on SCA on August 12th 2016. This proposal was heavily influenced by the above-mentioned EBA guidelines on the security of Internet payments. Following the feedback from a large number of respondents from the payments industry, the EBA published its final draft RTS on February 23rd 2017, about 1.5 months after the planned deadline. The final draft RTS have been submitted to the Commission for adoption, and they are now subject to scrutiny by the European Parliament and the Council, before being published in the Official Journal of the European Union. The RTS will be applicable 18 months after its entry into force, which suggests an application date of the RTS in November 2018 at the earliest.

Classification of common strong authentication solutions

Many online and mobile banking applications already use (strong) authentication solutions today. We divide these solutions into following categories.

The different categories of (strong) authentication solutions

Two-device-authentication (2da)

In this case the user has two independent devices: one device to access the banking website or app, and another device to authenticate himself or a payment. The first device, which we refer to as the banking device, is typically a desktop PC, laptop, or a mobile device (e.g. phone, tablet) that runs a mobile banking app. The second device, which we call the authentication device, is usually a hardware authentication token, a combination of a smart card and smart card reader, or a dedicated app on a mobile device. The authentication device generates one-time passwords (OTPs) over transaction data.

In order to perform a payment, the user first logs on to the banking app and enters the details of the payment (e.g. beneficiary account number, amount of money). The transaction data is then transferred to the authentication device. This can happen in many ways, depending on the capabilities of the device: the user might scan a QR-code representing the transaction using the hardware token, card reader or mobile device. Alternatively the user might manually enter the transaction details into the hardware token, card reader or mobile device. Finally both devices might be connected to each other via USB or Bluetooth. The user verifies and confirms the transaction data once they are present on the authentication device. The authentication device then generates a one-time password over the transaction data, which is transferred back to the banking device. This latter transfer can again be performed in different ways, depending on the capabilities of the device. It is common that the user manually enters the OTP into the banking device.

Two-app-authentication (2aa)

In contrast to 2da, this approach does not rely on two different devices, but on two different apps running on the same mobile device. The apps interact via so-called app-to-app communication. We refer to these apps as the banking app and authentication app respectively.

When a user wants to make a payment, he opens the banking app and enters the transaction data. When the user has submitted the transaction, the banking app opens the authentication app. After verification and confirmation of the transaction data by the user, the authentication app generates an OTP linked to the transaction data and sends it back to the banking app, which submits it to the banking server for verification. Other flows than the one just described exist as well, but the precise flow is not relevant for the remainder of this text.

One-app-authentication (1aa)

In this case the user not only uses a single device, but also a single app to initiate and authenticate transactions. The user does not employ a separate authentication device or app.

Out-of-band authentication (oob)

The above categories can be combined with an out-of-band approach, whereby the OTP is not generated by the token or app, but rather by the bank and delivered via a separate, out-of-band channel (e.g. SMS) to the user’s device.

In case of 2da, the user’s authentication device could then be a phone where he receives an SMS message. In case of 2aa or 1aa, the apps could reside on a mobile phone.

Requirements for strong customer authentication

Basic requirements

Article 97 of PSD2 requires Payment Service Providers to authenticate a user when he accesses an online payment account, when he initiates an electronic payment transaction, or when he carries out any action through a remote channel that may imply a risk of payment fraud (or other abuses).

A basic definition of “strong customer authentication” is present in article 4(30) of PSD2. It states that authentication has to be based on the use of two or more possible authentication elements, categorized as knowledge (i.e. something only the users knows, such as a password), possession (i.e. something only the user has, such as a token) or inherence (i.e. something only the user is, such as a fingerprint or face scan). Furthermore the authentication factors must be independent from each other. The SCA procedure constructed from these authentication elements must generate a one-time authentication code.

The categories of authentication solutions discussed above can meet these basic requirements:

  • 2da. The possession element is the authentication device. The knowledge or inherence element is entered onto the authentication device or banking device.
  • 2aa and 1aa. The possession element is the mobile device, which stores cryptographic keys to generate authentication codes. The knowledge or inherence element is entered onto the mobile device.
  • oob. The possession element is the mobile phone where the user receives authentication codes. The knowledge or inherence element is entered onto the banking device (for 2da) or mobile device (for 2aa and 1aa).

Dynamic linking

In case of a payment transaction, the authentication code must be dynamically linked to the amount and the payee, meaning that this code will change if either the amount or the payee is changed during the transaction.

The requirements regarding dynamic linking have significantly changed compared to the previous version of the draft RTS. Previously the draft RTS specified that the apps or devices that are used to initiate and authenticate a payment should be segregated. This requirement ruled out the “1aa” approach above.  However the EBA removed this requirement in the final draft RTS because it was “confusing” and also stated that “the independence of the elements constituting SCA does not require different devices and can be hosted on the same device”. In our opinion this means that the “1aa” and “2aa” approach can be used for dynamic linking under the final draft RTS.

Requirement 2 of Article 2 is a very broad requirement and states that payment transaction data needs to be protected throughout all phases of authentication:

  1. […] payment service providers shall adopt security measures which ensure the confidentiality, authenticity and integrity of each of the following:
    1. the amount of the transaction and the payee through all phases of authentication.
    2. the information displayed to the payer through all phases of authentication including generation, transmission and use of the authentication code.

Requirement 2b likely aims to prevent social engineering attacks whereby a user unwittingly confirms a payment transaction after the amount and payee have been altered by a fraudster. Indeed, there is a plethora of malicious software on multi-purpose devices (such as desktop PCs and mobile devices) that is capable of altering the payment transaction data that is displayed to the payer. On mobile devices malicious software often uses so-called “overlay” windows to achieve this goal.

Specific security controls are therefore required in order to comply with Article 2(2):

  • In the 2da category, a hardware token with the capability to scan a visual code (e.g. QR code or Cronto code) that contains the encrypted payment information, and to subsequently show the payment information to the payer, most likely meets the requirements. This approach is usually referred to as “What You See Is What You Sign” (WYSIWYS).
  • In the 2da category, a solution consisting of an authentication app running on a mobile device that receives the payment information via a secure, encrypted channel and that displays payment information in the app to the payee most likely meets the requirements as well. However in this case the mobile app needs to be additionally protected in order to meet the independence requirements, as discussed below.
  • A third option consists of following the “2aa” or “1aa” approach. In this case mobile apps need to exchange payment information via a secure channel, and also clearly show the payment information to the user. Additionally the authentication app (in case of 2aa) or the banking/auth app (in case of 1aa) should be equipped with security software that can detect malicious software and prevent it from interfering with a payment transaction. In general it is very hard for security software to provide strong guarantees that it can stop malicious software.
  • In case of “oob”, Requirement 2 implies that the SMS message should contain the payment information. The requirement to protect the confidentiality of the payment information could be interpreted as a need to encrypt the payment information in the SMS message. However clarification about this is required from the EBA and national competent authorities.

Protecting the possession element against cloning

Article 7 defines requirements related to the possession element, which are particularly relevant for mobile devices. The article says that “the use by the payer of elements categorized as possession shall be subject to measures designed to prevent replication of the elements”.

Mobile apps are very easy to clone if they do not contain countermeasures. Hence this requirement mandates the use of dedicated cloning countermeasures in apps. A basic countermeasure consists of including device-specific data, such as the device’s IMEI or ID, into the OTP generation. A stronger countermeasure encrypts data used by the app using a cryptographic key stored inside the device’s Secure Element. Another option consists of using a password or PIN to encrypt the data that is used by the app to generate an OTP.

Independence of authentication elements

Article 9 defines a number of requirements related to the independence of the various authentication elements, which is again very relevant in the context of mobile devices. We consider following requirements from the final draft RTS:

  1. Where any of the elements of strong customer authentication or the authentication code is used through a multi-purpose device including mobiles phones and tablets, payment service providers shall adopt security measures to mitigate the risk resulting from the multi-purpose device being compromised.
  2. For the purposes of paragraph 2, the mitigating measures shall include, but not be limited to:
    1. the use of separated secure execution environments through the software installed inside the multi-purpose device;
    2. mechanisms to ensure that the software or device has not been altered by the payer or by a third party or mechanisms to mitigate the consequences of such alteration where this has taken place.

Requirement 3a states that software-based secure execution environments can be used. This is a clear change from the previous draft RTS, where the requirement used the wording “trusted execution environments”, and which could have suggested a need for execution environments based on hardware. Hence, common mobile operating systems (e.g. Android, iOS) most likely meet the requirement of separated trusted execution environments via their sandboxing techniques. However these sandboxing mechanisms function correctly only as long as the device is not jailbroken or rooted. The sandboxing techniques of these mobile operating systems can be further augmented using so-called “runtime application self-protection” (RASP) technology. This type of technology allows detecting whether an app runs inside an emulator or virtual machine instead of on a regular mobile device.

Requirement 3b mandates Payment Service Providers to use security controls to detect, prevent and respond to the alteration of mobile apps and devices. Again, RASP technology for mobile apps provides such security controls. More specifically, RASP technology usually provides security services to protect the confidentiality and integrity of mobile apps, to detect whether a device is rooted, to detect, whether an app runs inside a debugger or emulator, etc.

  • Transaction risk analysis

The draft RTS mandates the usage of transaction risk analysis (TRA) to prevent, detect and block fraudulent payments. Article 2(3) stipulates that transaction risk assessment mechanisms should be based on elements such as the amount of the payment, known fraud scenarios, signs of malware infection in the payment session, etc.

Article 16 represents a major change to the final draft RTS. In the previous version of the draft RTS, transaction risk analysis could not be used to exempt a payment from SCA. The final draft RTS allow payments, which are rated as low-risk by the payment service provider, to be exempted from SCA.

This exemption is however subject to a number of conditions, such as:

  • Transaction risk assessment should take into account additional elements such as the payment patterns of the payer, the location of the payer and payee at the time of the payment transaction, characteristics of the payer’s device or software application, etc.
  • The fraud rate of the payer’s payment service provider determines the maximum payment amount that can be exempted from SCA. The lower the fraud rate of the payer’s payment service provider, the higher the payment amount that can be exempted from SCA. Article 16(2) defines certain thresholds for fraud rates that determine the payment amount that can be exempted. In any case the maximum payment amount that can be exempted from SCA is € 500; all payments above € 500 require SCA.

Summary

Chapter 3 of the final draft RTS defines a number of other exemptions from SCA, besides TRA. Table 1 and Table 2 summarize when SCA must be used and when exemptions are allowed, and this for access to payment accounts and payments respectively. In these tables, “1FA” refers to authentication using a single factor, such as a password.

Summary of requirements regarding SCA for access to payment accounts

Summary of requirements regarding SCA for payments

Payments below € 30 can only be exempted from SCA if the cumulative amount, or the number, of previous remote electronic payment transactions initiated by the payer since the last application of strong customer authentication does not, respectively, exceed EUR 100 or 5 consecutive individual remote electronic payment transactions.

 Liability for payment fraud

 Under PSD2 the SCA procedure is the responsibility of the Account Servicing PSP (ASPSP). Payment Initiation Service Providers (PISPs) must use the credentials issued by the ASPSP, unless there is a prior contractual agreement in place between the PISP and the ASPSP that the former’s credentials may be used.

Article 73(1) of PSD2 states that the payer’s payment service provider must refund the payer if any unauthorised payments were performed on behalf of the payer, unless the payment service provider suspects fraud:

[…] in the case of an unauthorised payment transaction, the payer’s payment service provider refunds the payer the amount of the unauthorised payment transaction immediately, and in any event no later than by the end of the following business day, after noting or being notified of the transaction, except where the payer’s payment service provider has reasonable grounds for suspecting fraud and communicates those grounds to the relevant national authority in writing.

If payments are initiated by a PISP, article 73(2) clarifies that the ASPSP can transfer liability to the PISP:

Where the payment transaction is initiated through a payment initiation service provider, the account servicing payment service provider shall refund immediately, and in any event no later than by the end of the following business day the amount of the unauthorised payment transaction and, where applicable, restore the debited payment account to the state in which it would have been had the unauthorised payment transaction not taken place. If the payment initiation service provider is liable for the unauthorised payment transaction, it shall immediately compensate the account servicing payment service provider at its request […].

The payer always bears all the losses related to unauthorised payments if he acted fraudulently. He might also bear some losses if the unauthorised payment resulted from the use of a loss or stolen payment instrument.

These articles from PSD2 imply that the payer’s payment service provider is liable for unauthorised payments even if he provides strong customer authentication in line with the RTS, unless the payer has acted fraudulently. This incentivizes payment service providers to not simply choose the SCA procedure that meets the requirements of the RTS, but to select an SCA procedure based on the payment risk.

 Compliance of common authentication solutions

We now evaluate some of the most common authentication solutions against the above requirements from the final draft RTS. We differentiate between two scenarios: access to payment accounts, and payment authentication.

Access to payment accounts

Table 3 lists the authentication solutions, grouped according to the various categories (2da, 2aa, 1aa and oob), and indicates which solutions comply with the requirements for access to payment accounts. For authentication solutions in the “2da” category, only the authentication device is described. The banking device can be a laptop, desktop, mobile device, etc. as long as it is separate from the authentication device.

The solutions in the category “2da” generally comply with all requirements. This includes solutions based on hardware tokens, smart cards and smart card readers, and mobile OTP generators. Solutions based on the usage of a hardware token or smart card meet the anti-cloning and independence requirements since hardware-based protection is deemed to be sufficient. Solutions based on mobile OTP generators meet the requirements if the mobile app is protected using cloning countermeasures and RASP technology, such as root/jailbreak detection mechanisms.

The solutions in the “2aa” and “1aa” categories also comply with all requirements, but again under the condition that the mobile apps are protected using cloning countermeasures and RASP technology.

Solutions in the “oob” category also generally comply.

Payment authentication

Table 4 lists the authentication solutions and indicates which solutions comply with the requirements for access to payment accounts.

The conclusions for payment authentication are largely the same as for access to payment accounts. It is noteworthy that solutions based on one-button hardware tokens, which do not support dynamic linking of transaction data, can only be used if the payment is exempted from SCA (e.g. because it is a low-risk payment).

Solutions in the “oob” category need to make sure that the SMS message contains payment information. In order to comply with the confidentiality requirement regarding Dynamic Linking, payment service providers should consider encrypting the payment information in the SMS message.

It is expected that payment service providers will select strong authentication solutions from the list of compliant solutions in line with the risk of the payments that they process. In other words payment service providers that process high-value transactions are likely to opt for more secure solutions. This is the case because payment service providers are liable for unauthorised payments even if they provide strong customer authentication, unless the payer acted fraudulently.

Compliance of common authentication solutions with SCA requirements for access to payment accounts

Compliance of common authentication solutions with SCA requirements for payments

 

Geplaatst in Uncategorized | Tags: , , , , , , , | 2 reacties