Giesecke & Devrient , München

No, the clarification proposed by the EBA should cover all relevant aspects.
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.
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.
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 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.
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).
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.
Yes, the clarification is reasonable and addresses all relevant topics.
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.
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.
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).
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.
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.
As mentioned in the answer to question 15, these standards could contain respective profiles which offer practical implementation guidelines regarding specific technologies.
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.
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 eIDAS 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.
Yes, 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 eIDAS regulation, but only in an implicit way referring to privacy in general which does actual imply a confidential transfer of communication.
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”.
Yes
[Small and medium-sized enterprises (SMEs)"]"
[Issuing of payment instruments and/or acquiring of payment transactions"]"
Gisela.Meister@gi-de.com
Dr. Gisela Meister
++49 89 4119 1931
Yes