Стандарт платформы цифрового рубля. Спецификация на программный модуль

Сокращения, используемые при формировании шаблона, представлены в Таблице 5.

Таблица 4 — Описание кодов шаблона подписи потоков

3.1.2 Список компонентов

В Таблице 5 представлено описание компонентов, отображенных на Рисунке 2.

Таблица 5 — Описание компонентов функциональной схемы решения

3.1.3 Функции по информационным потокам

В Таблице 6 представлена связь информационных потоков с соответствующими им функциями.

Таблица 6 — Связь потоков с функциями ПМ

3.2 Описание классов и методов ПМ

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

Необходимость вывода ошибок и отображаемая пользователю информация в интерфейсе МП должны определяться разработчиком МП.

Передача параметров при вызове функций СКЗИ должна быть реализована в соответствии с рекомендациями производителей ОС.

Не рекомендуется использовать пустые значения входных параметров функций.

Все методы должны прерывать выполнение и возвращать код ошибки «Требуется инициализация ПМ», если не был вызван метод инициализации ПМ.

Если вызов метода произошел во время выполнения метода инициализации, ПМ не должен прерывать выполнение метода. Ранее вызванная инициализация должна завершиться, после чего выполняется обработка вызова.

3.2.1 Класс Core

Класс Core содержит основные методы ПМ.

3.2.1.1 Метод init (filesWithCheckSums)

Метод инициализации ПМ и СКЗИ.

Входные данные

- filesWithCheckSums — массив пар строк. Массив содержит эталонные значения хэшей, рассчитанные от файлов и ресурсов МП, целостность которых необходимо проверить, и пути к ним. Хэши должны быть рассчитаны в соответствии с документом [30].

Выходные данные

• result — строка, в случае успеха возвращает «ОК».

Требования

Выполнение проверок.

1. В случае повторного вызова метода инициализации вернуть код ошибки «Инициализация ПМ уже выполнена».

2. Проверить:

а) наличие root-доступа для Google Android, HarmonyOS и Аврора или jailbreak для Apple iOS;

b) маскировку наличия у пользователя прав суперпользователя (Root Cloaking Detection);

c) использование устройством модифицированной (неофициальной) прошивки (Custom Firmware Detection);

d) запуск приложения на эмуляторе устройства (Emulator Detection);

e) использование функций отладчика при запуске приложения (Debug Detection);

f) наличие программных средств, позволяющих изменять поведение приложений или ОС за счет перехвата вызовов и других способов воздействия на программную среду (Hooks Detection).

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

4. Инициализировать СКЗИ для обеспечения корректной работы функций криптографической защиты, инициализировать область памяти в СКЗИ.

5. При получении уведомления от СКЗИ об отсутствии или недостаточном количестве информационной энтропии выполнение метода инициализации должно приостанавливаться, а после сбора достаточного количества энтропии корректного возобновляться.

6. Вызвать метод checkIntegrity (filesWithCheckSums). На вход передать значения, полученные во входных параметрах метода инициализации.

7. Установить в хранилище СКЗИ серверный ГОСТ-TLS-сертификат и связанную с ним цепочку сертификатов, включающую все промежуточные сертификаты, сертификат промежуточного УЦ и сертификат корневого УЦ:

a) корневые (самоподписанные) сертификаты УЦ БР и УЦ Безопасности, промежуточный сертификат ПУЦ УНЭП должны быть включены в ресурс МП;

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

8. Вернуть «ОК».

9. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.1.2 Метод initCryptContext (storeId, userId)

Метод инициализации контейнера криптографических ключей.

Входные данные <3>

<3> Список входных данных может быть расширен в зависимости от особенностей реализации СКЗИ.

• storeId — строка, уникальный идентификатор сегмента хранилища СКЗИ;
• userId — строка, уникальный идентификатор пользователя МП. Необязательный параметр.

Выходные данные

• cryptContext — структура данных, полученная от СКЗИ и содержащая информацию о состоянии и параметрах работы с криптографическим провайдером.

Требования

Для каждого пользователя может быть создано несколько защищенных хранилищ с доступом по паролю. Идентификаторы хранилищ должны быть уникальными для уникальных пользователей и формироваться на стороне МП (требования к идентификатору хранилища СКЗИ и идентификатору пользователя МП см. в пунктах 3.2.3.2 и 3.3.2).

1. Если идентификатор пользователя не передан, то перейти к шагу 6 и выполнить инициализацию контекста для корневого хранилища.

2. Проверить, был ли ранее сохранен идентификатор пользователя МП во внутреннем хранилище ПМ.

3. Если идентификатор пользователя найден, то перейти к шагу 6.

4. Если идентификатор пользователя не найден, то вызвать метод удаления найденных сегментов хранилища СКЗИ и всей ключевой информации — deleteStore (storeId).

5. Сохранить идентификатор пользователя и идентификатор хранилища СКЗИ во внутреннем хранилище ПМ, если они не были ранее сохранены во внутреннем хранилище ПМ.

6. Вызвать метод инициализации контекста криптографического провайдера в СКЗИ в соответствии с уникальным идентификатором хранилища:

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

b) в ответ СКЗИ должно возвращать объект cryptContext, содержащий структуру данных с информацией о криптопровайдере, для выполнения последующих криптографических операций и управления криптографическими ресурсами.

7. Вернуть полученный объект cryptContext.

8. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.1.3 Метод checkIntegrity (filesWithCheckSums)

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

Входные данные

- filesWithCheckSums — массив, содержащий эталонные значения хэшей, рассчитанных от файлов и ресурсов МП, целостность которых необходимо проверить, и пути к ним (структура элементов массива может определяться разработчиком ПМ в зависимости от особенностей ОС).

Выходные данные

• result — строка. В случае успеха возвращает код «ОК», в случае неуспеха — код «INVALID».

Требования

1. Рассчитать контрольные значения хэшей для каждого файла из filesWithCheckSums. Для этого:

a) инициировать вызов в СКЗИ функции вычисления хэшей необходимого файла;

b) хэши должны рассчитываться в соответствии с документом [30].

2. Сравнить вычисленные хэши и значения контрольных сумм из filesWithCheckSums для проверяемого файла.

3. В случае совпадения всех вычисленных хэшей с эталонными значениями вернуть код «ОК».

4. В случае хотя бы одного не совпадения — вернуть код «INVALID».

5. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ необходимо прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.1.4 Метод getAccessTime (storeId)

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

Входные данные

• storeId — строка, идентификатор хранилища СКЗИ.

Выходные данные

- accessTime — время в секундах, оставшееся до конца блокировки.

Требования

1. Извлечь из внутреннего хранилища ПМ значение времени окончания блокировки по идентификатору защищенного хранилища СЗКИ.

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

a) если время окончания блокировки для хранилища не найдено, то вернуть 0;

b) если в результате вычисления дельты получено отрицательное значение, то вернуть 0.

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

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий необходимо прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.1.5 Метод getPasswordExpirationTime (storeId, timeZone)

Метод получения времени действия пароля к хранилищу СКЗИ.

Входные данные

• storeId — строка, идентификатор хранилища СКЗИ;
• timeZone — строка, часовой пояс, в котором необходимо вернуть дату и время истечения срока действия пароля.

Выходные данные

- expirationTime — datatime, дата и время срока истечения действия пароля в часовом поясе из timeZone.

Требования

1. Вызвать функцию СКЗИ для получения времени истечения срока действия пароля для полученного идентификатора хранилища СКЗИ.

2. Привести полученное временное значение к часовому поясу, полученному в параметре timeZone.

3. Вернуть дату и время истечения срока действия пароля.

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий необходимо прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.1.6 Метод changePassword (storeId)

Метод изменения пароля к хранилищу СКЗИ.

Входные данные

- storeId — строка, идентификатор хранилища СКЗИ.

Выходные данные

• result — строка, в случае успеха возвращает код «ОК».

Требования

1. Вызвать метод СКЗИ для изменения пароля защищенного хранилища. Интерфейс для смены пароля сегмента хранилища должен вызываться с помощью СКЗИ.

2. После успешного выполнения функции вернуть «ОК».

3. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.1.7 Метод releaseContext (cryptoContext)

Метод деинициализации работы с защищенным хранилищем.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере.

Выходные данные

- result — строка, в случае успеха возвращает код «ОК»

Требования

1. Вызвать функцию СКЗИ для деинициализации cryptContext.

2. Если установлено одностороннее или двустороннее ГОСТ-TLS соединение, то при завершении работы с хранилищем соединение необходимо разрывать.

3. После успешного выполнения функции вернуть «ОК».

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ необходимо прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.1.8 Метод getAuditLog (timeBegin, timeEnd)

Метод получения журнала аудита. <4>

<4> Журнал формируется за период времени по всем хранилищам в рамках одного мобильного устройства. При вызове функции необходимо дополнительно применять фильтрацию при выводе логов пользователю.

Входные данные

- timeBegin — Unix Timestamp, дата начала фиксации событий;

- timeEnd — Unix Timestamp, дата окончания фиксации событий.

Выходные данные

• auditLog — массив структур данных, содержащих следующие элементы:
• id — строка, уникальный идентификатор действия;
• createdAt — Unix Timestamp, дата и время действия;
• functionName — строка, название вызванного метода;
• result — строка, результат выполнения функции (SUCCESS, FAIL);
• inputData — строка, список входных данных, может быть пустым;
• outputData — строка, список выходных данных, может быть пустым;
• storeId — строка, идентификатор хранилища, может быть пустым;
• errorCode — целое число, код ошибки, может быть пустым;
• errorMessage — строка, описание ошибки, может быть пустым.

Требования

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

2. Отсортировать извлеченные данные по возрастанию даты и времени действия (createdAt).

3. Вернуть извлеченный отсортированный список.

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.1.9 Метод registerInstallation()

Метод регистрации установки и учета СКЗИ.

Входные данные

- отсутствуют

Выходные данные

• id — строка, уникальный идентификатор установки СКЗИ;
• date — datatime, дата и время установки СКЗИ в UTC.

Требования

1. Метод должен выполнять действия по регистрации экземпляра СКЗИ с учетом имеющихся механизмов СКЗИ.

2. Разработчик ПМ должен самостоятельно продумать алгоритм регистрации, если используемое СКЗИ не предоставляет механизм поэкземплярного учета.

3. В результате успешного выполнения метода вернуть уникальный идентификатор установки экземпляра СКЗИ и дату и время установки в UTC.

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ необходимо прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.2 Класс Rng

3.2.2.1 Метод customizeEntropyScreen (textLabels, backgroundColor, controlColor)

Метод предназначен для адаптации дизайна экрана работы с БДСЧ к стилю МП. Реализация работы БДСЧ и возможность адаптации дизайна экрана работы с БДСЧ должны соответствовать эксплуатационной документации на СКЗИ.

Входные данные <5>

<5> Список входных данных может быть расширен в зависимости от возможностей СКЗИ по изменению дизайна экрана сбора энтропии.

• textLabels — массив строк, содержащий тексты для замены надписей;
• backgroundColor — строка, содержащая шестнадцатеричный код цвета замены для фона;
• controlColor — строка, содержащая шестнадцатеричный код цвета замены для элементов управления.

Выходные данные

- result — строка, в случае успеха возвращает код «ОК».

Требования

1. Вызвать соответствующую функцию СКЗИ для адаптации дизайна экрана работы с БДСЧ. На вход передать полученные параметры.

2. Вернуть «ОК».

3. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3 Класс Operations

Класс Operations содержит криптографические методы ПМ.

3.2.3.1 Общие требования к криптографическим методам

Все методы должны прерывать выполнение и возвращать код ошибки в соответствии с описанием в разделе 3.2.6, если:

• отсутствует инициализированное хранилище СКЗИ для полученного cryptContext;
• пароль хранилища неверный;
• целостность файлов или ресурсов МП нарушена.

3.2.3.2 Доступ к криптографическим функциям и защищенному хранилищу в СКЗИ

1. Защищенное хранилище СКЗИ должно быть сегментировано для возможности хранения различных пар криптографических ключей.

2. СКЗИ должно иметь возможность создания отдельного защищенного хранилища с доступом по паролю.

3. Доступ к определенному сегменту хранилища СКЗИ должен выполняться в соответствии с уникальным идентификатором хранилища и паролем.

4. Пароль к хранилищу устанавливается при создании хранилища.

5. В рамках одной сессии пользователя после первой инициализации хранилища по идентификатору и паролю доступ к хранилищу криптографических ключей осуществляется по полученному от СКЗИ объекту cryptContext.

6. При инициализации хранилища необходимо проверять срок действия пароля при помощи функции СКЗИ. Если срок действия пароля истек, то необходимо вернуть код, соответствующий ошибке «Истек срок действия пароля» (см. раздел 3.2.6). Доступ к криптографическим функциям не должен предоставляться до тех пор, пока пароль не будет изменен.

3.2.3.3 Блокировка доступа

Если вызов любого метода СКЗИ для заданного идентификатора хранилища завершается ошибкой, связанной с неверно введенным паролем, ПМ должен:

1. Прервать выполнение метода.

2. Обновить во внутреннем хранилище информацию о том, сколько раз подряд пароль был введен неверно.

3. При достижении 5 неудачных попыток аутентификации необходимо сохранить во внутреннем хранилище время окончания блокировки для данного экземпляра хранилища в UTC, рассчитанное как текущее время + 30 минут. Если ранее время окончания блокировки уже сохранялось, необходимо сохранить новое значение.

4. Вернуть код, соответствующий ошибкам «Истек срок действия пароля» или «Неверный пароль» (см. раздел 3.2.6).

Если пароль введен корректно и выполнен вызов метода СКЗИ, то счетчик неуспешных попыток должен сбрасываться.

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

Количество неудачных попыток и время блокировки доступа должны настраиваться константами на этапе сборки, храниться в неизменяемых ресурсах и соответствовать правилам использования СКЗИ. Значения параметров могут быть уточнены на этапе разработки ПМ.

Значения по умолчанию:

- количество неудачных попыток — 5;

- время блокировки доступа к криптографическим функциям — 30 минут.

3.2.3.4 Проверка сертификатов и криптографических ключей

При использовании закрытого криптографического ключа СКЗИ должно выполнять проверки срока действия закрытого ключа. Если срок действия ключа истек, необходимо прервать выполнение метода и вернуть соответствующую ошибку.

При использовании сертификатов криптографических ключей необходимо получить доступ к ранее сохраненному CAC посредством СКЗИ и проверить наличие сертификата в списке. Если сертификат недействителен, необходимо прервать выполнение метода и вернуть соответствующую ошибку.

3.2.3.5 Метод saveCertificates (cryptContext, certDate, certStoreType, certFormat)

Метод, сохраняющий сертификаты криптографических ключей.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• certData — структура данных, содержащая массивы байт и псевдонимы, под которыми сертификаты сохраняются в хранилище СКЗИ;
• certStoreType — строка, содержащая тип хранилища сертификатов. Перечень возможных значений определяется функциональностью предоставляемой СКЗИ;

- certFormat — строка, содержащая формат сертификатов.

Выходные данные

• result — строка, в случае успеха возвращается «ОК».

Требования

1. Вызвать функцию СКЗИ для сохранения полученных сертификатов в указанное хранилище:

a) если не удалось сохранить сертификат, прервать выполнение метода и вернуть соответствующую причину ошибки;

b) при необходимости преобразовать сертификаты в нужный формат.

2. Вернуть «ОК».

3. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.6 Метод saveCrl (crlData, crlFormat)

Метод, сохраняющий CAC.

Входные данные

• crlData — массив байт, содержащий CAC;
• crlFormat — строка, содержащая формат CAC.

Выходные данные

- result — строка, в случае успеха возвращается «ОК».

Требования

1. Вызвать функцию СКЗИ для сохранения CAC в хранилище сертификатов СКЗИ:

a) если не удалось сохранить CAC, прервать выполнение метода и вернуть соответствующую причину ошибки;

b) при необходимости преобразовать CAC в нужный формат.

2. Вернуть «ОК».

3. В случае других непредвиденных ошибок прервать выполнение метода и вернуть соответствующую причину ошибки.

3.2.3.7 Метод genKeyPair (cryptContext, lenghtKey)

Метод формирования и сохранения криптографических ключей пользователя.

Входные данные

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

Выходные данные

- result — строка, в случае успеха возвращается «ОК».

Требования

1. Вызвать метод СКЗИ для формирования криптографических ключей пользователя:

a) в соответствии с указанной длиной;

b) ключи должны формироваться в соответствии с [2], [20].

2. Вызвать метод СКЗИ для сохранения сформированных криптографических ключей пользователя в соответствии с полученным cryptContext:

a) пара ключей должна сохраняться в соответствующем защищенном хранилище;

b) закрытый ключ должен быть неэкспортируемым.

3. Если ключи успешно созданы и сохранены, необходимо возвращать код «ОК».

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.8 Метод genTlsKeyPair (cryptContext, lenghtKey)

Метод формирования и сохранения транспортных криптографических ключей.

Входные данные

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

Выходные данные

- result — строка, в случае успеха возвращается «ОК».

Требования

1. Вызвать метод СКЗИ для формирования криптографических ключей:

a) в соответствии с указанной длиной;

b) ключи должны формироваться в соответствии с документами [2], [20].

2. Вызвать метод СКЗИ для сохранения сформированных криптографических ключей в соответствии с полученным cryptContext:

a) пара ключей должна сохраняться в соответствующем защищенном хранилище;

b) закрытый ключ должен быть неэкспортируемым.

3. Если ключи успешно созданы и сохранены, необходимо вернуть код «ОК».

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.9 Метод createCertRequest (cryptContext, certRequestParams, isSubstitution)

Метод создания запроса на СКПЭП пользователя.

Входные данные

- cryptContext — структура данных, содержащая информацию о криптографическом провайдере;

- certRequestParams — структура данных, содержащая атрибуты и поля для включения в СКПЭП. В случае формирования запроса на СКПЭП с целью его использования для операций с ЦР структура certRequsetParams должна соответствовать документу [10];

- isSubstitution — флаг замены существующего сертификата. Значение false, если запрос на сертификат создается первый раз; значение true для запроса на обновление существующего сертификата.

Выходные данные

• request — массив байт, содержащий созданный запрос в формате PKCS#10/PKCS#7.

Требования

1. Вызвать функции СКЗИ для формирования запроса на СКПЭП пользователя МП:

a) в соответствии с полученными входными данными. Криптографическая пара ключей определяется исходя из полученного cryptContext;

b) если isSubstitution=true, сформированный запрос подписать старым криптографическим ключом.

2. В случае успеха при первом запросе на сертификат вернуть результат в формате PKCS#10. При обновлении сертификата вернуть результат в формате PKCS#7.

3. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.10 Метод createTlsCertRequest (cryptContext, certRequestParams, isSubstitution)

Метод создания запроса на сертификат транспортного криптографического ключа.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• certRequestParams — структура данных, содержащая атрибуты и поля для включения в сертификат транспортного криптографического ключа. В случае формирования запроса на транспортный сертификат с целью его использования для операций с ЦР структура certRequsetParams должна соответствовать корневому УЦ Безопасности участника ПлЦР и документу [10];
• isSubstitution — флаг замены существующего сертификата. Значение false, если запрос на сертификат создается первый раз; значение true для запроса на обновление существующего сертификата.

Выходные данные

- request — массив байт, содержащий созданный запрос в формате PKCS#10/PKCS#7.

Требования

1. Вызвать функции СКЗИ для формирования запроса на сертификат:

a) если isSubstitution=true, сформированный запрос подписать старым криптографическим ключом.

2. В случае успеха при первом запросе на сертификат вернуть результат в формате PKCS#10. При обновлении сертификата вернуть результат в формате PKCS#7.

3. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.11 Метод genKeyPairAndRequest (cryptContext, certRequestParams, lenghtKey, isSubstitution)

Единый метод формирования ключей и создания запроса на СКПЭП.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• certRequestParams — структура данных, содержащая атрибуты и поля для включения в СКПЭП. В случае формирования запроса на СКПЭП с целью его использования для операций с ЦР структура certRequsetParams должна соответствовать документу [10];
• lenghtKey — целое число, длина закрытого ключа в битах;

- isSubstitution — флаг замены существующего сертификата. Значение false, если запрос на сертификат создается первый раз; значение true для запроса на обновление существующего сертификата.

Выходные данные

• request — массив байт, содержащий созданный запрос в формате PKCS#10/PKCS#7.

Требования

1. Последовательно вызвать методы:

a) genKeyPair (cryptContext, lenghtKey):

i. На вход передать контекст хранилища и длину ключа.

b) createCertRequest (cryptContext, certRequestParams, isSubstituion):

i. На вход передать контекст хранилища, набор атрибутов для включения в СКПЭП и флаг замены сертификата.

2. Вернуть сформированный запрос на сертификат в формате PKCS#10 при создании запроса на сертификат впервые или в формате PKCS#7 при обновлении сертификата.

3. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций ПМ или СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.12 Метод genTlsKeyPairAndRequest (cryptContext, certRequestParams, lenghtKey, isSubstituion)

Единый метод формирования транспортных ключей и создания запроса на сертификат.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• certRequestParams — структура данных, содержащая атрибуты и поля для включения в транспортный сертификат. В случае формирования запроса на транспортный сертификат с целью его использования для операций с ЦР структура certRequsetParams должна соответствовать корневому УЦ Безопасности участника ПлЦР и документу [10];
• lenghtKey — целое число, длина закрытого ключа в битах;

- isSubstitution — флаг замены существующего сертификата. Значение false, если запрос на сертификат создается первый раз; значение true для запроса на обновление существующего сертификата.

Выходные данные

• request — массив байт, содержащий созданный запрос в формате PKCS#10/PKCS#7.

Требования

1. Последовательно вызвать методы:

a) genTlsKeyPair (cryptContext, lenghtKey):

i. На вход передать контекст хранилища и длину ключа.

b) createTlsCertRequest (cryptContext, certRequestParams, isSubstituion):

i. На вход передать контекст хранилища, набор атрибутов для включения в СКПЭП и флаг замены сертификата.

2. В случае успеха при первом запросе на сертификат вернуть результат в формате PKCS#10. При обновлении сертификата вернуть результат в формате PKCS#7.

3. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций ПМ или СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.13 Метод createSignature (cryptContext, data, certId, signatureType)

Метод подписания исходящих ЭС.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• data — массив байт, содержащий ЭС;
• certId — строка, идентификатор сертификата подписи;
• signatureType — строка, тип операции (возможные типы: CMScert, CMSid).

Выходные данные

- signature — ЭП типа CMScert либо CMSid, закодированная в base64. Сертификат или идентификатор сертификата включен в структуру подписи.

Требования

1. Вызвать функцию СКЗИ по формированию ЭП с передачей массива байтов, содержащего ЭС:

a) ЭП должна формироваться в соответствии с указанным типом операции и идентификатором сертификата подписи;

b) алгоритмы, использующиеся при формировании ЭП, должны соответствовать [2], [20].

2. Закодировать ЭП по алгоритму base64. В случае формирования ЭП целью ее использования для операций с ЦР алгоритмы кодирования должны соответствовать документам [11].

3. В случае успешного выполнения вызова метода вернуть сформированную ЭП.

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.14 Метод createRawSignature (cryptContext, data, certId)

Метод подписания транзакционного сообщения.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• data — массив байт, содержащий ЭС;
• certId — строка, идентификатор сертификата подписи.

Выходные данные

- signature — массив байт, который содержит подпись ЭС сообщения типа RAW, закодированную в base64.

Требования

1. Вызвать функцию СКЗИ по формированию ЭП с передачей массива байтов, содержащего ЭС:

a) ЭП должна формироваться в соответствии с указанным типом операции и идентификатором сертификата подписи;

b) алгоритмы, использующиеся при формировании ЭП, должны соответствовать [2], [20].

2. Если функции СКЗИ возвращают ЭП в формате big-endian, то данный массив байт инвертировать в формат little-endian.

3. Закодировать ЭП по алгоритму base64. В случае формирования ЭП целью ее использования для операций с ЦР алгоритмы кодирования должны соответствовать документам [11].

4. В случае успешного выполнения вызова метода вернуть ЭП типа RAW.

5. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.15 Метод encryptData (cryptContext, data, certIds, certFormat, certPattern)

Метод зашифрования исходящих ЭС.

Входные данные

- cryptContext — структура данных, содержащая информацию о криптографическом провайдере;

- data — массив байт, содержащий ЭС;

• certIds — массив сертификатов получателя в формате X509 (необязательный параметр);
• certFomat — строка, формат сертификатов (необязательный параметр);
• certPattern — шаблон поиска сертификата, содержащий массив пар ключ — значение. В качестве ключа необходимо указать название поля, по которому будет осуществляться поиск, в качестве значения — содержимое поля (необязательный параметр).

Выходные данные:

- encryptedData — строка, содержащая массив байт зашифрованных сообщений.

Требования

1. Во входных данных передать массив и формат сертификатов, или шаблон для поиска сертификатов.

2. Выполнить сжатие полученного массива байт ЭС. В случае использования ЭП для операций с ЦР алгоритмы сжатия должны соответствовать документам [11].

3. Вызвать функцию СКЗИ по зашифрованию ЭС с передачей массива байтов, содержащего ЭС:

a) зашифрование должно выполняться с использованием полученных сертификатов получателя;

b) если получен шаблон для поиска сертификата, извлечь сертификат с использованием соответствующей функции СКЗИ по заданному шаблону поиска;

c) алгоритмы, использующиеся при зашифровывании, должны соответствовать [3], [21], [22], [23].

4. Закодировать зашифрованное сжатое ЭС по алгоритму base64. В случае формирования ЭП с целью ее использования для операций с ЦР алгоритмы кодирования должны соответствовать документам [11].

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

6. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.16 Метод verifyRawSignature (cryptContext, data, signature, certRawId)

Метод проверки подписи с типом RAW.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• data — массив байт, содержащий сообщение;
• signature — массив байт, содержащий ЭП типа RAW для сообщения из data;
• certRawId — строка, содержащая идентификатор сертификата для проверки ЭП типа RAW.

Выходные данные

• result — строка, в случае успеха возвращает код «ОК», в случае неуспеха возвращает код «INVALID».

Требования

1. С помощью функции СКЗИ найти сертификат в хранилище СКЗИ в соответствии с полученным cryptContext и certRawId.

2. Вызвать функцию СКЗИ для проверки ЭП:

a) проверку необходимо выполнять в соответствии с типом подписи RAW и извлеченным сертификатом;

b) алгоритмы, использующиеся при вычислении значения ЭП, должны соответствовать [2], [20].

3. В случае успешной проверки ЭП вернуть код «ОК». Если ЭП неверная, вернуть код «INVALID».

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или если получены ошибки при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.17 Метод verifySignature (cryptContext, data, signature, signatureType)

Метод проверки подписи входящих ЭС.

Входные данные

• cryptContext — массив объектов, содержащий информацию о используемых криптографических провайдерах;
• signature — массив строк, содержащий массивы байт ЭП, закодированные в base64. Может быть передано несколько ЭП;
• data — массив байт, содержащий расшифрованное, декодированное и разжатое ЭС;
• signatureType — массив строк, содержащий типы подписей (возможные значения: CMScert, CMSid).

Выходные данные

- result — строка, в случае успеха возвращает код «ОК», в случае неуспеха возвращает код «INVALID»;

- certIds — массив строк, содержащий идентификаторы сертификатов, с помощью которых была выполнена проверка ЭП. Необязательный параметр.

Требования

1. Декодировать полученные ЭП по алгоритму base64. В случае использования ЭП для операций с ЦР алгоритмы декодирования должны соответствовать документам [11].

2. Если передано несколько ЭП, проверить все полученные ЭП.

3. Для типа CMScert из входящего сообщения извлечь сертификат отправителя, содержащий открытый ключ и данные.

4. Для типа CMSid из входящего сообщения извлечь данные и идентификатор сертификата открытого ключа. Посредством функции СКЗИ выполнить поиск сертификата в хранилище СКЗИ в соответствии с полученным cryptContext.

5. Вызвать функцию СКЗИ для проверки каждой ЭП по отдельности:

a) проверку выполнить в соответствии с указанным типом подписи и извлеченным открытым ключом;

b) алгоритмы, использующиеся при вычислении значения ЭП, должны соответствовать [2], [20].

7. В случае успешного выполнения проверки всех ЭП вернуть код «ОК». Если хотя бы одна ЭП неверная, вернуть код «INVALID».

8. Если реализаций функций СКЗИ возвращает id сертификатов проверки ЭП, то вернуть их в параметре certIds.

9. В случае неуспешного выполнения какого-либо из перечисленных выше действий, а также если число ЭП не соответствует количеству переданных типов ЭП или получены ошибки при вызове функций СКЗИ, прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.18 Метод decryptData (cryptContext, data)

Метод расшифрования входящих ЭС.

Входные данные

- cryptContext — структура данных, содержащая информацию о криптографическом провайдере;

- data — строка, содержащая зашифрованный массив байт.

Выходные данные

• decryptedData — строка, содержащая массив байт расшифрованного ЭС.

Требования

1. Декодировать полученное ЭС по алгоритму base64 в соответствии с [11].

2. Вызвать методы СКЗИ для расшифровки полученного массива байт:

a) алгоритмы, использующиеся для зашифрования, должны соответствовать [3], [21], [22], [23].

3. Восстановить исходный объем байт, расшифрованный на шаге 2. В случае использования ЭП для операций с ЦР используемые алгоритмы должны соответствовать документам [11].

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

5. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.19 Метод decryptAndVerifyData (cryptContext, data, signature, signatureType)

Единый метод проверки ЭС.

Входные данные

• cryptContext — массив объектов, содержащий информацию о используемых криптографических провайдерах;

- data — строка, содержащая массив байт зашифрованного, закодированного, сжатого ЭС;

- signature — массив строк, содержащий массивы байт ЭП;

- signatureType — массив строк, содержащий типы подписей (возможные значения: CMScert, CMSid).

Выходные данные:

• result — строка, в случае успеха возвращает «ОК», в случае неуспеха возвращает «INVALID»;
• decryptedData — строка, содержащая массив байт расшифрованного ЭС. Возвращается только в случае успешной проверки ЭП.

Требования

1. Последовательно вызвать методы:

a) decryptData (cryptContext, data):

i. На вход передать контекст хранилища и массив байт зашифрованного сообщения.

b) verifySignature (cryptContext, data, signature, signatureType):

i. На вход передать массив контекстов хранилищ, разжатое ЭС, набор ЭП, типы подписей.

2. Если при выполнении метода verifySignature получен код «INVALID», вернуть код «INVALID».

3. Если при выполнении метода verifySignature получен код «OK», вернуть код «OK» и расшифрованное разжатое ЭС в параметре decryptedData.

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.20 Метод signatureAndEncryptData (cryptContext, data, certId, signatureType, certIds, certFormat, certPattern)

Единый метод формирования ЭС.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• data — массив байт, содержащий ЭС;
• certId — строка, идентификатор сертификата подписи;
• signatureType — строка, тип подписи (возможные значения: CMScert, CMSid);

- certIds — массив байт, содержащий сертификаты получателя в формате X.509 (необязательный параметр);

- certFormat — строка формат сертификатов (необязательный параметр);

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

Выходные данные

• result — массив байт, содержащий зашифрованное ЭС, закодированное по алгоритму base64.
• signature — массив байт, содержащий сформированную ЭП, закодированную по алгоритму base64.

Требования

1. Необходимо последовательно вызвать методы:

a) createSignature (cryptContext, data, certId, signatureType):

i. На вход передать контекст хранилища, массив байт ЭС, тип подписи, идентификатор сертификата подписи.

a) encryptData (cryptContext, data, certIds, certFormat, certPattern):

i. На вход передать контекст хранилища, массив байт сжатого ЭС, сертификат получателя и формат сертификата либо шаблон для поиска сертификата.

2. При успешном выполнении методов вернуть:

• массив байт, содержащий зашифрованное сообщение, закодированное по алгоритму base64;
• массив байт, содержащий ЭП, закодированную по алгоритму base64.

3. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.21 Метод deleteStore (storeId)

Метод удаления данных сегмента хранилища СКЗИ.

Входные данные

• storeId — строка, идентификатор хранилища СКЗИ.

Выходные данные

- result — строка, в случае успеха возвращает «ОК».

Требования

1. Вызвать функции СКЗИ, отвечающие за гарантированное удаление сегмента хранилища СКЗИ и всех сохраненных в ней данных. Уничтожение ключевой информации должно осуществляться в соответствии с документом [32].

2. После успешного выполнения функций удалить данные из внутреннего хранилища.

3. Вернуть «ОК».

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.22 Метод deleteCert (cryptoContext, certPattern)

Метод удаления сертификатов ключей пользователя.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• certPattern — шаблон поиска сертификатов, содержащий массив пар ключ — значение.

Выходные данные

- result — строка, в случае успеха возвращает «ОК».

Требования

1. Вызвать функцию СКЗИ для получения сертификатов в соответствии с полученным шаблоном поиска и контекстом хранилища.

2. Вызвать функцию СКЗИ для удаления найденных сертификатов.

3. После успешного выполнения функций вернуть «ОК».

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.23 Метод getCert (cryptoContext, certPattern, certFormat)

Метод извлечения сертификатов ключей пользователя.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• certPattern — шаблон поиска сертификатов, содержащий массив пар ключ — значение;
• certFormat — формат сертификатов.

Выходные данные

• certs — массив байт, содержащий найденные сертификаты в требуемом формате.

Требования

1. Вызвать функцию СКЗИ для получения сертификатов в соответствии с полученным шаблоном поиска и контекстом хранилища.

2. Вызвать функцию СКЗИ для извлечения найденных сертификатов.

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

4. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.3.24 Метод getExpirationTimeCert (cryptoContext, certId)

Метод получения срока действия сертификата.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• certId — строка, идентификатор сертификата.

Выходные данные

- time — datatime, дата и время истечения срока действия найденного сертификата.

Требования

1. Вызвать функцию СКЗИ для получения времени истечения срока действия сертификата в соответствии с полученным идентификатором и контекстом хранилища.

2. После успешного выполнения функции вернуть полученную дату и время истечения срока действия сертификата.

3. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.4 Класс GostTlsSocket

Класс содержит методы для работы с сокетами, предназначенными для создания соединений для передачи данных, защищенных по протоколу ГОСТ TLS.

Реализация методов класса может различаться в зависимости от особенностей среды функционирования ПМ и СКЗИ входящего в состав ПМ.

3.2.4.1 Метод getGostTlsSocket (cryptoContext, clientGostTlsCertId, result)

Метод создания сокета, предназначенного для установки защищенного по протоколу ГОСТ TLS соединения.

Входные данные

• cryptContext — структура данных, содержащая информацию о криптографическом провайдере;
• clientGostTlsCertId — строка, идентификатор клиентского ГОСТ TLS сертификата. Опционально. Передается если необходимо установить двухстороннее ГОСТ TLS соединение;
• result — ссылка на строку для возврата результата исполнения метода.

Выходные данные

- В случае успеха метод возвращает ссылку на экземпляр класса GostTlsSocket.

- В случае ошибки возвращается null и код ошибки в строке result.

Требования

1. Создать экземпляр класса GostTlsSocket. Объект должен содержать:

• cryptContext;

- ссылку на хранилище корневых сертификатов;

- clientGostTlsCertId (опционально, если передан во входных данных).

2. Если при создании объекта возникла ошибка, освободить все ресурсы, задействованные выполнением данного запроса, вернуть null и записать в строку result код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.4.2 Метод GostTlsSocket connect (host, port, waitForConnected)

Метод экземпляра класса GostTlsSocket. Метод используется для открытия защищенного подключения по адресу и порту, указанным в параметрах вызова метода.

Входные данные

- host — строка, host для подключения сокета;

- port — натуральное число, порт для подключения сокета;

- waitForConnected — натуральное число, время ожидания подключения сокета в мс. Передается опционально, значение по умолчанию — 30000 мс.

Выходные данные

• result — строка, в случае успеха возвращает «ОК».

Требования

1. Если для данного сокета существует не закрытое соединение, прервать обработку вызова, вернуть код ошибки «Сокет уже используется».

2. Получить IP-адрес по хосту. В случае ошибки прервать обработку вызова, вернуть код ошибки «Хост неизвестен».

3. При открытии подключения ПМ должен выполнить взаимодействие с сервером по указанным в параметрах вызова адресу и порту по протоколу handshake согласно требованиям документов [4] или [5].

4. Для выполнения проверки статуса отзыва сертификата транспортного (TLS) криптографического ключа, генерации эфемерной ключевой пары и создания сессионного ключа ПМ должен вызвать соответствующие функции СКЗИ.

5. Если ПМ не поддерживает версию протокола ГОСТ TLS сервера, вернуть код ошибки «Не поддерживаемая версия протокола TLS».

6. Если при получении сессионного ключа возникла ошибка, вернуть код ошибки «Ошибка получения сессионного ключа».

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

8. В случае неуспешного выполнения какого-либо из перечисленных выше действий или получения ошибок при вызове функций СКЗИ прервать выполнение метода и вернуть код ошибки в соответствии с описанием в разделе 3.2.6.

3.2.4.3 Метод GostTlsSocket close (waitForDisconnected)

Метод экземпляра класса GostTlsSocket. Метод предназначен для закрытия защищенного подключения.

Входные данные

• waitForDisconnected — натуральное число, время ожидания закрытия соединения в мс. Передается опционально, значение по умолчанию — 30000 мс.

Выходные данные

- result — строка, в случае успеха возвращает «ОК».

Требования

1. Выполнить закрытие соединения в соответствии с требованиями документов [4] или [5].

2. В случае превышения времени ожидания закрытия соединения значения входящего параметра waitForDisconnected вернуть код ошибки «Превышен таймаут закрытия соединения».

3. Освободить все задействованные данным соединением ресурсы.

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

3.2.4.4 Метод GostTlsSocket write (data, waitForByteWritten)

Метод экземпляра класса GostTlsSocket. Метод предназначен для передачи данных в открытое защищенное по протоколу ГОСТ TLS соединение.

Входные данные

• data — массив байт, передаваемых в сокет;
• waitForByteWritten — натуральное число, время ожидания записи в соединение минимум 1 байта в мс. Передается опционально, значение по умолчанию — 30000 мс.

Выходные данные

- result — строка, в случае успеха возвращает «ОК».

Требования

Метод должен поддерживать режим асинхронной записи.

1. Выполнить передачу массива данных data с использованием методов криптографической защиты, предоставляемых СКЗИ в составе ПМ, в соответствии с требованиями документов [4] или [5].

2. В случае превышения времени записи блока передаваемых данных параметра waitForByteWritten, вернуть код ошибки «Превышен таймаут записи данных».

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

4. В случае разрыва соединения вернуть код ошибки «Соединение потеряно».

3.2.4.5 Метод GostTlsSocket read (buf, bufSize, waitForByteRead)

Метод вызывается для экземпляра класса GostTlsSocket и используется для чтения данных из защищенного ГОСТ TLS соединения.

Входные данные

- buf — буфер для данных, получаемых из защищенного ГОСТ TLS соединения.

- bufSize — натуральное число, размер буфера buf в байтах.

- waitForByteRead — натуральное число, время ожидания чтения данных из соединения в мс. Передается опционально, значение по умолчанию — 30000 мс.

Выходные данные

• result — строка, в случае успеха возвращает «ОК».

Требования

Метод должен поддерживать режим асинхронного чтения.

1. Выполнить прием блока данных в массив buf с использованием методов криптографической защиты, предоставляемых СКЗИ в составе ПМ, в соответствии с требованиями документов [4] или [5].

2. В случае превышения времени ожидания данных для чтения параметра waitForByteRead, вернуть код ошибки «Превышен таймаут ожидания данных».

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

4. В случае разрыва соединения вернуть код ошибки «Соединение потеряно».

3.2.4.6 Метод GostTlsSocket getStatus ()

Метод вызывается для экземпляра класса GostTlsSocket и используется для получения сведения о его состоянии.

Выходные данные

• result — строка, возможные значения:
• «Готов к использованию»;
• «Соединен с :«.»

Требования

Метод должен вернуть состояние сокета на основании данных ПМ без попытки отправки запроса проверки соединения к серверу.

3.2.4.7 Метод GostTlsSocket getConnectionStatus (waitForConnected)

Метод вызывается для экземпляра класса GostTlsSocket и используется для уточнения статуса соединения сокетов в состоянии «Соединен с :«.»

Входные данные

- waitForConnected — натуральное число, время ожидания ответа от сервиса в мс. Передается опционально, значение по умолчанию — 30000 мс.

Выходные данные

• result — строка, возможные значения:
• «Соединен»;

- «Не соединен»;

- «Превышен таймаут ожидания ответа от сервера»;

- «Отсутствует техническая возможность проверки соединения».

Требования

1. В случае если метод вызывается для сокета, находящегося в состоянии «Готов к использованию», вернуть «Не соединен».

2. В случае если на основании данных ПМ сокет находится в состоянии «Соединен» и имеется техническая возможность проверки статуса соединения, метод должен инициировать проверку состояния соединения и вернуть ее результат в строке result. В случае если при проверке состояния соединения превышен лимит ожидания ответа сервера, вернуть «Превышен таймаут ожидания ответа от сервера» в строке result.

3. В случае если на основании данных ПМ сокет находится в состоянии «Соединен» и отсутствует техническая возможность проверки статуса соединения, вернуть «Отсутствует техническая возможность проверки соединения» в строке result.

Сведения, полученные в результате проверки соединения с сервером, носят информативный характер и не влияют на статус сокета. При получении ответа «Не соединен» МП должно вызвать метод GostTlsSocket close (waitForDisconnected) для освобождения ресурсов, которые были использованы ранее открытым соединением, и (при необходимости) повторного использования сокета.

3.2.4.8 Уничтожение экземпляра класса

Класс должен содержать метод, вызываемый автоматически в момент уничтожения экземпляра класса. Данный метод должен выполнять проверку наличия и инициировать закрытие открытого ГОСТ TLS соединения.

3.2.5 Сервисные функции

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

3.2.5.1 Удаление данных из хранилища ПМ

Метод должен удалять сохраненные данные ПМ на уровне файловой системы ОС в пределах пространства, выделенного для МП.

3.2.5.2 Сбор информации о взаимодействии с ПМ

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

Список данных, которые необходимо сохранять:

• id — строка, уникальный идентификатор действия;
• createdAt — Unix Timestamp, дата и время действия;
• functionName — строка, название вызванного метода;
• result — строка, результат выполнения функции (SUCCESS, FAIL);

- inputData — строка, список входных данных, может быть пустым;

- outputData — строка, список выходных данных, может быть пустым;

- storeId — строка, идентификатор хранилища СКЗИ, может быть пустым;

• errorCode — целое число, код ошибки, может быть пустым;
• errorMessage — строка, описание ошибки, может быть пустым

Значение cryptContext, входные и выходные данные для криптографических функций не сохраняются. Описание требований к хранению данных см. в пункте 3.4.

3.2.6 Список ошибок

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

Таблица 7 — Список ошибок

3.3 Порядок использования ПМ

3.3.1 Инициализация ПМ

Для инициализации ПМ, СКЗИ и выполнения проверки целостности файлов и ресурсов МП необходимо вызывать метод init (filesWithCheckSums). filesWithCheckSums должен содержать эталонные значения хэшей, рассчитанные от файлов и ресурсов МП, целостность которых необходимо проверить, и пути к ним. Хэши должны быть рассчитаны в соответствии с документом [30].

Рекомендуется вызывать данный метод после каждой перезагрузки приложения однократно до выполнения любых вызовов ПМ.

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

3.3.2 Работа с криптографическими функциями

Для работы с криптографическими функциями:

1. МП должно вызвать метод init (filesWithCheckSums).

2. МП должно вызвать метод initCryptoContext (storeId, userId):

a) МП должно передать уникальный идентификатор хранилища СКЗИ и уникальный идентификатор пользователя МП во входных параметрах функции ПМ;

b) требования к формированию идентификаторов зависят от особенностей реализации СКЗИ и ПМ;

c) при работе с хранилищем СКЗИ будет запрошена установка/ввод пароля;

d) для каждого пользователя может быть создано несколько защищенных хранилищ с доступом по паролю. Необходимость использования дополнительного усложненного пароля определяется МП в зависимости от вида выполняемой операции;

e) идентификаторы хранилищ СКЗИ должны быть уникальными для различных пользователей МП и различных сегментов хранилищ одного пользователя;

f) идентификатор пользователя МП должен быть уникальным;

g) МП определяет какой сегмент хранилища СКЗИ необходимо использовать для выполнения криптографической операции, а также формирует и хранит уникальный идентификатор сегмента хранилища;

h) сегмент хранилища СКЗИ для хранения транспортных сертификатов и сертификатов для проверки ЭП определяется разработчиком исходя из особенностей реализации СКЗИ и особенностей ПМ.

3. В случае использования МП и ПМ новым пользователем криптографические ключи, не принадлежащие ему, должны удаляться с использованием механизмов СКЗИ по гарантированному уничтожению ключей (подробнее см. в разделе 3.2.3.22).

4. После успешного создания защищенного сегмента хранилища МП получит от СКЗИ объект cryptContext, который будет использоваться для вызова криптографических функций в рамках одной сессии пользователя.

5. Объект cryptContext формируется на стороне СКЗИ и содержит информацию о состоянии и параметрах работы с криптографическим провайдером для выполнения операций криптографии и управления криптографическими ресурсами.

6. В случае завершения сессии пользователя или аварийного завершения работы МП или ПМ МП должно вызвать метод releaseContext (cryptoContext) и деинициализировать работу с хранилищем СКЗИ. Для продолжения работы с криптографическими функциями необходимо заново инициализировать хранилище СКЗИ.

3.3.3 Загрузка САС

Возможны следующие взаимодействия с САС:

1. В ПМ передается пустой САС:

a) при вызове функции saveCrl на вход будет передан пустой САС. СКЗИ должно обновить и обнулить ранее загруженный САС. В таком случае при проверке наличия в САС сертификат никогда не будет аннулированным.

2. САС не передается в ПМ:

a) функция saveCrl не вызывается. САС загружен не будет. Проверка наличия сертификатов в САС в таком случае не выполняется.

3. САС передается в ПМ:

a) передать в функции saveCrl САС, содержащий непустой список аннулированных сертификатов.

3.3.4 Смена пароля для доступа к хранилищу

1. Для получения срока истечения действия пароля МП может вызывать функцию getPasswordExpirationTime (storeId, timeZone).

2. Срок действия пароля определяется политикой использования СКЗИ.

3. При приближении времени смены пароля или в случае получения кода ошибки 16 МП должно вызвать метод changePassword (storeId):

a) в результате вызова метода запрашивается ввод старого и нового пароля. При выполнении требований к паролям устанавливается новый пароль и обновляется его срок действия.

3.3.5 Смена криптографических ключей пользователя

При получении уведомления об истечении срока действия криптографических ключей пользователя МП должно инициировать формирование новых криптографических ключей пользователя и формирование запроса на СКПЭП в соответствии с требованиями из [11].

3.3.6 Сбор ЦО

Сбор информации о системном окружении для последующего использования и формирования ЭС рекомендуется реализовать на стороне МП для снижения рисков и зависимостей в МП.

В зависимости от целей использования рекомендуется собирать ЦО одним из следующих способов:

1. Формировать ЦО в соответствии с требованиями, указанными в стандарте [12];

2. В случае использования ЦО для операций с ЦР формировать ЦО в соответствии с требованиями, описанными ниже.

Требования к сбору ЦО для использования в операциях с ЦР:

1. Собрать информацию о системном окружении. Параметры, включаемые в ЦО, зависят от ОС устройства. Обязательный список параметров зависит от ОС устройства и перечислен в Таблице 8.

2. ЦО формируется следующим образом:

a) собранная информация об устройстве должна быть объединена в одну строку формата XML, как указано в таблице, с применением функции trim ко всем собранным значениям и названиям параметров. Названия параметров с точностью до символа должны соответствовать указанным в Таблице 8 из этой Спецификации;

b) если какой-либо параметр не удалось получить, необходимо указать его пустое значение в виде <параметр></параметр>.

3. Если для получения параметра требуется дополнительное разрешение пользователя, то МП должно его запрашивать.

Требования к передаче ЦО для операций с ЦР определены в документе [11].

Таблица 8 — Требования к параметрам ЦО

3.3.7 Установка ГОСТ TLS соединения

При установке ГОСТ TLS соединения МП должно:

1. Создать экземпляр класса GostTlsSocket вызовом метода ПМ getGostTlsSocket. На вход метода передать cryptoContext и идентификатор клиентского ГОСТ TLS сертификата, если требуется установить двухстороннее ГОСТ TLS соединение.

2. Вызвать метод ПМ connect для созданного экземпляра класса GostTlsSocket. В параметрах вызова передать адрес и порт подключения. После успешного выполнения данного метода будет открыто защищенное ГОСТ TLS соединение.

3. МП, используя методы сокета write и read, может передавать и считывать данные из защищенного ГОСТ TLS-соединения.

4. Для проверки статуса соединения сокетов МП может использовать метод getConnectionStatus.

5. После завершения использования соединения оно должно быть закрыто. Для этого МП может вызвать метод GostTlsSocket close (waitForDisconnected). При выполнении данного метода все ресурсы будут освобождены.

6. Контроль необходимости открытия/закрытия соединения должен выполняться на стороне МП. Установка нового TCP-соединения для каждого внешнего вызова не является обязательной. Чтобы создать соединение с другим хостом/портом при открытом соединении, необходимо создать новый экземпляр класса GostTlsSocket.

3.4 Требования к логическому хранению данных

3.4.1 Требования к составу, структуре и способам организации данных в системе

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

Требования к хранилищу СКЗИ описаны в пункте 3.4.4.

Внутреннее хранилище должно быть расположено в приватной области данных, недоступной для других приложений.

Во внутреннем хранилище ПМ должна сохраняться следующая информация:

• Блокировка доступа к хранилищу:
• primary key storeId — строка, идентификатор хранилища СКЗИ;

- lockEnd — время окончания блокировки доступа в формате Unix Timestamp.

• Учет пользователей
• primary key id — строка, уникальный идентификатор;
• userId — строка, идентификатор пользователя МП;
• storeId — строка, идентификатор хранилища СКЗИ;

- createdAt — дата и время сохранения информации в формате Unix Timestamp;

• isDeleted — флаг, отображающий факт удаления ключевой информации пользователя

- Учет неудачных попыток ввода пароля:

- primary key storeId — строка, идентификатор хранилища СКЗИ;

- целое число count — целое число, количество неуспешных попыток ввода пароля (подряд).

• Журнал действий:
• primary key id — строка, уникальный идентификатор действия;
• createdAt — дата и время действия в формате Unix Timestamp;
• functionName — строка, название вызванного метода;
• result — строка, результат выполнения функции (SUCCESS, FAIL);
• inputData — строка, список входных данных (может быть пустым);
• outputData — строка, список выходных данных (может быть пустым);
• storeId — строка, идентификатор хранилища СКЗИ (может быть пустым);
• errorCode — целое число, код ошибки (может быть пустым);
• errorMessage — строка, описание ошибки (может быть пустым).

3.4.2 Схема хранения ключевой информации

На Рисунке 3 изображена схема хранения ключевой информации при использовании ПМ для подключения к ПлЦР. Описание компонентов схемы приведено в Таблице 9.

Рисунок 3 — Схема хранения ключевой информации

3.4.3 Требования к контролю, хранению, обновлению и восстановлению данных

Необходимо обеспечить бесперебойное функционирование ПМ.

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

Специальных требований к сроку хранения данных не предъявляется.

3.4.4 Требования к программному обеспечению

3.4.4.1 Общие требования

ПМ должен иметь в своем составе сертифицированное СКЗИ не ниже класса КС1, или же сам являться сертифицированным СКЗИ не ниже класса КС1. Рекомендуется выбирать СКЗИ, разрешенные к использованию на территории Российской Федерации и за ее пределами.

СКЗИ должно быть разрешено для встраивания в ИС.

СКЗИ должно обладать пакетом документации, достаточным для встраивания в ПМ.

Операционная система, для которой предназначено СКЗИ, должна соответствовать операционной системе, в которой будет функционировать МП.

Производитель СКЗИ должен гарантировать работу СКЗИ во всех средах функционирования ПМ.

СКЗИ должно предоставлять программный интерфейс для вызова криптографических функций из ПМ.

СКЗИ не должно возвращать результаты работы методов напрямую пользователю МП.

3.4.4.2 Требования к функциям защиты информации

СКЗИ должно обеспечивать выполнение таких функций защиты информации, как:

• создание ключей ЭП и ключей проверки ЭП в соответствии с [2];
• хранение криптографических ключей, СКПЭП, транспортных криптографических ключей и сертификатов транспортных криптографических ключей в защищенном хранилище в мобильном приложении;
• формирование и проверка ЭП согласно [2], [20];
• зашифрование и расшифрование ЭС. Алгоритмы, используемые при зашифровании: [3], [21], [22], [23];
• установление защищенного соединения между приложением и сервером с использованием протокола одностороннего и двустороннего TLS в соответствии с [4], [5].

СКЗИ должно соответствовать требованиям, предъявляемым к средствам ЭП в документе [35].

СКЗИ должно иметь в составе ПДСЧ, соответствующий требованиям документа [24].

ПДСЧ для выработки инициализирующей последовательности должен использовать БДСЧ.

ПДСЧ должен поддерживать возможность параллельной работы в независимых сессиях.

СКЗИ должен предоставлять функции по адаптации дизайна экрана работы с БДСЧ (при наличии). Реализация работы БДСЧ и возможность адаптации дизайна экрана работы с БДСЧ должны соответствовать эксплуатационной документации на СКЗИ.

В СКЗИ должна быть реализована функция проверки статуса отзыва сертификата транспортного (TLS) криптографического ключа с использованием САС и/или OCSP, а также функция проверки статуса отзыва сертификата ЭП с использованием САС.

Режим проверки статуса отзыва сертификата транспортного (TLS) криптографического ключа с использованием OCSP должен быть настраиваемым в конфигурации СКЗИ.

3.4.4.3 Требования к хранению и доступу к ключевой информации

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

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

Пароли пользователей должны быть неизвлекаемыми из СКЗИ. Вызов криптографических функций СКЗИ должен выполняться с указанием идентификатора сегмента хранилища СКЗИ. Интерфейс ввода пароля от хранилища должно предоставлять СКЗИ.

СКЗИ должно осуществлять контроль срока действия пароля и осуществлять его замену по запросу.

СКЗИ должно предоставлять возможность работы в рамках сессии пользователя без дополнительного запроса пароля.

Если указан неверный пароль, то ответ на вызов любого метода СКЗИ для данного пользователя должен содержать соответствующее исключение.

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

В СКЗИ должны быть реализованы функции удаления сегмента хранилища и гарантированного уничтожения ключевой информации по идентификатору хранилища СКЗИ в соответствии с документом [32].

СКЗИ должно предоставлять функции для установки, удаления и получения сертификатов ключей пользователя, САС, а также извлечения времени истечения действия сертификата.

При сохранении САС в хранилище СКЗИ должно проверять номер САС в разрезе его серии, а не сквозную нумерацию. Проверка должна предотвращать загрузку устаревших данных.

СКЗИ должно поддерживать возможность хранения корневых сертификатов в едином хранилище для всех пользователей.

3.4.5 Требования к форматам ЭП

СКЗИ должно поддерживать различные форматы ЭП:

• CMScert (PKCS#7, содержит сертификат открытого ключа, соответствующего закрытому ключу, на котором произведено формирование ЭП);
• CMSid (PKCS#7, содержит идентификатор открытого ключа, соответствующего закрытому ключу, на котором произведено формирование ЭП);
• RAW (не содержит сертификата или идентификатора ключа, формат записи последовательности байт подписи — little-endian).

3.4.6 Требования к встраиванию СКЗИ

Встраивание СКЗИ в ПМ должно проводится в соответствии с требованиями и рекомендациями, изложенными в эксплуатационной документации на СКЗИ.

При встраивании должен быть проведен контроль возвращаемых значений при обращениях к функциям СКЗИ.

Встраивание не должно влиять на инженерно-криптографические свойства СКЗИ.

МП должно использовать только документированные функции ОС и СКЗИ, использование которых при разработке возможно без построения новых СКЗИ.

Если ПМ не является СКЗИ, то методы СКЗИ не должны быть доступны для вызова из МП.

ПМ должен предоставлять механизм поэкземплярного учета (регистрации) СКЗИ, учитывающий технологию распространения МП через магазины приложений и/или официальный сайт финансовой организации или Банка России. Работоспособность должна быть гарантирована с магазинами приложений Google Play, App Store, RuStore, NashStore, AppGallery.

Действия по регистрации СКЗИ должны осуществляться посредством использования технических средств и механизмов ПМ, в том числе с использованием механизмов СКЗИ при их наличии. При регистрации СКЗИ не должны быть задействованы сторонние сервисы.

4 Нефункциональные требования

4.1 Требования к производительности ПМ

Рекомендуется обеспечить следующие показатели назначения:

• время выполнения каждой криптографической операции ([FN-1.4] - [FN-1.9], [FN-1.12] - [FN-1.16]) должно составлять не более 0,3 секунды;
• время выполнения каждого единого вызова ([FN-1.10], [FN-1.11], [FN-1.17], [FN-1.18]) должно составлять не более 0,5 секунды;
• время инициализации ядра ПМ ([FN-1.1]) на мобильных устройствах, соответствующих требованиям раздела 2.2, должно составлять не более 3 секунд.

Показатели назначения указаны для данных размером до 1 Мб.

4.2 Содержание, объем и организация работ по созданию ПМ

4.2.1 Общие требования

Содержание и порядок выполнения работ по созданию ПМ рекомендуется выполнять в соответствии с стандартом [17].

Если ПМ является сертифицированным СКЗИ, то работы по его созданию и вводу эксплуатацию должны быть организованы в соответствии с требованиями документов [9] и [24].

Если ПМ имеет в своем составе сертифицированное СКЗИ, работы по созданию и вводу в эксплуатацию ПМ должны быть организованы в соответствии с его правилами пользования (в соответствии с требованиями к эксплуатации СКЗИ документа [9]). Если в правилах пользования СКЗИ, входящего в состав ПМ, не указано иное, ПМ должен пройти исследования по оценке его влияния на СКЗИ (см. раздел 4.2.3 Спецификации).

Также при организации работ по созданию ПМ рекомендуется учесть требование о внесении ПМ в Реестр (см. раздел 4.2.4 Спецификации).

4.2.2 Требования к разработчику ПМ

Разработчик ПМ должен соответствовать всем требованиям, предъявляемым к производителю ПО для внесения его в Реестр [14].

Разработчик ПМ должен иметь лицензию ФСБ России на разработку, производство, распространение шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнение работ, оказание услуг в области шифрования информации, техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя) на виды работ из Приложения к Положению [18], в части пунктов 1 <6>, 2, 3.

<6> В случаях, когда ПМ является СКЗИ.

4.2.3 Работы по подготовке и проведению оценки влияния ПМ на выполнение требований, предъявленных к СКЗИ

Необходимость проведения оценки влияния ПМ на СКЗИ определяется в документе [9] и эксплуатационной документации СКЗИ.

В разделе приведена информация о типовом подходе при проведении оценки влияния ПМ на выполнение требований, предъявленных к СКЗИ.

В эксплуатационной документации на ПМ по результатам оценки влияния среды функционирования на выполнение требований, предъявленных к СКЗИ, должен быть отражен факт использования данной спецификации, если ПМ разработан в соответствии с ней.

Оценка влияния может быть выполнена в один или два этапа. При выполнении оценки влияния в один этап исследование проводится после встраивания ПМ в МП. Оценка в два этапа проводится после встраивания СКЗИ в ПМ и после встраивания ПМ в МП.

Исследования по оценке влияния проводятся в соответствии с документом «Техническое задание на проведение исследований по оценке влияния специального программного обеспечения Программного модуля» (далее — ТЗ).

Разработку ТЗ и проведение исследований ПМ должна выполнять организация, имеющая действующий аттестат аккредитации испытательной лаборатории ФСБ России или допущенная ФСБ России на проведение таких работ (далее — Лаборатория).

Исследования рекомендуется проводить на основании договора между Лабораторией и Разработчиком ПМ.

Для проведения исследований Разработчик ПМ предоставляет материалы в соответствии с требованиями ТЗ. Список материалов для обеспечения исследований может включать:

• исходные тексты исследуемого ПМ, МП (передаются при встраивании ПМ в МП);
• документы разработчика ПМ (МП), описывающие архитектуру ПМ (МП), модульный состав и назначение модулей, среду исполнения;
• описания и комментированные листинги исходных текстов доступа ПМ к функциям встраиваемого СКЗИ. В случае, если ПМ является СКЗИ, передаются исходные тексты доступа МП к функциям СКЗИ;
• спецификации вызовов ПМ (описание аргументов и форматов вызовов);
• описание процедуры компиляции исходного кода ПМ;
• описание внешних вызовов (вызовы операционной среды, аппаратных средств, других программ и т.д.);
• эксплуатационную документацию;
• дистрибутивы ПМ, МП (передаются при встраивании ПМ в МП).

Приведенный список не является исчерпывающим. Лаборатория, проводящая исследования, может запросить дополнительные материалы в соответствии с ТЗ.

Разработчик ПМ должен описать трассы вызовов ПМ — СКЗИ в соответствии с документом [34] для использования данной информации при проведении оценки корректности встраивания СКЗИ в ПМ, а также ПМ в МП.

Для проведения исследований Разработчик предоставляет Лаборатории экземпляры МП со встроенным ПМ. МП предоставляются для каждой ОС, в которой функционирует ПМ.

Для ПМ, функционирующего в ОС iOS, МП предоставляется через магазин приложений App Store.

Для ПМ, функционирующих в ОС Android, ОС HarmonyOS и ОС Аврора, МП предоставляются через магазины приложений Google Play, RuStore, NashStore, AppGallery или в виде rpm-файлов для ОС Аврора или apk-файлов для ОС Android и HarmonyOS с инструкцией по скачиванию и установке на устройство.

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

Экспертиза результатов исследований ПМ осуществляется ФСБ России.

4.2.4 Работы по внесению ПМ в Реестр

Для внесения ПМ в Реестр при его проектировании и разработке должны быть учтены требования нормативных документов [14] и [15].

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

ПМ должен сопровождаться комплектом документации в соответствии с разделом 4.3.3 настоящей Спецификации.

Поскольку ПМ имеет в своем составе сертифицированное СКЗИ, для подачи заявки на включение ПМ в Реестр необходимо положительное решение ФСБ России об оценке влияния (если в правилах пользования СКЗИ не указано иное).

Для регистрации ПМ в Реестре должны быть подготовлены и доступны экспертам демонстрационные версии МП со встроенным ПМ. Для ПМ, функционирующего в OS iOS, могут быть представлены исходные тексты проекта и их описание.

4.3 Требования к программной документации

4.3.1 Общие требования к составу технической документации

Разработчик ПМ должен предоставить комплект документации, достаточный для прохождения процедур по оценке влияния ПМ на СКЗИ, а также для включения ПМ в Реестр.

Если ПМ является СКЗИ, то состав и содержание предоставляемой документации должны соответствовать стандартному комплекту документов для СКЗИ в соответствии с [9].

4.3.2 Требования к документации, предоставляемой для прохождения оценки влияния

Требования к составу и содержанию технической документации, предоставляемой в Лабораторию для проведения оценки влияния, перечислены в Таблице 10.

Таблица 10 — Документация для проведения оценки влияния

Указанная в Таблице 10 документация предоставляется Лаборатории, проводящей исследования по оценке влияния ПМ на СКЗИ.

Эксперты Лаборатории проводят анализ полноты и корректности эксплуатационной документации на исследуемый ПМ в части, определяющей порядок использования СКЗИ на соответствие требованиям и рекомендациям, изложенным в эксплуатационной документации на СКЗИ.

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

4.3.3 Требования к документации, предоставляемой для включения ПМ в Реестр

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

Таблица 11 — Документация для включения ПМ в Реестр

Требования к составу и содержанию документации составлены на основе документа [16] и могут изменяться в соответствии с его актуальной версией.

Указанная документация прикладывается к заявлению о включении сведений о ПО в Реестр и согласуется Экспертным советом Министерства цифрового развития, связи и массовых коммуникаций РФ.

4.3.4 Требования к порядку актуализации документации ПМ

В документацию ПМ могут вноситься изменения по следующим причинам:

• устранение обнаруженных ошибок в ПМ и документации ПМ;
• развитие и усовершенствование ПМ;
• инициатива владельца ПМ.

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

Порядок обновления и необходимость повторной экспертизы ФСБ проектных и/или эксплуатационных документов ПМ должны быть определены в отчетных документах по результатам оценки влияния.

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

4.4 Порядок контроля и приемки ПМ

4.4.1 Виды, состав, объем и методы испытаний ПМ

Для ПМ рекомендуется проводить следующие виды испытаний:

• предварительные испытания;
• приемочные испытания.

Предварительные и приемочные испытания ПМ должны быть организованы и проведены в соответствии с [19].

Объем и методы предварительных и приемочных испытаний определяются документом «Программа и методика испытаний».

Испытания должны проводиться с помощью демонстрационного или полнофункционального МП, содержащего в составе реализацию ПМ, подлежащую испытаниям. Специальные требования к функциональности демонстрационного приложения в данной спецификации не предъявляются.

Испытания должны проводиться во всех средах функционирования ПМ.

4.4.2 Общие требования к приемке работ

Предварительные и приемочные испытания должны проводиться Разработчиком ПМ.

Программы всех этапов испытаний составляются Разработчиком на основании документа «Программа и методика испытаний».

Программы испытаний должны предусматривать следующие виды проверок:

1. Проверка комплектности поставки ПМ и пакета документации.

2. Проверка содержания документации ПМ.

3. Проверка реализации функций ПМ в соответствии с требованиями спецификации.

4. Проверка требований к производительности ПМ.

По результатам этапов испытаний оформляются отчетные документы. К отчетным документам относятся Протоколы и Отчеты о результатах испытаний.

Отчетные документы подписываются членами комиссии и утверждаются председателем комиссии.

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

В случае выявления отклонений от требований Спецификации формируется перечень необходимых доработок и рекомендуемые сроки устранения этих отклонений.

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

Приемочные испытания ПМ проводят в соответствии с документом «Программа и методика приемочных испытаний».

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

4.5 Требования к порядку встраивания ПМ в МП

4.5.1 Требования к организации работ

Встраивание ПМ в МП должно осуществляться в соответствии с порядком и требованиями, описанными в технической документации на ПМ и в документе [7].

Если ПМ является СКЗИ, то его встраивание в МП должно осуществляться в соответствии с правилами пользования СКЗИ и положениями документа [9].

При планировании и организации работ по встраиванию ПМ в МП необходимо учитывать, что в соответствии с п. 4.1. документа [25], МП должно пройти сертификацию в системе сертификации Федеральной службы по техническому и экспортному контролю или оценку соответствия по требованиям к оценочному уровню доверия (далее — ОУД) не ниже, чем ОУД 4, в соответствии с требованиями национального стандарта Российской Федерации [8], или обеспечить выполнение требований документа [26] в случаях, когда это необходимо.

Работы по встраиванию ПМ в МП должны соответствовать требованиям Приложения 2 документа [29].

Работы по встраиванию ПМ в МП должны включать работы по оценке влияния аппаратных, программно-аппаратных и программных средств сети (системы) конфиденциальной связи, совместно с которыми предполагается штатное функционирование ПМ, на выполнение предъявленных к входящему в его состав СКЗИ требований, если в документе [9] или в эксплуатационной документации на СКЗИ указывается на необходимость их проведения.

4.5.2 Требования к разработчику МП

Для встраивания ПМ в МП разработчик должен:

• иметь опыт программирования на языках Kotlin или Java, Swift, C++;
• обладать знаниями о современных стандартах в области криптографии и защиты информации;
• знать требования документов [11], предъявляемые к сертификатам ПлЦР, в случае использования ПМ для выполнения операций с ЦР;
• соответствовать требованиям, предъявляемым к разработчикам в документе [26] для прохождения оценки соответствия ОУД4;
• иметь лицензию ФСБ России на разработку, производство, распространение шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнение работ, оказание услуг в области шифрования информации, техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя) на виды работ из Приложения к Положению [18], в части пунктов 1 <7>, 2, 3.

<7> В случаях, когда ПМ является СКЗИ

4.5.3 Требования к совместимости с МП

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

ПМ не должен оказывать негативного влияния на производительность приложения, время автономной работы или потребление данных.

4.5.4 Требования к использованию функций ПМ

При использовании методов ПМ должен выполняться контроль кодов возврата, возникающих при отклонениях от штатного выполнения команд.

Все вызовы методов интерфейса ПМ должны осуществляться вне основного потока приложения.

Вызов функций ПМ для осуществления защиты ЭС в случае выполнения операций с ЦР должен осуществляться в соответствии с требованиями документов, входящих в [11].

Реализация сценариев выпуска ключей и сертификатов должна соответствовать описаниям в документах [28] и [31].

4.5.5 Требования к механизмам доставки транспортных сертификатов и сертификатов проверки ЭП

МП должно содержать встроенный транспортный ГОСТ-TLS сертификат, корневые (самоподписанные) сертификаты УЦ Безопасности и ПУЦ УНЭП для установления соединения с сервисами финансовой организации и сертификат УЦ БР. При изменении данных сертификатов требуется обновление МП. Другие сертификаты должны загружаться в СКЗИ путем вызова соответствующей функции ПМ (см. п. 3.4.2. и 3.2.3.5 настоящей Спецификации).

В МП должны быть предусмотрен механизм обновления транспортного ГОСТ-TLS сертификата финансовой организации, сертификатов проверки ЭП финансовой организации, а также соответствующих цепочек сертификатов, включающих все промежуточные сертификаты. Для финансовой организации являющейся участником ПлЦР это сертификаты проверки ЭП КО и КК участника ПлЦР, КО и КК ПлЦР.

При обновлении сертификатов МП приложение должно вызывать соответствующий метод ПМ для загрузки сертификатов в СКЗИ.

4.6 Поддержка жизненного цикла ПМ

Разработчику ПМ рекомендуется предоставлять следующие услуги по обеспечению сопровождения ПМ:

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

При выпуске новой версии ПМ разработчику рекомендуется предоставить обновленный пакет документации и пройти процедуру оценки влияния на СКЗИ (описание см. в п. 4.2.3 настоящей Спецификации) в случае:

• изменения требований к условиям функционирования ПМ, а именно изменения требований к программной и/или аппаратной среде функционирования;
• изменения функциональных требований к ПМ;
• изменения конфигурации или версии программного и аппаратного обеспечения, используемого в СКЗИ;
• выявления уязвимостей или инцидентов, которые могут повлиять на безопасность СКЗИ.

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

4.7 Характеристики пользователей и персонала

4.7.1 Требования к пользователям ПМ

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

Требования к квалификации пользователей ПМ в настоящей Спецификации не описываются.

4.7.2 Требования к персоналу, обеспечивающему техническую поддержку и модернизацию ПМ

Для сопровождения ПМ рекомендуется создать Службу технической поддержки. При создании Службы технической поддержки необходимо учитывать, что ПМ имеет в своем составе СКЗИ. Любые работы по поддержке и модернизации ПМ должны выполняться с учетом требований правил пользования СКЗИ и положения [9]. Режим и технология работы Службы технической поддержки должны быть определены на стадии проектирования ПМ и описаны организацией — разработчиком ПМ в документе «Описание жизненного цикла ПМ».

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