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 second part talks about why you need non-repudiation and how to move beyond authentication codes. The first part introduces SCA and what it means for mobile authentication. The third part shows why certain classical approaches are not compliant with the RTS and explains the nextAuth approach to SCA.
A critical but hidden property: non-repudiation
Even though the Regulatory Technical Standard (RTS) never mentions it, non-repudiation is a critical property in the approval of transactions. Non-repudiation means that the payer cannot dispute his/her approval of the transaction. This implies that the authentication code on a transaction can only have been generated by the payer. The RTS focuses on external threats (not the payer, nor the payment service provider), and imposes several requirements to mitigate these threats:
- authentication codes must be unforgeable;
- authentication codes must be specific to the amount and the payee.
With non-repudiation, the payer can no longer dispute transactions.
But non-repudiation means that one has to consider also the payment services provider as a threat. The payment services provider (PSP) should not be able to produce an authentication code as if it was coming from the payer.
To ensure that authentication codes cannot be forged, one could use a proper digital signature scheme with a high security level. When using a digital signature scheme with a 128-bit security level*, the signature can only have been generated by the payer’s device. Of course, this implies that the used signature scheme is not broken, which would effectively reduce its security level.
To go from unforgeable to non-repudiable signatures, the payer needs to be involved in the signing process. On a technical level, this means the signing key cannot be extracted from the mobile device. Furthermore, it also implies that the PSP has no access to the signing key. This rules out approaches based on symmetric key cryptography, since both the prover (payer) and verifier (PSP) use the same key. With this key, the PSP can always generate authentication codes on new transactions, impersonating the payer. If a payer disputes his/her transaction, he/she can always claim that it was the PSP that generated the authentication code… and there is no way for the PSP to disprove this claim.
By putting a non-repudiable signature over the entire transaction, one ends up with a non-repudiable transaction. This also ensures that the authentication code, in this case signature, is specific to at least the amount and the payee.
From authentication code to authentication protocol
One might get the impression that an authentication code is just a piece of data that is sent from the payer to the server. However, the RTS does not limit authentication codes to such a form. This creates an opportunity to further boost security and, at the same time, meet other RTS requirements.
One of these requirements is that the authentication code should be sent over a secure channel. This to prevent unauthorised parties from learning the authentication code. By including payer authentication in the establishment of the secure channel, one can strongly tie the authentication code to the secure channel.
The establishment of a secure channel typically starts with both parties generating session parameters. After establishing the session parameters, the secure channel must first provide authentication of the PSP. Then, the payer’s device computes the authentication code, authenticating the payer, over the session parameters and the authenticated information from the PSP. Finally, the payer’s device sends back the authentication code over the secure channel. Any authentication code outside the current secure channel is now useless, since it does not cover the correct parameters.
Simply sending an authentication code over a secure channel does not give the same security guarantees. The authentication code is not bound to the secure channel. As such there is no guarantee that the authentication code did not come from another session. This creates a whole range of security issues. Most notably are Man In the Middle Attacks, where payers are tricked into generating an authentication code for a session that is not theirs.
Continue to the third part on why certain classical approaches are definitely not RTS-compliant and how the nextAuth achieves SCA.
* the consensus within the cryptographic community is that the security level should be above 100-bit for near term security (defined as secure for at least 10 years).
