Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
The rationale behind PSD2’s requirements for strong customer authentication, to address the huge upsurge in cybercrime attacks against electronic payments, is necessary and indeed overdue, as Card Not Present attacks have been the modus operandi in Europe for a decade.
The EBA’s reasoning on the requirements of strong customer authentication is generally in the correct direction, but there are a number of in-practicalities introduced within the subsequent definitions that would undermine the wider adoption of electronic commerce that is intended to be protected, and potentially introduce dichotomous requirements to other currently forthcoming EU regulations, in particular GDPR.
Given the provisions of Articles 2-5, Article 1 e) would appear to be non-sequitur:
i) If dynamic data is being utilised, then stolen card data can have no utility, hence blacklists for ‘stolen’ (or in UK law fraudulent use of) card data are unnecessary;
ii) ‘Signs of malware infection’ are the most likely form of ‘assumed compromise (ENISA guidance July 2012), but PSD2 requirements to prevent the factors of authentication ‘being suureptiously stolen over the internet would preclude this. ‘Known fraud scenarios’ would appear to be precluded, or at least severely limited, by EBA clarification at the public hearing that the merchant should no maintain the role of the current generation of merchant/acquirer fraud prevention techniques;
Further elements of Chapter 1 are covered below under individual articles.
Provisions of Article 2.2.b would enable a compromised POS to ‘dynamically link’ a malicious transaction, rather than that expected by the user and displayed on the terminal.
Provisions of Article 2.3 rely upon the genuine user having control over the level of the amount ot be locked for any given payee.
Provisions of Article 2.4 would suggest that a fixed authentication code would need to be generated up front to secure a subsequent series of batched payments where the sum of the subsequent transactions is not yet known, but which need to be signed in advance.
The timing of the ‘dynamic link’ would suggest that a post fact stop check, over one or more channels, would enable the user to authorise (or report abuse in case of an initial transaction altered by a compromised POS terminal face to face) subsequent transaction within a batch (similar to provisions of Payment Strategy Forum in Request to Pay).
However, the delivery of One Time Passwords to users would either entail the development of ESP, or provide for the delivery of the OTP to the user through a channel, typically currently seen as to a registered device. Given that the compromise of one factor cannot allow for the compromise of another, this would suggest that ‘something one knows’ is unavailable as a factor.
Provisions of Article 3 should enable multiple facets of authentication to be managed within the one factor, i.e the multiple claims delivered over the single device (for example GPS location on mobile).
Provisions of Article 4 should extend to ensure that multi-modalities of biometrics (potentially to include behavioural biometrics that can have a role to play) can enable greater Aassurance that it has not been a mis-interpretation of a false presentation of characteristics.
In the case of contactless cards, one assumes that the EBA interpretation is that the transaction shall fall back to Chip and PIN, under EMV exemption.
However, for wearables there is no such capability as there is no PIN.
If the 150euro limit is reached on, for example, a public transport network, there is no such capability for falling back in the case of cards, nor equally for wearables.
Over and above the the practical limitations of this approach, mandating exemptions prevents the principal of risk based assessments on any given transaction. 3.2.2, 36a) states that ‘PSD2 exemptions should be based on the level of risk involved in the service provided’, which will typically nvolve the merchant/acquirer rather than just the credential issuer.
Article 12a) goes on to state that the ‘level of assurance is assured’. Given cross references to eIDAS the level of assurance needs defining, in particular given the assumption that, with biometrics necessary for subsequent SCA, the level of assurance will need to be Substantial or High.
Acceptable ‘Environments under the PSP’s responsibility include, … the internet environment provided’. Given that no such environment is immune from breach via interception over the internet’, the issuance of the credentials under such circumstances are less secure than the requirements for their subsequent use.
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?
Disclaimer - Whilst this consultation response is from the lead author of the MIDAS Alliance sponsored British Standards Institution’s PAS499 Code of Practice on Digital Identification & Authentication, and is based upon discussions held within the MIDAS Alliance community. However, the views are the author’s own, and do not necessarily represent the views of other members of the Alliance/the BSI/or other engaged in the development of the Publicly Available Specification.The rationale behind PSD2’s requirements for strong customer authentication, to address the huge upsurge in cybercrime attacks against electronic payments, is necessary and indeed overdue, as Card Not Present attacks have been the modus operandi in Europe for a decade.
The EBA’s reasoning on the requirements of strong customer authentication is generally in the correct direction, but there are a number of in-practicalities introduced within the subsequent definitions that would undermine the wider adoption of electronic commerce that is intended to be protected, and potentially introduce dichotomous requirements to other currently forthcoming EU regulations, in particular GDPR.
Given the provisions of Articles 2-5, Article 1 e) would appear to be non-sequitur:
i) If dynamic data is being utilised, then stolen card data can have no utility, hence blacklists for ‘stolen’ (or in UK law fraudulent use of) card data are unnecessary;
ii) ‘Signs of malware infection’ are the most likely form of ‘assumed compromise (ENISA guidance July 2012), but PSD2 requirements to prevent the factors of authentication ‘being suureptiously stolen over the internet would preclude this. ‘Known fraud scenarios’ would appear to be precluded, or at least severely limited, by EBA clarification at the public hearing that the merchant should no maintain the role of the current generation of merchant/acquirer fraud prevention techniques;
Further elements of Chapter 1 are covered below under individual articles.
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.
The provisions of Article 2 potentially represent the greatest threat to user experience, jeopardising the use of electronic payments. ‘Dynamic linking’, if implemented by asking the user to digitally ‘sign’ each individual online transaction (for example using a CAP reader) would inevitably lead to cart abandonment at levels way in excess of those experienced under 3DS.Provisions of Article 2.2.b would enable a compromised POS to ‘dynamically link’ a malicious transaction, rather than that expected by the user and displayed on the terminal.
Provisions of Article 2.3 rely upon the genuine user having control over the level of the amount ot be locked for any given payee.
Provisions of Article 2.4 would suggest that a fixed authentication code would need to be generated up front to secure a subsequent series of batched payments where the sum of the subsequent transactions is not yet known, but which need to be signed in advance.
The timing of the ‘dynamic link’ would suggest that a post fact stop check, over one or more channels, would enable the user to authorise (or report abuse in case of an initial transaction altered by a compromised POS terminal face to face) subsequent transaction within a batch (similar to provisions of Payment Strategy Forum in Request to Pay).
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?
Provisions of Article 3 that ‘something one knows’ are unrepeatable would logically suggest a requirement for One Time Passwords. This is a very valuable interpretation, as any form of static data being used within a SCA context is worthless in the face of existing cybercriminal methodology, let alone forthcoming attack vectors.However, the delivery of One Time Passwords to users would either entail the development of ESP, or provide for the delivery of the OTP to the user through a channel, typically currently seen as to a registered device. Given that the compromise of one factor cannot allow for the compromise of another, this would suggest that ‘something one knows’ is unavailable as a factor.
Provisions of Article 3 should enable multiple facets of authentication to be managed within the one factor, i.e the multiple claims delivered over the single device (for example GPS location on mobile).
Provisions of Article 4 should extend to ensure that multi-modalities of biometrics (potentially to include behavioural biometrics that can have a role to play) can enable greater Aassurance that it has not been a mis-interpretation of a false presentation of characteristics.
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?
Article 8.1.b.i/ii) necessitate a separate customer experience at POS for contactless payments, and indeed separate merchant experience at checkout, given that the nth purchase breaching a cumulative sum of 150 euros requires SCA. Up until the moment of presentation of credential neither the user nor the merchant’s sales assistant know whether SCA will be required. This undermines the usability of contactless payments but also introduces other issues depending on the medium being used to instigate the contactless payment.In the case of contactless cards, one assumes that the EBA interpretation is that the transaction shall fall back to Chip and PIN, under EMV exemption.
However, for wearables there is no such capability as there is no PIN.
If the 150euro limit is reached on, for example, a public transport network, there is no such capability for falling back in the case of cards, nor equally for wearables.
Over and above the the practical limitations of this approach, mandating exemptions prevents the principal of risk based assessments on any given transaction. 3.2.2, 36a) states that ‘PSD2 exemptions should be based on the level of risk involved in the service provided’, which will typically nvolve the merchant/acquirer rather than just the credential issuer.
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?
The list of exemptions, and in particular the mandating of exemptions where they occur, as noted above, are at odds with the principle of the development of a risk based approach set out within the Directive.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?
Provisions of Article 12a) maintain that the issuing of credentials for subsequent strong customer authentication should be managed within an environment offering ‘adequate authentication’. This may be a linguistic misinterpretation, but it is not possible to issue credentials utilising a process or circumstances that are easier to breach than the credentials thereby being issued.Article 12a) goes on to state that the ‘level of assurance is assured’. Given cross references to eIDAS the level of assurance needs defining, in particular given the assumption that, with biometrics necessary for subsequent SCA, the level of assurance will need to be Substantial or High.
Acceptable ‘Environments under the PSP’s responsibility include, … the internet environment provided’. Given that no such environment is immune from breach via interception over the internet’, the issuance of the credentials under such circumstances are less secure than the requirements for their subsequent use.