Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
At the core of FIDO specifications [2] is the generation of a public/private key pair on a FIDO Authenticator device where the private key is contained within, and protected by, the FIDO Authenticator [3]. Proof-of-possession of this private key is the basis for FIDO Authenticators’ capability to fulfill the possession requirements for strong customer authentication. We note that there are a range of technologies available for FIDO Authenticators to use to protect the private key from being exported from the user’s device.
The degree to which a FIDO Authenticator protects the FIDO authentication private key from theft or tampering is implementation-specific, but can be tested. It is for this type of testing, presumably performed by 3rd-party security labs, that FIDO Alliance is currently defining requirements; the Alliance will be launching a formal FIDO Security Certification Program later in 2016.
A well-protected private key cannot be exported from the device; nor can an attacker duplicate or spoof that key. Thus, any authentication ceremony which uses that key, subject to the service provider’s required level of assurance, proves possession of the device on which it was generated.
Because only the FIDO Authenticator itself contains the private key, the only practical way to attack that key is to attack the user’s personal device. When the FIDO Authenticator leverages modern technology for the protection of the private key, such as secure elements, Trusted Execution Environments (TEE) or TPM chips (which is the trend with consumer electronics today, especially mobile devices), the attacker must actually gain physical possession of that user’s device to even attempt an exploit. This type of attack does not scale and is quickly detectable as mobile devices are highly personal and quickly missed by the owner. Such an attack is therefore not economical from a cyber-crime perspective.
Even if an individual’s device is captured, the only way an attacker can unlock that key is through a second factor -- in the case of FIDO UAF [4] this would typically require the attacker to also have a spoof of the genuine user’s biometrics (though other options are available such as PIN codes), and in the case of FIDO U2F this would typically require the attacker to also have the first-factor credentials for the user’s account such as their username and password. Simply having possession of a FIDO Authenticator does not grant access to any account protected by that FIDO Authenticator, which is why all FIDO Authenticators are inherently multi-factor authenticators. When an adversary must steal someone’s device before launching an attack on their Authenticator, it materially changes the risk model.
Many FIDO-compliant solutions are further bolstered by the presence of a hardware-backed Attestation Key, present in every FIDO Authenticator of that make and model, that attests to the particulars of the device itself. This Attestation Key can be used by an online service provider (Relying Party) to understand what kind of technology (e.g., biometric type, hardware security element, etc.) is being used in that particular device. This Attestation Key provides an additional role in the chain of trust.
Some FIDO Authenticators go a step further and take advantage of the FIDO Metadata Service which is a mechanism for online services to reference a local cache of authenticator-manufacturer-provided metadata about the authenticator itself. This is a public service operated by the FIDO Alliance, optional for online services and authenticator vendors, that if used may help facilitate the exchange of relevant information that online service providers can use to make informed trust decisions when presented with a previously unknown FIDO Authenticator requesting registration.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/specifications/overview/
[3] An Authenticator is a logical component that may be contained in a device, such as in a physically secure execution environment (i.e., a Trusted Execution Environment (TEE) or Secure Element) in a smartphone or Trusted Platform Module (TPM) of a computer, or may reside in a separate physical device (e.g., a USB token with a Secure Element that can be attached to a laptop, or a smartwatch that is connected via Bluetooth Smart with another device).
[4] Note that version 1.0 of FIDO specifications includes two types of protocols: the Universal 2nd Factor (U2F) and Universal Authentication Framework (UAF); these protocols support two different use cases that will both be supported in the new FIDO 2.0 specifications, whose web browser and web server components have been submitted for formal standardization to the W3C. We discuss the two specifications in more detail in our Appendix which can be found in our full response available at [1].
The FIDO Alliance does not assert that there is any single “silver bullet” solution for authentication that is capable of supplanting all other authentication technology currently in operation. The FIDO specifications and associated testing programs enable a new solution that does provide a much stronger “first signal” of strong, reliable authentication to any given online service’s authentication infrastructure that is not phishable, privacy-respecting, and cryptographically reliable. But most modern authentication systems will also incorporate what is typically referred to as “risk-based authentication” that will look at behavior-based characteristics in addition to the authentication credentials themselves. The FIDO Alliance recognizes the value of these systems but we do not produce requirements or guidance on how such systems should be used.
We note that there is an emerging array of biometric solutions in the market that rely on measurements of behavior, rather than “traditional” biometrics that focus on measuring the unique aspects of a person’s biometric sample (fingerprint, iris, etc.). As with all other forms of biometric authentication, some of these behavior-based biometrics are more reliable than others.The key distinguisher is whether that behavior-based biometric is able to measure a trait that has a high enough level of uniqueness.
All biometrics -- behavior-based and otherwise -- are not equal; the FIDO Alliance is researching the feasibility of launching a biometric testing program to validate that biometrics proposed for use in FIDO Authenticators meet thresholds for accuracy and robustness.
Note that FIDO specifications also ensure that privacy of biometrics is protected by requiring that biometrics never leave the device; under no circumstances are biometrics to be shared with or stored by online service providers. The FIDO Security Certification Program mentioned earlier as a way of testing how well a FIDO Authenticator protects the private keys, will also test how well that FIDO Authenticator, if biometric are used, protects the user’s biometric information from unauthorized access to the locally stored biometric templates.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
The independence of authentication elements is an essential question when considering strong customer authentication -- particularly when all authentication factors rely upon the traditional “shared secrets” model of credentials, such as passwords and one-time passcodes.
Given the risks associated with payments, it is understandable that the authors of this requirement would insist on the independence of the authentication elements. In an architecture when both the first and second factor are “shared secrets,” one would want to ensure that if the first channel (i.e., a web browser), were compromised by an attack that the second “secret” not be provided through that same compromised browser but instead be provided through an independent channel, such as a phone.
The proliferation of mobile devices -- where consumers expect to engage in secure commerce without carrying anything other than their device -- has presented significant new challenges to the model of having two distinct authentication elements. This challenge has been exacerbated by an increasing array of successful attacks on “shared secrets” credentials (phishing, man-in-the-middle), including ones supporting independent, multiple factors -- meaning that even if the practical challenges of requiring consumers to carry two separate elements could be overcome, the security risks would still be significant.
Fortunately for all parties considered, the state-of-the-art solution for online authentication is no longer dependent solely on the “shared secrets” model of passwords and one-time-passcodes. The state-of-the-art solution leverages architectures such as FIDO, where we use asymmetric cryptography for authentication, and do so in a way that is designed to address both modern security and mobility challenges, as well as consumer expectations.
The FIDO architecture is widely used today, with more than 100 million FIDO Certified devices already in market [2], and several firms using these devices to protect financial transactions. This points to a deployment pattern that meets (a) increased demand from users for transaction convenience and (b) the original security purpose of this independence requirement, albeit in an innovative way that facilitates market acceptance and delivers even greater security than what was likely envisioned by the authors of this requirement at the time it was drafted.
In the FIDO architecture the “secret” is never shared, only a cryptographic proof-of-possession of the secret is shared. In addition, the FIDO architecture takes advantage of Channel ID / Token Binding capabilities to mediate the risk of man-in-the-middle attacks. Given the market’s embrace advancement of a new, more secure authentication model, the original analysis of how to mediate attacks on payment services credentials, which drove the creation of this requirement, should be revisited.
We suggest the FIDO architecture (or other similar architectures) offers a truly “best of both worlds” solution to the problems that drove the creation of this requirement.
> With biometric solutions being used for “user verification” (a “what you are” authentication factor) we address increased market demand for greater user convenience than anything we have used for online payments before.
> With the FIDO privacy requirements, we ensure biometric data is never shared, addressing requirements by data protection authorities and consumer concerns about sharing biometric information online.
> With asymmetric cryptography at the heart of the security model, we address the security requirement designed to mitigate theft of payment service credentials by all known attacks that successfully harvest “shared secret” credentials, the same techniques that are behind 95% of all web app attacks that lead to data breach (per Verizon’s 2015 Data Breach Investigations Report [3]).
The result of this combination is a single-gesture, multi-factor authentication event (“what you are” -- the on-device biometric user verification step plus “what you have” -- the cryptographic proof-of-possession of the private key) packaged for consumers in a very simple user experience they are already familiar with since they likely use this same user experience to unlock their device several times per day.
We assert this is a far better outcome for all parties involved than explicit channel separation of “shared secret” credentials, as the requirement seems to anticipate. That being said, FIDO Authenticators often offer additional independence of authentication elements above-and-beyond what has been described above. We detail these Factors of Independence in the appendix attached to our response.
Note that the EBA is not alone in considering whether “traditional” multi-factor authentication solutions require a physically distinct, rather than merely logically separate, token. The U.S. government went through a similar process this past year, when it considered how to enable its agencies to extend the trust model of its Personal Identity Verification (PIV) smart cards to mobile devices. First launched in 2004, the PIV was designed for an era dominated by desktops, where the notion of an employee having to bring a separate physical token to log in made sense. Desktops themselves had little built-in security; the PIV smart card enabled users to bring strong security with them. The White House issued two policy memoranda for Federal agencies (OMB memoranda M-06-16 and M-07-16) that called for two-factor authentication solutions where “one of the two factors to be provided by a device that is separate from the device accessing the remote resource.”
However, with the move toward mobile devices -- most of which were not practical to use with the ISO 7816 smart card form factor -- the U.S. National Institute of Standards and Technology (NIST) issued new guidance in December, 2014 to agencies (Special Publication 800-157, “Guidelines for Derived Personal Identity Verification (PIV) Credentials” [4]), to provide the technical details for a system by which mobile devices such as smartphones and tablets are provisioned with strong credentials, allowing these credentials to take the place of the smart card for remote authentication to federal system. As part of this, NIST and the White House made clear that these two OMB memoranda would have to be written to remove the requirement that one factor be separate from the device accessing the resource, noting that “guidance will be updated by OMB to provide an alternative to current remote authentication policy.” 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 PIV-grade security without the need for a physically distinct token -- prompted the U.S. government to rethink its requirements in this area.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/certification/fido-certified/
[3] http://www.verizonenterprise.com/DBIR/2015/
[4] http://csrc.nist.gov/publications/nistbul/itlbul2014_12.pdf
One of the biggest challenges for Financial Institutions (FIs) who operate with a global footprint is interpreting and complying with the various mandated standards presented by the various governing bodies across multiple regions. Finding solutions to comply with these mandates can be a time consuming and costly effort for participating FIs to implement.
Several preeminent FIs are FIDO Alliance Board Members, and are providing proactive requirements to address concerns specific to the financial community. FIDO would help drive out a standard that could be easily adopted and implemented by the various FIs. By adopting FIDO within the EBA technical standards to define the model for authentication, FIs would be able to quickly react to changing regulations and reduce the costs associated with implementing those solutions. By leveraging FIDO Alliance specifications; the EBA could help establish a common pragmatic standard that all participating FIs could easily adopt.
With regards to “dynamic linking”, the FIDO UAF specification provides a feature called transaction confirmation. The use case for this feature is as follows: imagine a situation in which an online service wants the user to confirm a transaction (e.g., such as a payment) so that any tampering of a transaction message during its route to the end device display and back can be detected. If a FIDO UAF Authenticator is equipped with a transaction confirmation display, the FIDO UAF architecture makes sure that the system supports What You See is What You Sign mode (WYSIWYS). More details can be found in the UAF specifications available for download at [2]. As long as a financial services provider can associate the authentication operation with an account holder, then dynamic linking may be enabled through transaction confirmation.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/specifications/download/
See response to item #4 where we explain how FIDO-compliant implementations fulfill, and improve upon, the security requirements that drove the creation of the independence requirements.
Note we respond to all three questions 7, 8 and 9 around exemptions here:
The FIDO Alliance does not have views on particular exemptions to requirements for strong authentication.
The FIDO Alliance has 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.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
At a high level, the clarifications address important issues. We do note that the clarifications seem to focus on specific types of solutions; for those credential solutions that work differently, these clarifications may be less applicable.
From the FIDO Alliance’s perspective, to protect the user's personalized security credentials four steps are necessary:
(1) As a first step, the security goals and assumptions of the authentication protocol need to be documented to build the foundation for a solid design. For the FIDO U2F specification the documentation can be found at [2] and the respective text for FIDO UAF can be found at [3].
(2) Since the design of the authentication protocol impacts which parties have access to personalized security credentials the 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 [4]. FIDO protocols rely on widely deployed Internet security protocols and cryptographic algorithms.
(3) Third, implementations need to comply to the technical specifications. This compliance is accomplished in FIDO with the certification program described at [5].
(4) As a last step, products may voluntarily choose to go through a third-party security certification. The development of such a program is currently ongoing in the FIDO Alliance and is expected to be launched in 2016.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html
[3] https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-security-ref-v1.0-ps-20141208.html
[4] https://fidoalliance.org/resources/FIDO__Privacy_White_Paper_Jan_2016.pdf
[5] https://fidoalliance.org/certification/
As the use of multi-factor authentication has spread, so have attacks on some of the most popular methods. Some types of one-time password technologies, for example, have been shown to be vulnerable to malware, phishing attacks and man-in-the-middle attacks.
Google (a FIDO Alliance member) discussed the extent of the problem last summer, noting that these days, a “phisher can pretty successfully phish for an OTP just about as easily as they can a password” [2] and noted their shift to FIDO hardware-based solutions as the way to stop these targeted phishing attacks [3].
Phishing is rendered moot by FIDO’s use of long-proven asymmetric public key cryptography, where the private key is the only “secret,” and it is stored on the user’s Authenticator device. Only the public key is ever shared with the online service, resulting in no credential secrets ever being shared with servers, which renders the threat of credential theft from a data breach at the website or even phishing attack moot. The only way to attack a FIDO credential/private key is to attack the user’s personal device and particularly the Authenticator.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://www.youtube.com/watch?v=UBjEfpfZ8w0
[3] Note that Google had previously tried to drive two-factor login by offering OTP through both SMS and a free OTP app based on the OATH protocol; these comments reflect their experience with this technology.
“Enrolment” in the FIDO sense involves the process by which a security credential is first created on a device. We refer to this as the “registration” process [2]. During registration, FIDO Authenticators generate a public-private key pair directly on the device. One benefit of this approach is that it reduces the attack surface of the authentication solution; there is no need to generate a credential remotely, and thus, no issues associated with secure transmission or delivery of the credential.
Note that one FIDO Authenticator can generate multiple key pairs; FIDO specifications call for the Authenticator to create a new key pair specifically for each online application that invites the user to register FIDO credentials. This ensures that there is no information provided by the FIDO Authenticator or the FIDO protocols that could be used by different service providers to track the use of an authenticator across applications, websites, etc.
Note, however, that FIDO specifications do not describe or mandate what other application-specific data needs to be provided by the user during the initial registration phase since this varies heavily from use case to use case. We discuss one option for this in more detail in our response to question 19, exploring the way that identity proofing processes associated with eID cards might be leveraged for this purpose.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] There is a diagram of the registration process contained within our full response published at [1]
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 100 products from over 50 companies in just the first 9 months of operation; details are at [2].
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 only alternative we have seen proposed in the marketplace to certification is self-assessment, which we have observed leads to some level of abuse in some cases, either intentionally or unintentionally, by vendors advertising FIDO implementations that turn out to be non-compliant upon inspection.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/certification/
While other authentication solutions might offer a potential attack at various segments of the payment chain, FIDO specifically designed our specifications so that the only potential attack vector in the user-credential-authentication step is to steal the user’s device and then attempt to break the second factor. No credential secrets are ever shared with servers, which renders the threat of credential theft from a data breach moot. Thus, the only segment of the chain that offers an attack vector is the segment where use of a strong credential is first initiated. That said, FIDO specifications do not apply to other steps in the chain after authentication of the user’s credentials to the appropriate account with the payment service provider.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
The FIDO technical specifications are created based on building blocks developed primarily by other recognized standards developing organizations, such as the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C). The standardization process in the FIDO Alliance, as well as the process in the IETF and the W3C, follow the principles of open standards development.
The standards process is open to all interested and informed parties who choose to join the FIDO Alliance, participate through our Liaison Program, attend FIDO Alliance public events and webinars, participate in our free open developer forum, or provide written comment on our published specifications through our public website. Finalized specifications are published on the FIDO Alliance website at [2] and these documents are available for download at no cost. Furthermore, membership at the FIDO Alliance is not a prerequisite for deployment of FIDO implementations. Some of the FIDO Alliance members have also published their FIDO protocol implementations as open source and we expect more open source projects around FIDO specifications in the future.
We cannot provide feedback on the term ‘common’ since it is less well defined.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/specifications/download/
The FIDO Alliance is familiar with the e-IDAS initiative; the government 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.
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.
One challenge that eIDAS may have, in common with many public sector schemes, is gaining the level of visibility and “brand recognition” across the EU. It has taken many decades for currently recognised commercial brands to be accepted as effective “trust marks” in transactions and eIDAS will face similar challenges. One advantage of the FIDO ecosystem is that it leverages the existing trust relationships between the highly recognized brands that are implementing FIDO solutions, thus accelerating market acceptance of these new capabilities without any prerequisite branding campaign.
Cooperation between e-IDAS and FIDO Alliance would be mutually beneficial in advancing the goals of both initiatives.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
NA2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].At the core of FIDO specifications [2] is the generation of a public/private key pair on a FIDO Authenticator device where the private key is contained within, and protected by, the FIDO Authenticator [3]. Proof-of-possession of this private key is the basis for FIDO Authenticators’ capability to fulfill the possession requirements for strong customer authentication. We note that there are a range of technologies available for FIDO Authenticators to use to protect the private key from being exported from the user’s device.
The degree to which a FIDO Authenticator protects the FIDO authentication private key from theft or tampering is implementation-specific, but can be tested. It is for this type of testing, presumably performed by 3rd-party security labs, that FIDO Alliance is currently defining requirements; the Alliance will be launching a formal FIDO Security Certification Program later in 2016.
A well-protected private key cannot be exported from the device; nor can an attacker duplicate or spoof that key. Thus, any authentication ceremony which uses that key, subject to the service provider’s required level of assurance, proves possession of the device on which it was generated.
Because only the FIDO Authenticator itself contains the private key, the only practical way to attack that key is to attack the user’s personal device. When the FIDO Authenticator leverages modern technology for the protection of the private key, such as secure elements, Trusted Execution Environments (TEE) or TPM chips (which is the trend with consumer electronics today, especially mobile devices), the attacker must actually gain physical possession of that user’s device to even attempt an exploit. This type of attack does not scale and is quickly detectable as mobile devices are highly personal and quickly missed by the owner. Such an attack is therefore not economical from a cyber-crime perspective.
Even if an individual’s device is captured, the only way an attacker can unlock that key is through a second factor -- in the case of FIDO UAF [4] this would typically require the attacker to also have a spoof of the genuine user’s biometrics (though other options are available such as PIN codes), and in the case of FIDO U2F this would typically require the attacker to also have the first-factor credentials for the user’s account such as their username and password. Simply having possession of a FIDO Authenticator does not grant access to any account protected by that FIDO Authenticator, which is why all FIDO Authenticators are inherently multi-factor authenticators. When an adversary must steal someone’s device before launching an attack on their Authenticator, it materially changes the risk model.
Many FIDO-compliant solutions are further bolstered by the presence of a hardware-backed Attestation Key, present in every FIDO Authenticator of that make and model, that attests to the particulars of the device itself. This Attestation Key can be used by an online service provider (Relying Party) to understand what kind of technology (e.g., biometric type, hardware security element, etc.) is being used in that particular device. This Attestation Key provides an additional role in the chain of trust.
Some FIDO Authenticators go a step further and take advantage of the FIDO Metadata Service which is a mechanism for online services to reference a local cache of authenticator-manufacturer-provided metadata about the authenticator itself. This is a public service operated by the FIDO Alliance, optional for online services and authenticator vendors, that if used may help facilitate the exchange of relevant information that online service providers can use to make informed trust decisions when presented with a previously unknown FIDO Authenticator requesting registration.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/specifications/overview/
[3] An Authenticator is a logical component that may be contained in a device, such as in a physically secure execution environment (i.e., a Trusted Execution Environment (TEE) or Secure Element) in a smartphone or Trusted Platform Module (TPM) of a computer, or may reside in a separate physical device (e.g., a USB token with a Secure Element that can be attached to a laptop, or a smartwatch that is connected via Bluetooth Smart with another device).
[4] Note that version 1.0 of FIDO specifications includes two types of protocols: the Universal 2nd Factor (U2F) and Universal Authentication Framework (UAF); these protocols support two different use cases that will both be supported in the new FIDO 2.0 specifications, whose web browser and web server components have been submitted for formal standardization to the W3C. We discuss the two specifications in more detail in our Appendix which can be found in our full response available at [1].
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].The FIDO Alliance does not assert that there is any single “silver bullet” solution for authentication that is capable of supplanting all other authentication technology currently in operation. The FIDO specifications and associated testing programs enable a new solution that does provide a much stronger “first signal” of strong, reliable authentication to any given online service’s authentication infrastructure that is not phishable, privacy-respecting, and cryptographically reliable. But most modern authentication systems will also incorporate what is typically referred to as “risk-based authentication” that will look at behavior-based characteristics in addition to the authentication credentials themselves. The FIDO Alliance recognizes the value of these systems but we do not produce requirements or guidance on how such systems should be used.
We note that there is an emerging array of biometric solutions in the market that rely on measurements of behavior, rather than “traditional” biometrics that focus on measuring the unique aspects of a person’s biometric sample (fingerprint, iris, etc.). As with all other forms of biometric authentication, some of these behavior-based biometrics are more reliable than others.The key distinguisher is whether that behavior-based biometric is able to measure a trait that has a high enough level of uniqueness.
All biometrics -- behavior-based and otherwise -- are not equal; the FIDO Alliance is researching the feasibility of launching a biometric testing program to validate that biometrics proposed for use in FIDO Authenticators meet thresholds for accuracy and robustness.
Note that FIDO specifications also ensure that privacy of biometrics is protected by requiring that biometrics never leave the device; under no circumstances are biometrics to be shared with or stored by online service providers. The FIDO Security Certification Program mentioned earlier as a way of testing how well a FIDO Authenticator protects the private keys, will also test how well that FIDO Authenticator, if biometric are used, protects the user’s biometric information from unauthorized access to the locally stored biometric templates.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].The independence of authentication elements is an essential question when considering strong customer authentication -- particularly when all authentication factors rely upon the traditional “shared secrets” model of credentials, such as passwords and one-time passcodes.
Given the risks associated with payments, it is understandable that the authors of this requirement would insist on the independence of the authentication elements. In an architecture when both the first and second factor are “shared secrets,” one would want to ensure that if the first channel (i.e., a web browser), were compromised by an attack that the second “secret” not be provided through that same compromised browser but instead be provided through an independent channel, such as a phone.
The proliferation of mobile devices -- where consumers expect to engage in secure commerce without carrying anything other than their device -- has presented significant new challenges to the model of having two distinct authentication elements. This challenge has been exacerbated by an increasing array of successful attacks on “shared secrets” credentials (phishing, man-in-the-middle), including ones supporting independent, multiple factors -- meaning that even if the practical challenges of requiring consumers to carry two separate elements could be overcome, the security risks would still be significant.
Fortunately for all parties considered, the state-of-the-art solution for online authentication is no longer dependent solely on the “shared secrets” model of passwords and one-time-passcodes. The state-of-the-art solution leverages architectures such as FIDO, where we use asymmetric cryptography for authentication, and do so in a way that is designed to address both modern security and mobility challenges, as well as consumer expectations.
The FIDO architecture is widely used today, with more than 100 million FIDO Certified devices already in market [2], and several firms using these devices to protect financial transactions. This points to a deployment pattern that meets (a) increased demand from users for transaction convenience and (b) the original security purpose of this independence requirement, albeit in an innovative way that facilitates market acceptance and delivers even greater security than what was likely envisioned by the authors of this requirement at the time it was drafted.
In the FIDO architecture the “secret” is never shared, only a cryptographic proof-of-possession of the secret is shared. In addition, the FIDO architecture takes advantage of Channel ID / Token Binding capabilities to mediate the risk of man-in-the-middle attacks. Given the market’s embrace advancement of a new, more secure authentication model, the original analysis of how to mediate attacks on payment services credentials, which drove the creation of this requirement, should be revisited.
We suggest the FIDO architecture (or other similar architectures) offers a truly “best of both worlds” solution to the problems that drove the creation of this requirement.
> With biometric solutions being used for “user verification” (a “what you are” authentication factor) we address increased market demand for greater user convenience than anything we have used for online payments before.
> With the FIDO privacy requirements, we ensure biometric data is never shared, addressing requirements by data protection authorities and consumer concerns about sharing biometric information online.
> With asymmetric cryptography at the heart of the security model, we address the security requirement designed to mitigate theft of payment service credentials by all known attacks that successfully harvest “shared secret” credentials, the same techniques that are behind 95% of all web app attacks that lead to data breach (per Verizon’s 2015 Data Breach Investigations Report [3]).
The result of this combination is a single-gesture, multi-factor authentication event (“what you are” -- the on-device biometric user verification step plus “what you have” -- the cryptographic proof-of-possession of the private key) packaged for consumers in a very simple user experience they are already familiar with since they likely use this same user experience to unlock their device several times per day.
We assert this is a far better outcome for all parties involved than explicit channel separation of “shared secret” credentials, as the requirement seems to anticipate. That being said, FIDO Authenticators often offer additional independence of authentication elements above-and-beyond what has been described above. We detail these Factors of Independence in the appendix attached to our response.
Note that the EBA is not alone in considering whether “traditional” multi-factor authentication solutions require a physically distinct, rather than merely logically separate, token. The U.S. government went through a similar process this past year, when it considered how to enable its agencies to extend the trust model of its Personal Identity Verification (PIV) smart cards to mobile devices. First launched in 2004, the PIV was designed for an era dominated by desktops, where the notion of an employee having to bring a separate physical token to log in made sense. Desktops themselves had little built-in security; the PIV smart card enabled users to bring strong security with them. The White House issued two policy memoranda for Federal agencies (OMB memoranda M-06-16 and M-07-16) that called for two-factor authentication solutions where “one of the two factors to be provided by a device that is separate from the device accessing the remote resource.”
However, with the move toward mobile devices -- most of which were not practical to use with the ISO 7816 smart card form factor -- the U.S. National Institute of Standards and Technology (NIST) issued new guidance in December, 2014 to agencies (Special Publication 800-157, “Guidelines for Derived Personal Identity Verification (PIV) Credentials” [4]), to provide the technical details for a system by which mobile devices such as smartphones and tablets are provisioned with strong credentials, allowing these credentials to take the place of the smart card for remote authentication to federal system. As part of this, NIST and the White House made clear that these two OMB memoranda would have to be written to remove the requirement that one factor be separate from the device accessing the resource, noting that “guidance will be updated by OMB to provide an alternative to current remote authentication policy.” 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 PIV-grade security without the need for a physically distinct token -- prompted the U.S. government to rethink its requirements in this area.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/certification/fido-certified/
[3] http://www.verizonenterprise.com/DBIR/2015/
[4] http://csrc.nist.gov/publications/nistbul/itlbul2014_12.pdf
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].One of the biggest challenges for Financial Institutions (FIs) who operate with a global footprint is interpreting and complying with the various mandated standards presented by the various governing bodies across multiple regions. Finding solutions to comply with these mandates can be a time consuming and costly effort for participating FIs to implement.
Several preeminent FIs are FIDO Alliance Board Members, and are providing proactive requirements to address concerns specific to the financial community. FIDO would help drive out a standard that could be easily adopted and implemented by the various FIs. By adopting FIDO within the EBA technical standards to define the model for authentication, FIs would be able to quickly react to changing regulations and reduce the costs associated with implementing those solutions. By leveraging FIDO Alliance specifications; the EBA could help establish a common pragmatic standard that all participating FIs could easily adopt.
With regards to “dynamic linking”, the FIDO UAF specification provides a feature called transaction confirmation. The use case for this feature is as follows: imagine a situation in which an online service wants the user to confirm a transaction (e.g., such as a payment) so that any tampering of a transaction message during its route to the end device display and back can be detected. If a FIDO UAF Authenticator is equipped with a transaction confirmation display, the FIDO UAF architecture makes sure that the system supports What You See is What You Sign mode (WYSIWYS). More details can be found in the UAF specifications available for download at [2]. As long as a financial services provider can associate the authentication operation with an account holder, then dynamic linking may be enabled through transaction confirmation.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/specifications/download/
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
See response to item #5 where we seek further clarification regarding “dynamic linking” and the potential relationship to transaction confirmation available in FIDO UAF specifications.See response to item #4 where we explain how FIDO-compliant implementations fulfill, and improve upon, the security requirements that drove the creation of the independence requirements.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
See response to item #9.8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
See response to item #9.9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].Note we respond to all three questions 7, 8 and 9 around exemptions here:
The FIDO Alliance does not have views on particular exemptions to requirements for strong authentication.
The FIDO Alliance has 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.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].At a high level, the clarifications address important issues. We do note that the clarifications seem to focus on specific types of solutions; for those credential solutions that work differently, these clarifications may be less applicable.
From the FIDO Alliance’s perspective, to protect the user's personalized security credentials four steps are necessary:
(1) As a first step, the security goals and assumptions of the authentication protocol need to be documented to build the foundation for a solid design. For the FIDO U2F specification the documentation can be found at [2] and the respective text for FIDO UAF can be found at [3].
(2) Since the design of the authentication protocol impacts which parties have access to personalized security credentials the 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 [4]. FIDO protocols rely on widely deployed Internet security protocols and cryptographic algorithms.
(3) Third, implementations need to comply to the technical specifications. This compliance is accomplished in FIDO with the certification program described at [5].
(4) As a last step, products may voluntarily choose to go through a third-party security certification. The development of such a program is currently ongoing in the FIDO Alliance and is expected to be launched in 2016.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html
[3] https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-security-ref-v1.0-ps-20141208.html
[4] https://fidoalliance.org/resources/FIDO__Privacy_White_Paper_Jan_2016.pdf
[5] https://fidoalliance.org/certification/
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].As the use of multi-factor authentication has spread, so have attacks on some of the most popular methods. Some types of one-time password technologies, for example, have been shown to be vulnerable to malware, phishing attacks and man-in-the-middle attacks.
Google (a FIDO Alliance member) discussed the extent of the problem last summer, noting that these days, a “phisher can pretty successfully phish for an OTP just about as easily as they can a password” [2] and noted their shift to FIDO hardware-based solutions as the way to stop these targeted phishing attacks [3].
Phishing is rendered moot by FIDO’s use of long-proven asymmetric public key cryptography, where the private key is the only “secret,” and it is stored on the user’s Authenticator device. Only the public key is ever shared with the online service, resulting in no credential secrets ever being shared with servers, which renders the threat of credential theft from a data breach at the website or even phishing attack moot. The only way to attack a FIDO credential/private key is to attack the user’s personal device and particularly the Authenticator.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://www.youtube.com/watch?v=UBjEfpfZ8w0
[3] Note that Google had previously tried to drive two-factor login by offering OTP through both SMS and a free OTP app based on the OATH protocol; these comments reflect their experience with this technology.
12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].“Enrolment” in the FIDO sense involves the process by which a security credential is first created on a device. We refer to this as the “registration” process [2]. During registration, FIDO Authenticators generate a public-private key pair directly on the device. One benefit of this approach is that it reduces the attack surface of the authentication solution; there is no need to generate a credential remotely, and thus, no issues associated with secure transmission or delivery of the credential.
Note that one FIDO Authenticator can generate multiple key pairs; FIDO specifications call for the Authenticator to create a new key pair specifically for each online application that invites the user to register FIDO credentials. This ensures that there is no information provided by the FIDO Authenticator or the FIDO protocols that could be used by different service providers to track the use of an authenticator across applications, websites, etc.
Note, however, that FIDO specifications do not describe or mandate what other application-specific data needs to be provided by the user during the initial registration phase since this varies heavily from use case to use case. We discuss one option for this in more detail in our response to question 19, exploring the way that identity proofing processes associated with eID cards might be leveraged for this purpose.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] There is a diagram of the registration process contained within our full response published at [1]
13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].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 100 products from over 50 companies in just the first 9 months of operation; details are at [2].
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 only alternative we have seen proposed in the marketplace to certification is self-assessment, which we have observed leads to some level of abuse in some cases, either intentionally or unintentionally, by vendors advertising FIDO implementations that turn out to be non-compliant upon inspection.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/certification/
14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].While other authentication solutions might offer a potential attack at various segments of the payment chain, FIDO specifically designed our specifications so that the only potential attack vector in the user-credential-authentication step is to steal the user’s device and then attempt to break the second factor. No credential secrets are ever shared with servers, which renders the threat of credential theft from a data breach moot. Thus, the only segment of the chain that offers an attack vector is the segment where use of a strong credential is first initiated. That said, FIDO specifications do not apply to other steps in the chain after authentication of the user’s credentials to the appropriate account with the payment service provider.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].The FIDO technical specifications are created based on building blocks developed primarily by other recognized standards developing organizations, such as the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C). The standardization process in the FIDO Alliance, as well as the process in the IETF and the W3C, follow the principles of open standards development.
The standards process is open to all interested and informed parties who choose to join the FIDO Alliance, participate through our Liaison Program, attend FIDO Alliance public events and webinars, participate in our free open developer forum, or provide written comment on our published specifications through our public website. Finalized specifications are published on the FIDO Alliance website at [2] and these documents are available for download at no cost. Furthermore, membership at the FIDO Alliance is not a prerequisite for deployment of FIDO implementations. Some of the FIDO Alliance members have also published their FIDO protocol implementations as open source and we expect more open source projects around FIDO specifications in the future.
We cannot provide feedback on the term ‘common’ since it is less well defined.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf
[2] https://fidoalliance.org/specifications/download/
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
NA17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
NA18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
NA19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
Please note this answer has been extracted from our complete response which we were not able to provide due to the submission requirements of this form. To see our complete response in context, with introductory and summary information not included in our online form submission, please download our full response here [1].The FIDO Alliance is familiar with the e-IDAS initiative; the government 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.
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.
One challenge that eIDAS may have, in common with many public sector schemes, is gaining the level of visibility and “brand recognition” across the EU. It has taken many decades for currently recognised commercial brands to be accepted as effective “trust marks” in transactions and eIDAS will face similar challenges. One advantage of the FIDO ecosystem is that it leverages the existing trust relationships between the highly recognized brands that are implementing FIDO solutions, thus accelerating market acceptance of these new capabilities without any prerequisite branding campaign.
Cooperation between e-IDAS and FIDO Alliance would be mutually beneficial in advancing the goals of both initiatives.
[1] https://fidoalliance.org/resources/FIDO_EBA_Response_2016-02-08.pdf