How Mobile Authentication Works
As passwords are no longer considered secure enough, businesses are increasingly using mobile authentication to protect their users and services. Mobile authentication software uses the security chip and the built-in authentication capabilities of the mobile device to ensure that the person who wants to sign in to the service is the owner who originally signed up.
During signup, customers use their device with the mobile authentication app to register their account. This creates a pair of cryptographic keys, a private key that remains on the phone and a public key that is transferred to the server side.
Later on, when users want to sign in again, the device uses a biometric recognition method to identify and authenticate them, sending a session signature that was signed with the private key and whose validity can be checked using the corresponding public key. Transactions can be signed in a similar manner.
Accessing Applications on a Desktop
In many cases, users will be accessing your applications using a desktop computer. The NEVIS Authentication Cloud service can be used to authenticate your users with the secure biometric methods using their mobile phones.
When the users starts the login, they enter their username, which can be a user ID or an email, the backend presents them with a QR code. They scan the code with the NEVIS Access app on their phones. The app can authenticate them using their preferred biometric method, and then sends the verification to the backend, which in turn, allows the users access to the application. The sessions are usually identified by unique, time-bound cookies. Using a mobile authenticator for a desktop session is often referred to as out-of-band authentication.
Using a Mobile to Access Applications
As mobile devices have become ubiquitous, very often they are users' primary means to access services online. For these cases we use a slightly modified user authentication journey.
As users try to access your backend application, the backend replies with an authentication requests, usually in the form of a deep-link that opens up the NEVIS Access app to perform the authentication. Once the user has authenticated with either their fingerprint or facial patterns, the app signs the challenge for the backend. The backend complete the process and issues the session cookie. When users access the service and authenticate with the same device, it is often called in-band authentication.
Biometrics, Identification and Authentication
Identification answers the question of 'who are you'. It aims to capture biometric data that can identify who you are. It can be a set of your fingerprints or your facial patterns. These biometrics can clearly and uniquely identify you. On mobile devices, for this purpose, there is a separate secure chip that runs completely independently on the main chip on the device. Its sole responsibility is the storage and processing of biometric data and authentication requests. The data never leaves the device. It cannot be tampered with. It is not even accessible for the authentication app.
Authentication aims to answer whether you are indeed the person who you claim to be. During authentication, your data is collected using biometric sensors and then it is compared to the data already stored on the device. If the resemblance is sufficient, you are authenticated.
Mobile Device Security
Apple’s Secure Enclave and ARM’s TrustZone and Google Titan M are all implementations of a Trusted Execution Environment (TEE), an isolated secure environments within the mobile phone. But device security has a lot more to it. From the lock screen to the secure storage of your biometric data on those security chips, from the biometric sensors to the hardware-backed Keystore on Android and the Keychain on iOS, these are all implemented to make the identification and authentication of the phone's owner as secure and as smooth as possible. Your biometric data and the private key, never leaves the device, it cannot be tampered with in transit. It is not even directly accessible for the authentication app. The authentication app relies on the device, and uses these features and capabilities for passwordless authentication. Applications build on these and ideally provide a hardened, tamper-proof extension of these services to third parties like you.
The principles behind these extensions rely on asymmetric cryptography, where the private key remains protected on the mobile device and its public counterpart is used on the server side to verify the authentication signature. This way no passwords or password hashes are ever transferred over networks; the private key never leaves the device and even if the device is stolen it cannot be used to steal your fingerprints for instance. Even if the public keys are stolen, they are of little value as at best people could use their mobiles to sign in to the cyber criminals protected back-ends with their mobiles if they chose to do so.
QR, Deeplink or Push Notification
A QR code is a convenient authentication solution when users visit your website from a desktop browser. It is fast and secure. All they need to do is scan the QR code with their mobile access app and authenticate with their face or fingerprint on the device. A push notification is the way for the backend to automatically alert the access app on the user's mobile to perform an authentication and confirm the user's request to access the backend.
For mobile visitors, the deeplink offers a convenient solution because your backend application can automatically redirect to the access app on the user's mobile for authentication. This solution also leverages the biometric sensor capabilities of the device.
FIDO Clients for iPhones and Android Devices
Our brandable FIDO mobile clients use the FIDO Universal Authentication Framework (FIDO UAF) for passwordless sing-up, log-in authentication and transaction signing. They are tamper-proof, hardened mobile applications that leverage the biometric authentication capabilities of iPhones and Android Smartphones. These clients are FIDO compliant, hardened for extra security and are also brandable to your specifications. They will appear in the Apple App Store and the Google Play Store under your account as your organization's own FIDO UAF Client app.
Strong Customer Authentication (SCA) and the EU Revised Directive on Payment Services (PSD2)
In essence, the legal directive requires that payment service providers use strong customer authentication wherever customers access their payment accounts online, or initiate a payment transaction. The final implementation deadline is set for December 31, 2020. In the context of the law, strong authentication means that two or more elements of knowledge, possession or inheritance that are independent need to be used in the authentication. Knowledge, such as knowing a password, will no longer be enough for online payments, and these transactions will be declined. Customers will need to have access to FIDO UAF clients that extend this strong security concept with possession: the mobile phone they own, and inheritance: their fingerprints of facial patterns used for biometric authentication.
Azure AD B2C Authentication
If you already use Azure Active Directory as your identity service provider, the NEVIS Authentication Cloud service gives you speedy integration and an economical strong authentication platform. When you sign up for your NEVIS Authentication Cloud, your instance will be hosted in Azure enabling you to integrate your back-end services in less than a day. You are also given a NEVIS Access app, a FIDO UAF compliant mobile authentication app that your customers can use. The whole integration process can usually be completed in a day. The longest part of the process is usually getting your company's brand-new access app approved in the app stores.