Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Our response to question 2 concerns EBA’s technical model, consisting of the three components “channel”, “mobile application” and “device”. We suggest extending this model by a fourth component called “mobile application module” as described below.
Rationale:
Up to now, EBA wording suggests that mobile banking is only possible using either two physically distinct devices or at least two distinct mobile applications on one physical device. However, there is an established, market-proven solution available using only one mobile banking application on one physical device.. The mobile application consists of two parts: the banking module and the signature module. Both parts communicate each with a server: the banking module communicates with a bank server and the signature module with the security server which is located either at the bank location (with the bank server) or the bank’s IT provider.
The „application channel“ connects the banking module of the mobile banking application to the bank server, while the “security channel” connects the signature module of the same mobile banking application to the security server.
Both channels are encrypted, authenticated and integrity-protected, e.g. by using the TLS protocol and/or public key certificates. Once a transaction is entered by the end user in the „banking module“, it is sent via the application channel to the application server. The application server checks transaction details and forwards a summary of the transaction specific to the amount of the transaction and the payee via the security server over the security channel to the signature module in the mobile application. The signature module will display the transaction details to the end user and ask for approval. Upon approval, the transaction summary is signed using the end user’s private signature key located in the signature module. This private key is only unlocked cryptographically after the security server had checked the security status of the whole mobile app (integrity check – app not modified, device binding – not copied to another mobile device, jailbreak/root detection etc.). Once signed by the signature module, the transaction signature is sent back through the security channel to the security server and forwarded to the application server which then executes the transaction.
Using this approach, security is based on a security anchor outside the mobile device, e.g. the security server. There are 2-App-approaches available on the market from other vendors with separated banking and security logic. Those require the transfer of sensitive data (such as TANs or signatures) between the two apps locally on the unprotected smartphone. In our single-App approach, the transfer of sensitive information happens always over the backend between two servers (security server and bank server) which are located in protected IT environments and much better protected than locally through the mobile device. On the security server side, much more additional online security checks can be applied when required.
Provide evidence:
Our technology is used by 20 banks with more than 6 million end customers worldwide since 2012. For a reference list, please visit http://www.kobil.com/de/implementationen/ . There was not a single fraud case among those customers so far. Furthermore, KOBIL technology is permanently reviewed and audited by external security experts such as Fraunhofer SIT, VDE and other institutions. Appropriate reports and certifications can be provided upon request.
Alternative regulatory options:
The channel, device, mobile application or mobile application module through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device, mobile application or mobile application module used for initiating the electronic payment transaction. If segregation is done on the mobile application module level, an external security server must be applied that performs inherent security checks on the whole mobile application and unlocks the private signature keys only in case of success.
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.
Specific Point:Our response to question 2 concerns EBA’s technical model, consisting of the three components “channel”, “mobile application” and “device”. We suggest extending this model by a fourth component called “mobile application module” as described below.
Rationale:
Up to now, EBA wording suggests that mobile banking is only possible using either two physically distinct devices or at least two distinct mobile applications on one physical device. However, there is an established, market-proven solution available using only one mobile banking application on one physical device.. The mobile application consists of two parts: the banking module and the signature module. Both parts communicate each with a server: the banking module communicates with a bank server and the signature module with the security server which is located either at the bank location (with the bank server) or the bank’s IT provider.
The „application channel“ connects the banking module of the mobile banking application to the bank server, while the “security channel” connects the signature module of the same mobile banking application to the security server.
Both channels are encrypted, authenticated and integrity-protected, e.g. by using the TLS protocol and/or public key certificates. Once a transaction is entered by the end user in the „banking module“, it is sent via the application channel to the application server. The application server checks transaction details and forwards a summary of the transaction specific to the amount of the transaction and the payee via the security server over the security channel to the signature module in the mobile application. The signature module will display the transaction details to the end user and ask for approval. Upon approval, the transaction summary is signed using the end user’s private signature key located in the signature module. This private key is only unlocked cryptographically after the security server had checked the security status of the whole mobile app (integrity check – app not modified, device binding – not copied to another mobile device, jailbreak/root detection etc.). Once signed by the signature module, the transaction signature is sent back through the security channel to the security server and forwarded to the application server which then executes the transaction.
Using this approach, security is based on a security anchor outside the mobile device, e.g. the security server. There are 2-App-approaches available on the market from other vendors with separated banking and security logic. Those require the transfer of sensitive data (such as TANs or signatures) between the two apps locally on the unprotected smartphone. In our single-App approach, the transfer of sensitive information happens always over the backend between two servers (security server and bank server) which are located in protected IT environments and much better protected than locally through the mobile device. On the security server side, much more additional online security checks can be applied when required.
Provide evidence:
Our technology is used by 20 banks with more than 6 million end customers worldwide since 2012. For a reference list, please visit http://www.kobil.com/de/implementationen/ . There was not a single fraud case among those customers so far. Furthermore, KOBIL technology is permanently reviewed and audited by external security experts such as Fraunhofer SIT, VDE and other institutions. Appropriate reports and certifications can be provided upon request.
Alternative regulatory options:
The channel, device, mobile application or mobile application module through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device, mobile application or mobile application module used for initiating the electronic payment transaction. If segregation is done on the mobile application module level, an external security server must be applied that performs inherent security checks on the whole mobile application and unlocks the private signature keys only in case of success.