Retail banks face a dilemma: users, these days, are demanding frictionless access to their banking app yet, at the same time, they will not tolerate any weakness in the security of their transactions. How to solve this conundrum?
Well, TrustBuilder proves that airtight security and customer experience can go hand in hand. TrustBuilder Mobile Authenticator caters to mobile users who want to get rid of passwords without compromising on security.
Read on to learn how:
TrustBuilder Mobile Authenticator is a solution to obtain verifiable confirmation from a user using their trusted phone without the need to enter a password.
The type of confirmations that a user can give ranges from “I’m still there and holding my phone” and “I’m explicitly giving my consent for this activity” to “I approve this payment request from the merchant.” The former case is typically referred to as: authentication.
The latter case is referred to as ‘payment initiation’ of which Secure Customer Authentication (SCA) is the subject of this article. With EU 2015/2366, the European Commission and the European Banking Authority issued the second Payment Services Directive (PSD2). The Berlin Group issued standards for PSD2-compliant payments within a payment ecosystem. The system described below complies with the ‘NextGenPSD2 XS2A Decoupled SCA Approach: Implicit Start of the Authorization Process’.
We’ll illustrate a potential passwordless payment with a fictional bank, BestPay. For the example, we are assuming that BestPay is a TrustBuilder customer, using TrustBuilder Mobile Authenticator. We’ll use the story of Hanna, a buyer at a fictional online shop called BestBuys, affiliated with BestPay. We will follow Hanna as she uses the BestPay app on her smartphone.
Hanna receives an invitation from her bank to activate passwordless payments. She installs the app from BestPay on her personal phone.
She only needs to provide her consent and activate the phone. She is told that this activation actually starts a cryptographic process. In this process, her phone generates secret keys that are used to establish a super-secure channel between her phone and the bank. The secret keys are safely stored in the vault on her phone and cannot be retrieved by a hacker or any other cybercriminal.
To keep fit, Hanna goes off for a run. Down at the park, it starts raining and her feet get wet. So she thinks: high time to buy new shoes.
Surfing the web, she finds BestBuys offering summer sales up to 50%. BestBuys happens to be affiliated with her bank, so she wants to try out passwordless payments.
Hanna is a happy customer of both BestBuys and her bank BestPay thanks to this frictionless handling of her payment.
Rather than entering a password into the browser or app that is then sent to the server, TrustBuilder Mobile Authenticator lets the user give their consent and approve transactions simply by using their trusted device.
The TrustBuilder Mobile Authenticator process to the bank (or third-party payment services provider) is basically broken up into two disjoint steps:
This means that user authentication is out-of-band, i.e., using a different device and channel. Given the security of the vault and the biometrics on mobile phones, the security of TrustBuilder Mobile Authenticator is superior to traditional methods. The only requirement of this model is that the TrustBuilder Mobile Authenticator client must be installed on the trusted mobile and be registered at the TrustBuilder Mobile Authenticator server beforehand.
The authentication between the Mobile Authenticator client and the server adopts a SIGMA cryptographic protocol (‘SIGn-and-Mac’). The SIGMA family of key-exchange protocols offer perfect forward secrecy which means that session keys remain protected even in case the long-term secrets used for the key exchange are compromised. To ensure secrecy of the mobile client as well as mutual authentication between the mobile client and the server, these protocols adopt Diffie-Hellman and add a secure hash and signature of the requester. In this way, the SIGMA protocol of TrustBuilder Mobile Authenticator establishes a trusted channel between the mobile client and the authentication server.
From a PSD2 perspective, TrustBuilder Mobile Authenticator adds consent and signing of the payment request, as per the SCA requirements for PSD2.
The process with TrustBuilder Mobile Authenticator is as follows. In this process we assume the user has previously installed and activated the payment app that contains the TrustBuilder Mobile Authenticator client, as described below.
The bank (or, in general, a payment service provider) installs the secure TrustBuilder Mobile Authenticator server. They also publish a payment app (or extend their banking app) that contains the TrustBuilder Mobile Authenticator client.
They then invite their customers to install the payment app on a device they trust, i.e. that they own and that has a secure vault for secret keys that only they can unlock. The customer then follows these steps:
The activation process is handled by the TrustBuilder Mobile Authenticator client in collaboration with the TrustBuilder Mobile Authenticator server using the SIGMA-1 cryptographic protocol.
With EU 2015/2366, the EU issued the second Payment Services Directive (PSD2). Whereas in the UK, the Open Banking initiative standardizes PSD2-compliant payment services, the EU set up the Berlin Group, led by EU banks and payment processors.
The European Banking Authority issued a Regulatory Technical Standard (RTS) relative to PSD2, which calls for multi-factor authentication and explicit detailed payer consent in what is called Strong Customer Authentication (SCA). SCA basically adds dynamic linking of transaction details (amount and payee) to the multi-factor authentication of the payer.
The Berlin Group further standardizes PSD2-compliant Access-to-Account (XS2A) practices in technical detail. The aforementioned step #1 payment initiation implements the ‘Decoupled SCA Approach: Implicit Start of the Authorization Process’.
This Decoupled SCA Approach: Implicit Start of the Authorization Process works as follows:
The Secure Customer Authentication (SCA) is performed by TrustBuilder Mobile Authenticator as described above.
There may be several parties between the merchant and the bank. Payment initiation can, legally speaking, only be done by a licensed Payment Initiation Service Provider (PISP). Large e-merchants may pick the PISP role themselves, but often the PISP role is done by the merchant’s Acquirer or a third-party payment service provider (TPPSP). The bank may also be an intermediary and be the Account Servicing Payment Service Provider (ASPSP) as a front door to the bank holding the buyer’s account.
A more elaborate process involves token exchange that builds upon OAuth 2. The Berlin Group has standardized this under OAuth2 SCA Approach: Implicit Start of the Authorization Process with Confirmation Code.
Are you interested in offering your banking customers the best of both worlds: ease of use and the highest level of security? Contact us and we will help make your customers happy.
Subscribe
Register for our newsletter and stay updated on IAM and TrustBuilder.
Engage in a chat with our product people to discuss IAM trends and challenges, and our solutions.
Take our Maturity Assessment to find out how you can accelerate your digital transformation.
Experience the power of TrustBuilder.io Suite through a demo, personalized to your challenges.
Visit our offices, send us a mail, call us, or simply fill out a contact form.
