Неполная классификация типов СКЗИ: не хватает средства защиты от НСД для ключевой информации
Opened this issue · 6 comments
Дискуссия в #43 показала на неполноту классификации средств ЭЦП.
Имеется классификация
- Программные средства ЭЦП с защитой личного ключа через разделение секрета
- Программно-аппаратные средства ЭЦП путем выполнения операций с личным ключом внутри аппаратной платформы
и дискуссия #43 показала что есть
- Программные средства ЭЦП с защитой личного ключа средствами носителя ключевой информации
Действительно, полная классификация средств ЭЦП включает (по увеличению надежности):
- Программные средства с размещением контейнера личного ключа где-то у пользователя
- Программные средства с размещение личного ключа на носителе ключевой информации
- Программно-аппаратные средства ЭЦП
В данной классификации в планируемых требованиях выпадает второй (по порядку и по надежности) класс средств ЭЦП.
Для исправления данной проблемы нужно
- или полностью убрать программные средства ЭЦП как морально устаревшие
- или ввести класс СКЗИ "средство защиты от несанкционированного доступа ключевой информации" с требованиями по защищенному хранению контейнера и его предоставлению после ввода пароля (с защитой от перебора согласно СТБ 34.101.78 п 11.1):
(АШ, АИ1 или АИ2) или АШИ | УГ, УК1, УЗ3 | Б2 |
УЗ3 = СТБ 34.101.78 п 11.1
Введение отдельного класса может закрыть дополнительные аспекты криптографической защиты информации, так отчуждаемые носители ключевой информации кроме средств ЭЦП могут применяться в средствах предварительного и линейного шифрования, средствах генерации ключей
с требованиями по защищенному хранению контейнера и его предоставлению после ввода пароля (с защитой от перебора согласно СТБ 34.101.78 п 11.1)
В таком случае ключевым (в отношении аутентификации) становится механизм защиты ключа на пароле, который отсутствует в предлагаемом маршруте, что странно. Раз средство не нагружено внутренним функционалом, оно должно понимать, кому делегирует выполнение некоторой работы с объектом защиты.
- Программные средства с размещением контейнера личного ключа где-то у пользователя
- Программные средства с размещение личного ключа на носителе ключевой информации
В чем разница между 1 и 2? Здесь НКИ понимается шире, чем контейнер с личным ключом, записанный на определенный накопитель?
Отвечая на #43 (comment) замечу, что в #43 (comment) допускалась возможность делегирования аппаратной защиты ключа сертифицированному средству. Предлагаемое лицензиатом решение предполагает сертификацию данного средства как СКЗИ.
Мы же склоняемся к следующей логической цепочке: программное средство проверяется на соответствие СТБ 34.101.27-2011 -> проверяется соответствие требованию ЗО.5 -> заявитель предоставляет доказательство соответствия аппаратной (вспомогательной) составляющей своего продукта ТНПА в части физической безопасности -> проверяется соответствие Common Criteria (СТБ 34.101.1, 2, 3), что не обязательно означает сертификацию составляющей как СКЗИ, а допускает получение сертификата средства технической защиты информации (как это и делается сейчас).
Здесь же считаю уместным упомянуть вопрос bcrypto/skzi#3 (comment) и призвать заинтересованные стороны к активному поиску консенсуса.
Резюмируя: основная проблема с новым маршрутом (в предлагаемой редакции) -- невнятность с определением криптографических функций, которые возлагаются на такое средство.
Раздел 4.7 СТБ 34.101.27-2011 описывает перечень методов защиты объектов как перечень возможных методов, но не обязательных. Т.о. метод ЗО.5 может не предъявляться разработчиком. Разработчиком могут быть заявлены рекомендуемые в СТБ 34.101.27-2011 криптографические методы ЗО.3 и ЗО.4 с последующем "размещением контейнера личного ключа где-то у пользователя" на диске ПЭВМ или USB-флешке.
Тем более, что новый маршрут не отвергает логической цепочки, предложенной коллегами, а лишь обеспечивает возможность выбора для владельцев информационных систем по использованию различных типов отчуждаемых НКИ (либо не использованию таких НКИ), в зависимости от требований, предъявляемых к защите информации в данной информационной системе.
Раздел 4.7 СТБ 34.101.27-2011 описывает перечень методов защиты объектов как перечень возможных методов, но не обязательных. Т.о. метод ЗО.5 может не предъявляться разработчиком. Разработчиком могут быть заявлены рекомендуемые в СТБ 34.101.27-2011 криптографические методы ЗО.3 и ЗО.4 с последующем "размещением контейнера личного ключа где-то у пользователя" на диске ПЭВМ или USB-флешке.
Согласно #43 (comment) (в частности) требования СТБ 34.101.78-2019 предоставляют только два варианта, которые, в терминах п.4.7. СТБ 34.101.27-2011, описаны в ЗО.5 и ЗО.6. Да, в указанном пункте перечисляются и другие механизмы защиты, что логично, поскольку стандарт носит общий характер. СТБ 34.101.78-2019 профилирует его в данном аспекте, так что использование "криптографических методов" не может привести к сертификации по обсуждаемому маршруту.
СТБ 34.101.78-2019 содержит два варианта аппаратной защиты контейнера : по паролю (СТБ 34.101.45, приложение Е) и с помощью высокоэнтропийного ключа с защитой по СТБ 34.101.60. При этом требования к самой аппаратной платформе как к СЗИ в первом случае не уточняются, например, по отчуждаемости от ПЭВМ и т.д. (некое устройство) , а во втором не заявлена вообще. В таком случае формально не будет противоречия с СТБ 34.101.78 и СТБ 34.101.27 (требования к аппартной платформе также не определены) в случае хранения зашифрованного контейнера на жестком диске ПЭВМ или на USB-флешке.
Новый маршрут с предлагаемыми для обсуждения требованиями:
(АШ, АИ1 или АИ2) или АШИ | УГ, УК1, УЗ | Б2 |, где УЗ = СТБ 34.101.78 р. 11
предлагает усилить требования СТБ 34.101.78 в части размещения контейнера EncryptedPrivateKeyInfo (левая часть рис. 2 - Защита ключевого контейнера) на аппаратной платформе, обеспечивающей доступ к контейнеру с помощью высокоэнтропийного ключа.
Вопрос формирования такого ключа должен оставаться в ведении программного средства ЭЦП.