¶ Архитектура и принципы работы
¶ Назначение
PayControl (далее - PC) – программный комплекс, предназначенный для подтверждения пользователем операций в системах дистанционного банковского обслуживания и/или электронного документооборота.
PC призван, в первую очередь, повысить уровень удобства подтверждения и информационной безопасности по сравнению с такими способами подтверждения как SMS, одноразовые пароли (One-Time Password), скретч-карты, MAC-токены и пр.
При помощи PC могут подтверждаться волеизъявления на совершение банковских транзакций, аутентификация, создание и исполнение документов, факты получения и/или ознакомления с определенной информацией.
¶ Состав
PC состоит из двух частей: Серверной и Клиентской.
¶ Серверная часть
PC Server
Интегрируется с серверной частью прикладной системы (ДБО или ЭДО) и выполняет следующие функции:
- регистрация пользователей в PC;
- генерация и обновление ключевой информации пользователей PC;
- управление процессом подтверждения транзакций;
- формирование биллинговых и информационных отчётов.
PC External
Выполняет функции по взаимодействию с мобильными приложениями, включая:
- регистрацию устройств пользователей;
- предоставление информации о транзакциях для подтверждения пользователем;
- прием и проверку при помощи PC Server подтверждения транзакций (электронной подписи).
PC Pusher
Выполняет функции по отправке в мобильное приложение push-уведомлений о необходимости подтверждения транзакций. PC Pusher представляет собой приложение для развёртывания в рамках существующего сервера приложений. Доступ к функциям PC Pusher со стороны прикладной системы не осуществляется. С ним взаимодействует только PC Server.
PC Server Signer
Компонент back-end, имитирующий работу мобильного приложения Клиента в части генерации и хранения ключей, подтверждения транзакций и т.д., но управляемый прикладной системой. PC Server Signer предназначен для реализации сценариев подписания, протекающих на серверной стороне прикладной системы.
АРМ Разбора конфликтных ситуаций
Предоставляет из себя веб-интерфейс пользователя и предназначен для получения подробной информации о пользователях PC, транзакциях, подписаниях, устройствах и т.д. Также генерирует отчеты, которые могут предоставляться комиссиям по разрешению конфликтов в качестве доказательных материалов.
¶ Клиентская часть
Представляет собой приложение для мобильных платформ iOS (13 и выше) и Android (5 и выше), выполняющее следующие функции:
- управление пользователями и их ключами в рамках мобильного приложения (считывание, хранение, использование, обновление, удаление);
- получение данных транзакций для подтверждения от серверной части в режиме онлайн или офлайн;
- отображение подтверждаемой информации на экране мобильного телефона;
- выработка электронных подписей на основе данных транзакции, ключей пользователя, времени выработки и (опционально) отпечатка устройства;
- отправка электронных подписей в серверную часть в режиме онлайн или отображение пользователю кода подтверждения в режиме офлайн.
Клиентская часть поставляется в виде встраиваемых библиотек для интеграции в мобильное приложение или отдельного приложения.
¶ Схема взаимодействия компонентов
¶ Архитектура и принципы работы
¶ Принцип работы
Использование PC подразумевает, что подписание транзакции выполняется на стороне Пользователя прикладной системы (системы дистанционного банковского обслуживания – ДБО/электронного документооборота – ЭДО) в его мобильном телефоне.
Для этого у Пользователя есть его ключи, вся информация для онлайн-взаимодействия (URL’ы, данные для идентификации и пр.), а также необходимые для работы настройки.
С целью упрощения логики работы прикладной системы для получения подписи ей необходимо просто передать на подпись набор данных на сервер PC и дождаться уведомления от сервера PC о подписании Пользователем. Результат (подпись и результат её проверки) передаётся прикладной системе в виде обратного вызова.
Данная схема приведена на Рисунок 2:
Пояснения по схеме на Рисунке 2:
- создание транзакции;
- push-уведомление не содержит никакой информации о транзакции, служит только для того, чтобы «разбудить» приложение/уведомить пользователя о том, что есть транзакция для подтверждения;
- запрос данных транзакции сопровождается кодом аутентификации запроса на основе ключа пользователя (КAUTH);
- код аутентификации привязан к содержанию запроса и ко времени формирования;
- данные транзакции могут представлять собой текст или бинарные данные (например, PDF);
- отображение данных пользователю;
- вычисление подписи выполняется одновременно по двум наборам алгоритмов: симметричным и асимметричным;
- подпись привязана к 4-м составляющим: содержанию транзакции, времени, отпечатку смартфона и ключу пользователя (KHMAC и Kprivate);
- результат передается прикладной системе с набором служебных параметров, включая предъявленные коды (подпись), время, результат проверки, скоринг, данные по устройству, данные для дополнительной аутентификации и пр.
В данной схеме не имеет значения источник документа, т.е. как он появился на стороне прикладной системы. Он может быть создан в веб-интерфейсе, в мобильном приложении, может быть создан автоматически.
Это отражено на Рисунке 3:
¶ Пользователи PC
«Пользователь PC» - это сущность, однозначно сопоставляемая с обезличенным уникальным идентификатором, к которому в дальнейшем привязывается вся информация о действиях этого пользователя в PC:
- информация о ключах (текущих и используемых ранее):
- ключи KHMAC и КAUTH;
- ключ KPUBLIC;
- срок действия;
- флаги;
- отпечаток привязанного устройства.
- информация о транзакциях:
- данные (если транзакция еще не была подтверждена);
- статус;
- хеш-сумма данных;
- параметры подтверждения: настройки скоринга, тип данных, возможность офлайн-подтверждения.
- информация о событиях:
- запросы с клиентской части;
- результат обработки запроса;
- информация об устройстве, с которого пришел запрос;
- IP-адрес, с которого пришел запрос;
- хеш-сумма тела запроса;
- предъявленный код аутентификации запроса.
- информация для отправки push-уведомлений:
- тип устройства;
- push-идентификатор устройства.
- информация о попытках подтверждения:
- тип операции: подписание/отмена;
- причина отмены (если есть): истёк таймаут, отменена сервером, отменена пользователем;
- значение подписи;
- результат проверки подписи;
- значения скоринга устройства.
В рамках PC информация никогда не удаляется, за исключением очистки данных транзакций после того, как транзакция подтверждена/отменена (при этом сохраняется хэш-сумма данных (SHA-256)).
Это позволяет в любой момент времени выяснить:
- какие ключи были использованы для подписания в каждый конкретный момент времени;
- какие ключи активны в настоящий момент;
- какие действия производились от имени Пользователя (какие запросы от него поступали и результат их выполнения) и какие события, связанные с этим пользователем, происходили;
- с какого устройства выполнялись запросы;
- какие транзакции и с каким результатом подтверждались/отменялись от имени Пользователя;
- и пр.
¶ Ключевая схема и сценарии работы
¶ Состав ключевой информации
Ключевая информация пользователя в PC состоит из следующих данных:
I Описательная информация:
- идентификатор прикладной системы;
- идентификатор пользователя;
- срок действия ключевой информации;
- флаги пользователя:
- необходимость сбора информации о событиях;
- необходимость сбора информации об устройстве и её состав;
- необходимость привязки к устройству пользователя (использование отпечатка устройства);
- требования к сложности пароля при сохранении;
- запрет на использование Apple TouchID/FaceID или Google Fingerprint;
- URL PC External
II Ключевая информация:
- Ключ KHMAC;
- Ключ КAUTH;
- Закрытый ключ KPRIVATE;
- Открытый ключ KPUBLIC.
Ключи KHMAC и КAUTH генерируются серверной частью PC и возвращаются прикладной системе для дальнейшей их передачи пользователю одним из предусмотренных способов. Данные ключи представляют собой случайные данные длиной по 32 байта каждый и используются для выработки кодов аутентификации сообщений (HMAC).
Ключевая пара KPRIVATE и KPUBLIC генерируются пользователем (клиентской частью), после чего ключ KPUBLIC регистрируется на сервере и используется для проверки подписи. Регистрация ключа KPUBLIC выполняется с контролем целостности и авторства на основе ключей KHMAC и КAUTH. Данные ключи формируются по алгоритму ECDSA с параметрами prime256v1 либо на основе алгоритма ГОСТ 34.10-2012.
¶ Срок действия ключей
Срок действия ключей задаётся на серверной части и устанавливается в момент формирования записи о ключах Пользователя, включая KHMAC и КAUTH. Так как за проверку результата подписания, а также за аутентификацию запросов, отвечает сервер PC, то контроль срока действия осуществляется на серверной части.
Значение срока действия по умолчанию – 1 год с момента генерации. Данное значение является параметром конфигурации и может быть изменено без ограничений при настройке сервера PC.
¶ Безопасность ключевой информации, хранящейся на мобильном устройстве
¶ Хранение ключей
Доступ к ключевой информации, хранящейся на мобильном устройстве (KНМАС, KPRIVATE), для последующего формирования электронных подписей и кодов подтверждения возможен только после разблокировки устройства и ввода пароля, TouchID/FaceID или Google Fingerprint в приложении. Минимальная длина пароля составляет 6 символов. Требования к сложности пароля могут быть определены конфигурацией сервера.
Ни пароль, ни какие-либо значения на основе пароля (например, значение хэш-суммы пароля) ни в какой форме не сохраняются в памяти мобильного телефона.
Ключевая информация (KНМАС, KAUTH), передаваемая сервером PC, хранится следующим образом:
- KНМАС - шифруется на значении, основанном на пароле и используемым в качестве первого ключа шифрования - Password-based Key Encryption Key (KEK);
- Затем KНМАС и KAUTH шифруются уникальным ключом устройства, сгенерированным аппаратной функцией смартфона и используемом в качестве второго KEK - Hardware KEK;
- Далее ключевая информация сохраняется в памяти смартфона. Важно, что КAUTH хранится только с помощью Hardware KEK без шифрования с помощью KEK на основе пароля. Это необходимо, так как PC Mobile SDK должен иметь возможность взаимодействовать с PC сервером, не запрашивая пароль у пользователя;
- Ключевая пара (KPRIVATE и KPUBLIC) генерируется внутри смартфона (Secure Enclave для iOS или Android KeyStore для Android) и не может быть экспортирована или извлечена. Ключ подписи (KPRIVATE) не может быть экспортирован, передан или украден с мобильного устройства.
При использовании ГОСТ-алгоритмов:
4a.1. Ключевая пара генерируется специализированным криптопровайдером (КриптоПро CSP) и хранится в контейнере провайдера;
4a.2. Контейнер защищен паролем пользователя, который устанавливается средствами КриптоПро CSP;
4a.3. Защищенный на пароле контейнер дополнительно шифруется с помощью Hardware KEK и далее сохраняется в памяти смартфона.
Кража сохраненных ключей или данных мобильного приложения, а также любая возможная модификация кода мобильного приложения бесполезны без знания пароля доступа к ключевой информации и ключа, который хранится в аппаратном обеспечении смартфона.
Схема хранения ключей:
keys_storage_store-116462db_(2).png)
Схема хранения ключей в PayControl ГОСТ:
хранение_гост.png)
¶ Использование ключевой информации в процессе подписания
Процесс подписания может быть осуществлен только на разблокированном устройстве, когда открыто приложение (PayControl App/SDK).
Подписание состоит из двух этапов:
- Генерация электронной подписи (ЭП);
- Генерация кода подтверждения (НМАС);
и предполагает следующий порядок действий:
- Расшифрование сохраненных ключей с помощью Hardware KEK. При использовании ГОСТ-алгоритмов так же происходит расшифрование контейнера КриптоПро CSP;
- Запрос пароля пользователя и расчёт KEK на его основе.
При использовании ГОСТ-алгоритмов:
2a.1. Предъявление пароля для доступа к ключевому контейнеру; - Расшифрование KНМАС с помощью КЕК, основанного на пароле пользователя;
- Генерация кода подтверждения (НМАС) на основе KНМАС и данных транзакции;
- Генерация электронной подписи. При использовании ГОСТ-алгоритмов модуль КриптоПро CSP осуществляет подписание с помощью KPRIVATE, полученного из ключевого контейнера;
- Формирование кода аутентификации запроса к серверу РС на основе KAUTH.
Схема генерации электронной подписи и кода подтверждения:
keys_storage_using-81c3ce10.png)
Схема генерации электронной подписи и кода подтверждения в PayControl ГОСТ:
подписание_гост.png)
Для шифрования используется алгоритм AES-256 или ГОСТ 28147-89.
Для вычисления HMAC используется функция SHA-256 или ГОСТ 34.11-2012.
SHA-256 или ГОСТ 34.11-2012 используется для PBKDF2 с 2000 итераций.
RSA/ECDSA(prime256v1)/AES-256 используется в качестве аппаратного KEK в зависимости от платформы и версий операционной системы.
¶ Код активации и подтверждение пароля
В разделе "Персонализация мобильного приложения" вы можете найти, что первоначальный набор ключей (KHMAC и КAUTH) должен быть сгенерирован сервером PC и предоставлен мобильному приложению с данными персонализации.
Эти ключи могут быть предоставлены в зашифрованном виде, и KEK для шифрования основан на key_export_password или activation_code.
Может возникнуть сценарий, когда злоумышленник перехватит зашифрованные ключи и попытается найти key_export_password или activation_code с помощью грубой силы. Особенно, если приложение действительно использует слабые коды активации или пароль для экспорта.
В то же время существует другой сценарий, когда злоумышленник имеет неограниченный доступ к разблокированному телефону пользователя и пытается угадать пароль пользователя для расшифровки ключей подтверждения.
Чтобы предотвратить это, на PC предусмотрена онлайн-схема проверки учетных данных.
Схема основана на следующих принципах:
- Реальное значение кода активации или пароля (который используется для получения KEK для расшифровки) хранится на сервере PC;
- Это значение достаточно длинное и не может быть принудительно введено (случайное значение длиной 32 байта);
- Когда пользователь вводит код активации или пароль, это значение проверяется сервером PC - правильное оно или нет?;
- Если верно, то PC Server предоставляет реальную ценность для получения KEK;
- Если нет - сервер PC подсчитывает неудачные попытки;
- Если количество попыток превышено, то пользователь блокируется.
В дополнение:
- PC-сервер хранит только зашифрованный хэш правильного кода активации / пароля;
- Каждый запрос на проверку сопровождается пометкой времени и отличается от всех предыдущих, т.е. запрос не может быть повторен;
- Верификация основана на тех же криптоалгоритмах, что и сам ключ (ГОСТ или не ГОСТ).
¶ Аутентификация при доступе к PC External
Для авторизации доступа к функциям PC External со стороны клиентской части каждый запрос сопровождается кодом аутентификации запроса. Он имеет такие же свойства, как и код подтверждения, а именно:
- привязан к содержанию запроса;
- основан на ключе пользователя – КAUTH.
Запрос на предоставление информации со стороны PC External будет выполнен только в том случае, если проверка кода аутентификации будет пройдена успешно. В противном случае результатом запроса будет ошибка.
Код аутентификации представляет собой функцию:
AUTHCODEHTTP-Request = HMAC (KAUTH, RequestBody), где
HMAC – функция выработки кода аутентификации сообщения в соответствии с RFC2104, основанная на хеш-функции SHA-256;
KAUTH – ключ для генерации кодов аутентификации;
RequestBody – тело HTTP-запроса, отправляемого на сервер PC External.
Значение кода аутентификации помещается в HTTP-заголовок Authorization и проверяется на стороне сервера путем вычисления собственного кода, относящегося к пользователю, и его сравнения с представленным значением. Проверка состоит из следующих шагов:
- Извлечение из БД PC информации по пользователю PC;
- Проверяется, что пользователь не заблокирован (не стоит флаг блокировки);
- Извлечение из БД PC активного ключа KAUTH;
- Проверяется, что срок действия активного ключа не истёк;
- Проверяется, что активный ключ не помечен, как удалённый;
- Проверяется, что временная метка не просрочена;
- Проверяется, что отпечаток устройства соответствует зарегистрированному значению;
- Вычисление AUTHCODE’HTTP-Request;
- Сравнение предъявленного значения AUTHCODE c вычисленным значением AUTHCODE’.
В случае идентичности кодов запрос считается аутентифицированным и передаётся в дальнейшую обработку.
¶ Персонализация мобильного приложения, формирование всех ключей
Персонализация мобильного приложения подразумевает несколько шагов, выполняемых последовательно:
- Первым шагом Прикладная система создаёт (или обновляет) запись о пользователе PC в серверной части PC.
- Прикладная система получает набор данных для персонализации (описательная информация, ключи KHMAC и КAUTH), которая должна быть передана на мобильное устройство одним из предусмотренных способов:
- [Automatically] Передача ключей в зашифрованном виде онлайн.
Данный способ подразумевает, что у пользователя существует канал связи с прикладной системой (например, уже установлено приложение Мобильного банкинга). В этом случае данные для персонализации и ключи могут быть доставлены из серверной части PC в зашифрованном виде и сохранены в мобильном телефоне. Ключом шифрования может являться любой секрет, известный прикладной системе и мобильному приложению. Например, пин-код пользователя, случайный одноразовый пароль, производная от идентификатора сессии и пр. - [QR-Code] Путем передачи пользователю QR-кода, который содержит всю необходимую описательную и ключевую информацию.
Данный способ подразумевает, что передача QR-кода должна осуществляться по доверенному каналу. Наиболее доверенный канал – на бумажном носителе при посещении. - [QR-Code + Activation Code] Передача ключей по двум каналам.
В данном случае PC разделяет ключевую информацию на две части. Первая часть предоставляется пользователю в виде QR-кода в интерфейсе браузера или любым другим способом, вторая – отправляется одноразово другим каналом: SMS, email, на бумажном носителе и пр. Пользователь после сканирования QR-кода вводит вторую часть ключа и получает полный набор для дальнейшего использования. - [Deep Link] Путем передачи пользователю deeplink-ссылки.
При переходе по ссылке пользователь автоматически переходит в мобильное приложение, получая данные для персонализации. - [Deep Link + Activation Code] Передача ключей по двум каналам.
После отправки прикладной системой запроса на создание пользователя PC Server генерирует Deep Link и код активации для персонализации (может передаваться различными каналами, например, по электронной почте или SMS). Клиент нажимает на ссылку и автоматически переходит в мобильное приложение, получая часть данных для персонализации. Далее Клиент вводит код активации в мобильном приложении для получения оставшихся данных для персонализации. При переходе по ссылке пользователь автоматически переходит в мобильное приложение, п
- [Automatically] Передача ключей в зашифрованном виде онлайн.
- Мобильное приложение:
- импортирует данные для персонализации, получая все необходимые для дальнейшей работы данные;
- при необходимости расшифровывает ключи KHMAC и КAUTH;
- генерирует ключевую пару KPRIVATE и KPUBLIC;
- формирует отпечаток устройства;
- получает push-идентификатор устройства;
- регистрирует на сервере PC KPUBLIC, отпечаток устройства и push-идентификатор;
- сохраняет данные о пользователе PC в памяти приложения.
Схемы вариантов персонализации приведены на схемах ниже:
Рисунок 7 - Автоматическая персонализация устройства
Рисунок 8 - Персонализация устройства с помощью QR
Рисунок 9 - Персонализация устройства двумя каналами
¶ Выработка и проверка подписи
Подпись данных транзакции вырабатывается на основе 4-х составляющих:
- данные транзакции, включая идентификатор пользователя;
- время формирования кода подтверждения;
- ключевая информация пользователя (KHMAC и KPRIVATE);
- отпечаток устройства.
PC предоставляет возможность подтверждения данных в онлайн- и офлайн-режимах.
Для подтверждения в офлайн-режиме подпись должна представлять собой последовательность, которая может быть предоставлена пользователем в ручном режиме для дальнейшей проверки. Другими словами, код подтверждения должен быть длиной не более 10 символов.
С целью получения подписи такой длины с соблюдением условия его зависимости от нескольких составляющих, необходимо использование симметричной криптографической операции с последующим «укорачиванием» результата по определенному алгоритму. Это необходимо для того, чтобы проверяющая сторона могла вычислить такое же значение, укоротить его по тому же алгоритму и сравнить результат.
При работе в онлайн-режиме ручных операций от пользователя не требуется. Поэтому есть возможность использования асимметричных алгоритмов, основанных на паре открытый-закрытый ключ. Значение электронной подписи может быть предоставлено в полном виде путем онлайн-обмена.
Поэтому в PC подпись вырабатывается в трех значениях:
- Код подтверждения полный – HMACMESSAGE;
- Код подтверждения «укороченный» – HMACMESSAGE при D от 6 до 10;
- Асимметричная подпись – SIGNATUREMESSAGE.
Код подтверждения (полный и «укороченный») представляет собой функцию:
HMACMESSAGE = Truncate (HMAC (KHMAC, Data+UserID+Отпечаток+T), D), где
HMAC – функция выработки кода аутентификации сообщения в соответствии с RFC2104, основанная на хеш-функции SHA-256;
KHMAC – ключ для генерации HMAC сообщения;
Data – данные транзакции в формате TLV;
UserID – идентификатор пользователя в PC в формате TLV;
Отпечаток – отпечаток устройства в формате 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+Отпечаток+T), где
SIGN – функция выработки электронной подписи по алгоритму ECDSA (prime256v1);
KPRIVATE – закрытый ключ из ключевой пары пользователя;
Data – данные транзакции в формате TLV;
UserID – идентификатор пользователя в PC в формате TLV;
Отпечаток – отпечаток устройства в формате TLV;
T – дискретное значение времени, интервал дискретизации – по умолчанию 180 секунд (настраиваемое значение) в формате TLV;
Операция «+» означает конкатенацию значений байтов.
Если клиентская часть имеет возможность вычислить и передать асимметричную подпись (сформирована ключевая пара и открытый ключ зарегистрирован на сервере), то сервер примет попытку подтверждения только если значения SIGNATUREMESSAGE и HMACMESSAGE проходят проверку одновременно.
Если клиентская часть не имеет возможность вычислить или передать значение подписи (открытый ключ не зарегистрирован на сервере, мобильный телефон офлайн, используется офлайн-подтверждение), то сервер примет подтверждение только по HMACMESSAGE.
Проверка подписи выполняется путем последовательной проверки корректности HMACMESSAGE и SIGNATUREMESSAGE.
Проверка HMACMESSAGE включает следующие шаги:
- Извлечение из БД PC информации о пользователе;
- Проверка, что пользователь не заблокирован (не стоит флаг блокировки);
- Извлечение из БД PC активного ключа KHMAC;
- Проверка, что срок действия активного ключа не истёк;
- Проверка, что активный ключ не помечен, как удалённый;
- Извлечение из БД значения отпечатка устройства (Отпечаток);
- Извлечение из БД PC информации о транзакции (Data), по которой выполняется подписание;
- Формирование дискретного значения времени (Т);
- Проверка допустимого значения D (проверяется источник HMACMESSAGE – онлайн или офлайн);
- Вычисление HMAC’MESSAGE;
- Сравнение предъявленного значения HMAC c вычисленным значением HMAC’.
Проверка считается успешной в случае идентичности значений.
Если источник запроса – онлайн-подтверждение, то выполняется проверка значения SIGNATUREMESSAGE:
- Извлечение из БД PC информации о пользователе;
- Проверка, что пользователь не заблокирован (не стоит флаг блокировки);
- Извлечение из БД PC активного ключа KPUBLIC;
- Проверка, что срок действия активного ключа не истёк;
- Извлечение из БД значения отпечатка устройства (Отпечаток);
- Извлечение из БД PC информации о транзакции (Data), по которой выполняется подписание;
- Формирование дискретного значения времени (Т);
- Выполнение функции Verify (SignatureMESSAGE, KPUBLIC, Data+UserID+Отпечаток+T), где
Verify - функция проверки электронной подписи по алгоритму ECDSA (prime256v1).
Проверка считается успешной в случае положительного результата функции Verify.
¶ Схема подписания транзакции
Для подписания данных с использованием PC выполняется следующая последовательность действий (см. пункт «Принцип работы»):
- прикладная система создает транзакцию:
- передает данные для подтверждения в PC Server;
- указывает адрес callback для возврата результата;
- PC Server:
- отправляет push-уведомление (при необходимости), чтобы уведомить клиентское приложение о наличии операций для подтверждения;
- клиентская часть:
- получает push-уведомление;
- получает список транзакций для подтверждения от PC;
- получает данные транзакции от PC;
- формирует электронную подпись;
- отправляет электронную подпись на сервер PC;
- PC Server:
- проверяет значения электронной подписи;
- отправляет callback в прикладную систему с значением электронной подписи и результатом её проверки;
- прикладная система получает callback и сохраняет значение электронной подписи.
В описанном сценарии получение пользователем push-уведомления не является обязательным условием подтверждения транзакции. Мобильное приложение имеет возможность самостоятельно запустить клиентскую часть PC и получить список транзакций для подтверждения. Схема работы приведена на Рисунке 10:
.svg)
Рисунок 10 - Схема подписания документа
¶ Имитовставка
В качестве дополнительной меры по соблюдению законодательства сервер PC может вычислять дополнительный серверный HMAC (также называемый имитовставкой (imit value)) с помощью специализированного криптопровайдера.
На данный момент поддерживается только один криптопровайдер - CryptoPro JCP, версия 2.0.41943.
В случае, если эта функция включена, то:
- процесс подписания будет включать в себя дополнительный шаг - вычисление imit value;
- callback приложению будет также поступать imit value;
- imit value может быть проверено в дополнение к SIGNATUREmessage и HMACmessage.
Заключительные шаги процесса подписания будут выглядеть следующим образом:
Рисунок 11 - Имитовставка
¶ Проверка подписи
Проверка подписи, сформированной ранее, выполняется путем запроса от прикладной системы на сервер PC с передачей данных для проверки: содержания документа и всех компонентов подписи (время, подпись SIGNATUREMESSAGE, симметричный код HMACMESSAGE и пр.).
То есть при необходимости проверки подписи Прикладная система:
- формирует (или извлекает) документ по собственным правилам (отображение пользователю может, но не обязательно, отличаться от исходного документа, например, в случае визуализации XML);
- извлекает значение подписи;
- выполняет запрос на проверку подписи в PC;
- получает результат проверки.
PC при этом самостоятельно выберет ключи, которые были использованы для формирования подписи в указанное время, и выполнит проверку с их использованием.
¶ Аутентификация пользователей при помощи PC
PC может использоваться не только для подтверждения операций (подписи), но и для аутентификации пользователей. Условием для проведения аутентификации, также, как и для подтверждения транзакций, является наличие у пользователя ключей PC.
Так как электронная подпись основана на времени, [опционально] отпечатке устройства, ключах и данных, то первые три составляющих могут использоваться для аутентификации. В этом случае в качестве данных может быть принят заранее известный серверу и клиенту набор данных, который клиент подтвердить путем выработки подписи.
Например, в качестве данных могут использоваться:
- строка с содержанием логина клиента
«Вход в систему интернет-банкинга, пользователь petrov@example.ru»; - строка со временем и названием системы
«Вход в систему «Брокер-Онлайн» от 01.09.2019 10:20:00»; - или любое другое значение.
Если значение формируется на сервере, то оно может быть передано клиенту для подтверждения. Если же клиентское приложение также знает принцип формирования данных – оно может сразу вычислить электронную подпись и предоставить её серверу для подтверждения личности пользователя.
¶ Обновление ключей
Ключи пользователя PC имеют ограниченный срок действия, который задаётся настройками сервера PC. Они могут быть обновлены двумя разными способами:
- со стороны Клиентской части, если действующий ключ еще не истёк;
- аналогично первоначальной персонализации (см. п. Персонализация мобильного приложения, формирование всех ключей), только в случае обновления ключей используется метод сервера PC «обновить пользователя» вместо «создать пользователя».
Обновление ключей подразумевает, что текущие ключи помечаются как «удаленные», а взамен них формируются новые, при помощи которых должна быть выполнена персонализация Клиентской части. На Клиентской части ключи, которые выводятся из обращения, должны быть удалены (заменены).
При обновлении инициируемым Клиентской частью, мобильное приложение имеет возможность запросить у сервера PC обновление ключей, подтвердив личность запрашивающего действующими ключами.
Схема обновления со стороны Клиентской части приведена на Рисунке 12.
Рисунок 12 - Обновление ключей
¶ Дополнительные сценарии
¶ Блокировка/разблокировка пользователя
PC позволяет выполнить временную блокировку пользователя. Блокировка подразумевает, что запросы от имени заблокированного пользователя не будут выполняться серверной частью PC. А именно:
- аутентификация сетевых запросов будет давать отрицательный результат;
- невозможно создание транзакций для подтверждения;
- невозможно подтверждение уже созданных транзакций;
- невозможны никакие действия с ключами пользователей (обновление, регистрация открытых ключей и пр.).
Остаются доступными следующие функции:
- разблокировка пользователя;
- удаление пользователя.
Блокировка/разблокировка осуществляется запросом со стороны прикладной системы к серверной части PC с указанием идентификатора пользователя.
¶ Удаление пользователя
Удаление пользователя подразумевает, что дальнейшее использование записи о пользователе возможно только для проверки подписей, сформированных ранее от его имени.
Все ключи пользователя помечаются как удаленные.
¶ Действия при компрометации ключей пользователя
При компрометации ключей возможно выполнение одного из сценариев:
- обновление ключей пользователя (в варианте, когда отсутствуют действующие ключи)
в этом случае текущие ключи будут помечены как «удаленные» и их дальнейшее использование возможно только для проверки ранее сформированных подписей; - блокировка с возможностью последующей разблокировки в случае, если компрометация не подтверждена;
- удаление пользователя и создание нового пользователя
в этом случае текущие ключи будут помечены как «удаленные» и их дальнейшее использование возможно только для проверки ранее сформированных подписей, обновление ключей невозможно;
Выбор сценария зависит от бизнес-процессов прикладной системы.
¶ Криптоалгоритмы, используемые PayControl
PC использует различные криптографические алгоритмы для реализации требований к ПО / оборудованию / безопасности. Всего существует 2 набора:
- Набор алгоритмов по умолчанию: SHA-256 / ECDSA (prime256v1) / AES-256;
- Алгоритмы ГОСТ: ГОСТ 34.11-2012 (256 бит) / ГОСТ 34.10-2012 (256 бит) / ГОСТ 28147-89.
Какие алгоритмы использовать, определяется приложением или конфигурацией сервера PC.
PC предусматривает два варианта реализации криптографических алгоритмов:
Вариант по умолчанию:
Сервер PC: Bouncy Castle;
PC Mobile SDK для iOS: интегрированные функции iOS + Apple Secure Enclave;
PC Mobile SDK для Android: интегрированные функции Android + Google KeyStore.
Вариант ГОСТ:
Сервер PC: CryptoPro JCP, версия 2.0.41943
PC Mobile SDK для iOS: CryptoPro CSP, версия 5.0
PC Mobile SDK для Android: CryptoPro CSP, версия CSP 5.0
При использования варианта ГОСТ электронные подписи генерируются на мобильном устройстве, используя сертифицированное средство CryptoPro CSP.