Introduction

PC is a software solution to confirm or sign digitally transactions in digital banking and/or electronic document management (e-docflow) systems.
The primary purpose of PC is to create a better customer experience and increase security level compared to SMS, one-time passwords (OTP) solutions, scratch cards, MAC tokens and etc.
PC can be used to confirm declarations of intention in digital banking transactions, authentication, creation and execution of documents, facts of receiving and/or reading a certain document.

Component parts

PC consists of following parts:

Component	Part	Description
Server	PC Server	PC Server is a pre-configured server or an application for an existing application server. PC functions can be accessed by the application system with calls to PC web services via REST API. This enables integration with any application platforms. The server part must be installed within the security perimeter of the application system. This component is integrated with the server part of digital banking or e-docflow system and performs the following functions: PC users’ registration; PC users’ key information generation and updates; Transaction confirmation operation; Billing and data reports generation.
	PC External	PC External Server is a pre-configured server or an application for an existing application server. PC External functions are not accessed by the application system. It interacts with PC Server on one end and with the client app on the other. Includes such function as: User devices’ registration; Provision of transactions information to be confirmed by the user; Transactions confirmation (digital signature) receive and verification via PC Server
	PC Pusher	PC Pusher is a pre-configured server or an application for an existing application server. PC Pusher functions are not accessed by the application system. It only communicates with the PC Server. Sends transaction confirmation push notifications to the mobile app.
Client		Performed as a mobile application for iOS 10.0 (and above) and Android 4.4 (and above) with the following functions: Users and keys management in a mobile app (read, storage, use, update, delete); Transaction details receiving in online or offline modes; Transaction details performance on a smartphone’s screen for client’s confirmation; Digital signatures generation on the basis of cryptographic transformation of transaction details, user keys, a timestamp and (optionally) a device fingerprint (based on key device parameters); Digital signatures transmission to the server component in online mode or a confirmation code display to the user in offline mode. The client component can be performed as a standalone application as well as a set of embedded libraries to be integrated into a mobile app.

See Figure 1 for the component interaction diagram.

Operation principle

With PC any document is signed by users of the Application System (digital banking or e-docflow system) right in their mobile phones.
For this purpose, the User has the keys, all the information required for online interaction (URLs, authentication data, etc.) and all the settings required for processing.
The Application processing is simplified as much as possible, thus, to get a signed document, the system has to transfer the document or a set of data to be signed to the PC Server and wait for the PC Server notification about transaction signed by user. The result — the signature itself and its verification outcome — is sent to the application system via a callback.

See Figure 2 for the interaction diagram.

Explanations for Figure 2:

Transaction is created;
A push-notification without any transaction data is used only to "wake up" the application/notify the user about a transaction pending confirmation;
Transaction data request is accompanied by the request authentication code based on the user key (Kauth);
The authentication code is associated with the request's contents and generation time;
Transaction data can be text or binary (e.g. PDF);
Data are displayed to the User;
Two sets of algorithms are used simultaneously to compute the signature: symmetric and asymmetric.
A signature is tied to four components: transaction contents, time, smartphone fingerprint and user key (Khmac and Kprivate);
The result is transferred to the Application System together with a set of service parameters, such as provided codes (signature), time, verification outcome, scoring, device data, additional authentication data, etc.

The source of the document is of no importance in this configuration, as the document originates from the Application System. Thus, it can be created in a web interface, or a mobile app, or even generated automatically.

This can be seen at Figure 3.

The transaction passes through the server component of the Application System even if it was created in a mobile app that will be used then for signing.
This is required to make the signing process transactional, including all the functions related to scoring, format and logic control and additional verifications.

PC Users

"PC User" is an entity unambiguously matched to an anonymous unique identifier, which is associated with all the information about the actions of this user in PC:

Keys (current and past):
- KHMAC and КAUTH keys;
- KPUBLIC key;
- Validity period;
- Flags;
- Associated device fingerprint;
Transaction information:
- data (if the transaction has not yet been confirmed);
- status;
- data hash;
- confirmation parameters: scoring settings, data type, availability of offline confirmation;
Event information:
- Client component requests;
- request handling result;
- information on the device from which the request originated;
- IP address of the request;
- hash of the request body;
- provided request authentication code;
Information required to send push-notifications:
- device type;
- push-identifier of the device;
Confirmation attempts information:
- operation type: approved/declined;
- Cancellation reasons (if any): expired timeout, server-initiated cancelation, user-initiated cancelation;
- signature value;
- signature verification result;
- device scoring values.

No data are ever deleted within PC, except for transaction data cleared after the transaction confirmation/cancellation (the SHA-256 hash of the data is preserved).

This can always be used to understand:

which keys were used to sign at any specific time period;
which keys are currently active;
which actions were made on behalf of the User (requests submitted by the User and their implementation results) and what User-related events took place;
which device was used to submit requests;
which transactions were confirmed/cancelled on behalf of the User (including the results thereof);
etc.

Base scenarios

Key information content

The key user information in PC consists of the following:

Descriptive information;
- Application System identifier;
- User identifier;
- Key data validity period;
- User flags;
  - Collect event data;
  - Collect device data and contents thereof;
  - User device association (use the device fingerprint);
  - Password requirements;
  - Restrict to use of Apple TouchID/FaceID or Google Fingerprint;
- URL PC External;
Key information
- Khmac key;
- Кauth key;
- Kprivate private key;
- Kpublic public key.

The Khmac and Кauth keys are generated by the PC server component and are returned to the application system in order to be transfered further to the user over one of the channels provided. These keys are random data - each 32 bytes in length - and are used to generate message authentication codes (HMAC).

The key pair of Kprivate and Kpublic is generated by the user (client component), after which the Kpublic key is registered on the server and is used to verify the signature. The Kpublic key is registered based on the Khmac and Кauth keys, maintaining integrity and origin. These keys are generated based on the ECDSA algorithm with the prime256v1 parameters.

Key validity period

The key validity period is specified on the server component and set at the moment the User key record is generated, including Khmac and Кauth. As the PC server is responsible for signature result verification and requests authentication, the validity period is verified by the server component.

The default validity period is 1 year from the moment of generation. This value is a configuration parameter and can be changed without any limitation within the PC Server setting up.

PC External access authentication

From the client component, each request is accompanied with an authentication code required to authorize access to PC External functions. It has the same properties as the confirmation code, namely:

Is associated with the request contents;
Is based on the user key - Кauth;

An information request from PC External can be fulfilled only if the authentication code is verified successfully. Otherwise, the request results in an error.

An authentication code is the following function:

AUTHCODEhttp-request = HMAC (Кauth, RequestBody), where

HMAC is the message authentication code generation function according to RFC2104, based on the SHA-256 hash function;
Кauth is the key used to generate authentication codes,
RequestBody is the body of the HTTP request submitted to the PC External server.

The value of the authentication code is sent to the PC-Authorization HTTP header and is verified on the server side (a user-associated code is calculated and compared to the value provided). Verification includes the following steps:

PC user information is extracted from the PC database;
Check the user is not blocked (the block flag must not be set);
The active Кauth key is extracted from the PC database;
Check that the active key is not expired;
Check that the active key is not marked for deletion;
The AUTHCODE’http-request value is calculated;
The AUTHCODE value provided is compared to the calculated AUTHCODE’ value.

If the codes are identical, then the request is considered authenticated and is submitted for further processing.

Security of key information stored in a mobile device

When the key information is stored on a mobile phone ( Khmac, Кauth, Kprivate ), it can only be accessed after the password was entered or the device was unlocked via TouchID/FaceID, or Google Fingerprint. The minimum length of the password is 6 characters. Password complexity requirements can be defined by PC Server configuration.

Neither the password nor any password-based values (such as the password hash-function value) are stored in the memory of the mobile phone in any form.

When the key information is being stored, it is sequentially encrypted with two keys:

A password-based value is used as the first key encryption key (KEK);
A device unique key, generated by the smartphone hardware-based feature (Secure Enclave for iOS or Android KeyStore for Android) is used as the second KEK.

Encrypted key information is then saved in the storage of the mobile phone.

In order to access the key information required to generate the signature, the mobile app has to do the following:

Decrypt the stored keys using the unique smartphone KEK (Secure Enclave or Key Store-based);
Request the password;
Calculate the KEK based on the password;
Use the newly obtained value to decrypt the key information.

Therefore, stealing stored keys or mobile app data, or any possible mobile app code modification is useless without knowing the access password to the key information and the key that is kept in the key storage of the smartphone.

See Figure 4 for the key storing and password verification diagram.

The AES-256 algorithm is used for encryption.

The SHA-256 function is used to calculate HMAC.

SHA-256 is used for PBKDF2 with 2000 iterations.

RSA/ECDSA(prime256v1)/AES-256 is used as Hardware KEK depending on the platform and operating system versions.

The password can be generated randomly on the client side and stored using the biometric identification features of the platform (Google Fingerprint or Apple TouchID/FaceID). In this case, the smartphone owner’s fingerprint will be required to access the key.

Mobile app personalization and keys generation

Mobile app personalization includes a few consequent steps:

First of all, the Application creates (or updates) a PC User record in the PC Server component.
The Application receives a set of personalized data (descriptive information, Khmac and Кauth keys), which is to be sent to the mobile device in one of the ways:
- [Automatically] Keys are sent in an encrypted form online.
  In this case it is assumed that the user already has an established communication channel with the Application (e.g. has a mobile banking app installed). Encrypted data for personalization and keys can be fetched from the PC Server component and saved on the mobile phone. Any secret known to the Application and the mobile app can be used as the encryption key. It can be a user-defined PIN, a random one-time password, a session password-based value, etc.
- [QR-Code] A QR code containing all the required descriptive and key information is submitted to the user.
  In this case, the QR code is sent over a trusted channel. Information stored on paper and passed during a personal visit is considered to be the most trusted way to store an encryption key.
- [QR-Code + Activation Code] Keys are transmitted over two channels.
  In this case, PC splits the key information into two parts. The first part is provided to the user as a QR code in the browser interface or over any other channel, while the second one is sent on a one-off basis over another channel: text message, email, paper document, etc.; The user scans the QR code and inputs the second part of the key, thus obtaining the complete set for further use.
The mobile app:
- Imports the personalized information, obtaining all the data required for further processing;
- Decrypts the Khmac and Кauth keys if necessary;
- Generates the Kprivate and Kpublic key pair;
- Generates the device fingerprint;
- Obtains the push identifier of the device;
- Registers the Kpublic key, the device fingerprint and the push identifier with the PC Server;
- Stores the PC user data in the mobile app memory.

Personalization options are shown in the diagrams below.

Signature generation and verification

Four components are used to generate the transaction data signature:

Transaction data, including user identifier;
Verification code generation timestamp;
User key information ( Khmac and Kprivate);
Device fingerprint.

PC can be used to confirm the data both online and offline.

For offline-mode, the signature must be a sequence that can be provided by the user manually for further verification. In other words, the verification code must have no more than 10 characters in length.

In order to get a signature of the required length while preserving its association with the specified components, a symmetric cryptographic operation is required, with the result being shortened according to a certain algorithm.
This is required to calculate the same value, shorten it using the same algorithm and compare the results by the server component.

No manual input from the user is required while working in online-mode. Thus, asymmetric algorithms based on a private-public key pair can be used. So, that the full value of the digital signature is provided online.

Therefore, the signature generated in PC includes three values:

Full confirmation code - HMACmessage
"Shortened" confirmation code HMACmessage with D in the range from 6 to 10;
Asymmetric signature - SIGNATUREmessage.

The confirmation code (both full and shortened) is the following function:

HMACmessage = Truncate (HMAC (Khmac, Data+UserID+Fingerprint+T), D), where

HMAC is the message authentication code generation function, according to RFC2104, based on the SHA-256 hash function;
Khmac - the key used to generate the HMAC message;
Data - the transaction information in TLV form;
UserID - the PC User identifier in TLV form;
Fingerprint - the device identifier in TLV form;
T - a discrete time value, with the default sampling interval of 180 seconds (can be customized), in TLV form;
Truncate - the function used to truncate the HMAC value to D decimal digits; acceptable values of D are from 6 to 10; when D is 0, the full HMAC value is used.
The "+" operation means the concatenation of byte values.

When used in the online-mode, PC Server only accepts for verification "full" confirmation codes (D = 0), which are 32 byte sequences.

In offline-mode, codes with the length of 6 to 10 characters can be used, as the user has to input them manually.

The asymmetric signature is the following function:

SIGNATUREmessage = SIGN (Kprivate, Data+UserID+Fingerprint+T), where

SIGN - the digital signature generation function based on the ECDSA algorithm (prime256v1);
Kprivate - the private key from the user's key pair;
Data - the transaction data in TLV form;
UserID - the PC User identifier in TLV form;
Fingerprint - the device identifier in TLV form;
T - a discrete time value, with the default sampling interval of 180 seconds (can be customized), in TLV form;
The "+" operation means the concatenation of byte values.

If the client component can calculate and transmit an asymmetric signature (the key pair is generated, and the public key is registered on the server), then the server will attempt to confirm the operation only if the SIGNATUREmessage and HMACmessage values are verified simultaneously.

If the client component cannot calculate or transmit the signature value (the public key is not registered on the server, the mobile phone is in offline mode, offline mode confirmation is used), then the server will accept the HMACmessage value verification only.

The signature is verified by the consecutive verification of the HMACmessage and SIGNATUREmessage.

HMACmessage verification value includes the following steps:

PC User information is extracted from the PC database;
Check the user is not blocked (the block flag must not be set);
The active Khmac key is extracted from the PC database;
Check that the active key is not expired;
Check that the active key is not marked for deletion.
The device fingerprint value is extracted from the database (the Fingerprint);
Extract from the PC database transaction data (the Data) value of the transaction to be signed;
The discrete time value (Т) is generated;
D valid value verification (the source of the HMACmessage is checked: whether it is online or offline);
The HMAC’message value is calculated;
Verification of the provided HMAC value in compare with the calculated HMAC’ value;

The verification is deemed successful if the values are identical.

In case of confirmation generated in online mode, the SIGNATUREmessage value is verified:

PC User information is extracted from the PC database;
Check the user is not blocked (the block flag must not be set);
The active Kpublic key is extracted from the PC database.
Check that the key is not expired;
The device fingerprint value is extracted from the database (the Fingerprint);
Extract from the PC database transaction data (the Data) value of the transaction to be signed;
The discrete time value (Т) is generated;
The Verify (SIGNATUREmessage, Kpublic, Data+UserID+Fingerprint+T) function execution, where
- Verify - the digital signature verification function based on the ECDSA algorithm (prime256v1);

The verification is deemed to be successful if the Verify function returns a positive result.

Document signing flow

The following actions sequence is performed in order to sign data with PC (see Operation principle):

The Application creates a transaction:
- Transmits the Data to the PC Server for verification;
- Inserts the callback address for returning the result;
PC Server
- Sends a push-notification (if required) to notify the client app about an operation pending confirmation;
The client component
- Receives the push-notification;
- Gets the list of transactions pending confirmation from PC;
- Gets transaction data from PC;
- Generates an digital signature;
- Sends the digital signature to the PC Server;
PC Server
- Verifies the digital signature values;
- Sends a callback to the Application with the digital signature value and the verification result;
The Application receives the callback and saves the digital signature value.

In the scenario above, the push-notification is not obligatory to be received by the user for the transaction to be confirmed.
The mobile app can start the client component of PC independently and get the list of transactions pending confirmation.

See Figure 8 for the operation flowchart.

Signature verification

A generated signature is verified by sending a request from the Application to the PC Server with the data to be verified: the contents of the document and all the components of the signature (time, SIGNATUREmessage, HMACmessage symmetric code, etc.).

Therefore, when a signature is to be verified, the Application:

Generates (or extracts) the document using its own rules (the document displayed to the user may be different from the original document, e.g. when XML rendering is used);
Extracts the signature value;
Makes the signature verification request to PC;
Gets the verification result.

PC will then select the keys that were used to generate the signature in the specified time and will use them for verification.

User authentication via PC

PC can be used not only for transaction confirmation (digital signing) but also for user authentication. Just like with transaction confirmation, the user must have PC keys to make authentication possible.

As an digital signature is based on time, device fingerprint (optional), keys and data, the first three components may also be used for authentication. In this case, a set of data known to the server and the client components can be used as data that can be then confirmed by the client with a generated signature.

For example, the following can be used as data:

A string with the client login:
"Log in to the online banking system, user smith@example.ru"
A string with a timestamp and the name of the system:
"Log in to the Broker Online system, 01.09.2019 10:20:00"
Any other value.

If the value is generated on the server, it can be transmitted to the client for verification. If the data generation algorithm is also known to the client application, it can then calculate the digital signature at once and present it to the server for the user identity authentication.

Key update

PC user keys have a limited validity period, which is set in the PC server settings. They can be updated in two different ways:

Automatically by the client component, if the existing key is still valid;
Similar to the initial personalization process (see Mobile app personalization and key generation), but the "update user" PC Server method is used instead of the "create user" method, in order to update the keys.

Keys update implies that existing keys are marked as deleted and are replaced with new keys, which are then used to personalize the client component. The superseded keys must be deleted (replaced) on the client component.

During an automatic update, the mobile app can request for the keys to be updated by the PC Server and use the existing keys to proove the identity of the requester.

See Figure 9 for the automatic update diagram.

Additional scenarios

User blocking/unblocking

A user can be temporarily blocked in PC. Blocking means that requests from the blocked user will not be handled by the PC Server component, namely:

Authentication of network requests will fail;
Transactions cannot be created for confirmation;
Previously created transactions cannot be approved;
No actions with User keys are possible (update, public key registration, etc.).

The following functions remain accessible:

Unblock User ;
Delete User.

A user can be blocked or unblocked on request from the Application (containing user identifier) to the PC Server component.

User delete

User delete means that the record of this user can subsequently be used only to verify signatures previously created on this user's behalf.

All the keys of the user are marked as deleted.

If user keys were compromised

When user keys are compromised, the following scenarios are possible:

User keys can be updated (if no existing keys are presented)
In this case, existing keys are marked as deleted and can be subsequently used only to verify the previously generated signatures;
The user can be blocked and later unblocked if the compromise suspicion turns to be false;
The user can be deleted, and a new user can be created.
In this case, existing keys are marked as deleted and can be subsequently used only to verify the previously generated signatures; update of the keys is not possible.

The proper scenario can be selected depending on the business processes of the Application System.

PC - Architecture and operating principles