Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
- 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).
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).
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).
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.
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 Mobile Payment.
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.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?
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.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).
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.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).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 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 likability. 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).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).
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 eIDAS specification 1.0 together with the eIDAS 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, confidentiality services as well as privacy functionality with very high level of assurance. The latter is aligned with the Draft ISO/IEC19286 “Privacy enhancing protocols and services“.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 Mobile Payment.