Введение

PayControl (далее PC) – программный комплекс, предназначенный для подтверждения и подписания пользователем операций в системах дистанционного банковского обслуживания и/или электронного документооборота (e-docflow). Основная цель PC - повысить уровень удобства подтверждения и информационной безопасности по сравнению с такими способами подтверждения как SMS, одноразовые пароли (One-Time Password), скретч-карты, MAC-токены и пр.
При помощи PC могут подтверждаться волеизъявления на совершение банковских транзакций, аутентификация, создание и исполнение документов, факты получения и/или ознакомления с определенной информацией.

Состав

PC состоит следующих компонентов:

	Наименование	Описание
Серверная часть	PC Server	PC Server это приложение для установки на серверную часть. Доступ к функциям PC Server осуществляется через вызовы веб-сервисов PC Server по REST API. Это позволяет интегрировать его с любыми платформами приложений. PC Server должен быть установлен в пределах периметра безопасности прикладной системы. Этот компонент интегрируется с серверной частью системы цифрового банкинга или электронного документооборота и выполняет следующие функции: регистрация пользователей в PC; генерация и обновление ключевой информации пользователей PC; управление процессом подтверждения транзакций; формирование биллинговых и информационных отчётов.
	PC External	PC External это приложение, устанавливаемое в демилитаризованной зоне (DMZ) бэкенда. Функции PC External не доступны для вызова со стороны прикладной системы. Оно взаимодействует с PC Server с одной стороны и с клиентским приложением — с другой. Включает следующие функции: регистрацию устройств пользователей; предоставление информации о транзакциях для подтверждения пользователем; прием и проверку при помощи PC Server подтверждения транзакций (электронной подписи)
	PC Pusher	PC Pusher это приложение, устанавливаемое в бэкенде или DMZ. Функции PC Pusher не доступны для вызова со стороны прикладной системы. Оно взаимодействует только с PC Server. Отправляет push-уведомления в мобильное приложение о том, что доступна транзакция для подтверждения.
	PC Server Signer	PC Server Signer это приложение для установки в бэкенде. Работает в качестве клиентского приложения — хранит ключи, подтверждает транзакции и т.п., но управляется прикладной системой. Этот компонент используется для сценариев подписания, полностью управляемых бэкендом прикладной системы.
	АРМ Разбора конфликтных ситуаций (PC CRT)	PC CRT - это приложение для установки в бэкенде. Предоставляет веб-интерфейс для получения детальной информации о пользователях PC, транзакциях, подтверждениях, устройствах и т.д. Также формирует отчёты, предоставляемые комиссиям по разрешению конфликтов в качестве доказательных материалов.
Клиентская часть	PC Mobile SDK / PC App	Представляет собой приложение для мобильных платформ iOS (13 и выше) и Android (7 и выше), выполняющее следующие функции: управление пользователями и их ключами в рамках мобильного приложения (считывание, хранение, использование, обновление, удаление); получение данных транзакций от серверной части для подтверждения в режиме онлайн или офлайн; отображение подтверждаемой информации на экране мобильного телефона; выработка электронных подписей на основе данных транзакции, ключей пользователя, времени выработки и (опционально) отпечатка устройства; отправка электронных подписей в серверную часть в режиме онлайн или отображение пользователю кода подтверждения в режиме офлайн. Клиентская часть поставляется в виде встраиваемых библиотек для интеграции в мобильное приложение или отдельного приложения.

Рисунок 1 — Схема взаимодействия компонентов.

Принцип работы

Использование PC подразумевает, что подписание транзакции выполняется на стороне Пользователя прикладной системы (системы дистанционного банковского обслуживания — ДБО, либо электронного документооборота — ЭДО) в его мобильном телефоне.
Для этого у Пользователя есть его ключи, вся информация для онлайн-взаимодействия (URL’ы, данные для идентификации и пр.), а также необходимые для работы настройки.
С целью упрощения логики работы прикладной системы для получения подписи ей необходимо просто передать на подпись набор данных на сервер PC и дождаться уведомления от сервера PC о подписании Пользователем. Результат (подпись и результат её проверки) передаётся прикладной системе в виде обратного вызова.

Схема процесса подписания приведена на Рисунке 2.

Пояснения по схеме на Рисунке 2:

1. создание транзакции;
2. push-уведомление не содержит никакой информации о транзакции, служит только для того, чтобы «разбудить» приложение/уведомить пользователя о том, что есть транзакция для подтверждения;
3. запрос данных транзакции сопровождается кодом аутентификации запроса на основе ключа пользователя (K_auth);
4. код аутентификации привязан к содержанию запроса и ко времени формирования;
5. данные транзакции могут представлять собой текст или бинарные данные (например, PDF);
6. отображение данных пользователю;
7. вычисление подписи выполняется одновременно по двум наборам алгоритмов: симметричным и асимметричным.
8. подпись привязана к 4-м составляющим: содержанию транзакции, времени, отпечатку смартфона и ключу пользователя (K_hmac and K_private);
9. результат передается прикладной системе с набором служебных параметров, включая предъявленные коды (подпись), время, результат проверки, скоринг, данные по устройству, данные для дополнительной аутентификации и пр.

В данной схеме не имеет значения источник документа, т.е. как он появился на стороне прикладной системы. Он может быть создан в веб-интерфейсе, в мобильном приложении, может быть создан автоматически.

Это отражено на Рисунке 3.

Транзакция проходит через серверный компонент Прикладной системы, даже если она была создана в мобильном приложении, которое затем будет использоваться для подписания.
Это необходимо для обеспечения транзакционности процесса подписания, включая все функции, связанные со скорингом, контролем формата и логики, а также дополнительными проверками.

Пользователи PC

«Пользователь PC» — это сущность, однозначно сопоставляемая с обезличенным уникальным идентификатором, к которому в дальнейшем привязывается вся информация о действиях этого пользователя в PC:

• информация о ключах (текущих и используемых ранее):
  • ключи K_hmac и K_auth;
  • ключ K_public;
  • срок действия;
  • флаги;
  • отпечаток привязанного устройства;
• информация о транзакциях:
  • данные (если транзакция еще не была подтверждена);
  • статус;
  • хеш-сумма данных;
  • параметры подтверждения: настройки скоринга, тип данных, возможность офлайн-подтверждения;
• информация о событиях:
  • запросы с клиентской части;
  • результат обработки запроса;
  • информация об устройстве, с которого пришел запрос;
  • IP-адрес, с которого пришел запрос;
  • хеш-сумма тела запроса;
  • предъявленный код аутентификации запроса;
• информация для отправки push-уведомлений:
  • тип устройства;
  • push-идентификатор устройства;
• информация о попытках подтверждения:
  • тип операции: подписание/отмена;
  • причина отмены (если есть): истёк таймаут, отменена сервером, отменена пользователем;
  • значение подписи;
  • результат проверки подписи;
  • значения скоринга устройства.

В рамках PC информация автоматически никогда не удаляется, за исключением очистки данных транзакций после того, как транзакция подтверждена/отменена (при этом сохраняется хэш-сумма данных (SHA-256)).

Это позволяет в любой момент времени выяснить:

• какие ключи были использованы для подписания в каждый конкретный момент времени;
• какие ключи активны в настоящий момент;
• какие действия производились от имени Пользователя (какие запросы от него поступали и результат их выполнения) и какие события, связанные с этим пользователем, происходили;
• с какого устройства выполнялись запросы;
• какие транзакции и с каким результатом подтверждались/отменялись от имени Пользователя;
• и пр.

Ключевая схема и сценарии работы

Состав ключевой информации

Ключевая информация пользователя в PC состоит из следующих данных:

1. Описательная информация;
   • идентификатор прикладной системы;
   • идентификатор пользователя;
   • срок действия ключевой информации;
   • URL PC External;
   • флаги пользователя:
     • необходимость сбора информации о событиях;
     • необходимость сбора информации об устройстве и её состав;
     • необходимость привязки к устройству пользователя (использование отпечатка устройства);
     • требования к сложности пароля при сохранении;
     • запрет на использование Apple TouchID/FaceID или Google Fingerprint;
2. Ключевая информация
   • Ключ K_hmac
   • Ключ K_auth
   • Закрытый ключ K_private
   • Открытый ключ K_public

Ключи K_hmac и K_auth генерируются серверной частью PC и возвращаются прикладной системе для дальнейшей их передачи пользователю одним из предусмотренных способов. Данные ключи представляют собой случайные данные длиной по 32 байта каждый и используются для выработки кодов аутентификации сообщений (HMAC).

Ключевая пара K_private и K_public генерируются пользователем (клиентской частью), после чего ключ K_public регистрируется на сервере и используется для проверки подписи. Регистрация ключа K_public выполняется с контролем целостности и авторства на основе ключа K_auth. Данные ключи формируются по алгоритму ECDSA с параметрами prime256v1 (для версии Lite), либо на основе алгоритма GOST 34.10-2012 (для версии ГОСТ).

Срок действия ключей

Срок действия ключей задаётся на серверной части и устанавливается в момент формирования записи о ключах Пользователя, включая K_hmac и K_auth. Так как за проверку результата подписания, а также за аутентификацию запросов, отвечает сервер PC, то контроль срока действия осуществляется на серверной части.

Значение срока действия по умолчанию — 1 год с момента генерации. Данное значение является параметром конфигурации и может быть изменено без ограничений при настройке сервера PC.

Безопасность ключевой информации, хранящейся на мобильном устройстве

Доступ к ключевой информации, хранящейся на мобильном устройстве ( K_hmac, K_private ), для последующего формирования электронных подписей и кодов подтверждения возможен только после разблокировки устройства и ввода пароля, TouchID/FaceID или Google Fingerprint в приложении. Минимальная длина пароля составляет 6 символов. Требования к сложности пароля могут быть определены конфигурацией сервера.

Ни пароль, ни какие-либо значения на основе пароля (например, значение хэш-суммы пароля) ни в какой форме не сохраняются в памяти мобильного телефона.

При хранении ключевой информации (K_hmac) она последовательно шифруется с помощью двух ключей:

• В качестве первого ключа шифрования (KEK) используется значение на основе пароля;
• Уникальный ключ устройства, сгенерированный аппаратной функцией смартфона (Secure Enclave для iOS или Android KeyStore для Android), используется в качестве второго KEK — Hardware KEK.

Зашифрованная ключевая информация сохраняется в памяти мобильного телефона.

Чтобы получить доступ к ключевой информации, необходимой для генерации кода подтверждения, мобильное приложение должно выполнить следующие действия:

1. Расшифровать сохранённые ключи с помощью уникального аппаратного ключа Hardware KEK (на основе Secure Enclave или хранилища ключей);
2. Запросить пароль;
3. Рассчитать KEK на основе пароля;
4. Использовать полученное значение для расшифровки ключевой информации.

Кража сохраненных ключей или данных мобильного приложения, а также любая возможная модификация кода мобильного приложения бесполезны без знания пароля доступа к ключевой информации и ключа, который хранится в аппаратном обеспечении смартфона.

В то же время K_auth хранится только с Hardware KEK, без шифрования с помощью KEK на основе пароля. Это необходимо, поскольку PC Mobile SDK должен иметь возможность взаимодействовать с PC Server без запроса пароля у пользователя.

Ключевая пара (K_private и K_public) генерируется внутри аппаратной части смартфона (Secure Enclave для iOS или Android KeyStore для Android) и не может быть экспортирована или извлечена. Доступ к ней возможен только после разблокировки устройства и только для конкретного мобильного приложения. Это означает, что подпись может быть сгенерирована только на разблокированном телефоне, когда мобильное приложение находится на переднем плане. Ключ для подписи (K_private) нельзя экспортировать, передать или украсть с устройства.

При использовании GOST в качестве набора криптоалгоритмов пара ключей для подписи генерируется специализированным криптопровайдером (например, CryptoPRO CSP) и хранится в его контейнере. В этом случае контейнер (в виде двоичных данных) хранится так же, как и K_hmac (зашифрованный с помощью двух ключей шифрования и защищенный с помощью Hardware KEK).

Рисунок 4 — Схема хранения ключей.

На рисунке 5 показано использование ключа (проверка пароля и расшифровка ключей)

Для шифрования используется алгоритм AES-256 или ГОСТ 28147-89.

Для вычисления HMAC используется функция SHA-256 или ГОСТ 34.11-2012.

SHA-256 или ГОСТ 34.11-2012 используется для PBKDF2 with 2000 iterations.

RSA/ECDSA(prime256v1)/AES-256 используется в качестве аппаратного KEK в зависимости от платформы и версий операционной системы.

Пароль может быть сгенерирован случайным образом на стороне клиента и сохранен с помощью биометрической идентификации на платформе (Google Fingerprint или Apple TouchID/FaceID). В этом случае для доступа к ключу потребуется отпечаток пальца владельца смартфона.

Код активации и подтверждение пароля

В разделе "Персонализация мобильного приложения" вы можете найти, что первоначальный набор ключей (K_hmac и K_auth) должен быть сгенерирован сервером PC и предоставлен мобильному приложению с данными персонализации.

Эти ключи могут быть предоставлены в зашифрованном виде, и KEK для шифрования основан на key_export_password или activation_code.

Может возникнуть сценарий, когда злоумышленник перехватит зашифрованные ключи и попытается найти key_export_password или activation_code методом перебора. Особенно, если приложение действительно использует слабые коды активации или пароль для экспорта.

В то же время существует другой сценарий, когда злоумышленник имеет неограниченный доступ к разблокированному телефону пользователя и пытается угадать пароль пользователя для расшифровки ключей подтверждения.

Чтобы предотвратить это, на PC предусмотрена Онлайн-схема проверки учетных данных.

Схема основана на следующих принципах:

1. Реальное значение кода активации или пароля (который используется для получения KEK для расшифровки) хранится на сервере PC;
2. Это значение достаточно длинное и не может быть введено вручную (случайное значение длиной 32 байта);
3. Когда пользователь вводит код активации или пароль, это значение проверяется сервером PC — правильное оно или нет?;
4. Если верно, то PC Server предоставляет значение для получения KEK;
5. Если нет — сервер PC подсчитывает неудачные попытки;
6. Если количество попыток превышено, то пользователь блокируется.

В дополнение:

• PC-сервер хранит только зашифрованный хэш правильного кода активации / пароля;
• Каждый запрос на проверку сопровождается пометкой времени и отличается от всех предыдущих, т.е. запрос не может быть повторен;
• Верификация основана на тех же криптоалгоритмах, что и сам ключ (ГОСТ или не ГОСТ).

Аутентификация при доступе к PC External

Для авторизации доступа к функциям PC External со стороны клиентской части каждый запрос сопровождается кодом аутентификации запроса. Он имеет такие же свойства, как и код подтверждения, а именно:

• привязан к содержанию запроса;
• основан на ключе пользователя — K_auth.

Запрос на предоставление информации со стороны PC External будет выполнен только в том случае, если проверка кода аутентификации будет пройдена успешно. В противном случае, результатом запроса будет ошибка.

Код аутентификации представляет собой результат функции:

AUTHCODEhttp-request = HMAC (Kauth, RequestBody), где

• HMAC - функция выработки кода аутентификации сообщения в соответствии с RFC2104, основанная на хеш-функции SHA-256 или GOST 34.11-2012;
• K_auth - ключ для генерации кодов аутентификации;
• RequestBody - тело HTTP-запроса, отправляемого на сервер PC External.

RequestBody всегда содержит следующие данные:

• метку времени для предотвращения повторных атак;
• отпечаток устройства (если применимо), который проверяется с помощью зарегистрированного отпечатка для пользователя PC;
• версию ключа для определения того, был ли обновлен набор ключей пользователя на сервере PC.

Значение кода аутентификации помещается в HTTP-заголовок PC-Authorization и проверяется на стороне сервера путем вычисления собственного кода, относящегося к пользователю, и его сравнения с представленным значением. Проверка состоит из следующих шагов:

1. Извлечение из БД PC информации по пользователю PC;
2. Проверяется, что пользователь не заблокирован (не стоит флаг блокировки);
3. Извлечение из БД PC активного ключа K_auth;
4. Проверяется, что срок действия активного ключа не истёк;
5. Проверяется, что активный ключ не помечен, как удалённый;
6. Проверяется, что временная метка не просрочена;
7. Проверяется, что отпечаток устройства соответствует зарегистрированному значению;
8. Вычисление AUTHCODE_http-request;
9. Сравнение предъявленного значения AUTHCODE c вычисленным значением AUTHCODE_http-request.

В случае идентичности кодов запрос считается аутентифицированным и передаётся в дальнейшую обработку.

Базовые сценарии

Персонализация мобильного приложения, формирование ключей

Персонализация мобильного приложения подразумевает несколько шагов, выполняемых последовательно:

1. Первым шагом Прикладная система создаёт (или обновляет) запись о пользователе PC в серверной части PC.
2. Прикладная система получает набор данных для персонализации (описательная информация, ключи K_hmac и K_auth), которая должна быть передана на мобильное устройство одним из предусмотренных способов:
   
   • [Автоматическая] Передача ключей в зашифрованном виде онлайн.
     Данный способ подразумевает, что у пользователя существует канал связи с прикладной системой (например, уже установлено приложение Мобильного банкинга). В этом случае данные для персонализации и ключи могут быть доставлены из серверной части PC в зашифрованном виде и сохранены в приложении конечного пользователя. Ключом шифрования может являться любой секрет, известный прикладной системе и мобильному приложению. Например, пин-код пользователя, случайный одноразовый пароль, производная от идентификатора сессии и пр.
     
   • [QR Code] Путем передачи пользователю QR-кода, который содержит всю необходимую описательную и ключевую информацию.
     Данный способ подразумевает, что передача QR-кода должна осуществляться по доверенному каналу. Наиболее доверенный канал – на бумажном носителе при посещении.
   • [QR Code + Код активации] Передача ключей по двум каналам.
     В данном случае PC разделяет ключевую информацию на две части. Первая часть предоставляется пользователю в виде QR-кода в интерфейсе браузера или любым другим способом, вторая – отправляется однократно другим каналом: SMS, e-mail, на бумажном носителе и пр. Пользователь после сканирования QR-кода вводит вторую часть ключа и получает полный набор для дальнейшего использования.
   • [Deep Link] Путем передачи пользователю deeplink-ссылки.
     При переходе по ссылке пользователь автоматически переходит в мобильное приложение, получая данные для персонализации.
   • [Deep Link + Код активации] Передача ключей по двум каналам.
     После отправки прикладной системой запроса на создание пользователя PC Server генерирует Deep Link и код активации для персонализации (может передаваться различными каналами, например, по электронной почте или SMS). Клиент нажимает на ссылку и автоматически переходит в мобильное приложение, получая часть данных для персонализации. Далее Клиент вводит код активации в мобильном приложении для получения оставшихся данных для персонализации. При переходе по ссылке пользователь автоматически переходит в мобильное приложение.
     
3. Мобильное приложение:
   • импортирует данные для персонализации, получая все необходимые для дальнейшей работы данные;
   • при необходимости расшифровывает ключи K_hmac и K_auth;
   • генерирует ключевую пару K_private и K_public;
   • формирует отпечаток устройства;
   • получает push-идентификатор устройства;
   • регистрирует на сервере PC K_public, отпечаток устройства и push-идентификатор;
   • сохраняет данные о пользователе PC в памяти приложения.

Схемы вариантов персонализации приведены на схемах ниже.

Рисунок 6 — Персонализация PC Mobile SDK (Автоматическая).

Рисунок 7 — Персонализация PC Mobile SDK (с помощью QR-кода или Deep-Link).

Рисунок 8 — Персонализация PC Mobile SDK (двумя каналами).

Выработка и проверка подписи

Подпись данных транзакции вырабатывается на основе 4-х составляющих:

• данные транзакции, включая идентификатор пользователя;
• время формирования кода подтверждения;
• ключевая информация пользователя ( K_hmac и K_private);
• отпечаток устройства.

PC предоставляет возможность подтверждения данных в онлайн- и офлайн-режимах.

Для подтверждения в офлайн-режиме, будет выработан короткий код подтверждения, который может быть введён пользователем вручную, для дальнейшей проверки. Таким образом, для удобства пользователя, код может быть длиной не более 10 символов.

С целью получения кода такой длины с соблюдением условия его зависимости от нескольких составляющих, необходимо использование симметричной криптографической операции с последующим «укорачиванием» результата по определенному алгоритму. Это необходимо для того, чтобы проверяющая сторона могла вычислить такое же значение, укоротить его по тому же алгоритму и сравнить результат.

При работе в онлайн-режиме ручных операций от пользователя не требуется. Поэтому есть возможность использования асимметричных алгоритмов, основанных на паре открытый-закрытый ключ. Значение электронной подписи может быть предоставлено в полном виде путем онлайн-обмена.

Поэтому в PC подтверждением будет являться одно из:

1. Код подтверждения «укороченный» HMAC_message при D от 6 до 10, для офлайн-режима;
2. Код подтверждения полный - HMAC_message и Асимметричная подпись - SIGNATURE_message, для онлайн-режима.

Код подтверждения (полный и «укороченный») представляет собой функцию:

HMACmessage = Truncate (HMAC (Khmac, Data+UserID+Fingerprint+T), D), где

• HMAC функция выработки кода аутентификации сообщения в соответствии с RFC2104, основанная на хеш-функции SHA-256, либо ГОСТ 34.11-2012;
• K_hmac - ключ для генерации HMAC сообщения;
• Data - данные транзакции в формате TLV;
• UserID - идентификатор пользователя в PC в формате TLV;
• Fingerprint - отпечаток устройства в формате TLV;
• T - дискретное значение времени, интервал дискретизации – по умолчанию 180 секунд (настраиваемое значение) в формате TLV;
• Truncate - функция обрезания значения HMAC до D десятичных знаков; допустимые значения D – от 6 до 10; при D = 0 используется полное значение HMAC. Передача значения подписи (асимметричной) обязательна.
• Операция «+» означает конкатенацию значений байтов.

При этом при работе в режиме онлайн PC Server принимает для проверки только «полные» коды подтверждения (D = 0), представляющие собой последовательность из 32 байт.

При работе в офлайн режиме возможно использование кодов, ограниченных длиной от 6 до 10 десятичных символов, так как пользователю необходимо предоставить их вручную.

Асимметричная подпись представляет собой функцию:

SIGNATUREmessage = SIGN (Kprivate, Data+UserID+Fingerprint+T), где

• SIGN - функция выработки электронной подписи по алгоритму ECDSA (prime256v1), либо ГОСТ 34.10-2012;
• K_private - закрытый ключ из ключевой пары пользователя;
• Data - данные транзакции в формате TLV;
• UserID - идентификатор пользователя в PC в формате TLV;
• Fingerprint - отпечаток устройства в формате TLV;
• T - дискретное значение времени, интервал дискретизации – по умолчанию 180 секунд (настраиваемое значение) в формате TLV;
• Операция «+» означает конкатенацию значений байтов.

Если клиентская часть имеет возможность вычислить и передать асимметричную подпись (сформирована ключевая пара и открытый ключ зарегистрирован на сервере), то сервер примет попытку подтверждения только если значения SIGNATURE_message и HMAC_message проходят проверку одновременно.

Если клиентская часть не имеет возможность вычислить или передать значение подписи (открытый ключ не зарегистрирован на сервере, мобильный телефон офлайн, используется офлайн-подтверждение), то сервер примет подтверждение только по HMAC_message.

Проверка подтверждения выполняется путем последовательной проверки корректности HMAC_message и SIGNATURE_message.

Проверка HMAC_message включает следующие шаги:

1. Извлечение из БД PC информации о пользователе;
2. Проверка, что пользователь не заблокирован (не стоит флаг блокировки);
3. Извлечение из БД PC активного ключа K_hmac;
4. Проверка, что срок действия активного ключа не истёк;
5. Проверка, что активный ключ не помечен, как удалённый;
6. Извлечение из БД значения отпечатка устройства (Fingerprint);
7. Извлечение из БД PC информации о транзакции (Data), по которой выполняется подписание;
8. Формирование дискретного значения времени (Т);
9. Проверка допустимого значения D (проверяется источник HMAC_message – онлайн или офлайн);
10. Вычисление HMAC_message;
11. Сравнение предъявленного значения HMAC c вычисленным значением HMAC_message.

Проверка считается успешной в случае идентичности значений.

Если источник запроса – онлайн-подтверждение, то далее выполняется проверка значения SIGNATURE_message:

1. Извлечение из БД PC информации о пользователе;
2. Проверка, что пользователь не заблокирован (не стоит флаг блокировки);
3. Извлечение из БД PC активного ключа K_public.
4. Проверка, что срок действия активного ключа не истёк;
5. Извлечение из БД значения отпечатка устройства (Fingerprint);
6. Извлечение из БД PC информации о транзакции (Data), по которой выполняется подписание;
7. Формирование дискретного значения времени (Т);
8. Выполнение функции Verify (SIGNATUREmessage, Kpublic, Data+UserID+Fingerprint+T) , где
   • Verify - функция проверки электронной подписи по алгоритму ECDSA (prime256v1)/ГОСТ 34.10-2012;

Проверка считается успешной в случае положительного результата функции Verify.

Схема подписания транзакции

Для подписания данных с использованием PC выполняется следующая последовательность действий (см. пункт «Принцип работы»):

1. Прикладная система создает транзакцию:
   • передает данные для подтверждения в PC Server;
   • указывает адрес callback для возврата результата;
2. PC Server
   • отправляет push-уведомление (при необходимости), чтобы уведомить клиентское приложение о наличии операций для подтверждения;
3. Клиентская часть
   • получает push-уведомление;
   • получает список транзакций для подтверждения от PC;
   • получает данные транзакции от PC;
   • формирует электронную подпись;
   • отправляет электронную подпись на сервер PC;
4. PC Server
   • проверяет значения электронной подписи;
   • отправляет callback в прикладную систему с значением электронной подписи и результатом её проверки;
5. Прикладная система получает callback и сохраняет значение электронной подписи.

В описанном сценарии получение пользователем push-уведомления не является обязательным условием подтверждения транзакции. Мобильное приложение имеет возможность самостоятельно запустить клиентскую часть PC и получить список транзакций для подтверждения.

Схема работы приведена на Рисунке 9:

Проверка подписи

Проверка подписи, сформированной ранее, выполняется путем запроса от прикладной системы на сервер PC с передачей данных для проверки: содержания документа и всех компонентов подписи (время, подпись SIGNATURE_message, симметричный код HMAC_message и пр.).

То есть при необходимости проверки подписи Прикладная система:

• формирует (или извлекает) документ по собственным правилам (отображение пользователю может, но не обязательно, отличаться от исходного документа, например, в случае визуализации XML);
• извлекает значение подписи;
• выполняет запрос на проверку подписи в PC;
• получает результат проверки.

PC при этом самостоятельно выберет ключи, которые были использованы для формирования подписи в указанное время, и выполнит проверку с их использованием.

Аутентификация пользователей при помощи PC

PC может использоваться не только для подтверждения операций (подписи), но и для аутентификации пользователей. Условием для проведения аутентификации, также, как и для подтверждения транзакций, является наличие у пользователя ключей PC.

Так как электронная подпись основана на времени, (опционально) отпечатке устройства, ключах и данных, то первые три составляющих могут использоваться для аутентификации. В этом случае в качестве данных может быть принят заранее известный серверу и клиенту набор данных, который клиент подтвердить путем выработки подписи.

Например, в качестве данных могут использоваться:

• строка с содержанием логина клиента:
  «Вход в систему интернет-банкинга, пользователь petrov@example.ru»
• строка со временем и названием системы:
  «Вход в систему «Брокер-Онлайн» от 01.01.2026 10:20:00»
• или любое другое значение.

Если значение формируется на сервере, то оно может быть передано клиенту для подтверждения. Если же клиентское приложение также знает принцип формирования данных – оно может сразу вычислить электронную подпись и предоставить её серверу для подтверждения личности пользователя.

Обновление ключей

Ключи пользователя PC имеют ограниченный срок действия, который задаётся настройками сервера PC. Они могут быть обновлены двумя разными способами:

• со стороны Клиентской части, если действующий ключ еще не истёк;
• аналогично первоначальной персонализации (см. п. Персонализация мобильного приложения, формирование всех ключей), только в случае обновления ключей используется метод сервера PC «обновить пользователя» вместо «создать пользователя».

Обновление ключей подразумевает, что текущие ключи помечаются как «удаленные», а взамен них формируются новые, при помощи которых должна быть выполнена персонализация Клиентской части. На Клиентской части ключи, которые выводятся из обращения, должны быть удалены (заменены).

При обновлении инициируемым Клиентской частью, мобильное приложение имеет возможность запросить у сервера PC обновление ключей, подтвердив личность запрашивающего действующими ключами.

Схема обновления со стороны Клиентской части приведена на Рисунке 11:

Дополнительные сценарии

Блокировка/разблокировка пользователя

PC позволяет выполнить временную блокировку пользователя. Блокировка подразумевает, что запросы от имени заблокированного пользователя, или в отношение этого пользователя не будут выполняться серверной частью PC, а именно:

• аутентификация сетевых запросов будет давать отрицательный результат;
• невозможно создание транзакций для подтверждения;
• невозможно подтверждение уже созданных транзакций;
• невозможны никакие действия с ключами пользователей (обновление, регистрация открытых ключей и пр.).

Остаются доступными следующие функции:

• разблокировка пользователя;
• удаление пользователя.

Блокировка/разблокировка осуществляется запросом со стороны прикладной системы к серверной части PC с указанием идентификатора пользователя.

Удаление пользователя

Удаление пользователя подразумевает, что дальнейшее использование записи о пользователе возможно только для проверки подписей, сформированных ранее от его имени.

Все ключи пользователя помечаются как удаленные.

Действия при компрометации ключей пользователя

При компрометации ключей возможно выполнение одного из сценариев:

• перевыпуск ключей пользователя.
  В этом случае текущие ключи будут помечены как «удаленные» и их дальнейшее использование возможно только для проверки ранее сформированных подписей;
• блокировка с возможностью последующей разблокировки в случае, если компрометация не подтверждена;
• удаление пользователя и создание нового пользователя.
  В этом случае текущие ключи будут помечены как «удаленные» и их дальнейшее использование возможно только для проверки ранее сформированных подписей. Перевыпуск ключей будет невозможен, потребуется создание нового пользователя.

Выбор сценария зависит от бизнес-процессов прикладной системы.

Выпуск сертификатов пользователей

PC позволяет интегрироваться с УЦ в инфраструктуре заказчика для выпуска сертификатов открытых ключей конечных пользователей. Выпуск сертификатов не является обязательным для работы основных и дополнительных сценариев, но может требоваться для выполнения регуляторных требований надзорных органов, либо в соответствии с внутренними требованиями организации.

Подробнее про поддержку режима PKI описано в статье PC PKI.

Криптоалгоритмы, используемые PayControl

PC использует различные криптографические алгоритмы для реализации требований к ПО / оборудованию / безопасности. Всего существует 2 набора:

1. Набор алгоритмов для версии Lite: SHA-256 / ECDSA (prime256v1) / AES-256.
2. Набор алгоритмов для версии ГОСТ: ГОСТ 34.11-2012 (256 бит) / ГОСТ 34.10-2012 (256 бит) / ГОСТ 28147-89.

Какие алгоритмы использовать, определяется прикладной системой или конфигурацией сервера PC.

PC предусматривает два варианта реализации криптографических алгоритмов:

1. Вариант по умолчанию:

   • Сервер PC: Bouncy Castle
   • PC Mobile SDK для iOS: интегрированные функции iOS + Apple Secure Enclave
   • PC Mobile SDK для Android: интегрированные функции Android + Google KeyStore

2. Вариант ГОСТ:

   • Сервер PC: CryptoPRO JCP, version 2.0.41943
   • PC Mobile SDK для iOS: CryptoPRO CSP, version 5.0
   • PC Mobile SDK для Android: CryptoPRO CSP, version CSP 5.0

При использования варианта ГОСТ электронные подписи генерируются на мобильном устройстве, используя сертифицированное средство CryptoPro CSP.