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:

#	Part	Description
Server	PC Server	PC Server is an application for back-end installation. PC Server functions can be accessed by the application system with calls to PC Server web services via REST API. This enables integration with any application platforms. PC Server 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 is an application to be installed in back-end's DMZ. 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 an application to be installed in back-end or DMZ. 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.
	PC Server Signer	PC Server Signer is an application for back-end installation. It works on behalf of Client mobile app - performs holding keys, transaction confirmation, etc., but it's managed by application system. This component is used to build signing scenarios, completely managed by application back-end.
	PC Conflicts Resolving Tool (CRT)	PC CRT is an application for back-end installation. It provides web-based User Interface to get detailed information about PC Users, Transactions, Confirmations, Devices, etc. Also it generates reports to be provided to conflicts resolving commissions as proving materials.
Client	PC Mobile SDK / PC App	Performed as a mobile application for iOS 12 (and above) and Android 7 (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.

Cryptographic keys in PC

Key information content

The key user information in PC consists of the following:

Descriptive information (Personalization Data);
- 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 (PC 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 or based on GOST 34.10-2012 algorithm.

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.

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 (Khmac) 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 - Hardware 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 confirmation code, the mobile app has to do the following:

Decrypt the stored keys using the unique smartphone Hardware 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.

In the same time Kauth is stored only with Hardware KEK without encrypting it with password-based KEK. It's required because of PC Mobile SDK has to be able to communicate with PC Server without asking a password from a User.

Signing Key Pair (Kprivate and Kpublic) is generated inside smartphone hardware (Secure Enclave for iOS or Android KeyStore for Android) and can not be exported or extracted. It can only be accessed after the device was unlocked and by exact mobile application only. It means that Signature can be generated only on exact unlocked phone when the mobile application is in foreground. Signing Key (Kprivate) can not be exported, transferred or stolen from hardware.

When you use GOST as crypto algorithms set, signing Key Pair is generated by specialized crypto-provider (for example, CryptoPRO CSP) and stored on provider's container. In this case container (as binary data) is stored in the same way as Khmac (encrypted with two KEKs and still protected with Hardware KEK).

See Figure 4 for the key storing diagram

And Figure 5 for the key usage (password verification and keys decryption) diagram

The AES-256 or GOST 28147-89 algorithm is used for encryption.

The SHA-256 or GOST 34.11-2012 function is used to calculate HMAC.

SHA-256 or GOST 34.11-2012 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.

Activation code and Password verification

In Mobile App Personalization chapter you can find that Initial keyset (Khmac and Kauth) has to be generated by PC Server and provided to Mobile App with Personalization Data.

These keys can be provided in encrypted state, and KEK for encryption is based on key_export_password or activation_code.

There can be scenario, when malefactor will intercept encrypted keys and will try to find key_export_password or activation_code via brute force. Especially, if an Application does use weak activation codes or export password.
In the same time, there is another scenario, when a malefactor has unlimited access to unlocked User's phone and tries to guess User's password to decrypt confirmation keys.

To prevent this, PC has Online credentials verification scheme.

The scheme based on following principles:

Real Activation Code value or Password (which is used to derive KEK for decryption) is stored on PC Server
This value is long enough and can not be brute forced (32 bytes long random value)
When a User provides Activation Code or Password, this value is verified by PC Server - is it correct or not?
If correct, then PC Server provides real value to derive KEK
If not - PC Server counts unsuccess attempts
If attempts count are exceeded, then user is blocked

In addition

PC Server holds salted hash of correct Activation Code / Password only
Each request for verification is mixed with time-stamp and differs from all previous, e. g. request can not be repeated
Verification is based on the same crypto algorithms set as the key itself(GOST or non-GOST)

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 or GOST 34.11-2012 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.

RequestBody always contain following data:

time-stamp to prevent repeat-attacks;
device fingerprint (if applicable) which is verified with registered one for a PC User;
key version to detect if user's keyset has been updated on PC 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;
Check that time-stamp is not bellow last request;
Check that device fingerprint corresponds to registered value;
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.

Base scenarios

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 or Deep-link] A QR code or Deep-link containing all the required descriptive and key information is submitted to the user.
  In this case, the QR code or Deep-link is sent over a trusted channel.
  For QR code - printed on a paper and passed during a personal visit is considered to be the most trusted way.
  For Deep-link - inter-application call on one mobile device.
- [ [QR Code or Deep-link] + 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 or Deep-link in the browser or over any other channel (SMS / Push notification / Email), 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 or goes by Deep-link 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;
Confirmation code generation timestamp;
User's keys ( 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 or GOST 34.11-2012 (256-bit length) 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) or GOST 34.10-2012 (256-bit length);
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) or GOST 34.10-2012 (256-bit length);

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.

Server-Side HMAC

As additional measure to comply with specified legislation, PC Server can calculate additional Server-Side HMAC (also called imit value) with specialized crypto engine.

At the moment only one crypto engine is supported - Crypto PRO JCP, version 2.0.41934.

In case if this feature is turned on, then

signing flow will include one additional step - calculate imit value;
callback to an Application will include imit value;
imit value can be verified in addition to SIGNATUREmessage and HMACmessage retrospectively.

The final steps of signing flow will looks like following

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 prove 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.

Cryptographic Engines in PC

In the document you can find that in some cases different crypto algorithms can be used to calculate security values.

PC allows to work with 2 sets of cryptographic algorithms:

Common cryptographic algorithms set: SHA-256 / ECDSA (prime256v1) / AES-256
GOST cryptographic algorithms set: GOST 34.11-2012 (256 bit) / GOST 34.10-2012 (256 bit) / GOST 28147-89

Which algorithms to use is defined by an Application or by PC Server configuration.

PC does use different implementations of cryptographic algorithms (cryptographic engines) to meet software / hardware / security requirements:

For Common set:
- PC Server: Bouncy Castle
- PC Mobile SDK for iOS: integrated iOS features plus Apple Secure Enclave
- PC Mobile SDK for Android: integrated Android features plus Google KeyStore
For GOST set:
- PC Server: CryptoPRO JCP, version 2.0.41943
- PC Mobile SDK for iOS: CryptoPRO CSP, version 5.0
- PC Mobile SDK for Android: CryptoPRO CSP, version CSP 5.0

In case of using GOST set, digital signatures are generated on mobile device with using CryptoPRO CSP as signature instrument in terms of legislation.