To reduce fraud in electronic payments, Strong Customer Authentication (SCA) is becoming the norm. This three-part series goes deeper into how to do proper Strong Customer Authentication on mobile devices and which classical approaches are definitely not compliant. This first part introduces Strong Customer Authentication and what it means for mobile authentication. The second part talks about why you need non-repudiation and how to move beyond authentication codes.
With the Payment Services Directive 2 (PSD2), the EU aims to reduce the risk of fraud in electronic payment services. Towards this goal it mandates the adoption of Strong Customer Authentication (SCA). From 14 September 2019, the Regulatory Technical Standard (RTS) on SCA applies. This regulation establishes the technical requirements for the payment services providers (PSPs).
In its 21 June 2019 opinion, the European Banking Authority (EBA) comments on the elements of SCA (individually). However, this opinion does not say anything about the global security of Strong Customer Authentication. We thus need to look deeper into the actual RTS requirements, in combination with EBA opinion, to determine how to achieve SCA in practice.
Strong Customer Authentication
The cornerstone of SCA is the “authentication code”. The authentication code is used both for accessing payment accounts and approving transactions. The authentication codes must be unforgeable and resistant to replay. If applicable, the transaction code must link to the transaction amount. An authentication code is generated based on authentication elements. The authentication code, however, should not reveal any information on the authentication elements used to generate it.
The RTS divides authentication elements in three categories:
- Possession elements (something you have);
- Knowledge elements (something you know);
- Inherence elements (something you are).
For SCA, two or more independent authentication elements from a different category are required. The breach of one of the authentication elements should not imply the breach of any of the other elements. This ensures that no valid authentication can take place based on only one of the elements.
SCA and mobile authentication
We will focus on mobile app approaches and which authentication elements make sense to achieve SCA. It should be noted that the mere fact of having an app installed on a mobile device does not constitute a possession element in the sense of SCA. A mobile app as such is a replication of other installs of that app, and replication of possession elements needs to be prevented. Your mobile app will thus need to fulfil further requirements.
What makes possession elements interesting is that these do not require any effort form the user. One of the criteria in the RTS is that measures should be taken to avoid replication of possession elements. As such, you cannot directly disclose the value of the element in order to prove possession. This rules out one of the most straightforward ways of demonstrating possession of a phone by creating a ‘profile’ of the device. These profiles typically consist of a number of device identifiers such as the model, IMEI, SIM card identifiers, phone number… Even though such a profile is likely unique, it is definitely not secure against replication. Any app on the mobile device might read these to create a remote, fake environment with identical identifiers.
Instead of sending over a profile, some value needs to be derived from a possession element that itself remains secret. The most common example is a cryptographic key, where that key is used in an algorithm to prove possession of the key. There are many approaches for storing and using cryptographic keys on a phone. These approaches range from simple file storage, using the keystore of the operating system, to using secure hardware. Another question that needs to be addressed is which kind of cryptographic algorithm to use. As we will show in part 3 of this series, the use of public-key cryptography offers many benefits over legacy choices such as a One Time Password (OTP).
Knowledge elements need be entered directly (not cached by the app or phone) by the user. Single use credentials printed on token cards are not considered a knowledge element, even though these are also entered by the user. A smartphone has quite limited input capabilities, ruling out complex passwords as these are too error prone to enter. PIN codes or equivalent low-entropy inputs appear to be the only sensible knowledge elements on smartphones.
The RTS also specifies that a user should be (temporarily) blocked after a number of consecutive failed authentication events. This can be achieved either by secure hardware at the mobile device or by having a server-assisted verification. In the former, the secure hardware on the user's device will lock itself, making it useless. In the latter, the server will block the user. Since mobile devices do not have secure hardware that can be blocked for app-specific knowledge elements, server-assisted verification will always be required.
Inherence elements on a mobile device: use the biometrics sensors provided by the mobile device. These biometrics sensors (fingerprint or faceID) are generally backed by secure hardware, which is capable of generating strong cryptographic signatures. This signature allows the backend server to verify someone’s biometric with high confidence. At the same time, the server does not learn anything about the biometric itself, fully respecting the user’s privacy.
Custom inherence elements
With custom implementations of face, voice or behavioural verification, one should always take into account privacy and accuracy aspects. Just as for knowledge elements, where one cannot rely on secure hardware on the mobile, these custom inherence elements must be verified with the server.
With regard to privacy, one should only collect the minimal amount of data necessary. Furthermore, these data must be adequately protected (on the mobile device, in transit and on the server). Also note that with server-processed data, GDPR article 9 comes into play, which is very restrictive on processing grounds for biometric data. It rules out 'legitimate interest' and 'contractual' grounds, often leaving only explicit consent as an option.
With regard to accuracy, one has to ensure that only the legitimate user can authenticate. One also needs to ensure that the authentication is live (the system cannot be fooled by pre-recorded footage).
Combining all these requirements with server-aided verification is far from trivial. There is a severe risk that you will either end up with collecting too much data (infringing on privacy and creating the risk of abuse of data for fraudulent authentication), or an inaccurate authentication system.
Continue to the second part on why you need non-repudiation and moving beyond authentication codes.