Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Data can be strong means of authentication and a high level of trust if generated by trustworthy execution environment, such as a smartcards with a display. This must be considered by RTS as an appropriate possession element that is controlled by PSU.
To summarize:
1. Both physical possession element and data may be acceptable dependent on the risk appetite of the payment service provider and the nature of the transaction.
2. The real issues are the integrity of the element generating this authentication data and the protection mechanisms for this data so that they cannot be inadvertently altered in transit.
3. For high risk transactions, the stronger level of authentication could be achieved through a tamper resistant physical device storing authentication and financial application data associated with a Trusted User Interface for the PSU to enter and/or capture user verification data. These security properties ensure a high level of control by the PSU of data generated for strong authentication purposes. This physical device shall undergo a security evaluation according to an independent and recognized security evaluation process.
For Case 1:
Behaviour-based characteristics provide means of risk mitigation in the context of user authentication and may therefore enhance other authentication methods, especially those with a lower level of trust (i.e. without secure hardware anchors). They can thus be part of a comprehensive risk management strategy. It is however not recommendable to base authentication solely on behaviour- and context-based data. From a security point of view the issue of trust of authentication credentials is merely shifted to the question of trust into context data. Generally, compromised user devices can provide compromised context and behavioural data. It is therefore essential to guarantee the integrity and authenticity of the collected data. Hardware-based trust anchors on the user devices or tokens may support establishing sufficient integrity proofs. In addition, collecting a broad variety of user-related context data might impose privacy risks which have to be addressed.
For Case 2:
Human’ behaviour-based characteristics (e.g. keystroke dynamics) may not be considered as of today to be “inherence” element in sense of §29 but may be considered for a use in conjunction with risk-based decision models. Behavioral biometrics lack of the sufficient maturity to replace any of the remainder three factors, including “inherence” physiological biometrics. Behavioural biometrics are learned over time and depends on the state of mind of the person or might even be subject to deliberate alteration. In physiological biometrics we consider that the one-time captured information is sufficient to compare biometrics samples. For behavioural biometrics a single sample may give no information enough about the person being recognized. It’s rather the temporal variation of the sample that provides with information that changes from consecutive patterns. Statistically, we are in the random process domain, highly complex to manage and at present less reliable.
- use an additional, independent device for receiving or generating authentication credentials (e.g. an external token),
- perform the authentication/authorization and web session management both in a trusted environment (e.g. a hardware token or a TEE), or
- at least execute the authentication/authorization or OTP generation in a trusted environment which may be located on the same user device but which is fully separated from the normal OS (i.e. a Trusted Execution Environment).
The challenge is the design of security architecture for strong authentication, enabling the joint security evaluation of all the hardware and/or software mobile components involved in the generation of the authentication data.
On the other hand, the Black Hat conference in August 2015 announced a dramatic increase in number of deployed malware applications. Malware may be designed to take remote control of a mobile device and generate unauthorized payment orders by impersonating the legitimate customer. The problem there is that the “possession factor” (the mobile) is used to enter the “knowledge-based” factor and the mobile may be controlled remotely if successfully attacked. Our recommendation is not to use static “knowledge” elements (e.g. PIN or a password) on devices combining multiple authentication factors (like mobile devices) unless a certified trusted user interface is implemented.
As an example, secure payment authentication solutions available today, e.g. 3DS with SMS, Virtual card numbers, and display card with dynamic cryptogram provide a good level of protection against on-line fraud. Such solutions should be included in Dynamic Linking as they can be used in combination with smart applications implemented on a mobile phone for example.
Independence and dynamic linking for mobile devices can also be ensured if coupled with Data generated by independent non-electronically linked tokens such as smartcards with a display, that the PSU can enter using the user interface of the mobile
Case 1 (based on recitals 41 & 42): The EBA inquires on which types of financial transactions (“low risk”) the strong authentication requirements could be relaxed.
Case 2 (based on recitals 38 & 39): The EBA seems rather to inquire on which personal payment devices could be exempted of the strict definition of “strong authentication” but yet be somehow acceptable in a strong authentication context.
Case 1. According to the exception regime as per Article 98.3, PSD2 refers to a transaction context rather than to particular authentication methods. In this scenario, SPA considers that the examples provided in recital 42. are clear and sufficient.
Case 2. For internet payments, it is important to include in the exemptions effective authentication solutions that are either in deployment or massively deployed already. Solutions that provide protection against replay attacks such as 3DS with SMS, dynamic virtual card number, or display card with a dynamic cryptogram should be included in the exemptions.
With respect additional exemption factors we confirm that recitals 41. and 42. provide with a sufficient rationale to back the “proportional-to-risk” principle applicable for the exemption regime for well-justified low-risk scenarios. SPA considers that if the objective is to improve the security of online payment services, the regime exemption should not be extended much and that strong authentication as a general rule should apply.
In relation with specific authentication methods that could be used in a secure online payment context, the RTS might precise the following:
Authentication solution implementing a physical factor “something you have” (a card, a smartphone) with an embedded secure element enabling the generation or use of one-time-password or ephemeral secrets (usable in a very short time) should be considered in exemptions. These solutions are considered safe even if they are not meeting the strict definition of strong authentication factors.
The inclusion of these criteria in exemptions would allow 3D Secure with SMS and display card with a dynamic cryptogram to be accepted as authentication solutions for internet payment.
In addition, the FIDO protocol offers a strong and privacy friendly authentication with context specific suitable security level which can be also combined with federation protocols (e.g. SAML, OpenID Connect). For SIM-based mobile devices the GSMA Mobile Connect protocol also offers strong authentication with context specific suitable security level.
Other relevant standards would include the Global Platform Secure Channel Protocol, EMVCo Next Gen including privacy protocol, and ISO 12812 on Mobile Financial Services.
For the efficient coordination of all these efforts and other standardization needs identified by the payments industry (for instance those identified by the ERPB), SPA considers that the creation of a European Standardization Body for Retail Payments could be considered by the EBA. This new standardization body might be responsible for the maintenance of the regulatory technical standards and for the regular publication of guidelines for implementation by the entities (ASPSP, PIS/AIS eventually TTP) involved in this new categories of internet payment services.
Therefore, we agree with respect to the eID, customer authentication, and secure communication the related standards could be used for PSD2 as well regarding the addressed matters. Yet, regarding the requirement “confidentiality” of communication there is no direct reference inside the e-IDAS regulation, but only in an implicit way referring to privacy in general which does actually imply a confidential transfer of communication.
Having precised the above points, SPA also outlines that the retail payments market is in a strong evolution stage, that it matters to foster innovation, and that any application of the e-IDAS framework, should not restrain future technological innovation.
Qualified trusted services may include:
Generation of session keys for communication between authenticated parties (ASPSP, PIS/AIS).
ID & Authentication services to comply with AML & KYC requirements.
Generation and validation of certificates for authentication and qualified digital signature purposes.
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.
No, the clarification proposed by the EBA should cover all relevant aspects.2. 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?
In order to provide strong means of authentication and a high level of trust it is preferable to use hardware-supported execution environments with a sufficient tamper resistance. These could be smartcards, USB tokens, NFC tokens or Bluetooth Low Energy (BLE) tokens with tamper resistant security ICs. For a moderate level of trust, Trusted Execution Environments (TEEs) with a hardware-supported root of trust as specified by Global Platform could be used. For lower levels of trust the use of pure software-based solutions may be acceptable. However, due to the high risk of software-based attacks and cloning of data it is strongly recommended to only allow software solutions which provide enhanced protection methods. These could include code-obfuscation, encryption, Whitebox Cryptography with an appropriate key management, device binding, and root detection (mobile devices). A standard software implementation without further protection will not provide a sufficient level of trust and security. It is also highly recommended to use software-protected solutions only in conjunction with tokenization (e.g. as defined by EMVCo) or alternate PAN (Primary Account Number) which minimizes the risk of stolen or cloned user credentials. The tokenization shall occur on a highly secured server and provide a limited number of payment keys (e.g. single-use keys) to the client device.Data can be strong means of authentication and a high level of trust if generated by trustworthy execution environment, such as a smartcards with a display. This must be considered by RTS as an appropriate possession element that is controlled by PSU.
To summarize:
1. Both physical possession element and data may be acceptable dependent on the risk appetite of the payment service provider and the nature of the transaction.
2. The real issues are the integrity of the element generating this authentication data and the protection mechanisms for this data so that they cannot be inadvertently altered in transit.
3. For high risk transactions, the stronger level of authentication could be achieved through a tamper resistant physical device storing authentication and financial application data associated with a Trusted User Interface for the PSU to enter and/or capture user verification data. These security properties ensure a high level of control by the PSU of data generated for strong authentication purposes. This physical device shall undergo a security evaluation according to an independent and recognized security evaluation process.
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?
This question is in SPA´s opinion not clearly formulated: Does EBA rather refer to expected behavioural consumer patterns when using a payment service? (Case 1) Or does EBA refer to behavioural biometrics (e.g., keystroke dynamics, handwritten signature…)? (Case 2)For Case 1:
Behaviour-based characteristics provide means of risk mitigation in the context of user authentication and may therefore enhance other authentication methods, especially those with a lower level of trust (i.e. without secure hardware anchors). They can thus be part of a comprehensive risk management strategy. It is however not recommendable to base authentication solely on behaviour- and context-based data. From a security point of view the issue of trust of authentication credentials is merely shifted to the question of trust into context data. Generally, compromised user devices can provide compromised context and behavioural data. It is therefore essential to guarantee the integrity and authenticity of the collected data. Hardware-based trust anchors on the user devices or tokens may support establishing sufficient integrity proofs. In addition, collecting a broad variety of user-related context data might impose privacy risks which have to be addressed.
For Case 2:
Human’ behaviour-based characteristics (e.g. keystroke dynamics) may not be considered as of today to be “inherence” element in sense of §29 but may be considered for a use in conjunction with risk-based decision models. Behavioral biometrics lack of the sufficient maturity to replace any of the remainder three factors, including “inherence” physiological biometrics. Behavioural biometrics are learned over time and depends on the state of mind of the person or might even be subject to deliberate alteration. In physiological biometrics we consider that the one-time captured information is sufficient to compare biometrics samples. For behavioural biometrics a single sample may give no information enough about the person being recognized. It’s rather the temporal variation of the sample that provides with information that changes from consecutive patterns. Statistically, we are in the random process domain, highly complex to manage and at present less reliable.
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)?
Based on the definition of strong authentication as used in the PSD2, the two or more factors for authentication shall be independent. Depending on the chosen authentication method and the security of the execution environment it is therefore indeed an issue if the same execution environment is chosen for storing authentication credentials and managing the web session for a payment transaction. If for example an SMS-OTP based authentication is performed on a mobile device on which the web session is active for the remote payment then the OTP could be phished and transaction details modified. This has already been proven by real attacks. It is therefore recommendable to either- use an additional, independent device for receiving or generating authentication credentials (e.g. an external token),
- perform the authentication/authorization and web session management both in a trusted environment (e.g. a hardware token or a TEE), or
- at least execute the authentication/authorization or OTP generation in a trusted environment which may be located on the same user device but which is fully separated from the normal OS (i.e. a Trusted Execution Environment).
The challenge is the design of security architecture for strong authentication, enabling the joint security evaluation of all the hardware and/or software mobile components involved in the generation of the authentication data.
On the other hand, the Black Hat conference in August 2015 announced a dramatic increase in number of deployed malware applications. Malware may be designed to take remote control of a mobile device and generate unauthorized payment orders by impersonating the legitimate customer. The problem there is that the “possession factor” (the mobile) is used to enter the “knowledge-based” factor and the mobile may be controlled remotely if successfully attacked. Our recommendation is not to use static “knowledge” elements (e.g. PIN or a password) on devices combining multiple authentication factors (like mobile devices) unless a certified trusted user interface is implemented.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
The use of dynamic elements and dynamic linking is quite common in standardized authentication/ authorization protocols. It should therefore not impose specific challenges if the generation of response data using cryptographic user credentials (e.g. an electronic signature of dynamic transaction data or an OTP generation based on dynamic transaction data and a user key) is done in a trustworthy environment. For untrusted environments (e.g. a mobile device or a PC/Laptop) dynamic session and/or transaction data may be intercepted and modified by an attacker. It is therefore advisable to link session and transaction data dynamically to mitigate the risk.As an example, secure payment authentication solutions available today, e.g. 3DS with SMS, Virtual card numbers, and display card with dynamic cryptogram provide a good level of protection against on-line fraud. Such solutions should be included in Dynamic Linking as they can be used in combination with smart applications implemented on a mobile phone for example.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
For mobile devices the objectives of independence and dynamic linking are fulfilled by external hardware security tokens coupled via NFC, Bluetooth or USB (e.g. contactless smartcards) and by Trusted Execution Environments as specified by Global Platform which have a hardware-anchored root of trust and an execution environment fully separated from the application processor and normal OS).Independence and dynamic linking for mobile devices can also be ensured if coupled with Data generated by independent non-electronically linked tokens such as smartcards with a display, that the PSU can enter using the user interface of the mobile
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
SPA considers that the recitals 37. to 45. address different issues and therefore the questions 7. and 8. could be interpreted differently:Case 1 (based on recitals 41 & 42): The EBA inquires on which types of financial transactions (“low risk”) the strong authentication requirements could be relaxed.
Case 2 (based on recitals 38 & 39): The EBA seems rather to inquire on which personal payment devices could be exempted of the strict definition of “strong authentication” but yet be somehow acceptable in a strong authentication context.
Case 1. According to the exception regime as per Article 98.3, PSD2 refers to a transaction context rather than to particular authentication methods. In this scenario, SPA considers that the examples provided in recital 42. are clear and sufficient.
Case 2. For internet payments, it is important to include in the exemptions effective authentication solutions that are either in deployment or massively deployed already. Solutions that provide protection against replay attacks such as 3DS with SMS, dynamic virtual card number, or display card with a dynamic cryptogram should be included in the exemptions.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
Refer to our answer to question 7.With respect additional exemption factors we confirm that recitals 41. and 42. provide with a sufficient rationale to back the “proportional-to-risk” principle applicable for the exemption regime for well-justified low-risk scenarios. SPA considers that if the objective is to improve the security of online payment services, the regime exemption should not be extended much and that strong authentication as a general rule should apply.
In relation with specific authentication methods that could be used in a secure online payment context, the RTS might precise the following:
Authentication solution implementing a physical factor “something you have” (a card, a smartphone) with an embedded secure element enabling the generation or use of one-time-password or ephemeral secrets (usable in a very short time) should be considered in exemptions. These solutions are considered safe even if they are not meeting the strict definition of strong authentication factors.
The inclusion of these criteria in exemptions would allow 3D Secure with SMS and display card with a dynamic cryptogram to be accepted as authentication solutions for internet payment.
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?
As described above, the various client side authentication tokens and execution environments provide a different level of trust and security. These different levels are already reflected in various standards and regulations, including the e-IDAS regulation. It should be considered to specify a minimum level of trust for a certain type of transaction and/or to request additional risk management steps if a solution with a low level of trust (e.g. software-based) is used.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Yes, the clarification is reasonable and addresses all relevant topics.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
If credentials aIf credentials are stored in unprotected environments (e.g. mobile device or PC/Laptop) there should be a clear revocation procedure available in case the device is lost or stolen. Since these kinds of devices do not provide any protection against cloning attacks it is recommendable to request measures to mitigate and detect cloning of user credentials. When credentials (or communication involving credentials) are stolen or intercepted there may arise privacy risks due to traceability and linkability. The storage and usage of credentials shall therefore be in compliance with existing privacy regulations, e.g. the new European Data Protection regulation.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?
It is recommended to align the enrolment/provisioning of authentication credentials with existing personalisation processes for payment products/solutions. In case of hardware tokens (i.e. payment cards) this includes the generation and provisioning of credentials in highly secure and certified environments with end-to-end protection. For mobile channels, Trusted Service Management (TSM) solutions exist that provide a highly secure Over the Air (OTA) provisioning (e.g. as used for SIM/UICC management and subscription management). It is recommended to request similar standards for authentication credentials as well, especially the generation of credentials in a trusted and secure environment, the end-to-end protection during transport/provisioning including strong mutual authentication, and the verification of integrity. For mobile devices it is additionally recommended to issue only restricted credentials (i.e. with a limited number of transactions and bound to a specific hardware, see question 2) if no hardware supported security environments are available.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?
For security critical applications the evaluation/certification by third parties has a long and successful track record in providing trust into the certified solutions. Since strong authentication solutions affect security as well as privacy topics it is recommendable to request third party evaluation/certification for these solutions as well. The resulting effort should be in line with the associated risks. As an example, a Common Criteria (CC) protection profile would offer technology-independent security requirements that could be evaluated with specified Evaluation Assurance Level (EAL).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?
The highest risks are to be expected for remote communication use cases (e.g. online payment) via insecure channels (e.g. the internet). Most issues can be expected on the client side since user devices may be compromised and users can be subject to social and phishing attacks. It is therefore recommendable to request appropriate device/ token security with high tamper resistance as well as protocols that are resistant to phishing and, man-in-the-middle attacks. If user credentials are stored on the server side or generated for one-time use (e.g. with tokenisation) then the server shall provide sufficient security as well. End-to-end protection is recommended for enrolment/provisioning as well as for the token/client device/server communication chain. Another high-risk area will be the generation and provisioning of credentials, if no secure and certified environment (data centre) is used in conjunction with an end-to-end secured transport channel.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?
The clarifications are well explained and seem suitable. 63d-f request minimum functionality requirements, security controls and technical requirements that should apply. This will also be possible if these standards are technology neutral and therefore not linked to specific technology solutions, which on the other hand could offer an appropriate guide to practical implementation. A solution could be to offer practical implementation guidelines regarding specific technologies inside respective profiles as part of the standards e.g. inside a (normative) annex.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?
As mentioned in the answer to question 15, these standards could contain respective profiles which offer practical implementation guidelines regarding specific technologies.17. 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?
The recently published e-IDAS specification 1.0 together with the e-IDAS token specification BSI /ANSSI TR 03110 as respective profile containing the use of tamper resistant user token for storage and use of secure user credentials reflect as well privacy requirements in a suitable and comprehensive way. Therefore, this standard could be valuated as an appropriate standard for eID management, secure communication and strong authentication with very high security level. A profile including implementations for Secure Elements (SE) is the EN 419212 standard for SE used as qualified signature/ seal creation devices would additionally be appropriate for web authentication, secure communication and confidentiality services with very high level of assurance.In addition, the FIDO protocol offers a strong and privacy friendly authentication with context specific suitable security level which can be also combined with federation protocols (e.g. SAML, OpenID Connect). For SIM-based mobile devices the GSMA Mobile Connect protocol also offers strong authentication with context specific suitable security level.
Other relevant standards would include the Global Platform Secure Channel Protocol, EMVCo Next Gen including privacy protocol, and ISO 12812 on Mobile Financial Services.
18. 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)?
Open standards could ensure other innovative business models and solutions and can enhance existing ones. They have to comply with other regulations and directives in Europe as e-IDAS and the Data Protection Regulation and therefore could face new requirements. As an example, the storage and usage of credentials shall be in compliance with existing privacy regulations, e.g. the new European Data Protection regulation. The requirements should be designed and maintained openly (access to everyone), in a flexible and scalable way (depending on the risk of the credentials / assets to be protected) and cover different technical implementations. They should be reviewed on a regular basis to support new technologies as well as new attack scenarios.For the efficient coordination of all these efforts and other standardization needs identified by the payments industry (for instance those identified by the ERPB), SPA considers that the creation of a European Standardization Body for Retail Payments could be considered by the EBA. This new standardization body might be responsible for the maintenance of the regulatory technical standards and for the regular publication of guidelines for implementation by the entities (ASPSP, PIS/AIS eventually TTP) involved in this new categories of internet payment services.
19. 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.
e-IDAS is the first attempt to harmonize an interoperable framework for the exchange of electronic credentials between citizens and systems of different EU member states. There are evident commonalities in the kind of security issues that e-IDAS and PSD2 are addressing.Therefore, we agree with respect to the eID, customer authentication, and secure communication the related standards could be used for PSD2 as well regarding the addressed matters. Yet, regarding the requirement “confidentiality” of communication there is no direct reference inside the e-IDAS regulation, but only in an implicit way referring to privacy in general which does actually imply a confidential transfer of communication.
Having precised the above points, SPA also outlines that the retail payments market is in a strong evolution stage, that it matters to foster innovation, and that any application of the e-IDAS framework, should not restrain future technological innovation.
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
As mentioned above, together with the referred generic privacy requirement, the qualified trust services, especially the seal services, are described very explicitly fulfilling data originality and data integrity to be applied for legal persons as e.g. AIS, PIS and ASPSDs. The gain of this new concept is that qualified seals are accepted as such European–wide and cannot be interpreted differently as it was the case with qualified signatures before, as substitute for “handwritten signatures”.Qualified trusted services may include:
Generation of session keys for communication between authenticated parties (ASPSP, PIS/AIS).
ID & Authentication services to comply with AML & KYC requirements.
Generation and validation of certificates for authentication and qualified digital signature purposes.