PSD2: Which Strong Authentication Solutions Comply with EBA’s draft RTS?

In this blog post I take a detailed look at the proposal for draft Regulatory Technical Standards (RTS) for strong customer authentication (SCA), which has been published in August 2016 by the European Banking Authority (EBA). I’ll first give some background information about the draft RTS, and then discuss common authentication solutions that are used by many online banking and mobile banking applications today. Subsequently I’ll discuss the actual requirements from the draft RTS, and evaluate to which extend current authentication solutions meet the requirements in the draft RTS. I also discuss which types of payments are exempted from the SCA requirements.

Background

The security of electronic payments is more and more subject to national and supranational regulations. An important regulatory initiative in this context is the European Union’s revised Payment Service 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 97 of PSD2 requires Payment Service Providers (PSPs) to authenticate users when they access an online payment account, or when they initiate an electronic payment transaction. Additionally PSD2 requires elements of a payment, such as the amount of money and identity of the beneficiary, to be included in the authentication process.

A basic definition of “strong customer authentication” (SCA) is present in article 4(30) of PSD2 itself. It states that authentication has to be based on the use of two or more possible authentication factors, 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.

Article 98 of PSD2 tasks the European Banking Authority (EBA) 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 (RTS) on SCA on August 12th 2016. This followed a Discussion Paper on the topic issued by the EBA in December 2015 which received 118 submissions in response (the second largest number of responses the EBA ever received). The EBA is expected to deliver the final draft RTS to the European Commission by January 13th 2017. Given the limited amount of time left, it is expected that the current draft RTS is close to the final version. The European Commission then has 3 months to review and approve them. If approved, the RTS become effective 18 months after the European Commission’s approval. This means the RTS will be effective in October 2018 at the earliest.

463b6396

The current headquarter of the European Banking Authority at Canary Wharf in London. (c) EBA

 

The draft RTS are somewhat related to the EBA Guidelines on the Security of Internet Payments, which I have discussed in previous blogposts here and here. An important difference is that the EBA Guidelines do not enforce the inclusion of payment data, such as the payment’s amount and beneficiary, into the calculation of the authentication code. The draft RTS, on the other hand, mandate this. The EBA Guidelines are in effect since 1 August 2015 in most member states of the European Union.

Classification of common strong authentication solutions

Many online and mobile banking applications already use (strong) authentication solutions today. I’d like to divide these solutions into following three categories, based on the categorization in [1].

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 I 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 I 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. I’ll 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.

Requirements from draft RTS for strong customer authentication

As mentioned above, PSD2 provides a basic definition for SCA. SCA must be based on the use of two or more elements that have to be independent from each other, namely knowledge (something only the user knows), possession (something only the user possesses), and inherence (something the user is). The SCA mechanism must generate a one-time password that is valid only once and only for a limited amount of time. I’ll now consider the most relevant requirements from the draft RTS and interpret their meaning.

  • Channel segregation

Article 2(2b) specifies that the apps or devices that are used to initiate and authenticate a payment should be segregated. The article states that “the channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.

This requirement raises the question whether app-to-app communication, as used in the “2aa” approach above, is actually allowed. Both apps cannot be denoted independent, because they communicate with each other. Nevertheless it is probably acceptable to say that they are segregated, because mobile operating systems (e.g. Android, iOS) apply sandboxing techniques to ensure that apps run in separated execution environments. However this is only true as long as the device is not jailbroken or rooted. If the device is jailbroken or rooted, it is not possible anymore to claim that the apps are segregated. Hence this requirement can be interpreted as mandating the usage of security controls that can detect whether a device is jailbroken or rooted, and that do not allow the apps to be used if the device appears to be jailbroken or rooted.

  • Protecting the possession element against cloning

Article 4 defines requirements related to the possession element, which are particularly relevant for mobile devices. The article says that “the use of elements categorized as possession shall be subject to measures designed to prevent replication of the elements, including in particular anti-cloning features to offer resistance against the risks of forging and cloning 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. Stronger countermeasures encrypt data used by the app using a cryptographic key stored inside the device’s Secure Element. However the best protection consists of using a password or PIN to encrypt the data that is used by the app to generate an OTP. In other words the best approach to protect the possession element consists of tightly linking it to the knowledge element.

  • Independence of authentication elements

Article 6 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. Consider following requirements from the draft RTS:

  1. Where any of the elements of strong customer authentication or the authentication code is used through a multi-purpose device including, but not limited to, mobiles phones and tablets, the authentication procedure shall provide measures to mitigate the risk of 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 implementation of separated trusted execution environments inside the multi-purpose device;
    2. Mechanisms to ensure that the software or device have not been altered by the payer or by a third party, or mechanisms to mitigate the risks related to such alteration where this has  taken place.

It is remarkable that the draft RTS only stresses multi-purpose devices such as mobiles and devices in requirement 2. Indeed, hardware tokens and smart card are often protected with a PIN, and in theory it is possible to compromise the token or smart card so that the PIN is also compromised. Since such attacks against hardware tokens and smart cards are very unlikely to happen, it appears that the EBA has decided not to pay attention to them in their draft RTS.

Requirement 3a can be interpreted in multiple ways. A first interpretation could be that common mobile operating systems (e.g. Android, iOS) 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. A second interpretation could therefore be that the requirement refers to trusted execution environments that are implemented using hardware support of the mobile device, along the lines of ARM TrustZone or GlobalPlatform’s TEE standard. However these technologies are barely used today.

Requirement 3b is clearer and mandates Payment Service Providers to use security controls to detect, prevent and respond to the alteration of mobile apps and devices. So-called “runtime application self-protection” (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 to prevent, detect and block fraudulent payments. Article 1(3e) stipulates that transaction risk assessment mechanisms should be based on elements such as the payer’s transaction history, the device used to conduct the payment, rules, etc.

It is noteworthy that the usage of transaction risk analysis does not exempt the Payment Service Provider from the SCA requirements in any case. In other words, Payment Service Providers have to perform strong customer authentication ànd transaction risk analysis for every transaction that is not explicitly exempted from SCA.

Evaluation of common authentication solutions against requirements from draft RTS

Finally, let’s evaluate some of the most common authentication solutions against the above requirements from the draft RTS. The authentication solutions are listed in the table below, and grouped according to the three categories (2da, 2aa and 1aa) defined above. 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. It is noteworthy that solutions based on one-button hardware tokens, which cannot be used for dynamic linking of transaction data, comply with the requirements for access to online payment accounts, but not with the requirements for transaction authentication.

The solutions in the category “2aa” also comply with all requirements, but again under the condition that the mobile apps are protected using cloning countermeasures and RASP technology. I also assume here that the draft RTS does not mandate the use of trusted execution environments like ARM TrustZone, as discussed above.

Finally, the “1aa” approach seems not to be compliant with the draft RTS requirements, primarily because it cannot meet the channel segregation requirement.

tabel-artikel-frederik

Exemptions from strong customer authentication

Chapter 2 of the draft RTS lists exemptions to SCA. The application of SCA is not required in following scenarios:

  • When the payer accesses exclusively the information of its payment account online, without disclosure of sensitive payment data.
  • Online credit transfers to a previously trusted payee, or when the payer and payee are the same natural person.
  • For contactless electronic payment at a point of sale, SCA is not required for payments not up to 50 EUR, with a cumulative limit of 150 EUR.
  • For remote electronic payments, SCA is not required up to 10 EUR, with a cumulative limit of 100 EUR.

The last requirement means, for instance, that SCA needs to be applied for individual wire transfers via online or mobile banking applications higher than 10 EUR. Also, an online purchase at an e-commerce shop (such as Amazon, Coolblue) will require SCA if the amount is higher than 10 EUR. This is very different from payment practices at many e-commerce shops today.

Conclusions

The draft RTS from the European Banking Authority (EBA) will define the minimum level of security required for authentication towards online and mobile banking applications under PSD2. Many traditional authentication solutions, based on the usage of a separate device for authentication, will meet the requirements from the draft RTS. However solutions that are entirely based on a single mobile app, combining banking and authentication functionality, will not be allowed anymore.

A major difference between the EBA Guidelines and PSD2 is that payment transaction authentication will be mandatory once the RTS come into effect. This means an authentication code for a payment needs to be calculated using the payment’s amount of money and beneficiary account number.

According to my interpretation the draft RTS seem to allow the usage of mobile banking and mobile authentication apps in an app-to-app setting, but only if the apps are sufficiently protected. In particular, the draft RTS seem to mandate the adoption of strong countermeasures against cloning of mobile apps, as well as the adoption of RASP technology to protect against the compromise of mobile devices.

Finally it is important to stress that the draft RTS mandates the usage of transaction risk analysis. Payment Service Providers have to perform strong customer authentication ànd transaction risk analysis for every transaction that is not explicitly exempted from SCA.

References

[1]          Vincent Haupert and Tilo Müller, On App-based Matrix Code Authentication in Online Banking, https://www1.cs.fau.de/content/app-based-matrix-code-authentication-online-banking

 

Advertenties
Dit bericht werd geplaatst in PSD2 en getagged met , , , , , . Maak dit favoriet permalink.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s