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.

Advertenties
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: , , , , , , , | Een reactie plaatsen

EBA Eases Strong Customer Authentication Requirements under PSD2

On Thursday 23 February, 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 general the EBA has relaxed its requirements compared to the RTS in the EBA’s Consultation Paper from August 2016. Here are the most important changes:

  1. Transaction risk analysis. The final draft RTS introduces an exemption to SCA based on the level of risk of a payment, and this for payments up to 500 euro. However, this exemption can only be used if the payer’s payment service provider (PSP) has an overall fraud rate lower than the reference fraud rate specified in the RTS. This change will be welcomed especially by the e-commerce industry, where SCA might generate user friction and therefore cancellations of purchases. An important question is however whether one-size-fits-all fraud rates will be usable across different industries, such as e-banking and e-commerce.
  2. No more channel segregation. The EBA has foregone its requirement to use different channels, devices or mobile applications to initiate and authenticate payments. This seems to make it possible to use a single device, and even a single mobile app, to initiate and authenticate a payment.
  3. Unattended payment terminals exempted. Terminals for paying a parking or transport fare are exempted from SCA. This makes sense to avoid queues at parking lots, on highways, underground transport, etc.
  4. Increase of threshold for remote payments. Previously remote payments up to 10 euro did not need SCA. This threshold has been raised to 30 euro.

As a next step, the EBA will submit the final draft RTS to the European Commission for adoption, after which they will be reviewed by the European Parliament and the Council of Ministers. If everything goes well, the RTS will become applicable in November 2018.

Overall, the importance of transaction risk analysis technology has gained importance in the final draft RTS. However, for this to work, PSPs will need to keep their fraud levels under control in order to meet the reference levels. So the exemption based on transaction risk analysis does not come for free. The RTS also provides much more flexibility to use mobile apps to authenticate payments. PSPs will need to protect these mobile apps against various threats, such as cloning, reverse engineering and tampering, in order to meet the RTS requirements.

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

PSD2: Is this the End of SMS-based Authentication?

Banks and payment service providers sometimes rely on SMS to verify the identity of a person who wishes to make a wire transfer or confirm a payment. They send an SMS message with a one-time password (OTP) to the person’s mobile phone, and the user has to enter this OTP into the application of the bank or payment service provider.

In this blog post I discuss whether SMS-based authentication will still be acceptable when the Strong Customer Authentication (SCA) requirements under PSD2 come into force. In August 2016, the European Banking Authority (EBA) published its draft proposal for the Regulatory Technical Standard (RTS) on Strong Customer Authentication (SCA). My analysis is based on this addendum to PSD2. We expect the RTS to be finalized by the EBA in the coming weeks.

In order to answer the question whether SMS-based authentication will be acceptable, we consider three scenarios for using SMS. We then discuss which of the three scenarios meet the requirements of the RTS.

smsScenario 1: two-device authentication (2da)

In this case the user has two independent devices: one device to access a banking website or banking 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 a mobile device that receives the SMS. We assume that the user authenticates himself towards the banking website or app using the OTP from the SMS, and a password or PIN.

This solution is compliant with the RTS when it is used to logon to the banking website or app. The solution can be compliant for signing a transaction, but only if two conditions are met. First, the SMS message must contain the transaction details (e.g. amount, beneficiary). Second, the content of the SMS message must be protected against alteration during transit and receipt by the mobile device. This latter requirement is not easily met by SMS messages, as they are usually not protected.

Hence, in general, SMS-based authentication can be used for logon, but not for signing.

Scenario 2: 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. The authentication app requests and receives the SMS messages.

Standard SMS-based authentication is not compliant for two reasons. First, the SMS can be intercepted and altered in transit. Second, the SMS can be intercepted by malware on the mobile device, meaning the channel segregation requirement from the RTS is not met.

The solution can be made compliant if the content of the SMS message is protected using an end-to-end secure channel that terminates in the authentication app, so that only the app can decrypt the SMS. However this is not the standard approach.

Scenario 3: 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.

This scenario is not compliant with the PSD2 requirements, because there is no channel segregation. The usage of SMS does not influence this.

Conclusion

We are still waiting for the final requirements on Strong Customer Authentication under PSD2. However if nothing changes compared to the current proposal, it is quite clear that SMS-based authentication will have a hard time meeting the requirements, especially those related to approving payments.

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

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

 

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

Strong authentication of Internet Payments in Europe: the new PSD2

Last Thursday, on October 8th, the European Parliament adopted the revised Directive on Payment Services, also known as PSD2. The new directive, which is the long awaited successor of the first Payment Services Directive from 2007, aims to harmonize the European retail payments market, which is very much fragmented along national borders, and foster the adoption of innovative, easy-to-use and secure payment schemes.

In this article I will provide an overview of the requirements of PSD2 regarding the authentication of consumers involved in a payment, which was a topic generating lots of discussions among members of the European Parliament during the past years.

What happened previously

PSD2 is the latest development in a series of European regulatory initiatives aimed at securing Internet payments. These initiatives aim to combat Card-Not-Present (CNP) fraud and increase the confidence of European citizens regarding e-commerce and other online activities.

In January 2013, the SecuRe Pay forum of the European Central Bank (ECB) published its final recommendations for the security of Internet payments. In February 2014, SecuRe Pay also published an assessment guide to help regulatory authorities apply the ECB’s recommendations.

In order to provide a more solid legal basis to the ECB’s recommendations, in December 2014 the European Banking Authority (EBA) published its final guidelines on the security of Internet payments, which are almost identical to the ECB’s recommendations. Since the negotiations for the PSD2 were still ongoing a two-step approach was chosen for the implementation of the EBA guidelines: immediate implementation as of August 1st 2015, followed by an upgrade with the more stringent regulations derived from the PSD2. On May 21st 2015, the EBA published the list of European national authorities that intended to enforce the guidelines.

Strong customer authentication under PSD2

PSD2 uses the same definition of “strong customer authentication” as the EBA guidelines, which is based on the traditional concept of two-factor authentication. “Strong customer authentication” is defined as “an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data”.

Under article 97(1) of PSD2, Payment Service Providers (PSPs) must apply “strong customer authentication where the payer:(a) accesses its payment account online; (b) initiates an electronic payment transaction; [or] (c) carries out any action, through a remote channel, which may imply a risk of payment fraud or other abuses”.

So far this is very similar to the EBA guidelines. However, article 97(2) of PSD2 goes a step further for “electronic remote payment transactions”, which includes all transactions over the Internet. For such transactions, Payment Service Providers must apply strong customer authentication that includes “elements which dynamically link the transaction to a specific amount and a specific payee”. This could also be referred to as strong payment authentication.

Draft regulatory technical standards will be developed by the EBA and submitted to the European Commission that will specify:

(a) the requirements of the strong customer authentication;

(b) the exemptions to the application of [strong customer authentication];

(c) the requirements with which security measures have to comply […] in order to protect the confidentiality and the integrity of the payment service users’ personalised security credentials; and

(d) the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, as well as for implementation of security measures […]”.

Implementation of PSD2

Following the European Parliament’s vote, PSD2 still needs to be formally adopted by the EU Council of Ministers, which will happen in late 2015. Afterwards the Directive will be published in the Official Journal of the EU. EU Member States will then have two years to introduce the necessary changes in their national laws in order to comply with the new rules. Hence PSD2 is expected to come into effect in late 2017.

However, a different adoption schedule applies to the requirements regarding strong customer authentication. PSD2 tasks the EBA with the development of technical standards for strong customer authentication. The EBA must submit the draft technical standards to the European Commission not later than 12 months after PSD2 comes into effect. The standards will come into effect 18 months after their adoption by the European Commission. As a consequence, the standards for strong customer authentication will come into effect about 30 months or 2.5 years after PSD2, hence in late 2020.

The EBA guidelines remain applicable as an interim solution, until PSD2 comes into effect.

Concluding thoughts

The arrival of PSD2 is good news for the harmonization of Internet payment security across Europe. Contrary to the EBA guidelines, national regulatory authorities cannot opt out from PSD2, as it will be translated into national law by the EU Member States. This means also countries such as the UK, who opted out from the EBA guidelines, will be subject to PSD2 and its requirements regarding strong customer authentication.

Strong customer authentication is an important component of the new retail payment market envisioned by the European legislators. Although strong payment authentication is already common practice in online banking services in many European countries, it may present a significant step for e-commerce services and may impact the check-out processes of e-commerce merchants. Hence e-commerce merchants will need to find secure but also convenient authentication mechanisms.

More details about the precise requirements and standards regarding strong customer authentication can be expected in 3 to 4.5 years. Taking into account that Payment Service Providers in most EU Member States already have to comply with the very similar EBA guidelines since August 1st of this year, this additional guidance seems to come rather late.

Finally, it remains to be seen how PSD2, which heavily focuses on the authentication aspects of payments, will integrate with the EBA guidelines. The security requirements put forth in the EBA guidelines have a broader scope than authentication, and also focus on security requirements such as the need for transaction monitoring and customer education.

Geplaatst in Uncategorized | Een reactie plaatsen

Security of Internet payments – National authorities enforcing EBA Guidelines

Last Thursday, on 21 May 2015, the European Banking Authority (EBA) published the compliance notifications from the various European national authorities regarding the enforcement of the EBA Guidelines for the Security of Internet Payments.

I already discussed the Guidelines in an earlier blogpost. This blogpost provides an update in light of the publication of the compliance notifications by the EBA.

Background

On December 19, 2014, the European Banking Authority (EBA) published its final guidelines regarding the security of Internet payments.

In accordance with Article 16 of the EBA Regulation, national authorities and financial institutions need to make every effort to comply with the guidelines. However, it is possible for national authorities to decide not to comply with the guidelines.

National authorities were expected to notify the EBA by 5 May 2015 whether or not they intended to comply with the Guidelines, and so the answers are available since 21 May 2015.

Compliance notifications

The table below summarizes the compliance notifications from the various member states of the European Union (EU) and the European Economic Area (EEA).

Member state Notification
Belgium, Bulgaria, Czech Republic, Denmark, Germany, Ireland, Greece, Croatia, Spain, France, Italy, Latvia, Lithuania, Luxembourg, Hungary, Malta, Netherlands, Austria, Poland, Portugal, Romania, Slovenia, Finland, UK (FSC in Gibraltar), Liechtenstein, Norway Complies or intends to comply
Estonia, Slovakia, UK (FCA), Iceland Is not compliant
Cyprus, Sweden Intends to comply partially

As the table shows, 26 national authorities stated that they will comply with the Guidelines, while two indicated partial compliance and four reported that they will not comply.

As such a large majority of the national authorities will enforce the Guidelines. Because of this, I believe that one of the most important objectives of the Guidelines, namely the harmonization of security of Internet payments across Europe, can be achieved.

The FCA’s standpoint

One of the most notable national authorities not to enforce the Guidelines is the UK’s Financial Conduct Authority (FCA). This is not surprising though, as it is in line with statements FCA made in March 2014 and April 2015 on its website.

FCA itself provides two reasons for this non-compliance. Firstly, FCA states it does not have the power to enforce the Guidelines without legislative changes to its mandate. Secondly, FCA believes that the requirements from the Guidelines come with significant costs for payment service providers, and since it is not entirely clear yet how the upcoming Payment Services Directive 2 (PSD2) will affect investments made by payment service providers in the context of the Guidelines, FCA prefers to wait until PSD2 is clear and adopt the Guidelines and PSD2 at the same time.

A third reason might be as follows: as mentioned in the European Central Bank’s Third Report on Card Fraud, the UK is one of very few member states that managed to reduce its Card-Not-Present (CNP) fraud levels in absolute terms during the period 2008 to 2012 (the other countries being Sweden and Greece). Since the EBA sees rising fraud levels as one of the main reasons for adopting the Guidelines, the decrease of fraud (before the Guidelines existed) might be seen as a good reason for not needing the Guidelines.

Hence, it can be imagined that payment service providers in the UK were reluctant to adopt the Guidelines, given the potential of additional costs for compliance with PSD2, and given that they already reduced CNP fraud without the Guidelines.

Effect of compliance notifications

Payment service providers that operate in a country whose national authority has decided to enforce the Guidelines have to comply by 1 August 2015.

In particular, this means that payment service providers have to implement strong, two-factor customer authentication when a customer consults sensitive payment data, and when the customer initiates a payment.

British payment service providers now have a competitive advantage compared to payment service providers from other European countries, as they face fewer compliance requirements. This might prompt payment service providers from outside the UK to relocate there in order to escape the requirements until PSD2 comes into effect.

Geplaatst in Uncategorized | 1 reactie