One of the most discussed requirements of the final Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) under PSD2 is the requirement to perform so-called “dynamic linking” to authenticate a financial transaction.
The dynamic linking requirement has three parts. First, it requires a payer to authenticate a financial transaction by calculating an authentication code over certain transaction data (at least the amount and some information identifying the beneficiary), so that the authentication code is linked to this data. Second, the confidentiality and integrity of the transaction data should be protected throughout the authentication process. Third, the online banking user should be aware of the transaction data that they authenticate. This latter requirement is often referred to as “What You See Is What You Sign” (WYSIWYS). This implies that merely showing a hash of the transaction data or a session identifier does not suffice.
The European legislators that drafted PSD2 introduced the dynamic linking requirement to counter man-in-the-middle attacks, whereby an adversary alters the details of a transaction after the payer authenticated the transaction. Such an attack could change a genuine transfer of 100 euro to a friend into a rogue transfer of 1000 euro to an imposter, without the genuine payer noticing. The WYSIWYS requirement intends to avoid social engineering attacks, whereby a payer is convinced to authenticate data they do not understand, and that later turns out to represent a fraudulent transaction. As such, PSD2 goes a step further than the EBA’s Final Guidelines on the Security of Internet Payments, which currently apply in most EU member states and do not require dynamic linking.
For banks, compliance with these PSD2 requirements raises several questions. How can a bank implement dynamic linking into its online or mobile banking application in such a way that it is convenient for the customer? Can SMS be used to implement dynamic linking? And what about batch transactions?
Let’s explore these topics.
Convenient Dynamic Linking
Consider the scenario where a user initiates a financial transaction via an online banking application running within the browser of their PC, using a dedicated hardware token or mobile banking app to authenticate the transaction.
One convenient way to implement dynamic linking relies on the usage of colored QR codes or CRONTO codes. When the user wants to initiate a transaction, they:
- Enter the transaction data into the online banking application in the browser. Based on this transaction data, the banking server generates a color code, representing the encrypted transaction data, and displays this in the browser.
- Scan the color code using the camera of their hardware token or mobile device. The device decodes the color code, decrypts the transaction data, and shows the cleartext transaction data to the customer on-screen.
- Authenticate to their device (e.g. key in the device’s PIN), and it calculates the authentication code over the transaction data using a cryptographic key stored on the device.
This approach meets all dynamic linking requirements described above, and additionally does not require the user to manually enter transaction data onto the device.
An alternative approach, only for mobile, consists of transferring the transaction data from the banking server to the mobile banking app using an encrypted push notification message. Here’s how it works:
- The user receives a push notification message on their phone.
- When they accept it, the mobile banking app opens and shows the transaction data to the user.
- The user authenticates using a fingerprint or face scan, for example.
- The device calculates the authentication code over the transaction data.
- The mobile banking app sends the authentication code back to the customer via the Internet.
This approach also complies with the dynamic linking requirements, and does not require the user to manually enter any data onto the mobile device.
The dynamic linking requirement also applies to batch transactions or bulk payments, whereby multiple transactions to different beneficiaries are combined. More specifically, the final RTS states that, for batch transactions, the authentication code must be specific to both the total amount of money of all transactions combined and to the various beneficiaries.
If the number of beneficiaries is large, it is impractical to show all of them to the user for validation. The following approaches can then be used to balance security and user convenience:
- Show the user the beneficiaries corresponding to transactions with the largest risk.
- Show the user randomly selected beneficiaries.
- Do not show the user any whitelisted beneficiaries.
In any case, it is good practice to include a hash of all transactions into the calculation of the authentication code in order to protect the integrity of all transactions.
Dynamic Linking using SMS?
There is also the question of whether dynamic linking could be implemented using SMS. In this case, the user would receive an SMS message containing the transaction data as well as the authentication code calculated over the transaction data.
Given the requirement to protect the confidentiality and integrity of the transaction data, this would imply the transaction data inside an SMS message needs to be encrypted. It is not clear how the message could then be decrypted on the mobile device without using a dedicated app. The need for a mobile app to process SMS messages undermines one of the primary benefits of SMS.
In summary, banks should approach PSD2 not merely from a compliance point of view – it is important to consider how to optimize the user experience by means of convenient, strong authentication and dynamic linking procedures. For more information, download: PSD2: Which Strong Authentication and Transaction Monitoring Solutions Comply?
OneSpan is one of the partners at Future Digital Finance Forum in Helsinki on 31.10.-1.11.2018. Come meet the OneSpan experts and discuss more. Read more here.