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.


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.


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].


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.


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.


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.


[1]          Vincent Haupert and Tilo Müller, On App-based Matrix Code Authentication in 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.


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

The Three Laws of Cyber Fraud

Last week I attended the RSA Conference in San Francisco, which is probably the largest yearly cyber security conference and trade show in the world with about 22,000 attendees nowadays.

Moscone Center, home to the RSA Conference

Moscone Center, home to the RSA Conference

One of the most popular sessions at the conference is the Cryptographers’ Panel, during which some of the founding fathers of modern cryptography discuss trends in research and cyber security in general. This year the panel consisted of Ron Rivest, Adi Shamir, Whit Diffie and Ed Georgio (former chief codemaker and chief codebreaker at NSA). During the session Adi Shamir referred to his three laws of computer security, which he formulated many years ago:

  1. Absolutely secure systems do not exist.
  2. To halve your vulnerability, you have to double your expenditure.
  3. Cryptography is typically bypassed, not penetrated.
After the Cryptographers' Panel, with Adi Shamir and Ron Rivest

After the Cryptographers’ Panel, with Adi Shamir and Ron Rivest

The next day, I was a member of a panel about security in online and mobile banking applications, and Adi Shamir’s laws inspired me to define some laws regarding fraud in our online world prior to the panel discussion. They are as follows:

Law #1: There will always be cyber fraud

This follows from Adi Shamir’s first law, and is probably a no-brainer. We tend to work with systems that are secure enough, and try to keep fraud under control. Reducing fraud to zero would require resources that greatly exaggerate the cost of fraud itself. We try to control fraud, not remove it.

Law #2: Cyber fraud does not disappear, but is transformed (also known as the “balloon” law)

In physics, we have several fundamental laws of conservation, such as the law of conservation of energy. This law states that the total amount of energy in a closed system is constant. Energy available within the system can be transformed (e.g. from potential energy to kinetic energy), but it cannot be increased or destroyed.

I believe a similar conservation law roughly applies to fraud in our online world. Security controls that are introduced to protect online applications do not make fraud go away, but rather have criminals focus on ways to bypass these security controls or focus on other applications, i.e. they transform fraud.

The evolution of credit card fraud losses after the migration to EMV in Canada illustrates this. Prior to the introduction of the EMV standard for debit and credit cards, fraud was mainly the result of card cloning or counterfeiting. This type of fraud decreased in Canada as more and more payments card supported EMV. However, at the same time Card-Not-Present (CNP) fraud increased. Today the total amount of credit card fraud in Canada is higher than before the introduction of EMV, mainly because of the increase in CNP fraud. Similar patterns exist in other regions, such as the European Union.

Changes in Canadian Credit Card Fraud Losses, 2008  to 2013  (In CA$ millions). Source: Canadian Bankers Association

Changes in Canadian Credit Card Fraud Losses, 2008 to 2013 (In CA$ millions). Source: Canadian Bankers Association

From this perspective fraud is very much like a balloon: pressing it somewhere will make it expand somewhere else.

Law #3: Cyber fraud follows the path of least resistance

This is similar to Shamir’s third law, which stipulates that cryptographic systems are typically not broken, but bypassed. Hackers typically exploit vulnerabilities in implementations of cryptosystems and key management systems, rather than cryptanalyzing the algorithms themselves.

Again, the EMV migration in Canada illustrates this law. Because of the EMV technology, card cloning has become much harder, and certainly much harder than Card-Not-Present fraud, which involves making purchases using stolen credit card numbers. This results in higher losses due to CNP fraud.

Geplaatst in Uncategorized | Een reactie plaatsen

Security of Internet Payments: Legislative Developments in Europe

On December 19, 2014, the European Banking Authority (EBA) published its final guidelines regarding the security of Internet payments. This blog post provides an overview of the current regulatory and legislative initiatives within the European Union related to the security of Internet payments, with a special emphasis on upcoming requirements related to strong authentication of both customers and transactions.


During the past years, several European governmental and regulatory bodies have taken various legislative and regulatory initiatives regarding the security of Internet and mobile payments across the European Union.

The main drivers for these initiatives are the rising level of fraud observed in Internet payments, and security concerns among European citizens. According to the European Central Bank’s Third Report on Card Fraud from February 2014, Card-Not-Present (CNP) fraud within the European Union rose to €794 million in 2012, up more than 20% compared to 2008. Furthermore, according to the European Commission’s Special Eurobarometer on Cyber Security from 2013, about 28% of the European citizens does not feel confident about online banking or shopping.

It is remarkable to note that the US government currently does not take any steps similar to the EU. It appears that the EU sees rising fraud levels as a sign of market failure requiring regulators to step in and take corrective action, while the US adopts a “laissez-faire” policy and leaves it up to the market participants to address the fraud levels themselves.

In order to provide an answer to rising fraud levels and security concerns, in 2011 the European Central Bank (ECB) created the SecuRe Pay forum, a voluntary cooperation between the 28 national regulators of the European Union. After a period of consultation with parties from both the public and private sector, this forum published its final recommendations for the security of Internet payments in January 2013, followed by a complementary assessment guide in February 2014. In November 2013, SecuRe Pay published its recommendations on the security of mobile payments, but these recommendations are still in draft and it is currently not clear whether there are any plans to publish a final version of them. In order to provide a more solid legal basis to the ECB’s recommendations on Internet payments, 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. Payment Service Providers (PSPs) are expected to comply with these guidelines by August 2015.

At the same time, the European Commission is reviewing the Payment Services Directive (PSD) together with the European Parliament and the European Council of Ministers. The most recent draft for the new Payment Services Directive (“PSD2”), which was published in October 2014, contains several articles regarding the security of electronic payments, which seems to cover both Internet and mobile payments. It is expected that PSD2 will come into effect in the Spring of 2015, after which it needs to be translated into national law by the various EU member states. PSD2 also tasks EBA with the development of guidelines and technical standards for strong customer authentication, which are expected to become effective 30 months after PSD2. Once PSD2 comes into force, it will supersede the EBA Guidelines.

Tower 42 at 25 Old Broad Street in London, home to the European Banking Authority

Strong authentication under the EBA Guidelines and PSD2

One of the most critical items in the EBA guidelines is the requirement for PSPs to perform strong customer authentication in order to verify the customer identity before proceeding with an on-line payment, be it through online banking services or internet card payments, or when accessing or altering sensitive payment data. According to the EBA Guidelines, strong customer authentication is a procedure based on the use of two or more of the following elements: i) something only the user knows (knowledge, such as a static password or PIN), ii) something only the user possesses (possession, such as a token, smart card, or mobile phone) and iii) something the user is (inherence, such as a fingerprint). In addition, the elements selected must be mutually independent, i.e. the breach of one does not compromise the other(s). At least one of the elements should be non-reusable and non-replicable (except for inherence), and not capable of being surreptitiously stolen via the internet.

As an example, a hardware token generating one-time passwords (OTPs) and protected with a PIN would meet this definition of strong customer authentication, as also explained by the ECB’s assessment guide. The hardware token represents the possession element, while the PIN is the knowledge element. Both elements are independent, as theft of the hardware token does not compromise the PIN, and vice versa. Additionally one-time passwords are not reusable, and it is not feasible to clone the hardware token.

PSD2 goes a step further than the EBA Guidelines and, in Article 87 of the current proposal, requires PSPs to perform strong transaction authentication, linking the transaction to a specific amount and a specific payee. As mentioned above, the EBA will provide technical standards detailing the acceptable authentication mechanisms. Although transaction authentication is already common practice in online banking services in many European countries, this requirement presents a significant step for e-commerce services and may impact the check-out processes of e-commerce merchants.

Revisiting the example above, under PSD2 the hardware token would have to be able to calculate a Message Authentication Code (MAC) or digital signature over the transaction’s amount, payee, and optionally other transaction-related data.

Enforcement of the EBA Guidelines and PSD2

As mentioned above, the EBA Guidelines will come into effect in August 2015. In accordance with Article 16 of the EBA Regulation, competent authorities and financial institutions must make every effort to comply with the guidelines.

However, it is possible for competent authorities (e.g. financial regulators, national banks) to decide not to comply with the guidelines. Competent authorities are expected to notify the EBA whether or not they intend to comply within two months after the publication of the translations of the final guidelines. The EBA will subsequently publish notifications from the competent authorities on its website.

Hence, in the coming weeks and months it will become clear which competent authorities intend to comply. In this respect it is interesting to note that the British Financial Conduct Authority (FCA) writes that it “[…] will begin to assess firms’ implementation of these security measures when the updated Payment Services Directive requirements take effect”, which seems to signal a delay compared to the August 2015 implementation date. On the other hand the Bank of Spain has confirmed compliance with the guidelines. Differences in attitudes among competent authorities might lead to a segmentation within the EU, with some competent authorities adopting the guidelines and others not.

On the other hand, PSD2 will be translated into the national law of the EU member states, and therefore more strictly enforced.


The EBA guidelines on the security of Internet payments will come into effect in August 2015. A critical requirement from these guidelines is the adoption of strong customer authentication mechanisms by PSPs. However, it is important that PSPs anticipate the requirements of PSD2, which will most likely additionally require strong transaction authentication.

Finally it will be noteworthy to see which competent authorities decide to comply with the EBA Guidelines. One of the primary goals of the EBA Guidelines was to create a level-playing field for all PSPs across the EU through harmonization of payment security regulation. However if some competent authorities decide not to comply, PSPs might decide to move to member states with the least stringent regulation.

Update (April 7, 2015): In the meantime the EBA has clarified that it expects competent authorities to indicate whether or not they intend to enforce the EBA Guidelines by May 5th 2015. The EBA will publish the responses of the competent authorities on its website.

CSSF, the competent authority of Luxembourg, issued a circulaire transforming the EBA Guidelines into national law on February 9th. Similarly, BaFin from Germany issued a request for comments about transposal of the EBA Guidelines on February 4th.

Update (April 29, 2015): FCA, the competent authority of the UK, has published a statement on its website regarding the adoption of the EBA Guidelines. They will essentially adopt the EBA Guidelines at the same time as PSD2.

Geplaatst in Uncategorized | 12 reacties

The 4 roles of the security department

A couple of months ago, the Information Security Group (ISG) at Royal Holloway, University of London established a new Centre for Doctoral Training (CDT) in Cyber Security. The aim of this centre is to deliver highly-trained researchers in cyber security, in line with the UK government’s objective of strengthening the country’s cyber security capability.

As part of their training programme, researchers at the CDT have the opportunity to meet representatives from high-tech and consulting companies (like McAfee, Vodafone, MasterCard, KPMG) to give them a glimpse of what cyber security at companies is all about.

As part of the industry seminar series, I talked last week to the CDT researchers about possible career paths in information security. One of the topics I addressed was how to select a company to work for. While this is a broad and subjective topic, I believe it is essential to understand the role of the security department in the company you are considering to join. Therefore I created a model to identify and confront the various roles of the security department in a company (MBA graduates will be happy to see I used a two-by-two matrix to depict the model):

role_sec_deptIn my opinion the role of a security department in a company is determined mainly by two elements, namely 1) the importance of security for the company’s business strategy, and 2) support for the security department by the company’s executive management. This gives rise to four quadrants, each representing a potential role for the company’s security department.

The bottom-right quadrant, which I like to call the time bomb, is a place you want to avoid as a security practitioner. If security is important to the company’s business strategy but management does not support it, the company probably lacks resources to implement a decent security programme, resulting in incident-driven security management. In such an environment things will likely go horribly wrong one day. And when things go wrong, the security department will probably be blamed for it – that is, if the business still exists. So, not a very nice place to be.

The bottom-left quadrant is a place you want to avoid as well, and probably even more than the “time bomb”. When working at a company that has no business interest in security and where management does not support the security department, the security function might not exist in the first place or be outsourced. If it exists, security practitioners will essentially have a supporting role, outside the company’s value chain, without impact on the company’s business. So I call this role the slave. Again, not a very attractive place to be.

At first sight, it would be impossible for any company to be located in the top-left quadrant. Indeed, why would the management of a company pay attention to security when it is not important for the company’s business? This is where compliance comes into play. In more and more areas, such as financial services and healthcare, companies pay attention to security because they are required to do so because of legislative or regulatory pressure. Companies in this area often outsource their security function or work with consultants, as it is not at the core of their business. Security professionals here very often focus on maintaining the security of the company’s assets, such as the network infrastructure and sensitive data. I call this quadrant the guard.

Finally, the place where every ambitious security professional should work is with a company in the fourth quadrant. When your work is important for the company’s business, and management supports you, you are most likely to have an interesting role and the potential to be successful. That’s why I like to refer to this quadrant as the superman quadrant. Many security technology providers are located in this quadrant.

This model might simplify reality very much (which is why it is a model in the first place), but I do hope that all CDT students will remember this when they graduate in a few years, and that they will all find a role as a superman or superwoman!

Geplaatst in Uncategorized | Een reactie plaatsen

Making sense of SSL/TLS vulnerabilities

Update (29/11/2013): After a discussion with Kenny Paterson, the conclusion below has been reworked to show more clearly that the choice of the encryption mechanism in the SSL Record Protocol should depend on whether client-side or server-side mitigation techniques can be relied on.

SSL/TLS is arguably the most widely-used protocol to secure communications on the Internet nowadays. It is used, for instance, to protect the sensitive traffic of e-banking and e-commerce web applications. It is also becoming more and more popular as the basis for Virtual Private Networks (VPNs).

During recent months and years, several weaknesses have been discovered in the SSL/TLS protocol. Some attacks target the way data is encrypted by SSL/TLS, namely BEAST, Lucky 13, and the RC4 attack. Other attacks, like CRIME and BREACH, are based on exploiting the way data is compressed.

Here, we focus on attacks targeting the way data is encrypted in SSL/TLS, because these attacks seem to have caused conflicting opinions about which SSL/TLS ciphersuites are most appropriate to mitigate them.

Back in March, Matthew Green recommended abandoning RC4 immediately. In September SSL Labs at Qualys deprecated RC4 in its SSL/TLS Deployment Best Practices guide. On the other hand, at the recent ECC 2013 conference in Leuven, Emilia Kasper defended Google’s use of RC4 as primary cipher. Google’s Adam Langley seems to reinforce that position in a recent blog post.

So: should we use CBC-mode encryption, RC4, or something else? Let’s first take a step back and briefly look at how SSL/TLS works, before diving into the actual attacks.


SSL/TLS is not a single protocol, but rather a set of protocols. In this discussion, we are only concerned with two protocols, namely the SSL Handshake Protocol and the SSL Record Protocol.

The SSL Handshake Protocol is essentially an authenticated key establishment (AKE) protocol: its purpose is to authenticate the client and server, and establish a common secret between them.  It provides several key exchange methods, the most important ones being:

  • RSA: in this case the client generates a secret and provides it to the server, encrypted under the latter’s public key
  • Diffie-Hellman: in this case the client and server exchange their respective Diffie-Hellman public keys, and calculate a shared secret

The SSL Record Protocol subsequently uses the shared secret to protect the confidentiality and integrity of bulk data exchanged between the client and server, and to guarantee the freshness of the data using counters. It provides three ways to protect data:

  1. Using a MAC followed by encryption with a block cipher (e.g. AES) in CBC-mode
  2. Using a MAC followed by encryption with the stream cipher RC4
  3. Using a block cipher in a mode that provides authenticated encryption, such as GCM and CCM (available since TLS 1.2)

SSL/TLS cipher suites

SSL/TLS cipher suites consist of two parts. The first part determines the mechanism used to exchange the secret key (usually based on RSA or Diffie-Hellman), as well as the mechanism used to authenticate the client and/or server. The second part determines the algorithms used to MAC and encrypt bulk data.

The full list of cipher suites  is available in IANA’s TLS Cipher Suite Registry. As an example, the cipher suite “TLS_DHE_RSA_WITH_AES_128_CBC_SHA256” means the following:

  • DHE: use Ephemeral Diffie-Hellman to agree on the shared secret
  • RSA: use RSA digital signatures to authenticate the Diffie-Hellman key agreement
  • AES-128 CBC: use AES in CBC-mode to encrypt the data
  • SHA256: use HMAC-SHA26 to authenticate the data

Recent attacks against SSL/TLS

The most recent attacks have all focused on the SSL Record Protocol, and more specifically on two ways to protect data:

  1. Encryption with a block cipher in CBC-mode
  2. Encryption with the RC4 stream cipher

Let’s take a more detailed look at three attacks, namely the BEAST attack, Lucky 13 and the RC4 attack. The first two target CBC-mode encryption, while the latter focuses on RC4 encryption.

Browser Exploit Against SSL/TLS (BEAST)

The BEAST attack, reported by Julianno Rizzo and Thai Duong at the ekoparty conference in September 2011, is in fact an implementation of an attack discovered by Gregory Bard in 2004. The attack applies to all versions of SSL and also TLS 1.0.

As mentioned above, one of the options in the SSL Record Protocol is using CBC-mode encryption. CBC-mode encryption, like most modes of operation, requires an Initialization Vector (IV). According to good practices in cryptography, every message should be encrypted with a fresh, random IV.

However, in SSL and TLS 1.0, this is not the case. Although the first IV is a (pseudo) random string which is generated by the SSL Handshake Protocol, subsequent IVs are chosen in a deterministic, predictable way. More specifically the IV of a message is taken to be the final ciphertext block of the immediately-preceding message, and is therefore known to the adversary.

The BEAST attack allows a man-in-the-middle to decrypt session cookies, simply by injecting Javascript into the victim’s web browser.

There are basically four ways to mitigate the BEAST attack:

  1. Upgrade to TLS 1.1 or 1.2
  2. Use 1/n-1 record splitting. This means that encrypted SSL/TLS records are split into two parts: the first with only a single byte of application data and the second with the remaining application data. This is a client-side mitigation technique. The major browser vendors already implemented this back in January 2012.
  3. Use AES in a mode providing authenticated encryption
  4. Use RC4 instead of CBC encryption

Lucky 13

As mentioned above, the SSL Record Protocol aims to protect both the integrity and confidentiality of a message. In general there are three ways to combine integrity and confidentiality protection:

  1. Encrypt-then-MAC (the approach of IPsec)
  2. MAC-then-Encrypt
  3. Authenticated encryption

The SSL Record Protocol uses the MAC-then-Encrypt approach (and authenticated encryption as from TLS 1.2, but let’s forget about that for now). It starts by fragmenting the plaintext data, optionally compressing every fragment, and then calculating a MAC over the (compressed) fragment. Subsequently the fragment is padded to a multiple of the block cipher’s block size using a padding mechanism that is similar, but not identical to PKCS #7 padding. The padded message is encrypted using the block cipher in CBC-mode.

Unfortunately the MAC-then-Encrypt approach is vulnerable to so-called padding oracle attacks. Since the padding is not protected by a MAC, an adversary could intercept a ciphertext, alter it, and submit it to the SSL/TLS server for decryption. If the server returns different error messages (e.g. “incorrect padding” instead of “incorrect MAC”) for different altered ciphertexts, the adversary receives information that can be used to successfully decrypt the ciphertext.

The designers of SSL/TLS were aware of this problem many years ago, and therefore SSL/TLS servers do not return error messages indicating that the padding was wrong. However, there is still a difference in the amount of time it takes to decrypt ciphertexts, depending on whether or not the padding is correct.

In February, researchers from Royal Holloway reported a plaintext recovery attack against CBC-mode encryption, based on exploiting those timing differences. The adversary requires the target plaintext to be repeatedly sent in the same position in the plaintext stream in 2^13 ~ 8000 TLS sessions per byte of plaintext. Additionally the adversary has to be located on the same LAN as the machine being attacked in order to reliably measure timing differences.

There are basically three ways to mitigate the Lucky 13 attack:

  1. Use an SSL/TLS server-side implementation with constant-time CBC decryption. Adam Langley made a 500-line implementation for this in OpenSSL.
  2. Use AES in a mode providing authenticated encryption
  3. Use RC4 instead of CBC encryption. But as we discuss next, RC4 has its own problems.

The RC4 attack

RC4 is a stream cipher, meaning that it transforms a (short) cryptographic key into a (long) keystream of pseudorandom bytes. In order to encrypt a plaintext, the plaintext is XORed with the keystream.

In order for this to work, it is important that the keystream bytes are sufficiently random. Unfortunately several years ago, researchers already discovered statistical biases in the RC4 keystream, but they were never considered to be harmful enough in order to be exploitable.

Then, in March of this year, researchers from Royal Holloway, the University of Chicago at Illinois and the Eindhoven University of Technology reported additional biases in the first 256 bytes of the RC4-128 keystream, which can be exploited to perform a plaintext recovery attack. The attacker can be located anywhere on the path between the client and the server.

In order to be successful, the attacker needs to obtain the same plaintext encrypted under many different keys, on the order of 2^33 to 2^34 for reliable recovery of 16 bytes anywhere in the plaintext. For instance, in order to recover a cookie, the attacker would have to make the victim’s browser send about 1 to 10 billion copies of the same cookie, encrypted under different keys.

While the attack is feasible and reduces the security level of RC4 well below the strength one would expect from a 128-bit key length, the attack is not really practical at the moment. The only way to avoid it consists of abandoning RC4.

Conclusion: RC4 or CBC encryption?

The best option clearly is to move to TLS 1.2 and use an authenticated encryption mode such as GCM and CCM. So far no attacks are known against those modes. Today all major browser vendors support TLS 1.2, so this is the best way forward.

However, it will take some time for users to upgrade browsers to a version that supports TLS 1.2. Therefore, the question today is whether to use RC4 or CBC-mode encryption in the SSL Record Protocol.

In my opinion the answer to this question depends on whether you have control over the SSL/TLS client, SSL/TLS server or both. Let’s try to clarify that.

First, if you only control the SSL/TLS server, you may want to rely only on server-side techniques to mitigate the above-mentioned attacks. In order to counter the Lucky 13 attack, you can implement an SSL/TLS library with constant-time CBC decryption. The only server-side technique to address BEAST consists of using RC4, which exposes you to the RC4 attack. So you have to choose: either you accept the BEAST attack, or the RC4 attack. Since the RC4 attack is the more difficult one, I would settle with RC4 in this case.

Second, if you only control the SSL/TLS client, you can mitigate the BEAST attack using 1/n-1 record splitting. So that leaves you with the choice of accepting either the Lucky 13 or RC4 attack. Since the RC4 attack is much less feasible than the Lucky 13 attack, I would go for RC4 again.

Finally, if you control both the SSL/TLS client and server, the situation is different. In this case you can deploy 1/n-1 record splitting to avoid the BEAST attack, and constant-time decryption at the server-side to avoid the Lucky 13 attack. In this case, the best choice is to go for CBC-mode encryption, so that the RC4 attack is thwarted as well.

Bottom-line: it’s quite complicated today. The good news: it should all be much simpler in the future with TLS 1.2.

Afbeelding | Geplaatst op door | Een reactie plaatsen