Push-Based Validation with HID Approve™
The ActivID AS secure, out-of-band validation solution meets the needs of security- and cost-conscious banks, at the same time that it offers an easy-to-navigate registration process and client application for customers who want to use smart phones and tablets to perform authentication, account management and financial operations.
The solution enables applications to immediately notify users that their response is required to approve (or decline) a request. Applications then wait for users to respond using their personal device.
For example, a financial organization could leverage that capability to request user (the bank’s customer) approval of a financial transaction (such as, a money transfer from one account to another, or adding or changing a financial service from the user account).
Alternatively, a company can also use the push-based solution to request approval for log on to the company's IT system.
The use of a different channel to request the verification of the transaction adds an additional layer of security in case the endpoint generating the request was compromised.
As the push-based validation solution leverages the end user’s existing mobile device (smartphone or tablet), the solution provides a cost-effective alternative to devices such as hardware tokens or EMV ‘chip cards’ with dedicated EMV readers.
For end users, it offers a fast and convenient solution using smartphones and tablets to validate their access and operations.
The solution is comprised of:
-
ActivID Authentication Server (AS) – the authentication server sends transaction verification requests to mobile devices and verifies the authenticity of the response.
-
HID Approve application – this application receives validation requests and can digitally sign them to signify approval or decline of the request by the end user. It embeds the HID Approve SDK.
The HID Approve™ application provides a user friendly, convenient, and secured method to approve both logon requests and all types of transactions.
The application is available for Google® Android®, Apple® iOS®, Apple macOS® and Microsoft® Windows® 10.
It is also available as a standalone installer (certified by Identrust) for Microsoft Windows 10.
Note: The standalone distribution does not offer push-based authentication capabilities and has a separate upgrade path from that of the version available from the Microsoft Store.It facilitates secure authentications and/or transactions, and includes the following features:
-
Secure Code generation (mobile offline use) for One Time-Password (OTP), Challenge/Response (OCRA) and Signature (OCRA)
-
Multiple service providers
-
Mobile OS push notification network – ActivID AS connects to the mobile OS push notification network to send a small, efficient notification to mobile devices that a transaction is pending.
For privacy and security reasons, the push notification networks are not used to send transaction details or the response to the transaction. Instead, the HID Approve application uses its own secure communication channel. Currently supported push notification networks include Apple Push Network, Google Cloud Messaging and Microsoft Windows Notification Service (supported using the Microsoft® Azure® Cloud Computing Services).
-
Customer backend application – the backend application that sends transaction requests to ActivID AS.
The transactions are asynchronous, and ActivID AS is capable of notifying the backend application once the end user has responded to the transaction request. The backend application could be part of a web portal (in response to an end-user operation on the web portal) or could be driven by back-office processes.
Rampant attempts to defraud financial institutions and their customers are driving the development of new ways to securely validate financial transactions via different channels than those used to perform the transactions.
The ActivID AS, combined with the HID Approve application, provides a push-based, out-of-band validation service that uses existing smartphones and tablets to provide immediate, response-based fraud protection.
The push-based validation solution combines the capabilities of ActivID AS and the HID Approve application to manage services from different security contexts.
It offers support for:
-
Use of multiple services within a single HID Approve application. No need to install multiple applications on the user’s device.
-
Use of multiple credentials per user – by default, a service offers any or all of the following security methods:
- Logon Validation
- Action Validation
- One Time-Password
- Challenge/Response (OCRA)
- Signature (OCRA)
The following is a common scenario representing a secured banking transaction using the push-based validation solution.
This scenario could apply to any ‘Logon request’ validation or ‘Action’ validation, making this solution highly adaptable to a dynamic market. It offers varied possibilities of seamless pushed-based feature integration within a complex business environment.
-
A user initiates a transaction (making a purchase or transferring money) on a commercial or banking web site.
-
The web site initiates secure transaction verification.
-
The user receives a notification on their device and opens it to review the details (for example, ‘buy a DVD from your debit account for $10’ or ‘transfer $25,000 from your company bank account to company XYZ bank account’).
-
The user approves (or declines) the transaction on their device.
-
When the server receives the response from the user’s device, it tells the web site/application that the transaction is approved (or declined).
-
The web site receives the response and applies to user’s validation (approve or decline).
Features and Benefits
PKI-Based Exchanges
Financial institutions and online businesses must limit the risk of customer transaction disputes. Schemes based on Secret Key Infrastructure (SKI) solutions are more open to disputes between parties than Public Key Infrastructure (PKI) solutions as financial institutions must have access to the same secret that a bank’s customer uses to generate the transaction validation.
PKI-based validation does not have this problem because the private key can be generated outside the financial institution's backend system.
The HID Approve application leverages PKI technology for the push-based validation. The private key is protected (preventing extraction or cloning or access from another application). The same device can run multiple Services that call the HID Approve SDK, but each Service is separate and does not share credentials. For example, a user with two bank accounts (in two different banks) can register for a Service from each bank using the HID Approve application on the device.
Native Push Notification Capabilities
ActivID AS and the HID Approve application leverage native push notification capabilities of the device’s operating system:
-
The push notification solution is flexible, allowing a third party to add its own push notification medium if required.
-
When bank’s customers (users) initiate transactions that they must approve themselves, they must be able to approve as quickly as possible. Not only do users want to know that transactions have been completed, but also, the closer the approval is to the initial transaction, it is less likely that users will forget the transaction itself.
-
From a user’s experience, it is also important that transaction verification does not adversely impact device battery or data usage.
The Microsoft Azure Notification Hub infrastructure is used to send cross-platform, personalized push notifications:
-
Allowing targeting millions of individual users.
-
Abstracting the details of the different platform notification services (PNS).
Flexible Registration Solution
The HID Approve application provides a smooth and easy registration experience for users to initialize the required credentials.
-
It requests minimum input from users.
-
The solution offers the flexible provisioning workflows that can be adapted to specific use cases and security requirements.
-
The registration process securely binds an individual mobile device to a specific user’s account.
HID Approve SDK and Application
The HID Approve solution provides both a Software Development Kit (SDK) and an application.
The HID Approve SDK communicates with ActivID AS for provisioning and signing.
-
It is hosted on the mobile device and embedded into the customer’s application.
-
It allows developers to integrate the push solution using customized settings.
The HID Approve Mobile and Windows 10 applications are designed with a simple, ready to use interface for the exchanges with ActivID AS.
-
It simplifies the integration of the solution (the applications can be downloaded from a platform store).
-
It leverages the features by exposing a user friendly interface.
-
It minimizes the need for complex ActivID AS deployments (the default configurations are adapted to HID Approve Mobile and Windows 10 applications).
HID Approve applications are provided for each supported platform:
-
Google Android (versions 5.0 and later)
-
Apple iOS (versions 12.0 and later)
- Apple macOS (versions 10.15 and later)
-
Microsoft Windows 10 Home, Pro, Enterprise and Education editions (32 and 64-bit)
Java sample applications are included with the product to demonstrate both the service registration and the approval workflow on the HID Approve application.
Devices using HID Approve for iOS v3.0.2 with ActivID
Integration of Mobile Signing into Mobile Apps
The HID Approve SDK enables integration of the security features offered in the HID Approve mobile app into other apps enabling organizations to maintain full control of the end-user customer experience.
The HID Approve SDK comes with a sample application for each supported platform to demonstrate how to implement the functionality. This includes initialization (and re-initialization), push notification, transaction display to the user, and sending the response to the transaction request to the server as well as the secure code capability.
Cryptographic Keys and Auditing
The end-user RSA signing keys are anonymous keys (there is no key certificate or public key infrastructure managing those keys).
When these keys are provisioned into ActivID AS, there is a timestamp, which can be used in the future to enforce a key renewal.
The cryptographic keys provisioned and used by ActivID AS are:
-
AES 256 – used to encrypt user credential data and symmetric key cryptography.
-
RSA 2048 – used for transport and user signing keys for transaction signing.
-
ECC-DH – used to establish a secure channel between the HID Approve SDK and ActivID AS during provisioning.
To ensure non-repudiation, ActivID AS audits the following data for every push-based validation:
-
Transaction data
-
Signature value (for the transaction data)
-
Public key corresponding to the private key used to sign the transaction data
Service Key Renewal
Starting with HID Approve for iOS/Android 5.1, macOS 5.6, or Windows 4.5, users can renew the service keys from within the HID Approve application itself.
When service keys are about to expire:
-
End users can now simply renew their service keys directly from HID Approve application, without needing to delete the service and register a new one.
-
Legacy Credential expiration warnings have been removed from the application (even if they were configured in ActivID AS) and are now replaced by renewal prompts.
The renewal campaign consists of three phases:
-
Soft Key Renewal:
- Users can select a green banner prompting them to update. This will trigger the renewal.
- For multiple services, a yellow warning icon is displayed next to the Service name.
-
Hard Key Renewal:
- Users can no longer use their credentials, and they must select to either Update or Delete the service. If they choose to update, the renewal will be triggered as above.
- For multiple services, an orange warning icon is displayed next to the Service name.
-
After Expiration:
- Users will be warned by a gray banner that some operations might not be available.
- For multiple services, a gray warning icon is displayed next to the Service name.
-
The user must use HID Approve at least once within the key's time-life period.
-
Service key renewal is not available if the user only opens the HID Approve application by selecting Push notifications.
-
If the user chooses to delete the Service after expiration of the credential allowing communications with the server's key, an orphan device will remain on the server-side.
The key renewal event is audited on the server-side (see Sample Event for Device Renewal (Triggered by HID Approve)).
Starting with ActivID AS 8.3, the device validity is automatically computed and corresponds to the duration of the minimum value of "Key validity period (days)" of the keys (credential types CT_SMK, CT_PASA, CT_TDS...).
HID Approve then uses this value to automatically renew the device keys before expiration. During the renewal process, the device validity is also automatically updated so the device does not expire.
FIPS 140-2 Compliance
The HID Approve application for Android and iOS can operate in deployments requiring FIPS 140-2 L1-compliant operations. The cryptographic modules used in cryptographic operations are FIPS 140-2 Certified.
In addition, the ActivID AS Authentication Service can enforce that the HID Approve applications for Android and iOS operate in a FIPS mode through a back-end data configuration (see Device Type Provisioning Protocol).
When non-FIPS-compliant applications are used to register a service from a FIPS-enforced ActivID AS Authentication Service, an error message is displayed and the provisioning fails.
Solution Architecture and Workflow
The following diagram is an overview of the push-based validation solution architecture and workflow.
Solution Network Configuration
The HID Approve application requires a proper connection to the ActivID AS from the public network (intranet). Deployments that include use of reverse proxies and/or load balancers must ensure that all exchanges between ActivID AS and HID Approve are re-directed as expected:
In high availability deployments, a load balancer/reverse proxy must be configured for sticky sessions so that all calls made by mobile devices during provisioning are directed to the same
You must, however, accommodate the following HID Approve limitations:
-
As HID Approve does not pass back the HTTP Cookies or Headers that it receives in the response, achieving sticky sessions based on cookies or headers is not possible.
-
If you use a reverse proxy as the TLS termination point, setting up the TLS client authentication as "optional" might result in errors.
Sticky session based on source IP or TLS session might be alternatives depending on the capabilities of your load balancer/reverse proxy and your deployment architecture.
The required setting would be "SSLVerifyClient none" (adapting the syntax depending on your reverse proxy).