Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
1. https://www.owasp.org/index.php/Avoid_security_by_obscurity
Even though most behaviour-based characteristics cannot be used for “strong” consumer authentication, the PSD2 acknowledges that low risk transactions require a lower level of authentication than high risk transactions. Behaviour-based characteristics can be used as one factor in the risk assessment to determine the appropriate level of authentication. An escalating (step-up) authentication strategy could range from a no-authentication requirement for a micropayment made from an IP address habitually used by the consumer, to a single-factor authentication for low value transactions like a contactless payment, to two-factor authentication for a high value internet purchase, and to further measures such as a phone call for very high value transactions. A differentiating factor for PSPs may well be the simplicity of the consumer journey, not requiring intrusive authentication measures, which would be enabled by the PSP’s sophisticated risk evaluation capability.
1. http://cecs.louisville.edu/ry/Behavioral.pdf
A common approach to making the second factor dynamic (mentioned in Recital 96) is to deliver the “knowledge” element (e.g. a Transaction Authentication Number (TAN) or one-time password) to a mobile or wearable device wearable via text or push message. This is a sensible approach for an e-commerce transaction initiated from a PC, because a fraudster initiating a transaction via a laptop or PC is unlikely to be in possession of the customer’s mobile device.
Unfortunately, for m-commerce this approach of sending a TAN to the device actually makes matters worse instead of better. If the fraudster has control of the “possession” element (the mobile device), and the “knowledge” element is delivered to that same device, the fraudster now has the two elements required to complete the transaction. Any approach that uses the device on which the transaction is being initiated as both the “possession” element and the channel by which the “knowledge” element is received is clearly flawed. This issue is mentioned in paragraph 32 of the DP.
1. http://www.bbc.co.uk/news/technology-30623611
Dynamic linking of authorisation to transaction elements is necessary because even bona-fide TPPs have a “man in the middle” role between PSU and ASPSP. A genuine TPP will display the same transaction details to the PSU as are sent in the instruction to the ASPSP, but a bogus (or compromised) TPP could display to the consumer the details of the transaction that they intend to carry out, but send a completely different instruction the ASPSP (e.g. a payment of a higher amount to the fraudster’s account). To prevent this type of attack, it is necessary to guarantee that the transaction details presented to the customer match the transaction details sent to the ASPSP.
The gold standard of dynamic linking is the approach used by EMV cards. This takes key data of the transaction such as transaction amount currency, hashes them, and digitally signs them using a dynamically-generated key[1]. The calculation is carried out by the EMV card, and the result is known as an Authorisation Request Cryptogram (ARQC), which is sent to the card issuer as part of the transaction request. The issuer is able to carry out the same calculation which validates three things: i) the ARQC was generated by a bona-fide card; ii) the key data of the transaction have not been changed since the ARQC was generated; and iii) the ARQC is associated with this specific transaction. It can also indirectly authenticate the customer, as the card is able to directly validate the cardholder’s PIN, and will not generate the ARQC without cardholder authorisation (as mentioned in paragraph 31 of the DP).
Unfortunately, even EMV falls short of the requirements for dynamic linking. For one thing, the key data used to generate the ARQC do not include the merchant (payee) details – one of the features exploited in the attack described by Newcastle University researchers Emms et al[2]. Another weakness is that customers have no choice but to trust the terminal when it displays the amount of the transaction, which allows relay attacks as described by University of Cambridge researchers Drimer and Murdoch[3].
A comprehensive approach to dynamic linking would require a trusted app (e.g. one provided by the ASPSP), running in trusted hardware (e.g. the PSU’s mobile phone or wearable) where all input and output functions are protected against compromise by malware, with a hardware cryptographic element and protected key store, creating a digital signature across more transaction data elements than are included in the EMV ARQC calculation. The FIDO Alliance[4] has an architecture that supports “What You See is What You Sign” mode.
Dynamic linking in the absence of hardware cryptography and security-hardened device presents significant challenges. A naïve suggestion is for the PSP to send a text or push message to the consumer, containing the payee’s name and account number and the payment amount as well the authorisation code. For a transaction initiated on a mobile device the approach is insecure because it makes the “knowledge” element dependent on the “possession” element, so does not even provide secure two-factor authentication (see response to Question 4 above), let alone secure dynamic linking.
Irrespective of the mechanism used to dynamically link customer authorisation to a specific transaction, handling of recurring transactions is problematic. A normal transaction is initiated by the PSU, but a recurring transaction is initiated by (or on behalf of) the payee. In some cases it may be possible and desirable to obtain explicit authorisation from the payer for each occurrence, which would require delivering a notification to the PSU that a transaction is awaiting approval, and a secure method of retrieving and approving the transaction. In other cases (e.g. low value or micropayments) the PSU would not want to explicitly authorise each transaction. This could be achieved by means of a set of rules associated with the initial framework agreement with the PIS provider.
1. https://crypto.stanford.edu/~dabo/courses/cs255_winter14/lectures/EMV.pdf
2. http://homepages.cs.ncl.ac.uk/budi.arief/home.formal/Papers/CCS2014.pdf
3. https://www.cl.cam.ac.uk/research/security/banking/relay/
4. https://fidoalliance.org/specifications/overview/
The Zapp system in the UK meets the requirement in a different way. The e-commerce or m-commerce merchant passes the transaction instruction to the ASPSP via a back-channel not involving the initiating device. The ASPSP returns a TAN to the merchant, which is presented to the PSU to enter into an app provided by the ASPSP. The app uses the TAN entered by the PSU to retrieve the linked transaction from the ASPSP. The app presents the transaction details to the PSU to authorise, using whatever method of authentication I required by the ASPSP’s app. This approach has the benefit of not requiring special cryptographic support beyond the TLS used to secure communications between mobile device and ASPSP.
One area that definitely requires clarification is the provision in Article 74 (2) that says “Where the payee or the payment service provider of the payee fails to accept strong customer authentication, it shall refund the financial damage caused to the payer’s payment service provider”. This does not make sense as stated. Strong customer authentication is a concern of the payer’s AIS/PIS provider and ASPSP. The payee and the payee’s PSP play no role in customer authentication. The regulatory technical standards need to explain this article.
It follows from the above that a PIS provider should be able to make their own risk assessment and decide the level of customer authentication that they are prepared to apply. (Some high volume merchants such as supermarkets already do this for card transactions, avoiding the time penalty of making an online authorisation for transactions that they assess to be low risk). The suggestion in DP 42 D that the regulatory technical standards should describe in detail the transaction risk analysis criteria would limit the freedom for PIS providers to compete in this area.
It is important to note that some risk assessment criteria will only be available to the ASPSP, and not to the PIS provider. Examples include: opening date of the account, recent change of address, recent transaction history for the customer as a whole (the PIS provider will only have the history of payments initiated by that provider). The ASPSP may even take into account the prevalence of fraudulent transactions initiated by that PIS provider. This raises the question of whether the ASPSP may block a transaction based on their own risk assessment which differs from that of the PIS provider.
The FIDO solution has the added advantage of using “pluggable local authentication”, so is able to support a variety of authentication methods such as secure PIN, biometrics (face, voice, iris, fingerprint recognition) etc. This capability supports the PSD2 and EBA’s agenda to facilitate innovation.
1. https://fidoalliance.org/specifications/overview/
The tragedy is that despite the staggering costs incurred, the approach has been ineffective, with massive data thefts occurring from supposedly PCI-compliant organizations such as Target and Heartland. Gartner analyst Avivah Litan states baldly that the PCI standard “has largely been a failure”[2]. It would seem perverse for the regulatory technical standards to impose an approach that has proven to be such an epic failure in a closely related area.
One important component of an alternative approach is to minimise the transmission and sharing of PSCs. Rather than requiring consumers to enter security credentials into third party apps or websites, a secure delegated access model such as OpenID Connect[3] allows the issuer of the PSC to authenticate the PSU on behalf of the third party.
1. http://cdn.ttgtmedia.com/searchSecurityUK/downloads/RHUL_Bradley_2010.pdf
2. http://blogs.gartner.com/avivah-litan/2014/01/20/how-pci-failed-target-and-u-s-consumers/
3. http://openid.net/connect/
• Encouraging consumers to enter PSCs into websites other than that of their ASPSP increases their vulnerability to social engineering attacks such as phishing and man-in-the-middle attacks. The average consumer will not be able to distinguish between a bona-fide PIS provider and a fraudulent site when asked to provide their PSCs
• Some “screen scraping” PIS providers make misleading statements about the security of PSCs, claiming that the credentials are safe because they are always encrypted. It is true that the credentials are encrypted using TLS between the PSU’s browser and the PIS provider’s servers, and again between the PIS provider’s servers and the ASPSP’s servers. The crucial point is that the chain of encryption is broken as the credentials pass across the PIS provider’s server, where they appear (albeit briefly) in clear text. Even if the PIS provider has the best of intentions, this break in encryption provides an attack surface that a bad actor could exploit.
Unless the technical regulatory standards prescribe a delegated access model (as described in the response to Question 13) these are likely to remain the highest risk areas.
1. https://fidoalliance.org/specifications/overview/
The most appropriate mechanism for secure identification of AIS/PIS providers by ASPSPs would be a Public Key Infrastructure (PKI) mechanism whereby keys are issued to AIS/PIS providers by a certificate authority (CA) that is trusted by all ASPSPs. The AIS/PIS provider digitally signs each message and also includes a digital certificate with each message. This allows the ASPSP to validate that the entity that signed the message corresponds with the identity asserted in the certificate, and that the certificate is bona-fide since it is signed by the trusted CA. Hence an ASPSP can securely identify the sender of the message without requiring prior knowledge of the provider or pre-sharing of keys.
One consideration when using PKI is that certificates may be invalidated (revoked), for example if the corresponding signing key is compromised. Two mechanisms are available to check certificate validity. One uses the Online Certificate Status Protocol to check the validity of a certificate in real time. This is the most accurate approach, but does add to transaction latency and network load. The alternative is to use a Certificate Revocation List (CRL) which is a list of revoked certificates. The drawback with this approach is that CRLs are only circulated periodically, so many transactions may be initiated using a revoked certificate before the ASPSP is informed that the certificate is no longer valid.
Use of PKI and digital signatures could leverage the eIDAS regulation as discussed in Questions 19 & 20.
A better approach would be for the technical regulatory standards to explicitly state the areas in which flexibility and technical innovation are possible, with a view to avoiding the need to re-visit primary legislation described above.
The e-IDAS regulation is targeted at cross-border use of electronic identification, and explicitly states that it “does not aim to intervene with regard to electronic identity management systems and related infrastructures established in Member States”. ASPSPs already have mechanisms in place for secure authentication of their own customers, and while the regulation encourages Member states to “encourage the private sector to voluntarily use electronic identification means under a notified scheme for identification purposes when needed for online services or electronic transactions”, it would not be appropriate for the regulatory technical standards to try to impose a notified scheme on ASPSPs that already have a different solution in place.
The situation regarding secure identification of AIS/PIS providers to ASPSPs is different in two crucial respects. Firstly, there is not necessarily any pre-established trust relationship between a AIS/PIS provider and an ASPSP, and this is exactly the situation that a public key infrastructure is designed to address (see discussion of Question 17). Secondly, since AIS/PIS provider is a new category of organization having a unique business relationship with ASPSPs, the ASPSPs do not have pre-existing mechanisms in place to authenticate them. Specifying an e-IDAS mechanism as the authentication mechanism would not impact current solutions or investments.
For the purpose of secure identification of AIS/PIS providers to ASPSPs, it would be possible to specify that all qualified trust services could be accepted as the root CA for certificates (“qualified certificate”) presented by the AIS/PIS along with the digital signature (“electronic seal”) on the message.
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
Sending of instructions to a PSP by email is an ambiguous case, midway between online and offline instructions. It is not explicitly mentioned as an excluded case in Recital 95.2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
Ultimately “possession” elements must be hardware. Data can be copied unless held in a secure element, which could be a card, SIM or mobile handset. If data used as a “possession” element is held on a mobile device outside of a secure element, it can be compromised by malware attacks on the device. Some companies incorrectly claim to provide security without hardware by using a secret algorithm to scramble or encrypt the sensitive data. The Open Web Application Security Project explicitly identifies such “security by obscurity”[1] as a weak security control that nearly always fails. If authentication data is held on the device, it must be properly encrypted using a key held in a hardware secure element, hence unusable without physical possession of the device.1. https://www.owasp.org/index.php/Avoid_security_by_obscurity
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
In their review of behaviour-based authentication, Yampolskiy and Govindaraju[1] identify five categories of interaction. They conclude that human-computer interaction characteristics such as keyboard, mouse and haptic interaction “may be used for identification purposes but are not reliable enough to be employed in that capacity in the real world applications”. Only two categories are believed to be suitable for reliable large scale person identification: signature/handwriting and speech. Of these, only speech/voice would be useful in the context of access to account, especially when initiating the transaction from a mobile phone. It is debatable whether this should be classified as a behaviour-based characteristic or a biometric measure.Even though most behaviour-based characteristics cannot be used for “strong” consumer authentication, the PSD2 acknowledges that low risk transactions require a lower level of authentication than high risk transactions. Behaviour-based characteristics can be used as one factor in the risk assessment to determine the appropriate level of authentication. An escalating (step-up) authentication strategy could range from a no-authentication requirement for a micropayment made from an IP address habitually used by the consumer, to a single-factor authentication for low value transactions like a contactless payment, to two-factor authentication for a high value internet purchase, and to further measures such as a phone call for very high value transactions. A differentiating factor for PSPs may well be the simplicity of the consumer journey, not requiring intrusive authentication measures, which would be enabled by the PSP’s sophisticated risk evaluation capability.
1. http://cecs.louisville.edu/ry/Behavioral.pdf
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
An approach that uses the mobile or wearable device as the “possession” authentication element must keep the second (knowledge or inherence) factor independent from the device. This means that a static “knowledge” element (e.g. a password) would be appropriate, as would a biometric “inherence” element such as a fingerprint or heartbeat pattern. The drawback with both of these approached is that the second factor is static, which is not good practice. Passwords can be changed in principle, but in practice people do not change them frequently, and weak passwords can be compromised quite easily. Nevertheless, simple 4-digit PINs are still considered adequate to secure debit card transactions at ATM and POS. Biometric factors are inherently unchangeable, but of sufficient randomness and complexity to defy compromise by guessing (though still vulnerable to attack by copying, as proved by the cloning of German defence minister Ursula von der Leyen’s thumbprint from a photo[1]).A common approach to making the second factor dynamic (mentioned in Recital 96) is to deliver the “knowledge” element (e.g. a Transaction Authentication Number (TAN) or one-time password) to a mobile or wearable device wearable via text or push message. This is a sensible approach for an e-commerce transaction initiated from a PC, because a fraudster initiating a transaction via a laptop or PC is unlikely to be in possession of the customer’s mobile device.
Unfortunately, for m-commerce this approach of sending a TAN to the device actually makes matters worse instead of better. If the fraudster has control of the “possession” element (the mobile device), and the “knowledge” element is delivered to that same device, the fraudster now has the two elements required to complete the transaction. Any approach that uses the device on which the transaction is being initiated as both the “possession” element and the channel by which the “knowledge” element is received is clearly flawed. This issue is mentioned in paragraph 32 of the DP.
1. http://www.bbc.co.uk/news/technology-30623611
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
It is important to draw a distinction between authentication (establishing the identity of the PSU) and authorisation (PSU giving permission for a specific transaction to be performed). The PSU must be authenticated before they can authorise a transaction, so authentication is a prerequisite of authorisation, but the two processes are distinct. Dynamic linking refers to authorisation, not authentication.Dynamic linking of authorisation to transaction elements is necessary because even bona-fide TPPs have a “man in the middle” role between PSU and ASPSP. A genuine TPP will display the same transaction details to the PSU as are sent in the instruction to the ASPSP, but a bogus (or compromised) TPP could display to the consumer the details of the transaction that they intend to carry out, but send a completely different instruction the ASPSP (e.g. a payment of a higher amount to the fraudster’s account). To prevent this type of attack, it is necessary to guarantee that the transaction details presented to the customer match the transaction details sent to the ASPSP.
The gold standard of dynamic linking is the approach used by EMV cards. This takes key data of the transaction such as transaction amount currency, hashes them, and digitally signs them using a dynamically-generated key[1]. The calculation is carried out by the EMV card, and the result is known as an Authorisation Request Cryptogram (ARQC), which is sent to the card issuer as part of the transaction request. The issuer is able to carry out the same calculation which validates three things: i) the ARQC was generated by a bona-fide card; ii) the key data of the transaction have not been changed since the ARQC was generated; and iii) the ARQC is associated with this specific transaction. It can also indirectly authenticate the customer, as the card is able to directly validate the cardholder’s PIN, and will not generate the ARQC without cardholder authorisation (as mentioned in paragraph 31 of the DP).
Unfortunately, even EMV falls short of the requirements for dynamic linking. For one thing, the key data used to generate the ARQC do not include the merchant (payee) details – one of the features exploited in the attack described by Newcastle University researchers Emms et al[2]. Another weakness is that customers have no choice but to trust the terminal when it displays the amount of the transaction, which allows relay attacks as described by University of Cambridge researchers Drimer and Murdoch[3].
A comprehensive approach to dynamic linking would require a trusted app (e.g. one provided by the ASPSP), running in trusted hardware (e.g. the PSU’s mobile phone or wearable) where all input and output functions are protected against compromise by malware, with a hardware cryptographic element and protected key store, creating a digital signature across more transaction data elements than are included in the EMV ARQC calculation. The FIDO Alliance[4] has an architecture that supports “What You See is What You Sign” mode.
Dynamic linking in the absence of hardware cryptography and security-hardened device presents significant challenges. A naïve suggestion is for the PSP to send a text or push message to the consumer, containing the payee’s name and account number and the payment amount as well the authorisation code. For a transaction initiated on a mobile device the approach is insecure because it makes the “knowledge” element dependent on the “possession” element, so does not even provide secure two-factor authentication (see response to Question 4 above), let alone secure dynamic linking.
Irrespective of the mechanism used to dynamically link customer authorisation to a specific transaction, handling of recurring transactions is problematic. A normal transaction is initiated by the PSU, but a recurring transaction is initiated by (or on behalf of) the payee. In some cases it may be possible and desirable to obtain explicit authorisation from the payer for each occurrence, which would require delivering a notification to the PSU that a transaction is awaiting approval, and a secure method of retrieving and approving the transaction. In other cases (e.g. low value or micropayments) the PSU would not want to explicitly authorise each transaction. This could be achieved by means of a set of rules associated with the initial framework agreement with the PIS provider.
1. https://crypto.stanford.edu/~dabo/courses/cs255_winter14/lectures/EMV.pdf
2. http://homepages.cs.ncl.ac.uk/budi.arief/home.formal/Papers/CCS2014.pdf
3. https://www.cl.cam.ac.uk/research/security/banking/relay/
4. https://fidoalliance.org/specifications/overview/
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
Apple Pay, Android Pay and the like come closest to meeting the criteria of independence and dynamic linking. The combination of hardware crypto-security, a trusted app, and a biometric second factor all combine to give the required level of security. The FIDO Alliance mentioned in the discussion of Question 5 provides open specifications for mobile solutions to meet these criteria.The Zapp system in the UK meets the requirement in a different way. The e-commerce or m-commerce merchant passes the transaction instruction to the ASPSP via a back-channel not involving the initiating device. The ASPSP returns a TAN to the merchant, which is presented to the PSU to enter into an app provided by the ASPSP. The app uses the TAN entered by the PSU to retrieve the linked transaction from the ASPSP. The app presents the transaction details to the PSU to authorise, using whatever method of authentication I required by the ASPSP’s app. This approach has the benefit of not requiring special cryptographic support beyond the TLS used to secure communications between mobile device and ASPSP.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
The list of exemptions provided seems sensible, and the DP rightly says that it lists exemptions could apply, rather than where exemptions shall apply.One area that definitely requires clarification is the provision in Article 74 (2) that says “Where the payee or the payment service provider of the payee fails to accept strong customer authentication, it shall refund the financial damage caused to the payer’s payment service provider”. This does not make sense as stated. Strong customer authentication is a concern of the payer’s AIS/PIS provider and ASPSP. The payee and the payee’s PSP play no role in customer authentication. The regulatory technical standards need to explain this article.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
A key consideration is which party performs the risk analysis. A smooth customer journey is a highly desirable characteristic for a payment transaction, while strong customer authentication tends to be intrusive and to cause a less smooth journey. Hence an organization’s ability to instantly and accurately assess the risk level of a specific transaction, and to apply the least intrusive level of customer authentication commensurate with the organization’s risk appetite, should be considered an important competitive consideration.It follows from the above that a PIS provider should be able to make their own risk assessment and decide the level of customer authentication that they are prepared to apply. (Some high volume merchants such as supermarkets already do this for card transactions, avoiding the time penalty of making an online authorisation for transactions that they assess to be low risk). The suggestion in DP 42 D that the regulatory technical standards should describe in detail the transaction risk analysis criteria would limit the freedom for PIS providers to compete in this area.
9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
There are many factors that an organization may wish to consider in making a risk assessment for a transaction, such as: Geolocation; mode of payment (e.g. cardholder present / not present); risk level of the merchant category of the payee.It is important to note that some risk assessment criteria will only be available to the ASPSP, and not to the PIS provider. Examples include: opening date of the account, recent change of address, recent transaction history for the customer as a whole (the PIS provider will only have the history of payments initiated by that provider). The ASPSP may even take into account the prevalence of fraudulent transactions initiated by that PIS provider. This raises the question of whether the ASPSP may block a transaction based on their own risk assessment which differs from that of the PIS provider.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
The principles set out in DP 52 i-iii are sound and non-controversial, but the proposal to enforce the application of the principles is contentious – see response to Question 13 below.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
DP 51 B is rather confusing. Credentials stored on a server would be stored in the database, not in the hardware security module (not model). The hardware security module is used to store encryption keys securely, and to carry out cryptographic operations involving those keys.12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
A promising solution to the challenge of secure enrolment is offered by the FIDO Alliance registration process[1]. This eliminates the transmission of PSCs by having the user’s trusted device (mobile or wearable) perform a local authentication. Communication with the remote site uses standard public key cryptography.The FIDO solution has the added advantage of using “pluggable local authentication”, so is able to support a variety of authentication methods such as secure PIN, biometrics (face, voice, iris, fingerprint recognition) etc. This capability supports the PSD2 and EBA’s agenda to facilitate innovation.
1. https://fidoalliance.org/specifications/overview/
13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
The proposal for third party certification of technical components, devices and channels seems similar to the approach taken to enforcement of the PCI (Payment Card Industry) security standard by the cards industry. The cost to a single merchant of compliance to PCI has been estimated at £5 million[1], and the total cost to industry of applying and enforcing the PCI standard is incalculable.The tragedy is that despite the staggering costs incurred, the approach has been ineffective, with massive data thefts occurring from supposedly PCI-compliant organizations such as Target and Heartland. Gartner analyst Avivah Litan states baldly that the PCI standard “has largely been a failure”[2]. It would seem perverse for the regulatory technical standards to impose an approach that has proven to be such an epic failure in a closely related area.
One important component of an alternative approach is to minimise the transmission and sharing of PSCs. Rather than requiring consumers to enter security credentials into third party apps or websites, a secure delegated access model such as OpenID Connect[3] allows the issuer of the PSC to authenticate the PSU on behalf of the third party.
1. http://cdn.ttgtmedia.com/searchSecurityUK/downloads/RHUL_Bradley_2010.pdf
2. http://blogs.gartner.com/avivah-litan/2014/01/20/how-pci-failed-target-and-u-s-consumers/
3. http://openid.net/connect/
14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
At present, the segment of the chain with the highest risk is in the interaction between the PSU and PIS provider. Companies such as Sofort and Trustly require consumers to enter PSCs into their own website, then relay these to the ASPSP. There are two specific risks in this approach:• Encouraging consumers to enter PSCs into websites other than that of their ASPSP increases their vulnerability to social engineering attacks such as phishing and man-in-the-middle attacks. The average consumer will not be able to distinguish between a bona-fide PIS provider and a fraudulent site when asked to provide their PSCs
• Some “screen scraping” PIS providers make misleading statements about the security of PSCs, claiming that the credentials are safe because they are always encrypted. It is true that the credentials are encrypted using TLS between the PSU’s browser and the PIS provider’s servers, and again between the PIS provider’s servers and the ASPSP’s servers. The crucial point is that the chain of encryption is broken as the credentials pass across the PIS provider’s server, where they appear (albeit briefly) in clear text. Even if the PIS provider has the best of intentions, this break in encryption provides an attack surface that a bad actor could exploit.
Unless the technical regulatory standards prescribe a delegated access model (as described in the response to Question 13) these are likely to remain the highest risk areas.
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
Yes, the clarifications are comprehensive and suitable.16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
The regulation should specify the technical standards that are prescriptive and unambiguous regarding implementation of the interoperability elements, but which leave flexibility in implementation of the provider-specific elements. Examples of unambiguous technical standards for interoperability are TLS for message privacy and X.509 for digital certificates. Examples of standards that leave flexibility in implementation of the provider-specific elements include OpendID Connect for authentication/authorisation and the FIDO alliance specifications for biometrics[1].1. https://fidoalliance.org/specifications/overview/
17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
The industry standard TLS encryption is sufficient to ensure secure communications from point to point. Depending on the security framework adopted, certain data elements may require end-to-end encryption such as that used by the EMV standard.The most appropriate mechanism for secure identification of AIS/PIS providers by ASPSPs would be a Public Key Infrastructure (PKI) mechanism whereby keys are issued to AIS/PIS providers by a certificate authority (CA) that is trusted by all ASPSPs. The AIS/PIS provider digitally signs each message and also includes a digital certificate with each message. This allows the ASPSP to validate that the entity that signed the message corresponds with the identity asserted in the certificate, and that the certificate is bona-fide since it is signed by the trusted CA. Hence an ASPSP can securely identify the sender of the message without requiring prior knowledge of the provider or pre-sharing of keys.
One consideration when using PKI is that certificates may be invalidated (revoked), for example if the corresponding signing key is compromised. Two mechanisms are available to check certificate validity. One uses the Online Certificate Status Protocol to check the validity of a certificate in real time. This is the most accurate approach, but does add to transaction latency and network load. The alternative is to use a Certificate Revocation List (CRL) which is a list of revoked certificates. The drawback with this approach is that CRLs are only circulated periodically, so many transactions may be initiated using a revoked certificate before the ASPSP is informed that the certificate is no longer valid.
Use of PKI and digital signatures could leverage the eIDAS regulation as discussed in Questions 19 & 20.
18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
The introduction of new business models, as opposed to new technical mechanisms such as enhanced biometrics, cannot be handled by the technical regulatory standards alone, as it may well require adjustment of the primary legislation. To pick up the example given in the question, of AIS/PIS providers issuing their own credentials, that would introduce a completely new risk dynamic between AIS/PIS providers and ASPSP, and would require a re-examination of the responsibilities and liabilities of the various parties. For example, if the PIS provider takes on responsibility for authentication and authorisation, it would seem reasonable for Article 73 (2) to also place the responsibility on the PIS provider to provide the refund to the ASPSP immediately in case of unauthorised payments, until such time as the PIS provider can prove that the payment was indeed authorised by the PSU.A better approach would be for the technical regulatory standards to explicitly state the areas in which flexibility and technical innovation are possible, with a view to avoiding the need to re-visit primary legislation described above.
19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
The e-IDAS regulation is not a suitable solution for strong customer authentication, but it is suitable for secure identification of AIS/PIS providers to an ASPSP.The e-IDAS regulation is targeted at cross-border use of electronic identification, and explicitly states that it “does not aim to intervene with regard to electronic identity management systems and related infrastructures established in Member States”. ASPSPs already have mechanisms in place for secure authentication of their own customers, and while the regulation encourages Member states to “encourage the private sector to voluntarily use electronic identification means under a notified scheme for identification purposes when needed for online services or electronic transactions”, it would not be appropriate for the regulatory technical standards to try to impose a notified scheme on ASPSPs that already have a different solution in place.
The situation regarding secure identification of AIS/PIS providers to ASPSPs is different in two crucial respects. Firstly, there is not necessarily any pre-established trust relationship between a AIS/PIS provider and an ASPSP, and this is exactly the situation that a public key infrastructure is designed to address (see discussion of Question 17). Secondly, since AIS/PIS provider is a new category of organization having a unique business relationship with ASPSPs, the ASPSPs do not have pre-existing mechanisms in place to authenticate them. Specifying an e-IDAS mechanism as the authentication mechanism would not impact current solutions or investments.
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
For reasons given in the discussion of Question 19, e-IDAS is not an appropriate solution to handling PSCs. Other solutions such as OpenID Connect support secure delegated access without the need to involve central bodies such as “qualified trust providers”. These alternative approaches are likely to offer higher levels of competition and innovation, and hence lower costs and administrative overheads, than “qualified trust providers”.For the purpose of secure identification of AIS/PIS providers to ASPSPs, it would be possible to specify that all qualified trust services could be accepted as the root CA for certificates (“qualified certificate”) presented by the AIS/PIS along with the digital signature (“electronic seal”) on the message.