Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Data (e.g. certificates in files) are stored on clients’ devices like USB stick, PC, etc. and it is users’ responsibility to protect these files/data from stealing or copying. Users’ education is needed to explain that these data can be provided only on trusted sites of PSC issuer (bank). It will be crucial to solve authentication processing when initiating payment by 3rd party provider, so that user will provide credentials only on trusted sites of PCS issuer and they are not in possession of 3rd party.
Regarding to credentials stored in a mobile devices - mobile device with secret stored in app’s internal storage on condition that operating system ensures confidentiality in reasonable way (applications are not allowed to read other application’s data).
Regarding to possible practical implementation - behaviour-based characteristics shall be checked in trusted environment controlled by bank. Liveness shall be ensured e.g. by random challenge (when possible). E. g. user shall say or type given random phrase that is unlikely to be said/typed and recorded in real-life scenario.
Under ordinary circumstances, both shall be considered independent:
• physical key (possession) and combination lock sequence (knowledge) to open a safe
• encrypted secret (possession) stored in internal storage of mobile device and password (knowledge) used to decrypt the secret used to authorize a payment
An attacker can indeed apply force either against the authorized person or against the device (malware) to gain access. In both cases these acts of violence be considered as extraordinary circumstances.
Proposed strong customer authentication is Retail-centric. It does not propose a solution for batch payment processing common in Corporate domain.
E.g. how would you present information for 10 000 transactions being signed in a batch? We believe that e.g. SHA256 digest can be introduced as another possibility for dynamically binding the OTP with transaction.
Conclusion: We suggest to allow in specific cases allow ASPSP not to ensure dynamic linking when considering other aspects of respective activity or parameters of transactions (low value payments, low risk payment evaluated by fraud detection system, batch payments etc.)
1. Mobile device stores secret which counterpart is stored server-side (e.g. private and public key).
2. Secret is stored in encrypted form. Encryption/decryption key is derived from user password (PIN). Password derivation and encryption schemes are built so that wrong PIN allows decryption, decrypted secret is wrong and this fact cannot be validated without communication with server.
3. During operation authorization, user is asked to enter the PIN which is used to decrypt the secret in run-time.
4. Secret is used to sign the key operation data (payee, amount …) displayed to customer (What you see is what you sign principle, abbr. WYSIWYS), together with operation identification (random id, timestamp).
5. Signature together with operation data is sent to the back-end system.
6. Back-end system validates
• the signature of received operation data (integrity check)
• operation identification (to prevent replay attack)
7. If signature is valid, back-end system performs the operation
Fulfilled objectives:
• Dynamic linking: received signature is valid only for operation data displayed to customer and confirmed by himself (WYSIWYS).
• Independence:
o Device itself (e.g. stolen) cannot be used –encrypted secret is useless without PIN. Brute-force attack (guessing PIN) cannot be performed without interaction with back-end system, which is thus able to detect the attack and block the compromised device.
o Password itself (e.g. disclosed by accident) cannot be used – even if the attacker would be able to perform client-side authorization logic, he is not able to generate a valid signature without customer’s secret stored on mobile device.
While in use for 3 years, there is no report of single incident compromising security of this scheme.
Other point of view is to let clients decide what level of security they prefer. There are segments of clients which prefer user friendliness to security when accessing particular services (e.g. passive view of the account where there is no risk of fraudulent transactions, automatic download of statements secured by password only, e-mail enclosed statements without password protection (popular among students))
There must be invented some process of clients authentication chain (PSU – 3rd party - bank) where clients are providing credentials on banks’ websites. Otherwise clients’ credentials would be considered as potentially compromised and bank would have to focus on another part of payment security chain (typically fraud detection systems). Then also it becomes meaningless require strong authentication as it is inherently complicating authentication of payments.
• Each time customer accesses his PISP/AISP account, PISP/AISP redirects him to PSP’s infrastructure for authentication. Successful authentication leads to access token issue that grants third party application time-limited access to account.
• Almost the same, but long-term and not automated: In application controlled by PSP (e. g. Internet Banking), customer grants access to certain PISP/AISP. Application generates a single-purpose token and customer gives this token to PISP/AISP. PISP/AISP uses this token for authentication for limited time. User can revoke the token any time in application controlled by PSP.
Topic c., d., e., and f. need to be defined. By default, obsolete technologies should be banned – such as SHA-1, MD5 in case of hashing algorithms, anything less the TLS 1.1 for a connection setup.
A unified common standard needs to be defined on the EU level. This would ensure at least standard one way for AIS/PIS to be integrated with ASPSs. The standard should ensure an option for direct connection between AIS/PIS and ASPSPs so AIS/PIS are not forced to use “services” of some central integrator. On the other hand, central integration concept needs to be supported as an option.
In case, that AIS/PIS would have a unique solution he could address ASPSs directly or get integrated via a central integrator.
It would be beneficial to include an option to make the payment guaranteed. The common standard could be then used as a unified alternative for eCommerce payment button solutions.
It would be benefical to include an option to make it a fast payment. The common standard could be then used as a unified alternative for eCommerce payment button solutions.
Let us consider minimalistic strictly defined API defining:
• just two operations: basic payment initialization and basic account history fetch
• request/response message data model for both operations (e. s. taking essentials from ISO 20022 vocabulary
• representation of these messages (e. g. in form of JSON objects)
• transport protocol (e. g. HTTPS)
• authentication and authorization schema where these security aspects are relayed to ASPSP infrastructure (e. g. via OAuth standard)
Pros:
• Any PISP/AISP is able to develop single API client to interact with any bank in EU
• Package solutions could emerge in software industry helping ASPSP to
• Integration costs for ASPSP are limited because interface is simple
Having costs limited to minimal possible amount, APSPSs are still able to build own, functionality-rich interface beside this mandatory “EURO-API” when an business opportunity is identified.
Generally: as common and secure open standards of communication we assume this standards:
o Communication layer via RESTful over HTTPs (RFC 2818, 5785, 7230, 7231, 7232, 7233, 7234, 7235, 7236, 7237, RFC 7540, RFC 6690)
o Authentication and authorization schema based on industry standards OAuth 1.0/2.0 (RFC 5849 or RFC 6749, RFC 7521) or SAML 2.0 (standard defined via OASIS)
o Format for data Exchange based on JavaScript Object Notation (RFC 7159)
o Ontology developed from OMG-FIBO (Object management Group -Financial Industry Business Ontology) or/and ISO 20022
• REST + JSON as communication protocol
• ISO 20022 for data model definition (although default syntax is XML, the same data in the same structure can be also marshalled to JSON messages more suitable for mobile devices)
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.
Online setting of account parameters, parameters of client's authenitcation etc. – shall be the most protected, for the attacker not to be able to bypass strong authentication by tampering with the settings (e. g. pairing other security device replacing customer’s one, phone number change etc.).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?
We consider data as a possession element. As an example we can provide certificate saved in a file (*.p12, *. pfx extensions), in a browser or in a secured storage as a part of strong authentication.Data (e.g. certificates in files) are stored on clients’ devices like USB stick, PC, etc. and it is users’ responsibility to protect these files/data from stealing or copying. Users’ education is needed to explain that these data can be provided only on trusted sites of PSC issuer (bank). It will be crucial to solve authentication processing when initiating payment by 3rd party provider, so that user will provide credentials only on trusted sites of PCS issuer and they are not in possession of 3rd party.
Regarding to credentials stored in a mobile devices - mobile device with secret stored in app’s internal storage on condition that operating system ensures confidentiality in reasonable way (applications are not allowed to read other application’s data).
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?
When providing online services we always need to balance between user friendliness and security. We would like to use behavior based characteristics of transactions as a part of decision mechanism regarding to level of authentication. If a sophisticated mechanism decide, that the transaction is reflecting typical behavior of a client we do not want him to bother with complicated strong authorization mechanism.Regarding to possible practical implementation - behaviour-based characteristics shall be checked in trusted environment controlled by bank. Liveness shall be ensured e.g. by random challenge (when possible). E. g. user shall say or type given random phrase that is unlikely to be said/typed and recorded in real-life scenario.
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)?
Independence shall be considered with respect to circumstances (i.e. independent under ordinary circumstances).Under ordinary circumstances, both shall be considered independent:
• physical key (possession) and combination lock sequence (knowledge) to open a safe
• encrypted secret (possession) stored in internal storage of mobile device and password (knowledge) used to decrypt the secret used to authorize a payment
An attacker can indeed apply force either against the authorized person or against the device (malware) to gain access. In both cases these acts of violence be considered as extraordinary circumstances.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
There can be some troubles when using some specific solutions such as an offline OTP tokens. Offline OTP tokens are based on time synchronization without transaction linking.Proposed strong customer authentication is Retail-centric. It does not propose a solution for batch payment processing common in Corporate domain.
E.g. how would you present information for 10 000 transactions being signed in a batch? We believe that e.g. SHA256 digest can be introduced as another possibility for dynamically binding the OTP with transaction.
Conclusion: We suggest to allow in specific cases allow ASPSP not to ensure dynamic linking when considering other aspects of respective activity or parameters of transactions (low value payments, low risk payment evaluated by fraud detection system, batch payments etc.)
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
Example:1. Mobile device stores secret which counterpart is stored server-side (e.g. private and public key).
2. Secret is stored in encrypted form. Encryption/decryption key is derived from user password (PIN). Password derivation and encryption schemes are built so that wrong PIN allows decryption, decrypted secret is wrong and this fact cannot be validated without communication with server.
3. During operation authorization, user is asked to enter the PIN which is used to decrypt the secret in run-time.
4. Secret is used to sign the key operation data (payee, amount …) displayed to customer (What you see is what you sign principle, abbr. WYSIWYS), together with operation identification (random id, timestamp).
5. Signature together with operation data is sent to the back-end system.
6. Back-end system validates
• the signature of received operation data (integrity check)
• operation identification (to prevent replay attack)
7. If signature is valid, back-end system performs the operation
Fulfilled objectives:
• Dynamic linking: received signature is valid only for operation data displayed to customer and confirmed by himself (WYSIWYS).
• Independence:
o Device itself (e.g. stolen) cannot be used –encrypted secret is useless without PIN. Brute-force attack (guessing PIN) cannot be performed without interaction with back-end system, which is thus able to detect the attack and block the compromised device.
o Password itself (e.g. disclosed by accident) cannot be used – even if the attacker would be able to perform client-side authorization logic, he is not able to generate a valid signature without customer’s secret stored on mobile device.
While in use for 3 years, there is no report of single incident compromising security of this scheme.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
We prefer some kind of a list of examples rather than exhaustive list of possible exemptions. ASPSP should be able to decide whether strong authentication is needed or where are risk covered by other methods. For example if ASPSP is making huge investments into ensuring of clients end-points protection, detection mechanism of fraudulent activities and clients’ education, than it should be allowed to use weaker authentication (to deliver comfort and client friendliness) as whole chain of payment entering and processing is secured in other segments of transaction processing.Other point of view is to let clients decide what level of security they prefer. There are segments of clients which prefer user friendliness to security when accessing particular services (e.g. passive view of the account where there is no risk of fraudulent transactions, automatic download of statements secured by password only, e-mail enclosed statements without password protection (popular among students))
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
N/A9. 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?
N/A10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
N/A11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
The biggest issue is an authentication process when initiating payments using newly defined payment initiation service. It is not acceptable to allow a payment service user (PSU) to provide credentials issued by his bank to any 3rd party. PSU are continuously educated to provide credentials only on a trusted website of his bank. If it would be allowed to provide credentials on 3rd party webpages, it will completely confuse PSU and it will pave the way for fraudsters pretending to be certified 3rd party PIS provider. Current typical phishing vector is to redirect clients to fake “payment gateways” and to gather their credentials. We are educating clients that these types of gateways are fake and learn them not to provide credentials on these types of webpages. We have also noticed first confusion of clients related to these types of services. A client notified bank about possible fraudulent webpages gathering credentials, after investigation the bank has found out that this was a service of payment service provider (Sofort), which is using some kind of credentials redirection model. This is a typical example of the confusion of clients.There must be invented some process of clients authentication chain (PSU – 3rd party - bank) where clients are providing credentials on banks’ websites. Otherwise clients’ credentials would be considered as potentially compromised and bank would have to focus on another part of payment security chain (typically fraud detection systems). Then also it becomes meaningless require strong authentication as it is inherently complicating authentication of payments.
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?
Regarding enrolment via PISP/AISP (pairing account in PISP/AISP application to bank account), we see two options:• Each time customer accesses his PISP/AISP account, PISP/AISP redirects him to PSP’s infrastructure for authentication. Successful authentication leads to access token issue that grants third party application time-limited access to account.
• Almost the same, but long-term and not automated: In application controlled by PSP (e. g. Internet Banking), customer grants access to certain PISP/AISP. Application generates a single-purpose token and customer gives this token to PISP/AISP. PISP/AISP uses this token for authentication for limited time. User can revoke the token any time in application controlled by PSP.
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?
Alternative is to consider third parties to be untrusted. Then, every authentication and authorization of operation shall occur in environment of PSP and therefore is independent on third party. E. g. customer initiates payment in PISP, payment order is sent to PSP which continues in authorization as if it were a payment initiated in its own system. Customers authorizes the operation having full detail displayed in trusted environment.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?
The weakest point of the whole chain is a client/payment service user. Comprehensive education related to cybersecurity and prudent behavior on internet is needed. As already mentioned, the biggest issue would be to explain authorization of payments when using payment initiation services to not well educated PSUs who would be the most vulnerable segment endangered by phishing, malware and other threats15. 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?
Topic b. has two sides – legal and technical. The technical standard needs to enforce a concrete AIS/PIS identification in the request and digital signature of these requests. The legal side of entrusting AIS/PIS should be either left to ASPSPs (legally neutral alternative) or should enforce a contractual consent by the end customer (account owner) for a concrete AIS/PIS (legally strict alternative). The rationale behind is that we are talking about banking secrecy and end customer funds. The access needs to be given to AIS/PIS based on an agreement with the end customer.Topic c., d., e., and f. need to be defined. By default, obsolete technologies should be banned – such as SHA-1, MD5 in case of hashing algorithms, anything less the TLS 1.1 for a connection setup.
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?
Ad D]A unified common standard needs to be defined on the EU level. This would ensure at least standard one way for AIS/PIS to be integrated with ASPSs. The standard should ensure an option for direct connection between AIS/PIS and ASPSPs so AIS/PIS are not forced to use “services” of some central integrator. On the other hand, central integration concept needs to be supported as an option.
In case, that AIS/PIS would have a unique solution he could address ASPSs directly or get integrated via a central integrator.
It would be beneficial to include an option to make the payment guaranteed. The common standard could be then used as a unified alternative for eCommerce payment button solutions.
It would be benefical to include an option to make it a fast payment. The common standard could be then used as a unified alternative for eCommerce payment button solutions.
Let us consider minimalistic strictly defined API defining:
• just two operations: basic payment initialization and basic account history fetch
• request/response message data model for both operations (e. s. taking essentials from ISO 20022 vocabulary
• representation of these messages (e. g. in form of JSON objects)
• transport protocol (e. g. HTTPS)
• authentication and authorization schema where these security aspects are relayed to ASPSP infrastructure (e. g. via OAuth standard)
Pros:
• Any PISP/AISP is able to develop single API client to interact with any bank in EU
• Package solutions could emerge in software industry helping ASPSP to
• Integration costs for ASPSP are limited because interface is simple
Having costs limited to minimal possible amount, APSPSs are still able to build own, functionality-rich interface beside this mandatory “EURO-API” when an business opportunity is identified.
Generally: as common and secure open standards of communication we assume this standards:
o Communication layer via RESTful over HTTPs (RFC 2818, 5785, 7230, 7231, 7232, 7233, 7234, 7235, 7236, 7237, RFC 7540, RFC 6690)
o Authentication and authorization schema based on industry standards OAuth 1.0/2.0 (RFC 5849 or RFC 6749, RFC 7521) or SAML 2.0 (standard defined via OASIS)
o Format for data Exchange based on JavaScript Object Notation (RFC 7159)
o Ontology developed from OMG-FIBO (Object management Group -Financial Industry Business Ontology) or/and ISO 20022
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?
• PKI for PISP/AISP–ASPSP communication security• REST + JSON as communication protocol
• ISO 20022 for data model definition (although default syntax is XML, the same data in the same structure can be also marshalled to JSON messages more suitable for mobile devices)