Primary tabs

Federal Office for Information Security (Germany)

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.
Dynamic linking shall require the authentication code to be the result of a cryptographic operation on payee and amount.
No comment.
No comment.
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”.
No comments.
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.
No comment.
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.
No comment.
[Public administration"]"
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.
Federal Office for Information Security (Germany)