Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
We applaud EBA’s reasoning on the requirements for strong customer authentication, particularly the EBA’s focus in the Draft RTS on an approach that focuses on a high, rather than granular level of details. FIDO Alliance’s 250+ members are helping to lead a wave of innovation in the authentication market that is delivering excellent security alongside consumer convenience, and the approach taken in this paper will allow these innovations to flourish.
We appreciate the principles-based approach focused on not mandating any one technology and recognizing the amount of innovation ongoing in the space – given the rapid pace of innovation that is in some cases obsoleting some first-generation authentication technologies, the idea of a principled-based approach is essential here.
With regards to the provisions in Chapter 1 of the draft RTS, we offer comments on the following sections:
Article 1: Authentication procedure and authentication code
We request some clarification on 1(3)(b) – as we read it, it looks as if it may require that authentication procedures not reveal which of the two authentication factors was incorrect and caused the procedure to fail. If this is the case, it may create challenges with the user experience. For example, if a biometric scan fails or a user PIN is incorrect, it may be helpful to reveal that this is an issue. Also, full compliance with this requirement might stand in the way of gathering metrics that could be used to improve system performance.
We also request some clarification on 1(3)(c) – which requires that accounts/payments be blocked after too many incorrect attempts. While well intentioned, this could expose the service to denial of service attacks that flood an authentication service with fake, failure-causing authentication attempts, triggering user lockouts. We would suggest that the EBA consider rewording this article so that only attempts from the suspect channel / endpoint (e.g. the IP address of the DoS sources), if known, must be blocked.
Article 4: Requirements related to elements categorized as possession.
The focus on anti-cloning features in this Article is quite important, particularly given recent documented attacks such as those focused on account hijacking of consumer phones. (see https://www.wired.com/2016/06/even-ftcs-lead-technologist-can-get-hacked) When the phone itself is used as an authentication tool, it is essential that the authentication solution is firmly bound to the device itself, as opposed to a phone number that may be easily transferred by a modern-day attacker to “clone” a device.
Article 5: Requirements related to devices and software to read authentication elements categorized as inherence.
We believe the requirements in this section cover the necessary items. Please see our answer to question 3 for more details.
Article 6: Requirements related to the independence of the elements.
Given the proliferation of mobile devices and the need for any RTS to support mobile use cases, the approach taken in the RTS is spot-on. We particularly applaud the approach to providing measures to mitigate the risk of a multi-purpose device being compromised, such as the implementation of separated trusted execution environments inside the multi-purpose device. This mirrors the approach taken in the United States by the National Institute of Standards and Technology (NIST), as well as other countries around the world.
The evolution of mobile devices - in particular the increased use of hardware architectures that offer highly robust and isolated execution environments (such as TEE, SE and TPM) - which has allowed these devices to achieve top-grade security without the need for a physically distinct token – now allows for two separate, independent authentication elements to be delivered in a single multi-purpose device, and most commercial devices for consumers are shipping with these capabilities already built in. As we detailed in our response to the EBA discussion paper earlier this year, the FIDO specifications are specifically crafted to take advantage of these elements, delivering authentication that is stronger than “first generation” authentication solutions while also being much easier to use.
Article 7: Review of the strong customer authentication procedure
Given the wide variety of authentication solutions entering the marketplace – and their varying levels of security – a robust certification program to validate the security of solutions is important.
The FIDO Alliance believes that certification is vital, yet optional to the interoperability, security and privacy of solutions using the FIDO protocols. We have established an initial certification program that is entirely voluntary and has been utilized by more than 250 products from over 50 companies; details are at https://fidoalliance.org/certification/
Our current certification program is focused on ensuring compliance with the technical specifications with the help of self-operated conformance test tools and proctored interoperability testing. To address third-party security certification, the FIDO Alliance is currently in the process of developing a new security certification program.
The U.S. National Institute of Standards and Technology (NIST) recently launched an effort focused on measuring Strength of Function for Authenticators (SOFA) in biometrics. More information is at https://pages.nist.gov/SOFA/.
While an early stage effort, the approach NIST is taken to categorizing different threats involving biometrics may be of interest to the EBA – particularly Table 1 of the SOFA document, which outlines different types of spoof presentation attacks separated by levels based on time, expertise, and equipment.
That said, we note that our members have approached this issue from a different angle: it is our goal to make strong authentication cheaper, simpler and easier to use -- not only when compared to other approaches to strong authentication, but also when compared to passwords alone -- therefore reducing the market pressure for exemptions in a FIDO-enabled ecosystem.
Usability was the guiding design principle of FIDO, with a focus on enabling very strong, asymmetric public key cryptography alongside a user experience that surpasses any other authentication approach. FIDO specifications provide an open standard way to vastly improve the security and usability of authentication. For example, the user need only touch something (fingerprint sensor or present a “security key” device), look at something (iris or facial recognition), or say something (voice authentication), which is a vast improvement over the usability of typing passwords or one-time-passcodes.
The practical impact of FIDO-enabled solutions in the marketplace is that all parties can benefit from strong authentication without costs or burdens -- which should significantly reduce the demand for exemptions.
Since the design of the authentication protocol impacts which parties have access to personalized security credentials, the 250+ members of the FIDO Alliance have designed the FIDO authentication protocols in such a way that they use public key cryptography and separate user verification from the cryptographic authentication protocol itself.
The use of public key cryptography allows sensitive cryptographic keys to only be stored at the user’s device rather than on payment service providers or relying parties in general. Additionally, privacy has been taken into account from the beginning in the design and therefore ensures that users cannot be tracked across online services.
For a more detailed discussion about the privacy properties please see https://fidoalliance.org/resources/FIDO__Privacy_White_Paper_Jan_2016.pdf. FIDO protocols rely on widely deployed Internet security protocols and cryptographic algorithms.
One item that we do note: Art. 12(a) requires that “association” (registration) of PSCs with a user must take place “in environments under the payment services provider’s responsibility.” Similarly, Art. 13(d) seems to require that “activation” of PSCs, software or devices must take place “in a secure and trusted environment in accordance with the association procedures referred to in Article 12”.
We note that, as written, this may create challenges for a PSP relying on third-party authenticators complying with the FIDO specifications. Because these authenticators are built directly into the device, a PSP relying on such an authenticator may have limited visibility or control over what’s happening, client-side. Our concern is that, as written, FIDO registration may therefore be deemed to be taking place in an environment that is not fully under the PSP’s “responsibility” - unless “association of the payer with PSCs, device and software” is interpreted to mean just the step where the authentication Server stores the user’s public key and key handle upon registration (and excluding, for instance, key generation, registration request signing, etc., as these happen exclusively on the client-side). We would appreciate clarification here that makes clear this secure use case would not be precluded.
Accordingly, we recognize that e-IDAS may play a role in supporting strong authentication requirement for PSD2. The ability for European consumers to choose to leverage a strong credential they already have makes inherent sense.
“Choice” is, in our view, the essential issue here. While some consumers may wish to use a national ID solution for payments authentication, others may find that solution burdensome or simply prefer to use a different credential or credential service. Given that market acceptance of strong authentication is directly tied to reducing the burden placed on consumers to use the technology, letting them choose from a variety of different types of strong authentication solutions that meet EBA requirements offers the most logical path forward. Open standards and specifications maximize the opportunity for user choice in any market.
As governments consider ways to extend the functionality and trust model of traditional national ID cards, FIDO specifications offer a logical path to expand the e-IDAS ecosystem -- particularly for entities interested in using a country’s eID to “derive” a trusted public-private key pair from a national eID, using that eID as a root of trust. Specifically, FIDO allows for public key (PK) certificate pairs to be used for authentication without the overhead of a full-blown PKI system, enabling a more lightweight authentication solution using public key cryptography.
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
The Fast Identity Online (FIDO) Alliance appreciates the opportunity to provide comments to the EBA on the Consultation Paper on the Draft Regulatory Technical Standards on Strong Customer Authentication and Secure Communication.We applaud EBA’s reasoning on the requirements for strong customer authentication, particularly the EBA’s focus in the Draft RTS on an approach that focuses on a high, rather than granular level of details. FIDO Alliance’s 250+ members are helping to lead a wave of innovation in the authentication market that is delivering excellent security alongside consumer convenience, and the approach taken in this paper will allow these innovations to flourish.
We appreciate the principles-based approach focused on not mandating any one technology and recognizing the amount of innovation ongoing in the space – given the rapid pace of innovation that is in some cases obsoleting some first-generation authentication technologies, the idea of a principled-based approach is essential here.
With regards to the provisions in Chapter 1 of the draft RTS, we offer comments on the following sections:
Article 1: Authentication procedure and authentication code
We request some clarification on 1(3)(b) – as we read it, it looks as if it may require that authentication procedures not reveal which of the two authentication factors was incorrect and caused the procedure to fail. If this is the case, it may create challenges with the user experience. For example, if a biometric scan fails or a user PIN is incorrect, it may be helpful to reveal that this is an issue. Also, full compliance with this requirement might stand in the way of gathering metrics that could be used to improve system performance.
We also request some clarification on 1(3)(c) – which requires that accounts/payments be blocked after too many incorrect attempts. While well intentioned, this could expose the service to denial of service attacks that flood an authentication service with fake, failure-causing authentication attempts, triggering user lockouts. We would suggest that the EBA consider rewording this article so that only attempts from the suspect channel / endpoint (e.g. the IP address of the DoS sources), if known, must be blocked.
Article 4: Requirements related to elements categorized as possession.
The focus on anti-cloning features in this Article is quite important, particularly given recent documented attacks such as those focused on account hijacking of consumer phones. (see https://www.wired.com/2016/06/even-ftcs-lead-technologist-can-get-hacked) When the phone itself is used as an authentication tool, it is essential that the authentication solution is firmly bound to the device itself, as opposed to a phone number that may be easily transferred by a modern-day attacker to “clone” a device.
Article 5: Requirements related to devices and software to read authentication elements categorized as inherence.
We believe the requirements in this section cover the necessary items. Please see our answer to question 3 for more details.
Article 6: Requirements related to the independence of the elements.
Given the proliferation of mobile devices and the need for any RTS to support mobile use cases, the approach taken in the RTS is spot-on. We particularly applaud the approach to providing measures to mitigate the risk of a multi-purpose device being compromised, such as the implementation of separated trusted execution environments inside the multi-purpose device. This mirrors the approach taken in the United States by the National Institute of Standards and Technology (NIST), as well as other countries around the world.
The evolution of mobile devices - in particular the increased use of hardware architectures that offer highly robust and isolated execution environments (such as TEE, SE and TPM) - which has allowed these devices to achieve top-grade security without the need for a physically distinct token – now allows for two separate, independent authentication elements to be delivered in a single multi-purpose device, and most commercial devices for consumers are shipping with these capabilities already built in. As we detailed in our response to the EBA discussion paper earlier this year, the FIDO specifications are specifically crafted to take advantage of these elements, delivering authentication that is stronger than “first generation” authentication solutions while also being much easier to use.
Article 7: Review of the strong customer authentication procedure
Given the wide variety of authentication solutions entering the marketplace – and their varying levels of security – a robust certification program to validate the security of solutions is important.
The FIDO Alliance believes that certification is vital, yet optional to the interoperability, security and privacy of solutions using the FIDO protocols. We have established an initial certification program that is entirely voluntary and has been utilized by more than 250 products from over 50 companies; details are at https://fidoalliance.org/certification/
Our current certification program is focused on ensuring compliance with the technical specifications with the help of self-operated conformance test tools and proctored interoperability testing. To address third-party security certification, the FIDO Alliance is currently in the process of developing a new security certification program.
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
N/AQuestion 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
We believe the EBA has highlighted the most important threats, however, we note that there has been scant work done to date testing the strength of biometrics for use in authentication.The U.S. National Institute of Standards and Technology (NIST) recently launched an effort focused on measuring Strength of Function for Authenticators (SOFA) in biometrics. More information is at https://pages.nist.gov/SOFA/.
While an early stage effort, the approach NIST is taken to categorizing different threats involving biometrics may be of interest to the EBA – particularly Table 1 of the SOFA document, which outlines different types of spoof presentation attacks separated by levels based on time, expertise, and equipment.
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
The FIDO Alliance does not have views on particular exemptions to requirements for strong authentication.That said, we note that our members have approached this issue from a different angle: it is our goal to make strong authentication cheaper, simpler and easier to use -- not only when compared to other approaches to strong authentication, but also when compared to passwords alone -- therefore reducing the market pressure for exemptions in a FIDO-enabled ecosystem.
Usability was the guiding design principle of FIDO, with a focus on enabling very strong, asymmetric public key cryptography alongside a user experience that surpasses any other authentication approach. FIDO specifications provide an open standard way to vastly improve the security and usability of authentication. For example, the user need only touch something (fingerprint sensor or present a “security key” device), look at something (iris or facial recognition), or say something (voice authentication), which is a vast improvement over the usability of typing passwords or one-time-passcodes.
The practical impact of FIDO-enabled solutions in the marketplace is that all parties can benefit from strong authentication without costs or burdens -- which should significantly reduce the demand for exemptions.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
The FIDO Alliance does not have concerns regarding this list of exemptions.Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
FIDO Alliance believes that the EBA’s reasoning here is sound. In particular, we applaud the focus on ensuring that secret cryptographic material used in authentication is “stored in secure and tamper resistant devices and environments.”Since the design of the authentication protocol impacts which parties have access to personalized security credentials, the 250+ members of the FIDO Alliance have designed the FIDO authentication protocols in such a way that they use public key cryptography and separate user verification from the cryptographic authentication protocol itself.
The use of public key cryptography allows sensitive cryptographic keys to only be stored at the user’s device rather than on payment service providers or relying parties in general. Additionally, privacy has been taken into account from the beginning in the design and therefore ensures that users cannot be tracked across online services.
For a more detailed discussion about the privacy properties please see https://fidoalliance.org/resources/FIDO__Privacy_White_Paper_Jan_2016.pdf. FIDO protocols rely on widely deployed Internet security protocols and cryptographic algorithms.
One item that we do note: Art. 12(a) requires that “association” (registration) of PSCs with a user must take place “in environments under the payment services provider’s responsibility.” Similarly, Art. 13(d) seems to require that “activation” of PSCs, software or devices must take place “in a secure and trusted environment in accordance with the association procedures referred to in Article 12”.
We note that, as written, this may create challenges for a PSP relying on third-party authenticators complying with the FIDO specifications. Because these authenticators are built directly into the device, a PSP relying on such an authenticator may have limited visibility or control over what’s happening, client-side. Our concern is that, as written, FIDO registration may therefore be deemed to be taking place in an environment that is not fully under the PSP’s “responsibility” - unless “association of the payer with PSCs, device and software” is interpreted to mean just the step where the authentication Server stores the user’s public key and key handle upon registration (and excluding, for instance, key generation, registration request signing, etc., as these happen exclusively on the client-side). We would appreciate clarification here that makes clear this secure use case would not be precluded.
Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
N/AQuestion 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
N/AQuestion 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
The FIDO Alliance is familiar with the e-IDAS initiative; the governments of both Germany and the United Kingdom are members of FIDO Alliance, and many of our members are involved in supplying key components of national eID programs in countries across Europe. We note that one of the United Kingdom’s certified identity providers is using a FIDO solution to support strong authentication.Accordingly, we recognize that e-IDAS may play a role in supporting strong authentication requirement for PSD2. The ability for European consumers to choose to leverage a strong credential they already have makes inherent sense.
“Choice” is, in our view, the essential issue here. While some consumers may wish to use a national ID solution for payments authentication, others may find that solution burdensome or simply prefer to use a different credential or credential service. Given that market acceptance of strong authentication is directly tied to reducing the burden placed on consumers to use the technology, letting them choose from a variety of different types of strong authentication solutions that meet EBA requirements offers the most logical path forward. Open standards and specifications maximize the opportunity for user choice in any market.
As governments consider ways to extend the functionality and trust model of traditional national ID cards, FIDO specifications offer a logical path to expand the e-IDAS ecosystem -- particularly for entities interested in using a country’s eID to “derive” a trusted public-private key pair from a national eID, using that eID as a root of trust. Specifically, FIDO allows for public key (PK) certificate pairs to be used for authentication without the overhead of a full-blown PKI system, enabling a more lightweight authentication solution using public key cryptography.