Неполная классификация типов СКЗИ: не хватает средства защиты от НСД для ключевой информации

[andrewkostevich]

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

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

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

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

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

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

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

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

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

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

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

УЗ3 = СТБ 34.101.78 п 11.1

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

[zm1ca]

с требованиями по защищенному хранению контейнера и его предоставлению после ввода пароля (с защитой от перебора согласно СТБ 34.101.78 п 11.1)

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

[agievich]

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

В чем разница между 1 и 2? Здесь НКИ понимается шире, чем контейнер с личным ключом, записанный на определенный накопитель?

[zm1ca]

Отвечая на #43 (comment) замечу, что в #43 (comment) допускалась возможность делегирования аппаратной защиты ключа сертифицированному средству. Предлагаемое лицензиатом решение предполагает сертификацию данного средства как СКЗИ.

Мы же склоняемся к следующей логической цепочке: программное средство проверяется на соответствие СТБ 34.101.27-2011 -> проверяется соответствие требованию ЗО.5 -> заявитель предоставляет доказательство соответствия аппаратной (вспомогательной) составляющей своего продукта ТНПА в части физической безопасности -> проверяется соответствие Common Criteria (СТБ 34.101.1, 2, 3), что не обязательно означает сертификацию составляющей как СКЗИ, а допускает получение сертификата средства технической защиты информации (как это и делается сейчас).

Здесь же считаю уместным упомянуть вопрос bcrypto/skzi#3 (comment) и призвать заинтересованные стороны к активному поиску консенсуса.

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

[Siarhei-St]

Раздел 4.7 СТБ 34.101.27-2011 описывает перечень методов защиты объектов как перечень возможных методов, но не обязательных. Т.о. метод ЗО.5 может не предъявляться разработчиком. Разработчиком могут быть заявлены рекомендуемые в СТБ 34.101.27-2011 криптографические методы ЗО.3 и ЗО.4 с последующем "размещением контейнера личного ключа где-то у пользователя" на диске ПЭВМ или USB-флешке.
Тем более, что новый маршрут не отвергает логической цепочки, предложенной коллегами, а лишь обеспечивает возможность выбора для владельцев информационных систем по использованию различных типов отчуждаемых НКИ (либо не использованию таких НКИ), в зависимости от требований, предъявляемых к защите информации в данной информационной системе.

[zm1ca]

Раздел 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 профилирует его в данном аспекте, так что использование "криптографических методов" не может привести к сертификации по обсуждаемому маршруту.

[Siarhei-St]

СТБ 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 - Защита ключевого контейнера) на аппаратной платформе, обеспечивающей доступ к контейнеру с помощью высокоэнтропийного ключа.
Вопрос формирования такого ключа должен оставаться в ведении программного средства ЭЦП.