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 third part shows why certain classical approaches are not compliant with the RTS and explains the nextAuth approach to SCA. The first part introduces SCA and what it means for mobile authentication. The second part talks about why you need non-repudiation and how to move beyond authentication codes.
Classical approaches not satisfying RTS requirements
SMS authentication
The NIST special publication 800-63B on authentication and life cycle management advises against the use of SMS or voice over the public switched telephone network (PSTN) for out-of-band authentication. It explicitly mentions risks such as device swap, SIM change, number porting, or other abnormal behavior. It also states that voice-over-IP (VOIP) and email shall not be used for out-of-band authentication as these do not prove the possession of a specific device.
At first sight, the EBA opinion appears to suggest that an SMS could be used as a possession element. The idea being that an SMS demonstrates possession of a SIM card associated with a mobile phone number. The question remains how a valid authentication code can be derived from such a possession element (i.e. the SIM) when only using an SMS.
There are no guarantees that the possession element remains under control of the user. In a SIM-port attack, an attacker requests a legitimate SIM card registered to the mobile phone number of the victim. As such, one would suddenly find the possession element ‘transferred’ to the attacker, which is not compliant with the RTS. The content of the SMS is also not delivered over a secure channel. This violates the RTS requirements to use secure channels during authentication. Furthermore, it also breaks the entire argument that delivering an SMS somehow shows possession of a SIM card (or phone number).
One Time Passwords
One Time Passwords (OTPs), either generated by or delivered to the device, only bring a limited amount of security. The typical 6 digit OTP can be forged with a one in million probability. The EBA is of the opinion that an OTP generator which is unlocked with another factor, e.g., a PIN could constitute two elements. Both elements need to be independent, which obviously excludes the on-device software verification of this other factor. From the server’s point of view the authentication code still remains only 6 digits. Yet, the unforgeability of the authentication code is an essential RTS requirement, which the typical OTP cannot satisfy.
The nextAuth approach to SCA
The nextAuth technology is built around a layered security approach. It covers all aspects such as cryptography, PIN/biometric verification, implementation security, obfuscation and OS security features.
In terms of cryptography nextAuth uses the SIGMA-I protocol to establish a secure channel with mutual authentication using digital signatures. SIGMA-I can also be found in IPsec-IKEv2 standard and heavily inspired TLS1.3. From the perspective of SCA, this covers the requirements of unforgeable authentication codes (128-bit security of the digital signature scheme) and the usage of a secure channel. Since the server only stores public keys, a data breach at the server will not compromise customer authentication. Furthermore, even when the server’s private key becomes compromised, it remains impossible to perform a Man-In-The-Middle attack. This is due to having the mutual authentication protocol properly bound to the secure channel. By relying on digital (public key) signatures, nextAuth additionally achieves non-repudiation for all authentications, both for login and transaction approval.
In terms of authentication elements, nextAuth combines possession (device) with either knowledge (PIN) or inherence (biometrics). In the former case, our patent pending PIN verification protocol guarantees that local brute-forcing of the PIN on the phone is impossible. Our PIN verification protocol will also prevent the server from learning the actual PIN (or having to store it), removing potential server vulnerabilities. In the latter case, the biometric features and the secure enclave of the device are used to digitally sign the secure channel parameters. This approach also fulfils the GDPR requirements with respect to biometrics.
The combination of the underlying authentication elements, the PIN verification protocol and the mutual authentication protocol based on digital signature makes that nextAuth fully satisfies the RTS requirements on Strong Customer Authentication.