Submission #85

Primary tabs

View(active tab)

Federal Office for Information Security (Germany)

Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?

BSI does not agree with the statement in point 29 stating that behavioural data cannot be considered as a stand alone inherence element in the first place. From BSI perspective no biometric mechanisms shall be excluded. The development of biometric mechanisms is still ongoing. There are no well-established standards to compare the security level of biometric mechanisms so far and therefore no technology shall be excluded a priori.

BSI recommends the following extension: „The use of the elements of strong customer authentication referred to in Article 3, 4 and 5 shall be subject to procedures in terms of the technology, algorithms and parameters, ensuring that the breach of one of the elements does not compromise the reliability of the other elements unless one element is resistant against attacks with high attack potential.” E.g. for smart cards high assurance levels (e.g. Common Criteria Evaluation Assurance Level 4+) are usual for hardware and software. Because of the high protection level the independence is given if the password (knowledge) is verified by the smart card (ownership). Knowledge is not compromised if the smart card is lost because the PIN practically cannot be read out the smart card and therefore article 6, item 1 is met.

The term “trusted execution environment” is defined by GlobalPlatform for a specific technology. BSI recommends therefore a more generic term. BSI supposes the following change: “a. the implementation of a separated environment to protect authentication or binding procedures from other applications inside the multi-purpose device”. Any technology term should not be used in the RTS, this holds also for TLS.

Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.

Dynamic linking shall require the authentication code to be the result of a cryptographic operation on payee and amount.

Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant? No comment.

Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS? No comment.

Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?

An interpretation of chapter 2 could be that payment service provider are enforced not to use Strong Customer Authentication if one of the listed exemptions applies. From BSI perspective exemptions are acceptable based on a risk analysis. However, it is not acceptable to enforce not to use Strong Customer Authentication if the exemption applies. As an example a risk sensitive customer should have the choice to require Strong Customer Authentication for any access to his account. An ASPSP should have the choice to offer this service to the customer. If payment transactions without Strong Customer Authentication may lead to above-average loss, the PSP shall have the choice to enforce Strong Customer Authentication for such transactions.
Therefore BSI recommends to add “The usage of the listed exemptions is not mandatory”.

Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS? No comments.

Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?

PSP certificates issued according to Article 20 have to be revoked as soon as the authority withdraws the listing of the PSP.

The application of screen scraping leads to security risks for the customer. From BSI perspective third party PSP shall not be allowed to use screen scraping any more as soon as the interface according to article 20 is fully available for the third-party PSP. Instead, as soon as the interface according to article 20 is fully available, the third-party PSP shall be enforced to use that interface which allows the third-party PSP to access all needed data but not more.

Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards? No comment.

Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?

BSI welcomes the requirement to use cryptographic certificates for the identification of third party PSPs. However, website certificates seems not to be the right certificate type for this purpose. From BSI perspective the third party PSP as client is identified at the ASPSP as server thus client certificates are needed. Website certificates are server certificates which corresponds to the opposite, i.e. the server authentication. BSI suggests to consider instead electronic seals which are defined in chapter 5 of the eIDAS regulation.

From BSI perspective attributes according to article 20, item 3, are required to enforce the identification of the third-party PSP. BSI appreciates therefore the definition of these attributes. It has to be noted that these attributes are not part of the eIDAS regulation. Therefore a common security policy is required to reach interoperability and an adequate common security level. The common security policy has to be implemented by all parties involved in the processing of the certificates and the related attributes, especially by the trusted service provider. As already remarked,
e.g. the policy shall cover how PSP certificates issued according to Article 20 are revoked as soon as the authority withdraws the listing of the PSP. Other aspects may be part of the common security policy.

Certificate revocation lists and online status requests shall be supported by trusted service provider issuing certificates according to article 20 in an efficient way. Real time checking of the validity of the certificate shall be possible.

Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency. No comment.

Please select which category best describes you and/or your organisation [Public administration"]"

Please select which category best describes the services provided by you/your organisation [Other"]"

If you selected "Other", please provide details

The German Federal Office for Information Security (German BSI) investigates security risks associated with the use of IT and develops preventive security measures. It provides information on risks and threats relating to the use of information technology and seeks out appropriate solutions. This work includes IT security testing and assessment of IT systems, including their development, in co-operation with industry. Even in technically secure information and telecommunications systems, risks and damage can still occur as a result of inadequate administration or improper use. To minimise or avoid these risks, the German BSI's services are intended for a variety of target groups: it advises manufacturers, distributors andusers of information technology. It also analyses development and trends in information technology.

Name of organisation Federal Office for Information Security (Germany)