bcryptoregulatory / skzi-requirements Goto Github PK

Считаем необходимым строго установить требования по использованию физического источника шума в программно-аппаратных средствах защиты информации и смягчить данные требования только лишь в программных продуктах. Генерация личных ключей (секретных параметров ДПСЧ) должна производиться только с использованием сертифицированных программно-аппаратных средств.

Ранее в #9 уже обсуждался профиль с ПФ5, но обсуждение было закрыто по непонятным нам причинам. Считаем, что обсуждение стоит продолжить.
Сейчас имеется профиль
УГ1 или УГ2, ПФ1 или УК5, УС2, УСЗ или УС4, [ПФЗ], [ПФ5]
Считаем, что такой профиль некорректен по следующей причине.
По текущим требованиям ПФ5 нельзя использовать без ПФ1 (BSTS или BMQV) или УК5 (транспорт ключа). Но, например, в средствах, реализующих vpn с криптонаборами DHE, не нужны протоколы ПФ1 или транспорт ключа УК5.
Предлагаем писать ПФ5 через ИЛИ:
УГ1 или УГ2, ПФ1 или ПФ5 или ...

В профилях требований к СКЗИ линейного шифрования явно допущена опечатка: [ПФ4] или УК5.

В предложениях и вопросах по требованиям к СКЗИ неоднократно был поднят вопрос об отсутствии программно-аппаратных средств выработки ЭЦП.

Пояснение: в качестве программно-аппаратных средств выработки ЭЦП предлагается использовать СКЗИ класса криптографические токены.

Данная позиция вызвала ряд вопросов, поэтому предлагается для предметной критики/обсуждения здесь.

Поскольку одним из приоритетов при переработке таблиц является сокращение их объёма, выносятся на рассмотрение следующие предложение (которые следует рассматривать как независимые и требующие доработки и обсуждения):

1. Таблица 1 упраздняется
2. Удаляется столбец с требованиями к безопасности, а информация из него переносится в примечания.
3. Аналогично п.3 удаляется столбец с форматами данных
4. Обозначения в таблице 2 заменяются на другие, содержащие непосредственную ссылку на стандарт, например:

Относительно п.4 запрашиваются предложения по обозначениям, упрощающим восприятие таблиц.

К средствам предварительного шифрования выдвигается [Ф2], которое связано только с шифрованием сообщений, обмениваемых с компонентами ИОК, что не входит в область применения средств предварительного шифрования

Требуется актуализация требований.

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

Вот ближайший пример. Средство предварительного шифрования: AШ... и УГ1 или УГ2, ПФ1 или УК5, УС2, УСЗ или УС4. Можно понять, что получатель сообщения генерирует открытый ключ (УГ1 или УГ2), погружает его в сертификат (УС2) и в ИОК (УСЗ или УС4). Отправитель сообщения генерирует сеансовый ключ (УГ1 или УГ2), зашифровывает на нем сообщение (АШ...), а сеансовый ключ зашифровывает на открытом ключе получателя (УК5). Все хорошо, но что означает ПФ1? ПФ1 -- это онлайн-протокол, в котором выполняется несколько разнонаправленных пересылок между сторонами. Но у нас средство предварительного шифрования -- отправитель может ходить сразу, не ожидая ответа от получателя. Возможно речь идет о том, что стороны предварительно согласовывают сеансовый ключ с помощью ПФ1, сохраняют его, а затем используют всякий раз при отправке сообщений друг другу. Это только догадка, логика решения не до конца понятна. Если догадка все-таки верна, то решение представляется спорным, поскольку требуется хранить сеансовый ключ на протяжении длительного времени.

Предлагается:

1. Дать краткие пояснения по ячейкам таблицы. В виде примечаний или сносок.
2. Провести упрощения -- уменьшить число ячеек-кейсов. Убрать требования по непрофильному функционалу. Например, для средств линейного шифрования есть ячейка (АШ, АИ1) или (АШ, АИ2) или АШИ и есть ячейка (АШ, АИ1) или (АШ, АИ2) или АШИ, ФХ1 или ФХ2. Дописка ФХ1 или ФХ2 явно непрофильная, она касается конкретного средства. Исключить. Оставить только (АШ, АИ1) или (АШ, АИ2) или АШИ. Или даже (АШ, АИ1 или АИ2) или АШИ.

Дискуссия в #43 показала на неполноту классификации средств ЭЦП.

Имеется классификация

1. Программные средства ЭЦП с защитой личного ключа через разделение секрета
2. Программно-аппаратные средства ЭЦП путем выполнения операций с личным ключом внутри аппаратной платформы

и дискуссия #43 показала что есть

3. Программные средства ЭЦП с защитой личного ключа средствами носителя ключевой информации

Действительно, полная классификация средств ЭЦП включает (по увеличению надежности):

1. Программные средства с размещением контейнера личного ключа где-то у пользователя
2. Программные средства с размещение личного ключа на носителе ключевой информации
3. Программно-аппаратные средства ЭЦП

В данной классификации в планируемых требованиях выпадает второй (по порядку и по надежности) класс средств ЭЦП.

Для исправления данной проблемы нужно

• или полностью убрать программные средства ЭЦП как морально устаревшие
• или ввести класс СКЗИ "средство защиты от несанкционированного доступа ключевой информации" с требованиями по защищенному хранению контейнера и его предоставлению после ввода пароля (с защитой от перебора согласно СТБ 34.101.78 п 11.1):

(АШ, АИ1 или АИ2) или АШИ | УГ, УК1, УЗ3 | Б2 |

УЗ3 = СТБ 34.101.78 п 11.1

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

К УЦ и РЦ будут предъявляться требования определенные Приказом ОАЦ от 29.11.2013 №89

Считаем, что требования "Средства выработки ЭЦП" и "Средства проверки ЭЦП" избыточны, в виду того, что сертификаты могут не использоваться при построении прикладных систем. Кроме того в Законе об электронном документе и в СТБ 34.101.45 требования к составу ЭЦП (выработка, проверка, генерация личных и открытых ключей подписи) не предусматривают средства управления открытыми ключами.

Предлагаем исключить из требования к Средствам линейного шифрования при использовании схемы с Требованиями к криптографическим протоколам и управления ключами "УГ1 или УГ2" исключить из Требований к криптографическим алгоритмам "АХ1 или АХ2", оставив только требование "АШИ".

Предлагается в таблицу 1 в дополнение к ПФ4 (алгоритм DHE_PSK_BIGN) и ПФ5 (алгоритм DHT_PSK_BIGN) добавить новые механизмы формирования общего ключа: ПФ6 – формирование общего ключа по алгоритму DHE_BIGN согласно СТБ 34.101.65-2014 (п. B.2.5.1); ПФ7 - формирование общего ключа по алгоритму DHT_BIGN согласно СТБ 34.101.65-2014 (п. B.2.5.2).

Обоснование.
Многие разработчики реализовали VPN с поддержкой национальной криптографии. Для VPN есть внутренний стандарт, который определяет, что формирование общего ключа и аутентификация сторон должна выполняться таким же образом, как и в протоколе TLS. При этом другие механизмы VPN отличаются от TLS. В связи с этим, для сертификации VPN необходимо в дополнение к алгоритмам DHE_PSK_BIGN и DHT_PSK_BIGN добавить механизмы, соответствующие алгоритмам формирования общего ключа DHE_BIGN и DHT_BIGN.

На данный момент существует два маршрута требований к криптографическим протоколам и управлению ключами для криптографических токенов:

• УГ1 или УГ2, ПА1, ПИ, УК1, УК2, УКЗ, УК4, УК5, УС1, УС2
• УГ1 или УГ2, ПА1, ПА2, ПИ, УК1, УК2, УКЗ, УК4, УК5, УС1, УС2, УС7

Первый вариант создан как замена программно-аппаратным средствам выработки ЭЦП (см issue #4), а второй - для ID карт, и по этой причине имеет дополнительные требования ПА2 и УС7.

предложение: в соответствии с issue #2 уменьшить "профильность" маршрутов и объединить их в УГ1 или УГ2, ПА1, ПИ, УК1, УК2, УКЗ, УК4, УК5, УС1, УС2, [ПА2, УС7] и сместить акцент в логике использования обозначения [ ] с "необязательности требования" на "способ сокращения ветвления маршрутов"

Требование УЗ2 включает СТБ 34.101.78-2019 (пп. 11.2-11.5 раздела 11). Если посмотреть на п. 11.1 СТБ 34.101.78-2019 то можно видеть, что требование по разделению секрета для ключевого контейнера является условным, так как есть два варианта

1. Аппаратная защита контейнера на носителе ключевой информации

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

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

Если дополнительная защита контейнера затруднена, то вместо низкоэнтропийного
пароля следует использовать высокоэнтропийный ключ... Ключ защиты следует
разделить на несколько частичных секретов с помощью алгоритма, определенного в СТБ
34.101.60

Текущая редакция требований является безусловной - выбрасывает п. 1.

По тексту п.11.1 СТБ 34.101.78-2019 применение разделения секрета является условным (Если ... то), данную условность следует отразить в требованиях.

Как вариант, УЗ1, УЗ2 заменить на УЗ - СТБ 34.101.78-2019 (пп. 11.1-11.5 раздела 11)

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

Если мы имеем дело с логическими выражениями, то естественно поставить вопрос об их упрощении. Чем проще требования, тем лучше для всех.

Рассмотрим выражение УС2 или (УС2, УС5) из таблицы 2. Его можно преобразовать в УС2, [УС5]. Что означает [УС5]? Что можно реализовать УС5. А можно и не реализовывать. Требование УС5 фактически не выдвигается. Его можно исключить и тогда УС2 или (УС2, УС5) упрощается до УС2.

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

В средствах линейного шифрования второй профиль предлагаем изложить в следующей редакции: УГ1 или УГ2, ПФ1 или ПФ3 или УК5, AX1 или AX2, УС2, УС3 или УС4. Необязательные криптографические механизмы предлагаем не указывать и от применения квадратных скобок отказаться.

Предлагаем при генерации личных ключей включить в обязательном порядке только требование УГ1 (псевдослучайный датчик в это требование включен в соответствии с п.5.6 СТБ.34.101.27), а УГ2 исключить из требований, так как считаем, что с использованием только псевдослучайного датчика сгенерировать криптографически стойкий ключ невозможно.

В СТБ 34.101.79 BPACE не определяется, BPACE описан в СТБ 34.101.66,

Для средств линейного шифрования предлагается добавить в профиль следующую строку:
Требования к криптографическим алгоритмам: (АШ, АИ1) или (АШ, АИ2) или АШИ
Требования к криптографическим протоколам и управлению ключами: *УГ1 или УГ2, ПФ4, [УК1]
Требования безопасности: Б1 или Б2

Обоснование.
В текущих сертифицированных ОАЦ средствах канального шифрования нашей компании реализованы именно вышеуказанные стандарты. Передаваемые по каналу данные шифруются и для них обеспечивается контроль целостности, поэтому необходимо (АШ, АИ1) или (АШ, АИ2) или АШИ. УГ1 или УГ2 требуются для формирования эфемерных ключей. Протокол ПФ4 необходим для формирования общего ключа и аутентификации сторон. Алгоритм УК1 необходим для формирования по общему ключу ключа шифрования и ключа имитозащиты, а также для преобразования ключей шифрования и имитозащиты после шифрования определенного объема данных. Для cредств VPN формирование ключей шифрования и имитозащиты и их смена производится по внутреннему стандарту (как в TLS) без использования УK1 (в частности, ключи шифрования и имитозащиты формируются по общему ключу с использованием алгоритма генерации псевдослучайных чисел brng-hmac, а обновление ключей производится путем повторного выполнения протокола ПФ4). Для секретных ключей нет стандартизованных форматов криптоконтейнера (есть только для личных ключей и частичных секретов), поэтому требования к криптоконтейнеру не включаются. Согласно СТБ 34.101.65 протокол ПФ4 не требует сертификатов и их проверки, поэтому для данного типа средства канального шифрования требования к сертификатам (УС) не включаются.

В ряде маршрутов используется связка АП2, АХ1 или АХ2. Стоит рассмотреть вопрос целесообразности включения АХ1 или АХ2:

1. АП2 включает belt-hash (АХ1) как вспомогательный алгоритм.
2. Вряд ли алгоритмы хеширования предоставляются пользователю как сервисы.
3. Возможно, включение АХ2 было временной мерой (на этапе формирования таблицы).

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

Ссылка на СТБ 34.101.21 в полном объеме включает ссылку на иностранные криптографические алгоритмы

Для средств линейного шифрования строку с требованиями
УГ1 или УГ2, ПФЗ, УК1, У31, У32
предлагаем заменить на строку
УГ1 или УГ2, ПФЗ, УК1, У31

Обоснование.
У32 определяет требования к формату и механизмам защиты ключевого контейнера. При этом согласно СТБ 34.101.78-2019 (пп. 11.2-11.5 раздела 11) и СТБ 34.101.45-2013 (приложение Е) в ключевом контейнере может храниться личный ключ алгоритмов bign или частичный секрет алгоритма bels, который используется для защиты личного ключа. Протокол ПФЗ основан на использовании личного и открытого ключа bake, поэтому формат У32 не может использоваться: согласно СТБ 34.101.78-2019 криптоконтейнер может использоваться для хранения ключей c идентификатором BignAlgorithmIdentifier или BelsAlgorithmIdentifier).

Встаёт вопрос о статусе требований Ф1 и Ф3, в связи с тем что они:

1. Дублированы в Ф2 и Ф4
2. Содержатся в квадратных скобках

Выходит, что в случае, когда они обязательны (то есть в рамках ИОК), становятся актуальными требования Ф2 и Ф4, поглощающие их.

предлагается: убрать Ф1 и Ф3 и передать их названия механизмам Ф2 и Ф4 соответственно (.т.к. они более ёмкие)

Требования по форматам средств выработки ЭЦП и токенов должны совпадать: требование [Ф2] для средств выработки ЭЦП нет, следовательно не должно быть и у токенов

Название "Средства генерации личных и открытых ключей для средств ЭЦП" не очень удачно. Во-первых, "средства для средств". Во-вторых, пары ключей могут использоваться не только в алгоритмах ЭЦП, но еще и в алгоритмах транспорта (УК5), в протоколах (ПФ1).

Предлагаю сократить: ""Средства генерации личных и открытых ключей".

Для средств линейного шифрования строку с требованиями
УГ1 или УГ2, ПФ1 или УК5, УС2, УСЗ или УС4, [ПФЗ], [ПФ4]
предлагаем заменить на строку
УГ1 или УГ2, ПФ1 или ПФЗ или ПФ5 или ПФ6 или ПФ7 или УК5, УС2, УСЗ или УС4.

Обоснование.
По текущим требованиям в средстве линейного шифрования одновременно может использоваться ПФ1 (формирование общего ключа по протоколам BSTS и BMQV) и, например, ПФ4 (протокол DHE_PSK_BIGN). Не совсем понятно, почему при этом ПФ1 должен быть обязательно, а ПФ4 – необязательно. Более того, протокол ПФ4 не требует сертификатов и их проверки (согласно СТБ 34.101.65), а в указанной строчке сертификаты и их проверка обязательна (указано УС2, УСЗ или УС4). В то же время протокол ПФ5 требует использования сертификатов. Также предлагается разрешить использование протоколов ПФ6 (алгоритм DHE_BIGN согласно п. B.2.5.1 СТБ 34.101.65-2014) и ПФ7 (алгоритм DHT_BIGN согласно п. B.2.5.2 СТБ 34.101.65-2014), которые требуют использования сертификатов и их проверки. В связи с вышесказанным предлагаем писать:
УГ1 или УГ2, ПФ1 или ПФЗ или ПФ5 или ПФ6 или ПФ7 или УК5, УС2, УСЗ или УС4.

Предлагается при использовании защиты ключа по паролю, зашифрованный ключ хранить с соблюдением формата в соответствии с СТБ 34.101.23 п. 11

В столбце с требованиями к криптографическим алгоритмам средства указывают только алгоритмы, которые предоставляются пользователю в качестве сервиса: в случае криптографического токена алгоритмы АШ и АИ1 пользователю не предоставляются и носят внутренний служебный характер