Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
1.1 In article 1-3-e of the RTS there is confusion between security operations which are carried out in the authentication phase and in the phase requiring the authorisation of a payment operation by an ASPSP. In most instances, certain elements of information, such as the black list of stolen or compromised cards or a transaction history cannot technically be systematically made available to the organisation responsible for the authentication.
Proposal
Article 1-3-e of the draft RTS should be reformulated as follows :
“which, when combined with other ASPSP processes such as authorisation, must forewarn, detect and block fraudulent payment operations before the PSPs final authorisation. These mechanisms shall take into account, but not be limited to … (existing wording i, ii, iii, iv, v)”
Justification
Customer authentication and transaction authorisation are two complementary but different processes which need to be managed separately.
1.2 It would assist the understanding of the reader if EBA could provide examples of what is meant by “other abuse” in article 1-3-c of the RTS.
GENERAL REMARKS
The following general remarks are intended to reflect the coherence between the EBA Draft Regulatory Technical Standards and the revised Payment Services Directive (PSD2) :
- Since the notion of “electronic payment”, which is used in article 97 of the PSD2, is not defined specifically, with regard to cards, does the term cover face to face payments, contactless and / or contact payments, and / or remote payments ?
- Article 74-2 of the PSD2 states that if payee’s payment service provider or the payee itself does not require strong customer authentication, then it will be liable for any potential damages. However in the arguments put forward in the RTS (preamble 19-b), the notion is introduced that the PSP of the payee is obliged to implement strong authentication, except during the transitional period (until the end of 2018)
o This is not however reflected in any of the articles in the body of the RTS, thus generating a certain ambiguity with regard to the obligation (or not) for a payee to initiate a strong customer authentication. Clarification is needed so as to avoid creating a potential distortion of competition.
o If in effect there is an obligation for the payee to implement strong customer authentication, what would prevent the major payees (for example GAFA) from carrying out their acquiring activities outside the European Union ?
o What is more, at the end of the transitional period, does the EBA expect that the card issuers (i.e. the PSPs of the payer) must refuse to provide an authorisation for any card payment operation outside the EU (and hence anywhere in the world) which does not meet the exemption conditions (i.e. amounts over 10 euros or cumulative amounts over 100 euros for remote payment operations without strong authentication) ?
In practice this would mean that as of 2019, a European consumer wishing to use a European payment instrument (his card) from a EU country would be refused an authorisation by his PSP for the purchase of goods or services on a non-European (for example GAFA) website which had not implemented strong authentication for the levels provided for in the RTS.
o Could you please confirm that the only case where the strong customer authentication is not required is when the payer initiates his payment order from a non EU country ?
Proposal
The RTS must clarify this point to state clearly that the payee and/or its payment service provider have the choice to implement strong authentication (as stated in article 74-2 of the PSD12), and that if they do not then they will be liable for any potential damages
- The PSD2 also states in article 66-5 and 67-4 that the provision of payment initiation services shall not be dependent on the existence of a contractual relationship between the payment initiation service providers (PISP) and the account servicing payment service providers (ASPSP) for that purpose.
On the other hand, the RTS (preamble 19-b) states that if the PISP manages the strong authentication process itself then it must have a contract with the ASPSP.
- If a level playing field is to be guaranteed in Europe, the notion of payment initiation service providers (PISPs) and their relationship with the ASPSPs needs to be crystal clear to everyone.
o For example some acceptors (for example Amazon) provide “card on file” wallets and initiate “card not present” payment operations for their clients with cards which have been issued by ASPSPs, without the latter’s prior agreement.
In such cases would the acceptor be considered as a PISP and what would its obligations be as a PISP ?
Proposal
Either the last sentence of article 2-2b of the draft RTS should be deleted, or, at the very least, the word “logically” should be added so that the sentence becomes
“The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be LOGICALLY independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.”
Justification
The article should address the issue of logical independence" of the channels used to carry out a payment operation and its authentication so as to allow both to be carried out on the same device in areas such a m-commerce and t-commerce."
Proposal
Paragraph 1 in article 3 of the draft RTS should be deleted, and paragraph 2 should become
“The use of elements of strong customer authentication categorised as knowledge shall be subject to mitigation measures in order to prevent their disclosure to unauthorised parties, to limit the number of attempts at unauthorised access, and to provide the ability to modify the value in case of compromise”.
Justification
The constraints regarding “security features” in article 3-1 are not sufficiently explicit so as to guarantee a level playing field. What is more, the fact that there are 2 authentication factors should allow constraints regarding the knowledge factor to be lessened.
3.2 In the event that paragraph 1 of article 3 is still retained in the draft RTS, the notion of “non-repeatable characters” requires clarification.
Proposal
Article 3-1 of the draft RTS should be modified as follows :
“1. The elements of strong customer authentication categorised as knowledge shall be characterized by security features including, but not limited to, length, complexity, expiration time and SHALL BE RESILIENT TO BRUTE FORCE AND DICTIONARY ATTACKS ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorised parties”.
Justification
The term “non-repeatable characters” is imprecise and insufficient
3.3 One of the conclusions of the European Commission project BEAT https://www.beat-eu.org/ , which defined both an evaluation methodology and carried out an evaluation of deception methods on biometric sensors, is that the designated requirement described in article 5-2 of the Draft RTS is unattainable with any biometric sensor available today.
Proposal
Article 5-2 of the draft RTS should be modified as follows :
“2. The use of elements categorized as inherence SHOULD be subject to measures WHICH COULD PROVIDE ASSURANCE that the devices and the software provided to the payer guarantee resistance against unauthorised use of the elements through access to the devices and software. ”.
Justification
The described requirement is unattainable with any biometric sensor available today
3.4 By the same token, the notion that a Trusted Execution Environment (TEE) as referred to in article 6-3-a has not yet reached maturity on devices available to consumers and the general public, and the required business models are even less developed.
In fact, the RTS should avoid being too detailed with regard to security technologies, since these are constantly evolving. The RTS should deal with principles and remain technologically neutral.
Proposal
Article 6-3 of the draft RTS should be modified as follows :
“3. For the purposes of paragraph 2, the mitigating measures COULD include, FOR EXAMPLE, but WOULD not be limited to:
a. the implementation of separated trusted execution environments inside the multi-purpose device;
b. mechanisms to ensure that the software or device have not been altered by the payer or by a third party or mechanisms to mitigate the risks related to such alteration where this has taken place.”.
Justification
The technology to meet the designated requirement is simply not available today.
What is more, insisting on separate TEEs would exclude the possibility of both storing data and carrying out sensitive operations in an embedded secure element.
3.5 Clarification is needed as to what is meant by the use of the term certified auditors » in preamble (5) and in articles 7-1 and 16-1 of the draft RTS. This begs the question “Certified by whom and on what basis ?”.
- It is suggested that it would be better to have a more generic term such as “qualified auditor” with a definition of the term “qualified” as “recognised, referenced, labelled or certified by a competent authority or organisation”.
- The role of a "card scheme" should be included within the same articles of the draft RTS, since it plays a role in supervising the security of card payment operations (in particular through its type approval procedures for products and systems)."
- We believe that the EBA should accept other motives for exemptions, as provided for in fact in article 98-3 of the PSD2. viz. : the level of risk involved in the service provided, or the recurrence of the transaction.
Unless the EBA accepts the above-mentioned motives for exemption, then the current efficient and accurate tools used for scoring the European card payment operations would no longer be needed.
This could lead to some e-merchants (for example GAFA) to contract with acquiring PSPs outside the EU unless it is clearly stated that all electronic transactions initiated by a EU payer from a EU country must be strongly authenticated whatever the location of the payee.
Proposal
The draft RTS should extend the motives for exemption on the application of strong customer authentication to include tools used for scoring in the authorisation of payment operations, with an obligation that use of such tools must achieve (using both scoring techniques and, if needed, strong customer authentication) a pre-defined acceptable level of fraud which can be verified by an independent authority.
It would also be reasonable to include in the RTS that any risks resulting from such an exemption would be entirely the responsibility of the ASPSP, since the latter is liable for the financial risk.
Proposal
article 8.2 should be replaced by
« The application of strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/2366 CAN BE exempted where: ».
Justification
Principle of reasonable precaution
5.2 The following two proposals are made in the interests of coherence
Proposal
If a non-replayable authentication mechanism is used for “remote electronic payments” (using a single factor as is the case for contactless payments), then the individual amount and the cumulative amount defined for “remote electronic payments in article 8-2-d (10 and 100 euros) could be aligned with those proposed in article 8-1-b for contactless payments (50 and 150 euros)
Justification
In the interests of coherence
Proposal
An additional exemption to strong customer authentication as described in article 8.2 of the draft RTS should be added as follows :
8.2 (e) the payer initiates online a series of card payment operations with the same amount and for the same payee
Justification
There is a need to take into account payment operations which are recurrent, but made with a card
5.3 It is mentioned in preamble (52) and article 8-1-b of the draft RTS that operations in “contact” mode are not subject to an exemption because of historical reasons and because of the high level of security provided by “chip & pin”, whilst contactless payment operations are.
However, both MasterCard and Visa authorise “contact” payment operations in Europe with a chip without the use of the pin, for small amounts on vending machines and larger amounts, for example, at toll booths.
- How is this situation covered and dealt with in the draft RTS at the end of the transitional period ?
- How can a level playing field be guaranteed if there are already such solutions deployed throughout the EU today ?"
- If a chip (a card, a secure element, embedded secure element) is ultra-secure (for example EAL4+VAN5 certified) and is used as a means of storage for the Personalised Secure Credentials (PSCs), why is there a need for the PSCs to be stored in an encrypted form ?
Proposal
article 9.1-b and 9.1-c should be replaced and include an obligation to produce results : the new article 9-1-b would be
« Personalised security credential data as well as cryptographic material related to the encryption of the personalised security credentials shall be stored and protected in terms of integrity and confidentiality with security measures resistant to an attacker with a high attack potential ».
Justification
Principle of reasonable precaution
(The metric that can be used to assess the security of the solution can be typically the « attack potential” document provided by national certification bodies within SOGIS agreement http://www.sogis.org/documents/cc/domains/sc/JIL-Application-of-Attack-Potential-to-Smartcards-v2-9.pdf)
6.2 The draft RTS covers the modalities of strong customer authentication, the protection of PSCs and their communication to, for example, a cardholder. There is no mention however in the draft RTS of any guidance regarding the enrolment phase or the knowledge of the identity of the legitimate cardholder (apart from a tacit reference in articles 11 and 12).
Clearly, strong authentication without a controlled enrolment process makes no sense (as was illustrated by security incidents experienced during the launch of Apple Pay in the USA (see http://www.forbes.com/sites/thomasbrewster/2016/03/01/apple-pay-fraud-test/#3dd5456a3c15 )).
Proposal
A new article (10bis) should be included in the draft RTS to cover aspects related to enrolment and KYC
Article 10 bis : Enrolment of the payer, prior to the association of the payer with personalised security credentials, authentication device and software, the PSP or PISP offering the strong authentication service shall identify the identity of the payer (KYC or eKYC) through state of the art means of identification in order to ensure that the user associated with the personalised security credentials is the legitimate payer. To this end, the PSP or PISP can use the service of an eIDAS identity service provider”.
Justification
There is a need to cover the enrolment and KYC processes in the RTS
6.3 Article 13 mentions “personalised security credentials, authentication devices and software » on several occasions. However the list of means for the delivery and activation of Personalised Security Credentials is not exhaustive, and these can be delivered to the cardholder (payer) via (for example) the personalisation of an application in a device, and not by the transmission of a device or software.
In the interests of coherence, each occurrence of “authentication devices or software” should be removed, and “personalised security credentials, authentication devices or software” should be replaced throughout article 13 of the draft RTS by “personalised security credentials, whichever form factor is used to protect them” , as in the following proposal.
Other proposed changes (below) in article 13 are a result of this approach.
Proposal
Article 13 Delivery of personalised security credentials
The security measures to protect the confidentiality and integrity of payment service users’ personalised security credentials shall provide that the delivery of personalised security credentials is carried out in a secure manner.
To this end, these measures shall include:
(a) Effective and secure delivery mechanisms ensuring that the personalised security credentials are delivered to the legitimate payment services user
(b) Mechanisms ensuring the AUTHENTICITY AND INTEGRITY OF THE SOFTWARE, IF ANY, delivered to the payment services user via the internet
DELETE para (c) and para (d) becomes
(c) Arrangements ensuring that, in cases where the personalised security credentials , require to be activated before their use, the activation shall take place in a secure and trusted environment in accordance with the association procedures referred to in Article 12.
Justification
Article 13-b must be technologically neutral and not propose specific technical solutions.
What is meant by “bilateral identification”? Does it mean “mutual authentication with a certificate” as with TLS (Transport Layer Security) ?
In which case, the authors of the draft RTS should be aware that the EMV standard used today does not provide for a payment card to authenticate a payment terminal.
What is more, this capability is not explicitly planned in EMV 2025, which would mean de facto that this requirement of the draft RTS could not be met.
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?
REMARKS ON RTS CHAPTER 11.1 In article 1-3-e of the RTS there is confusion between security operations which are carried out in the authentication phase and in the phase requiring the authorisation of a payment operation by an ASPSP. In most instances, certain elements of information, such as the black list of stolen or compromised cards or a transaction history cannot technically be systematically made available to the organisation responsible for the authentication.
Proposal
Article 1-3-e of the draft RTS should be reformulated as follows :
“which, when combined with other ASPSP processes such as authorisation, must forewarn, detect and block fraudulent payment operations before the PSPs final authorisation. These mechanisms shall take into account, but not be limited to … (existing wording i, ii, iii, iv, v)”
Justification
Customer authentication and transaction authorisation are two complementary but different processes which need to be managed separately.
1.2 It would assist the understanding of the reader if EBA could provide examples of what is meant by “other abuse” in article 1-3-c of the RTS.
GENERAL REMARKS
The following general remarks are intended to reflect the coherence between the EBA Draft Regulatory Technical Standards and the revised Payment Services Directive (PSD2) :
- Since the notion of “electronic payment”, which is used in article 97 of the PSD2, is not defined specifically, with regard to cards, does the term cover face to face payments, contactless and / or contact payments, and / or remote payments ?
- Article 74-2 of the PSD2 states that if payee’s payment service provider or the payee itself does not require strong customer authentication, then it will be liable for any potential damages. However in the arguments put forward in the RTS (preamble 19-b), the notion is introduced that the PSP of the payee is obliged to implement strong authentication, except during the transitional period (until the end of 2018)
o This is not however reflected in any of the articles in the body of the RTS, thus generating a certain ambiguity with regard to the obligation (or not) for a payee to initiate a strong customer authentication. Clarification is needed so as to avoid creating a potential distortion of competition.
o If in effect there is an obligation for the payee to implement strong customer authentication, what would prevent the major payees (for example GAFA) from carrying out their acquiring activities outside the European Union ?
o What is more, at the end of the transitional period, does the EBA expect that the card issuers (i.e. the PSPs of the payer) must refuse to provide an authorisation for any card payment operation outside the EU (and hence anywhere in the world) which does not meet the exemption conditions (i.e. amounts over 10 euros or cumulative amounts over 100 euros for remote payment operations without strong authentication) ?
In practice this would mean that as of 2019, a European consumer wishing to use a European payment instrument (his card) from a EU country would be refused an authorisation by his PSP for the purchase of goods or services on a non-European (for example GAFA) website which had not implemented strong authentication for the levels provided for in the RTS.
o Could you please confirm that the only case where the strong customer authentication is not required is when the payer initiates his payment order from a non EU country ?
Proposal
The RTS must clarify this point to state clearly that the payee and/or its payment service provider have the choice to implement strong authentication (as stated in article 74-2 of the PSD12), and that if they do not then they will be liable for any potential damages
- The PSD2 also states in article 66-5 and 67-4 that the provision of payment initiation services shall not be dependent on the existence of a contractual relationship between the payment initiation service providers (PISP) and the account servicing payment service providers (ASPSP) for that purpose.
On the other hand, the RTS (preamble 19-b) states that if the PISP manages the strong authentication process itself then it must have a contract with the ASPSP.
- If a level playing field is to be guaranteed in Europe, the notion of payment initiation service providers (PISPs) and their relationship with the ASPSPs needs to be crystal clear to everyone.
o For example some acceptors (for example Amazon) provide “card on file” wallets and initiate “card not present” payment operations for their clients with cards which have been issued by ASPSPs, without the latter’s prior agreement.
In such cases would the acceptor be considered as a PISP and what would its obligations be as a PISP ?
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.
In its current form article 2.2-b is unclear and could be interpreted as requiring two physically independent channels (typically one to initiate a payment operation and another one, for instance a separate device, on which data linked to the authentication is received). This could be an obstacle to the development of m-commerce & t-commerce.Proposal
Either the last sentence of article 2-2b of the draft RTS should be deleted, or, at the very least, the word “logically” should be added so that the sentence becomes
“The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be LOGICALLY independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.”
Justification
The article should address the issue of logical independence" of the channels used to carry out a payment operation and its authentication so as to allow both to be carried out on the same device in areas such a m-commerce and t-commerce."
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?
3.1 Additional precision is needed in paragraph 1 of article 3 (Requirements related to elements categorised as knowledge)Proposal
Paragraph 1 in article 3 of the draft RTS should be deleted, and paragraph 2 should become
“The use of elements of strong customer authentication categorised as knowledge shall be subject to mitigation measures in order to prevent their disclosure to unauthorised parties, to limit the number of attempts at unauthorised access, and to provide the ability to modify the value in case of compromise”.
Justification
The constraints regarding “security features” in article 3-1 are not sufficiently explicit so as to guarantee a level playing field. What is more, the fact that there are 2 authentication factors should allow constraints regarding the knowledge factor to be lessened.
3.2 In the event that paragraph 1 of article 3 is still retained in the draft RTS, the notion of “non-repeatable characters” requires clarification.
Proposal
Article 3-1 of the draft RTS should be modified as follows :
“1. The elements of strong customer authentication categorised as knowledge shall be characterized by security features including, but not limited to, length, complexity, expiration time and SHALL BE RESILIENT TO BRUTE FORCE AND DICTIONARY ATTACKS ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorised parties”.
Justification
The term “non-repeatable characters” is imprecise and insufficient
3.3 One of the conclusions of the European Commission project BEAT https://www.beat-eu.org/ , which defined both an evaluation methodology and carried out an evaluation of deception methods on biometric sensors, is that the designated requirement described in article 5-2 of the Draft RTS is unattainable with any biometric sensor available today.
Proposal
Article 5-2 of the draft RTS should be modified as follows :
“2. The use of elements categorized as inherence SHOULD be subject to measures WHICH COULD PROVIDE ASSURANCE that the devices and the software provided to the payer guarantee resistance against unauthorised use of the elements through access to the devices and software. ”.
Justification
The described requirement is unattainable with any biometric sensor available today
3.4 By the same token, the notion that a Trusted Execution Environment (TEE) as referred to in article 6-3-a has not yet reached maturity on devices available to consumers and the general public, and the required business models are even less developed.
In fact, the RTS should avoid being too detailed with regard to security technologies, since these are constantly evolving. The RTS should deal with principles and remain technologically neutral.
Proposal
Article 6-3 of the draft RTS should be modified as follows :
“3. For the purposes of paragraph 2, the mitigating measures COULD include, FOR EXAMPLE, but WOULD not be limited to:
a. the implementation of separated trusted execution environments inside the multi-purpose device;
b. mechanisms to ensure that the software or device have not been altered by the payer or by a third party or mechanisms to mitigate the risks related to such alteration where this has taken place.”.
Justification
The technology to meet the designated requirement is simply not available today.
What is more, insisting on separate TEEs would exclude the possibility of both storing data and carrying out sensitive operations in an embedded secure element.
3.5 Clarification is needed as to what is meant by the use of the term certified auditors » in preamble (5) and in articles 7-1 and 16-1 of the draft RTS. This begs the question “Certified by whom and on what basis ?”.
- It is suggested that it would be better to have a more generic term such as “qualified auditor” with a definition of the term “qualified” as “recognised, referenced, labelled or certified by a competent authority or organisation”.
- The role of a "card scheme" should be included within the same articles of the draft RTS, since it plays a role in supervising the security of card payment operations (in particular through its type approval procedures for products and systems)."
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?
We are surprised at the EBA‘s reasoning on the exemptions of the application of article 97 of the PSD2 and the provisions proposed in Chapter 2 of the draft RTS for the following reasons :- We believe that the EBA should accept other motives for exemptions, as provided for in fact in article 98-3 of the PSD2. viz. : the level of risk involved in the service provided, or the recurrence of the transaction.
Unless the EBA accepts the above-mentioned motives for exemption, then the current efficient and accurate tools used for scoring the European card payment operations would no longer be needed.
This could lead to some e-merchants (for example GAFA) to contract with acquiring PSPs outside the EU unless it is clearly stated that all electronic transactions initiated by a EU payer from a EU country must be strongly authenticated whatever the location of the payee.
Proposal
The draft RTS should extend the motives for exemption on the application of strong customer authentication to include tools used for scoring in the authorisation of payment operations, with an obligation that use of such tools must achieve (using both scoring techniques and, if needed, strong customer authentication) a pre-defined acceptable level of fraud which can be verified by an independent authority.
It would also be reasonable to include in the RTS that any risks resulting from such an exemption would be entirely the responsibility of the ASPSP, since the latter is liable for the financial risk.
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?
5.1 Clarification is needed in the article 8.2 : ‘’The application of strong customer authentication….. is exempted where :….’’. Does it mean that it is mandatory ? or is it still possible for the payer’s PSP to require a SCA, for instance based on a risk analysis ?Proposal
article 8.2 should be replaced by
« The application of strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/2366 CAN BE exempted where: ».
Justification
Principle of reasonable precaution
5.2 The following two proposals are made in the interests of coherence
Proposal
If a non-replayable authentication mechanism is used for “remote electronic payments” (using a single factor as is the case for contactless payments), then the individual amount and the cumulative amount defined for “remote electronic payments in article 8-2-d (10 and 100 euros) could be aligned with those proposed in article 8-1-b for contactless payments (50 and 150 euros)
Justification
In the interests of coherence
Proposal
An additional exemption to strong customer authentication as described in article 8.2 of the draft RTS should be added as follows :
8.2 (e) the payer initiates online a series of card payment operations with the same amount and for the same payee
Justification
There is a need to take into account payment operations which are recurrent, but made with a card
5.3 It is mentioned in preamble (52) and article 8-1-b of the draft RTS that operations in “contact” mode are not subject to an exemption because of historical reasons and because of the high level of security provided by “chip & pin”, whilst contactless payment operations are.
However, both MasterCard and Visa authorise “contact” payment operations in Europe with a chip without the use of the pin, for small amounts on vending machines and larger amounts, for example, at toll booths.
- How is this situation covered and dealt with in the draft RTS at the end of the transitional period ?
- How can a level playing field be guaranteed if there are already such solutions deployed throughout the EU today ?"
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?
6.1 It should be noted that article 9-b imposes an obligation of due care and diligence which is problematic, as illustrated by the following question- If a chip (a card, a secure element, embedded secure element) is ultra-secure (for example EAL4+VAN5 certified) and is used as a means of storage for the Personalised Secure Credentials (PSCs), why is there a need for the PSCs to be stored in an encrypted form ?
Proposal
article 9.1-b and 9.1-c should be replaced and include an obligation to produce results : the new article 9-1-b would be
« Personalised security credential data as well as cryptographic material related to the encryption of the personalised security credentials shall be stored and protected in terms of integrity and confidentiality with security measures resistant to an attacker with a high attack potential ».
Justification
Principle of reasonable precaution
(The metric that can be used to assess the security of the solution can be typically the « attack potential” document provided by national certification bodies within SOGIS agreement http://www.sogis.org/documents/cc/domains/sc/JIL-Application-of-Attack-Potential-to-Smartcards-v2-9.pdf)
6.2 The draft RTS covers the modalities of strong customer authentication, the protection of PSCs and their communication to, for example, a cardholder. There is no mention however in the draft RTS of any guidance regarding the enrolment phase or the knowledge of the identity of the legitimate cardholder (apart from a tacit reference in articles 11 and 12).
Clearly, strong authentication without a controlled enrolment process makes no sense (as was illustrated by security incidents experienced during the launch of Apple Pay in the USA (see http://www.forbes.com/sites/thomasbrewster/2016/03/01/apple-pay-fraud-test/#3dd5456a3c15 )).
Proposal
A new article (10bis) should be included in the draft RTS to cover aspects related to enrolment and KYC
Article 10 bis : Enrolment of the payer, prior to the association of the payer with personalised security credentials, authentication device and software, the PSP or PISP offering the strong authentication service shall identify the identity of the payer (KYC or eKYC) through state of the art means of identification in order to ensure that the user associated with the personalised security credentials is the legitimate payer. To this end, the PSP or PISP can use the service of an eIDAS identity service provider”.
Justification
There is a need to cover the enrolment and KYC processes in the RTS
6.3 Article 13 mentions “personalised security credentials, authentication devices and software » on several occasions. However the list of means for the delivery and activation of Personalised Security Credentials is not exhaustive, and these can be delivered to the cardholder (payer) via (for example) the personalisation of an application in a device, and not by the transmission of a device or software.
In the interests of coherence, each occurrence of “authentication devices or software” should be removed, and “personalised security credentials, authentication devices or software” should be replaced throughout article 13 of the draft RTS by “personalised security credentials, whichever form factor is used to protect them” , as in the following proposal.
Other proposed changes (below) in article 13 are a result of this approach.
Proposal
Article 13 Delivery of personalised security credentials
The security measures to protect the confidentiality and integrity of payment service users’ personalised security credentials shall provide that the delivery of personalised security credentials is carried out in a secure manner.
To this end, these measures shall include:
(a) Effective and secure delivery mechanisms ensuring that the personalised security credentials are delivered to the legitimate payment services user
(b) Mechanisms ensuring the AUTHENTICITY AND INTEGRITY OF THE SOFTWARE, IF ANY, delivered to the payment services user via the internet
DELETE para (c) and para (d) becomes
(c) Arrangements ensuring that, in cases where the personalised security credentials , require to be activated before their use, the activation shall take place in a secure and trusted environment in accordance with the association procedures referred to in Article 12.
Justification
Article 13-b must be technologically neutral and not propose specific technical solutions.
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?
Article 17.1 requires that PSPs shall ensure secure bilateral identification when communicating between the payer’s device and the payee’s acceptance devices for electronic payments, including but not limited to payment terminals.What is meant by “bilateral identification”? Does it mean “mutual authentication with a certificate” as with TLS (Transport Layer Security) ?
In which case, the authors of the draft RTS should be aware that the EMV standard used today does not provide for a payment card to authenticate a payment terminal.
What is more, this capability is not explicitly planned in EMV 2025, which would mean de facto that this requirement of the draft RTS could not be met.