¶ Архитектура и принципы работы myDSS 2.0
¶ Назначение
myDSS 2.0 - клиент-серверное приложение, предназначенное для централизованного выполнения действий пользователей по созданию электронной подписи (КЭП, НЭП), управления сертификатами и других криптографических операций с использованием ключей, хранимых локально в отдельном приложении или встраиваемом SDK.
Предназначен для создания как квалифицированной, так и неквалифицированной электронной подписи документов и для аутентификации пользователей в корпоративных системах, системах ДБО, торговых площадках и порталах государственных услуг.
¶ Состав
myDSS 2.0 состоит из двух частей: Серверной (DSS Сервер) и Клиентской (myDSS SDK).
¶ Серверная часть
DSS Server
Выполняет следующие функции:
- регистрация учётных записей пользователей в DSS Server;
- генерация и обновление ключевой информации пользователей для взаимодействия с сервером DSS;
- управление процессом подтверждения операций.
Может интегрироваться с серверной частью Удостоверяющего центра (далее - УЦ).
mDAG (myDSS API Gateway)
Обеспечивает взаимодействие между сервером DSS и myDSS 2.0 SDK.
Сервис рассылки уведомлений
Выполняет функции по отправке в мобильное приложение push-уведомлений о необходимости подписания документов. Доступ к функциям Сервиса со стороны Прикладной системы не осуществляется, с ним взаимодействует только DSS Server.
Примечание: Если требования к безопасности инфраструктуры запрещают DSS устанавливать соединение с внешними PUSH-серверами, дополнительный сервис PUSH Proxy позволяет организовать подобное соединение из выделенного сегмента сети (DMZ).
¶ Клиентская часть
Представляет собой приложение для мобильных платформ iOS (13 и выше) и Android (8 и выше), выполняющее следующие функции:
- управление пользователями и их ключами в рамках мобильного приложения (считывание, хранение, использование, обновление, удаление);
- получение данных операций для подтверждения от серверной части;
- отображение подтверждаемой информации на экране мобильного телефона;
- выработка электронных подписей на основе данных операции, ключей пользователя, времени выработки и (опционально) отпечатка устройства;
- отправка электронных подписей в серверную часть.
Клиентская часть представляется в виде встраиваемых библиотек для интеграции в мобильное приложение или в виде самостоятельного приложения.
¶ Схема взаимодействия компонентов
.png)
Рисунок 1 - Схема взаимодействия компонентов
¶ Архитектура и принципы работы
¶ Принцип работы
Использование myDSS 2.0 подразумевает, что подписание документа выполняется на стороне Пользователя Прикладной системы (электронного документооборота – ЭДО / системы заключения сделок с недвижимостью / системы дистанционного банковского обслуживания – ДБО / иной системы) в его мобильном телефоне.
Для этого у Пользователя есть его ключи, вся информация для онлайн-взаимодействия (URL’ы, данные для идентификации и пр.), а также необходимые для работы настройки.
С целью упрощения логики работы Прикладной системы, для получения подписи ей необходимо просто передать на подпись набор данных на сервер DSS и дождаться, уведомления от сервера DSS о подписании Пользователем. Результат (подпись и результат её проверки) передаётся Прикладной системе в виде обратного вызова (либо в виде ответа на отдельный запрос).
Данная схема приведена на Рисунке 2:
Пояснения по схеме на Рисунке 2:
- создание операции в myDSS 2.0 инициируется Прикладной системой;
- push-уведомление не содержит никакой информации об операции и служит только для того, чтобы «разбудить» приложение/уведомить пользователя, о том, что есть операция для подтверждения;
- запрос данных операции сопровождается кодом аутентификации запроса на основе ключа пользователя (KAUTH);
- код аутентификации привязан к содержанию запроса и ко времени формирования;
- данные операции могут представлять собой текст или бинарные данные (например, PDF);
- вычисление подписи выполняется одновременно по двум наборам алгоритмов: симметричным и асимметричным;
- подпись привязана ко многим составляющим, включая содержание операции, время подписания, отпечаток смартфона и ключи пользователя (KCONF и KPRIVATE);
- результат передается Прикладной системе с набором служебных параметров, включая предъявленные коды (подпись), время, результат проверки, данные по устройству, данные для дополнительной аутентификации и пр.
В данной схеме не имеет значения источник документа, т.е. как он появился на стороне Прикладной системы. Он может быть создан в веб-интерфейсе, в мобильном приложении, может быть создан автоматически.
¶ Пользователи myDSS 2.0
«Пользователь myDSS 2.0» - это устройство пользователя, соответствующее одной или нескольким его учётным записям и зарегистрированное на сервере DSS.
Одному физическому пользователю могут соответствовать несколько пользователей myDSS 2.0. В свою очередь, пользователю myDSS 2.0 могут соответствовать несколько сертификатов.
К сущности пользователя myDSS 2.0 в дальнейшем привязывается вся информация о действиях этого пользователя, в частности:
- информация о сертификатах;
- информация о ключах (текущих и используемых ранее):
- ключи KCONF и КAUTH;
- ключ KPUBLIC;
- срок действия;
- флаги;
- отпечаток привязанного устройства.
- информация об операциях:
- данные (если операция еще не была подтверждена);
- статус;
- хеш-сумма данных.
- информация о событиях:
- запросы с клиентской части;
- результат обработки запроса;
- информация об устройстве, с которого пришел запрос;
- IP-адрес, с которого пришел запрос;
- хеш-сумма тела запроса;
- предъявленный код аутентификации запроса.
- информация для отправки push-уведомлений:
- тип устройства;
- push-идентификатор устройства.
- информация о попытках подтверждения:
- тип операции: подписание/отмена;
- причина отмены (если есть): истёк таймаут, отменена сервером, отменена пользователем;
- значение подписи;
- результат проверки подписи.
В рамках myDSS 2.0 информация никогда не удаляется, за исключением очистки данных операций после того, как операция подтверждена/отменена (при этом сохраняется хэш-сумма данных).
Это позволяет в любой момент времени выяснить:
- какие ключи были использованы для подписания в каждый конкретный момент времени;
- какие ключи активны в настоящий момент;
- какие действия производились от имени Пользователя (какие запросы от него поступали и результат их выполнения) и какие события, связанные с этим пользователем, происходили;
- с какого устройства выполнялись запросы;
- какие операции и с каким результатом подтверждались/отменялись от имени Пользователя.
¶ Ключевая схема и сценарии работы
¶ Состав ключевой информации
Ключевая информация пользователя в myDSS 2.0 состоит из следующих данных:
Описательная информация:
- идентификатор прикладной системы;
- идентификатор пользователя;
- срок действия ключевой информации;
- флаги пользователя:
- необходимость сбора информации о событиях;
- необходимость сбора информации об устройстве и её состав;
- необходимость привязки к устройству пользователя (использование отпечатка устройства);
- требования к сложности пароля при сохранении;
- запрет на использование Apple TouchID/FaceID или Google Fingerprint;
- URL mDAG
Ключевая информация:
- Ключ KCONF;
- Ключ КAUTH;
- Закрытый ключ KPRIVATE;
- Открытый ключ KPUBLIC.
Ключи KCONF и КAUTH генерируются сервером DSS и возвращаются прикладной системе для дальнейшей их передачи пользователю одним из предусмотренных способов. Данные ключи представляют собой случайные данные длиной по 32 байта каждый и используются для выработки кодов аутентификации сообщений (HMAC).
Ключевая пара KPRIVATE и KPUBLIC генерируются пользователем (клиентской частью), после чего ключ KPUBLIC регистрируется на сервере и используется для проверки подписи. Данные ключи формируются на основе алгоритма ГОСТ 34.10-2012.
¶ Срок действия ключей
Сроки действия ключей задаются на серверной части и устанавливаются в момент формирования записи о ключах Пользователя, включая KCONF и КAUTH. Так как за проверку результата подписания, а также за аутентификацию запросов, отвечает сервер DSS, то контроль срока действия осуществляется на серверной части.
Срок действия ключей электронной подписи (KPUBLIC, KPRIVATE) устанавливается Удостоверяющим центром.
¶ Безопасность ключевой информации, хранящейся на мобильном устройстве
Доступ к ключевой информации, хранящейся на мобильном телефоне (KCONF, KAUTH, KPRIVATE), возможен только после ввода пароля и разблокировки устройства с помощью TouchID/FaceID или Google Fingerprint. Минимальная длина пароля составляет 6 символов. Требования к сложности пароля могут быть определены конфигурацией сервера.
Ни пароль, ни какие-либо значения на основе пароля (например, значение хэш-функции пароля) ни в какой форме не сохраняются в памяти мобильного телефона.
Ключевая информация (KCONF, KAUTH), передаваемая сервером DSS, хранится следующим образом:
- KCONF - шифруется на значении, основанном на пароле и используемом в качестве первого ключа шифрования (KEK);
- KAUTH - на значении строки, сгенерированной функциями КриптоПро CSP;
- Затем KCONF и KAUTH шифруются уникальным ключом устройства, сгенерированном аппаратной функцией смартфона и используемом в качестве второго KEK - Hardware KEK.
Далее ключевая информация сохраняется в памяти смартфона.
Чтобы получить доступ к ключевой информации, необходимой для генерации кода подтверждения (HMAC), мобильное приложение должно выполнить следующее:
- Расшифровать сохраненные ключи с помощью уникального аппаратного KEK смартфона;
- Запросить пароль;
- Рассчитать KEK на основе пароля;
- Использовать вновь полученное значение для расшифровки ключевой информации.
Следовательно, кража сохраненных ключей или данных мобильного приложения, или любая возможная модификация кода мобильного приложения бесполезны без знания пароля доступа к ключевой информации и ключа, который хранится в хранилище ключей смартфона.
В то же время KAUTH хранится только с помощью аппаратного KEK без шифрования его с помощью KEK на основе пароля. Это необходимо, поскольку myDSS SDK должен иметь возможность взаимодействовать с сервером DSS (формировать коды аутентификации для заголовков запросов), не запрашивая пароль у пользователя.
Ключевая пара (KPUBLIC, KPRIVATE) генерируется специализированным криптопровайдером CryptoPro CSP и хранится в контейнере провайдера. Контейнер (в виде бинарных данных) шифруется на значении ПИН-кода, генерируемого CryptoPro CSP при создании контейнера. Сам ПИН-код хранится в аппаратном хранилище смартфона, зашифрованный на значении аппаратного KEK.
CSP-контейнер - eдиная сущность, включающая в себя закрытый, открытый ключ, сертификат и мета-информацию. Технически, контейнер - это один или несколько связанных друг с другом бинарных файлов. Контейнер по умолчанию шифруется средствами сертифицированного провайдера, то есть критически важное содержимое файлов всегда зашифровано.
Подписание операции (документов) может быть осуществлено только на разблокированном устройстве, когда открыто приложение (myDSS app/SDK). Ключ подписи (KPRIVATE) не может быть экспортирован, передан или украден со смартфона.
Схема хранения ключей на рисунке 3:
Рисунок 3 - Схема хранения ключей
На рисунке 4 приведена схема использования ключа (получение пароля и дальнейшая расшифровка ключей):
Рисунок 4 - Схема подписания данных операции
Для вычисления HMAC используется функция ГОСТ 34.11-2012.
Для вычисления электронной подписи используется фукнция ГОСТ 34.10-2012.
ECDSA(prime256v1)/AES-256 используется в качестве аппаратного KEK в зависимости от платформы и версий операционной системы.
О методах хранения CSP контейнеров читайте в соответствующей статье.
¶ Персонализация мобильного приложения
Возможны два сценария персонализации мобильного приложения пользователя в зависимости от способа передачи ключевой информации: онлайн либо по QR-коду.
¶ Онлайн-персонализация
myDSS проверяет наличие разрешения на online-регистрацию пользователя, установленное на DSS сервере. При наличии разрешения на DSS Сервере о возможности совершения онлайн-регистрации пользователями myDSS обращается к модулю CSP за формированием асимметричных сессионных транспортных ключей.
myDSS направляет запрос на регистрацию пользователя с данными о его устройстве, прикрепляя к нему Ktransp. В ответ DSS Сервер расшифровывает запрос, создает анонимную учетную запись пользователя, генерирует данные для персонализации (KAUTH и KCONF).
Данные ключи представляют собой случайные данные длиной по 32 байта каждый и используются для выработки кодов аутентификации сообщений (HMAC).
DSS Сервер зашифровывает данные для персонализации (KAUTH и KCONF) на Ktransp. После чего направляет зашифрованные данные в myDSS вместе с открытым ключом сервера.
Полученные данные myDSS расшифровывает при помощи модуля CSP и получает набор ключей KAUTH и KCONF, а также дополнительные флаги, свидетельствующие о возможностях пользователя (например, использование TouchId/FaceId, fingerprint устройства и т.д.).
Получив информацию о данных персонализации myDSS необходимо сохранить их. Для этого myDSS обращается к пользователю с необходимостью установки пароля. Пользователь задает пароль в мобильном приложении.
После сохранения зашифрованных данных о персонализации myDSS направляет запрос на DSS сервер об успешном сохранении.
DSS Сервер меняет статус пользователя на "installed" и возвращает информацию о статусе в myDSS.
В случае если myDSS на данном шаге получает от сервера какую-либо ошибку, пользователь и его данные удаляются с устройства.
myDSS демонстрирует пользователю alias, полученный вместе с данными персонализации.
alias - уникальный идентификатор пользователя
Пользователь сообщает alias оператору (сотруднику, отвечающему за выпуск подписи конкретному пользователю), Сотрудник заполняет заявку о клиенте, которая содержит в себе всю необходимую информацию о выпуске сертификата и включает туда alias полученный от пользователя.
DSS Сервер получает алиас и меняет статус пользователя на "not verified". DSS Сервер отправляет push-уведомление пользователю о необходимости проверить мобильное приложение.
myDSS проверяет необходимость проверки данных самим пользователем. Эти данные в последствии будут указаны в выпущенном пользователю сертификате.
myDSS демонстрирует пользователю данные для проверки. Пользователь проверяет данные и подтверждает их. myDSS передает DSS Серверу информацию о подтверждении данных пользователем. DSS Сервер меняет статус пользователя на "active" и возвращает статус myDSS.
Устройство однозначно идентифицировано как устройство данного пользователя. Доступен выпуск сертификата ЭП.
¶ Диаграмма процесса
¶ Персонализация по QR-коду
Процесс предполагает те же шаги, что и онлайн-персонализация (см.предыдущий подраздел), кроме начальных действий.
myDSS запрашивает у пользователя скан QR-кода. Пользователь сканирует QR-код, чью корректность проверяет myDSS (kid, uid, serviceURL, weakness, activationRequired, keyContent).
Если данные для персонализации требуют активации, DSS Сервер направляет Пользователю код активации. После того, как пользователь ввёл код активации, персонализация продолжается.
¶ Диаграмма процесса
¶ Выпуск сертификата
myDSS обращается к DSS Серверу за запросом на выпуск сертификата (списком операций, одной из которых может быть операция на выпуск сертификата). В ответ DSS Сервер формирует неподписанный запрос на выпуск сертификата и направляет его myDSS (формируется список операций, устройство запрашивает список операций, обращается к серверу данные операции "выпуск сертификата").
myDSS запрашивает у пользователя информацию о месте хранения ключей:
- на устройстве;
- на NFC-карте/токене (подробнее о работе с токенами можете узнать здесь).
Выбор места хранения ключей пользователем может быть задан заранее на стороне приложения. В таком случае, пользователю не потребуется совершать выбор самостоятельно (в случае SDK).
Пользователь выбирает вариант с хранением ключей на устройстве. CSP модуль вызывает биологический датчик случайных чисел и на основе собранной энтропии создает защищенный контейнер и генерирует в нем асимметричную ключевую пару KPUBLIC и KPRIVATE.
myDSS обращается к CSP модулю для подписания запроса на выпуск сертификата. Подписанный запрос на выпуск сертификата отправляется в DSS Сервер. DSS Сервер выпускает сертификат с помощью подключенного к нему Удостоверяющего центра.
В случае, если пользователь уже имеет сертификат на внешнем носителе (NFC-токен), он может сразу приступить к его установке в myDSS 2.0 (см. раздел Установка сертификата из NFC-токена).
¶ Диаграмма процесса
¶ Выпуск сертификата на NFC-токен
¶ Диаграмма процесса
¶ Установка сертификата
¶ Установка сертификата, выпущенного посредством DSS Сервера
myDSS запрашивает список сертификатов у DSS Сервера. DSS Сервер возвращает список сертификатов, в котором myDSS ищет требуемый.
myDSS обращается к CSP модулю для проверки, был ли ранее установлен сертификат. Если сертификат не был установлен, myDSS обращается к CSP модулю с запросом на установку. CSP модуль устанавливает сертификат и информирует myDSS о его успешной установке.
¶ Диаграмма процесса
¶ Установка сертификата из NFC-токена
Пользователь в приложении инициирует установку нового сертификата из внешнего носителя (NFC-токена). Приложение запрашивает у пользователя пароль от NFC-токена и сам носитель.
Предоставив пароль, приложение запрашивает список хранимых на токене сертификатов. Из полученного списка пользователю необходимо выбрать те, которые он хочет установить в myDSS.
myDSS направляет модулю CSP запрос на установку сертификата. В ответ получает результат установки.
¶ Диаграмма процесса
¶ Установка сертификата на NFC-токен
На этапе выпуска сертификата пользователь может указать NFC-токен в качестве места его последующего хранения. После того как сертификат будет выпущен и получен сервером DSS, пользователь может инициировать его установку.
При наличии сертификатов в обеих областях токена различие между PIN-кодом пользователя от PKCS#11 и PIN-кодом от ФКН приведёт к ошибке чтения сертификатов. Необходимо устанавливать одинаковый код для PKCS#11 и ФКН.
¶ Диаграмма процесса
¶ Обновление сертификата
Срок действия сертификата определяется настройками Удостоверяющего центра. В myDSS 2.0 предусматривается сценарий обновления сертификата, инициируемый УЦ.
¶ Диаграмма процесса
Рисунок 9 - Обновление сертификата
¶ Код активации ключевой информации
Как показано в разделе Персонализация мобильного приложения, первоначальный набор ключей (KCONF и KAUTH) должен быть сгенерирован сервером DSS и предоставлен мобильному приложению с данными персонализации.
Данный набор может быть предоставлен в зашифрованном виде. KEK для шифрования набора ключей может быть основан на key_export_password или activation_code.
Может возникнуть сценарий, когда злоумышленник перехватит зашифрованные ключи и попытается определить key_export_password или activation_code с методом "грубой силы", особенно если приложение действительно использует слабые коды активации или пароль для экспорта.
В то же время существует другой сценарий, когда злоумышленник имеет неограниченный доступ к разблокированному телефону пользователя и пытается угадать пароль пользователя для расшифровки ключей подтверждения.
Чтобы предотвратить это, в myDSS 2.0 предусмотрена онлайн-схема проверки учетных данных.
Схема основана на следующих принципах:
- Реальное значение кода активации или пароля (который используется для получения KEK для расшифровки) хранится на сервере DSS;
- Это значение достаточно длинное и не может быть принудительно введено (случайное значение длиной 32 байта);
- Когда пользователь вводит код активации или пароль, это значение проверяется сервером DSS;
- Если верно, то DSS Server предоставляет значение для получения KEK и последующей расшифровки набора ключей;
- Если нет - сервер DSS подсчитывает неудачные попытки;
- Если количество попыток превышено, то пользователь блокируется.
В дополнение:
- Сервер DSS хранит только хэш-сумму правильного кода активации / пароля;
- Каждый запрос на проверку сопровождается меткой времени и отличается от всех предыдущих, т.е. запрос не может быть повторен;
- Верификация основана на тех же криптоалгоритмах, что и сам ключ.
¶ Схема подписания документа
Для подписания данных с использованием myDSS 2.0 выполняется следующая последовательность действий:
- Прикладная система инициирует операцию:
- передает данные (документы), полученные из сторонней системы (ЭДО, моб.приложие, ДБО, и т.п.), для подтверждения в DSS Server;
- указывает адрес callback для возврата результата;
- DSS Server:
- возвращает Прикладной системе идентификатор документа и сформированной операции;
- отправляет push-уведомление (при необходимости), чтобы уведомить клиентское приложение о наличии операций для подтверждения;
- Клиентская часть:
- получает push-уведомление;
- получает список операций для подтверждения и их данные от DSS;
- формирует электронную подпись;
- отправляет электронную подпись на сервер DSS;
- DSS Server:
- проверяет значения электронной подписи;
- отправляет callback в прикладную систему с значением электронной подписи и результатом её проверки;
- Прикладная система получает callback (при асинхронном взаимодействии) и сохраняет значение электронной подписи. В случае синхронного взимодействия результат подписания можно получить в ответе на запрос к серверу DSS - EndConfirmation.
В описанном сценарии получение пользователем push-уведомления не является обязательным условием подтверждения операции. Мобильное приложение имеет возможность самостоятельно запустить клиентскую часть (myDSS 2.0) и получить список операций для подтверждения. Схема работы приведена на Рисунке 7:
Рисунок 7 - Схема подписания документа
¶ Проверка подписи
Проверка подписи, сформированной ранее, выполняется путем запроса от Прикладной системы на сервер DSS с передачей данных для проверки: содержания документа и всех компонентов подписи (время, подпись SIGNATUREMESSAGE, симметричный код HMACMESSAGE и пр.).
То есть при необходимости проверки подписи Прикладная система:
- формирует (или извлекает) документ по собственным правилам (отображение пользователю может, но не обязательно, отличаться от исходного документа, например, в случае визуализации XML);
- извлекает значение подписи;
- выполняет запрос на проверку подписи на стороне сервера DSS;
- получает результат проверки.
¶ Аутентификация пользователей при помощи myDSS 2.0
myDSS 2.0 может использоваться не только для подтверждения операций, но и для аутентификации пользователей. Условием для проведения аутентификации, также, как и для подтверждения операций, является наличие у пользователя ключей.
Так как электронная подпись основана на времени, [опционально] отпечатке устройства, ключах и данных, то первые три составляющих могут использоваться для аутентификации. В этом случае в качестве данных может быть принят заранее известный серверу и клиенту набор данных, который клиент подтвердить путем выработки подписи.
Например, в качестве данных могут использоваться:
- строка с содержанием логина клиента
«Вход в систему интернет-банкинга, пользователь petrov@example.ru»; - строка со временем и названием системы
«Вход в систему «Брокер-Онлайн» от 01.09.2019 10:20:00»; - или любое другое значение.
Если значение формируется на сервере, то оно может быть передано клиенту для подтверждения. Если же клиентское приложение также знает принцип формирования данных – оно может сразу вычислить электронную подпись и предоставить её серверу для подтверждения личности пользователя.
¶ Обновление профиля
Ключи пользователя myDSS 2.0 (KCONF и KAUTH) имеют ограниченный срок действия, который задаётся настройками сервера DSS.
Если срок действия подходит к концу, Пользователь может инициировать обновление, принцип действия которого аналогичен процедуре регистрации пользователя на другом устройстве с той лишь разницей, что в данном сценарии "новый" профиль пользователя регистрируется на том же устройстве, заменяя собой "старый" (с которого инициировано обновление). Обновления сертификата и ключей подписи при этом не происходит.
¶ Дополнительные сценарии
¶ Блокировка/разблокировка пользователя
myDSS 2.0 позволяет выполнить временную блокировку пользователя. Блокировка подразумевает, что запросы от имени заблокированного пользователя не будут выполняться сервером DSS. А именно:
- аутентификация сетевых запросов будет давать отрицательный результат;
- невозможно создание операций для подтверждения;
- невозможно подтверждение уже созданных операций;
- невозможны никакие действия с ключами пользователей (обновление, регистрация открытых ключей и пр.).
Остаются доступными следующие функции:
- разблокировка пользователя;
- удаление пользователя.
Блокировка/разблокировка осуществляется запросом со стороны Прикладной системы к серверной части DSS с указанием идентификатора пользователя.
¶ Удаление пользователя
Удаление пользователя подразумевает, что дальнейшее использование записи о пользователе возможно только для проверки подписей, сформированных ранее от его имени.
Все ключи пользователя помечаются как удаленные.
¶ Действия при компрометации ключей пользователя
При компрометации ключей возможно выполнение одного из сценариев:
- обновление ключей пользователя (в варианте, когда отсутствуют действующие ключи)
в этом случае текущие ключи будут помечены как «удаленные» и их дальнейшее использование возможно только для проверки ранее сформированных подписей; - блокировка с возможностью последующей разблокировки в случае, если компрометация не подтверждена;
- удаление пользователя и создание нового пользователя - в этом случае текущие ключи будут помечены как «удаленные» и их дальнейшее использование возможно только для проверки ранее сформированных подписей, обновление ключей невозможно.
Выбор сценария зависит от бизнес-процессов, реализуемых Прикладной системой.
¶ Аутентификация при доступе к mDAG
Для авторизации доступа к функциям mDAG со стороны клиентской части каждый запрос сопровождается кодом аутентификации запроса. Он имеет такие же свойства, как и код подтверждения, а именно:
- привязан к содержанию запроса;
- основан на ключе пользователя – КAUTH.
Запрос на предоставление информации со стороны mDAG будет выполнен только в том случае, если проверка кода аутентификации будет пройдена успешно. В противном случае результатом запроса будет ошибка.
Код аутентификации представляет собой функцию:
AUTHCODEHTTP-Request = HMAC (KAUTH, RequestBody), где
HMAC – функция выработки кода аутентификации сообщения в соответствии с RFC2104, основанная на хеш-функции ГОСТ 34.11-2012;
KAUTH – ключ для генерации кодов аутентификации;
RequestBody – тело HTTP-запроса, отправляемого на сервер mDAG.
Значение кода аутентификации помещается в HTTP-заголовок Authorization и проверяется на стороне сервера DSS путем вычисления собственного кода, относящегося к пользователю, и его сравнения с представленным значением. Проверка состоит из следующих шагов:
- Извлечение из БД DSS информации по пользователю myDSS 2.0;
- Проверяется, что пользователь не заблокирован (не стоит флаг блокировки);
- Извлечение из БД DSS активного ключа KAUTH;
- Проверяется, что срок действия активного ключа не истёк;
- Проверяется, что активный ключ не помечен, как удалённый;
- Проверяется, что временная метка не просрочена;
- Проверяется, что отпечаток устройства соответствует зарегистрированному значению;
- Вычисление AUTHCODE’HTTP-Request;
- Сравнение предъявленного значения AUTHCODE c вычисленным значением AUTHCODE’.
В случае идентичности кодов запрос считается аутентифицированным и передаётся в дальнейшую обработку.
¶ Криптоалгоритмы, используемые myDSS 2.0
myDSS 2.0 использует криптографические ГОСТ-алгоритмы для реализации требований к ПО / оборудованию / безопасности. В частности:
- ГОСТ 34.11-2012 (256 бит);
- ГОСТ 34.10-2012 (256 бит);
- ГОСТ 28147-89.
Сервер DSS: CryptoPro JCP, версия 2.0.41943
myDSS 2.0 SDK для iOS: CryptoPro CSP, версия 5.0
myDSS 2.0 SDK для Android: CryptoPro CSP, версия CSP 5.0
Электронные подписи генерируются на мобильном устройстве, используя сертифицированное средство CryptoPro CSP.