Activation

Edit on Github Send Feedback v1.9.0

Before a mobile app can perform authentication and transaction signing, it must first register with the server. In order to establish strong device binding, a key exchange must take a place first. We call this key exchange process “the activation”. During the activation, user needs to enter some credential to the mobile app to authenticate the key exchange.

The following components typically play role in the process of activation via activation code:

PowerAuth Mobile SDK - An SDK embedded in the mobile client application.
Enrollment Server - A front-end facing server application that is deployed in demilitarized zone (DMZ) in order to accommodate a communication between the PowerAuth Mobile SDK and PowerAuth Server.
Activation Code Delivery Application - An application (for example Internet banking) that initiates the activation process by requesting and then displaying or sending the activation code for the use in the PowerAuth Mobile SDK.
PowerAuth Server - A server application hidden deep in the secure infrastructure. It stores activation records and verifies the request signatures.

Architecture Overview

Specific role of each component depends on a particular activation pattern, as explained in the Activation Types chapter.

Activation Principle

The basic underlying principle of the activation process is simple: The mobile application sends its public key to the server and in return, it receives the server’s public key, initial counter value, and activation ID from the server.

Of course, to make this process work in a secure manner, several additional items must be present during the flow.

Activation Types

Each activation request generated by the mobile application uses some type of activation credentials that uniquely identify a specific user.

The activation credentials may be arbitrary and selected by a customer. We call activation type an activation via custom credentials. Such credentials can be essentially anything - username and password, phone number and SMS OTP, anything that uniquely identifies the user technically works. The design goal is to find such credentials that have sufficient quality of user verification. The custom credentials are verified against an existing service during the activation process.

More commonly, the activation credentials are managed by our systems. The typical activation type uses an activation code. An activation code is a temporary, single use token that is strongly connected to specific user and to pre-initialized activation record. Activation code is issued for a given user via an application where the user already is authenticated, such as the Internet banking.

Another type of credentials our systems manage are recovery codes. When enabled, our systems generate recovery codes during a successful activation. The mobile device then store them on the mobile device, protected by a secure vault mechanism (the secure vault requires the PIN code to unlock).

You can read more about specific activation types in dedicated chapters:

Application-Level Encryption

Since the activation process transfers extremely sensitive data payloads and user credentials between the mobile app and the server, additional application level encryption is used during the process.

The end-to-end application-level encryption is actually performed twice on a single payload.

The first layer of encryption protects the data transfer between the mobile app and intermediate Enrollment Server component (accessible from the Internet). After unwrapping the first encryption layer, the Enrollment Server gains access to the activation type and activation specific credentials. However, the Enrollment Server cannot unwrap the second encryption layer. Instead, the Enrollment Server passes the encrypted activation data to PowerAuth Server alongside either the user ID (for custom credentials), activation code (for activation via activation code) or recovery code (for activation via recovery code). The PowerAuth Server then decrypts the second encryption layer and it stores the activation data from the client. In response, it sends an encrypted server-side activation payload (again, the Enrollment Server cannot decrypt this payload). The Enrollment server finally re-encrypts the response and sends it to the mobile app.

Detailed documentation of End-to-End Encryption is available in a dedicated chapter.

A good place to review the exact request and response payload structure is in the PowerAuth Standard RESTful API documentation.

Key Derivation

After completing the activation flow, the mobile app and PowerAuth Server must derive additional factor specific signing keys that are based on a shared secret established during the activation.

The mobile app then stores these derived keys and throws away the unencrypted device private key and any intermediate products of the activation process. Only the derived keys are stored on the mobile app using a method appropriate for the particular key.

For example, a signature key related to the “knowledge factor” is stored encrypted using a key derived from a PIN code, a signature key related to the “biometry factor” is stored encrypted with a key that is retrieved from the biometric module of the device, etc.

The detailed description of the Key Derivation is available in a separate chapter.

Low-Level Implementation

To assure the best resilience of the process and to make sure that no sensitive cryptographic data remains allocated in the memory, the core of the mobile app component is implemented in C/C++.

Activation States

The following diagram shows transitions between activation states:

Activation Lifecycle

State	Description
`CREATED`	The activation record is created using an external channel, such as the Internet banking, but the key exchange between the client and server did not happen yet.
`PENDING_COMMIT`	The activation record is created and key exchange between the client and server already took place, but the activation record needs additional approval before it can be used.
`ACTIVE`	The activation record is created and active. It is ready to be used for typical use-cases, such as generating signatures.
`BLOCKED`	The activation record is blocked and cannot be used for most of the use-cases, such as generating signatures. It can be unblocked and activated again.
`REMOVED`	The activation record is removed and permanently blocked. It cannot be used for generating signatures or ever unblocked.

Last updated on Oct 07, 2024 (06:31) Edit on Github Send Feedback