ИТТАС:Предложение 4: Добавить новый профиль, предполагающий использование алгоритма DHE_PSK_BIGN согласно СТБ 34.101.65-2014 (п. B.2.5.3) about skzi-requirements

[zm1ca]

В текущем варианте Таблицы 2 предполагается сертификация описанных Вами средств по профилю *УГ1 или УГ2, ПФ2 или УК1 или УК5, [ПФ4].

Мы стараемся сделать свои требования простыми и лаконичными, поэтому стремимся добавлять новые профили в Таблицу 2 только в случаях, когда их отсутствие связывает руки разработчикам. Дополнительно предлагаем ознакомиться с замечанием #2, а именно:

Провести упрощения -- уменьшить число ячеек-кейсов. Убрать требования по непрофильному функционалу.

[Alex-ITTAS]

У нас имеется средство, реализующее vpn. В данном средстве формирование общего ключа и аутентификация сторон выполняется по ПФ4 (DHE_PSK_BIGN). Данный протокол является безопасным и самодостаточным.
При этом нет необходимости в использовании ПФ2 или УК1 или УК5: 1) ПФ2 не используется, так как формирование общего ключа выполняется по ПФ4; 2) УК1 не используется, так как согласно стандарту на vpn (и tls) по общему ключу формирование ключа шифрования и ключа имитозащиты выполняется c помощью алгоритма brng-hmac (УГ2), а после шифрования заданного объема данных согласно стандарту на vpn необходимо заново выполнить ПФ2; 3) УК5 не используется, так как в DHE используется не траспорт ключа, а протокол Диффи-Хеллмана.

Таким образом, средство vpn с криптонабором DHE_PSK_BIGN не может соответствовать профилю
*УГ1 или УГ2, ПФ2 или УК1 или УК5, [ПФ4]
который при использовании ПФ4 может быть раскрыт одним из трех способов:

1. *УГ1 или УГ2, ПФ2, ПФ4
2. *УГ1 или УГ2, УК1, ПФ4
3. *УГ1 или УГ2, УК5, ПФ4
   Возможно данный профиль нужно поменять на
   *УГ1 или УГ2, ПФ2 или ПФ4 или УК5, [УК1].
   Алгоритм УК1 нужен в некоторых средствах для обновления ключа после защиты определенного объема данных и/или для порождения по общему ключу ключа шифрования и ключа имитозащиты.
   Считаем, что писать УК1 через ИЛИ не совсем корректно, так как УК1, как правило, используется для других целей, отличных от ценей протоколов формирования общего ключа или алгоритма транспорта ключа.

[zm1ca]

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

Распределённый заранее секрет может быть основой для построения предварительного мастер-ключа (см. PSK в п.6.2.4 СТБ 34.101.65). Мы допускаем использование алгоритма преобразования ключа (СТБ 34.101.31-2011 (п. 7.2 раздела 7)) как для обновления ключа после шифрования заданного объема данных, так и для обработки заранее сформированных общих ключей, при условии соблюдения мер защиты (см. п 6.3.2 СТБ 34.101.65-2014).

так как согласно стандарту на vpn (и tls) по общему ключу формирование ключа шифрования и ключа имитозащиты выполняется c помощью алгоритма brng-hmac

предложение: поскольку в описании каждого из алгоритмов формирования общего ключа B.2.5.1-4 присутствует фраза "по pre_master_secret" строится master_secret (см. 8.16)", можно сделать вывод, что указанный алгоритм 8.16 является специализированным алгоритмом преобразования ключа, а значит допустимо представление требования УК1 в виде:
| УК1 | преобразование ключа | СТБ 34.101.31-2011 (п. 7.2 раздела 7) или СТБ 34.101.65-2014 (п. 8.16 раздела 8) |

[agievich]

Поддерживаю предложение о расширении функционала УК1.

Профиль *УГ1 или УГ2, ПФ2 или ПФ4 или УК5, [УК1] выглядит логично.

Профиль *УГ1 или УГ2, ПФ2 или УК1 или УК5, [ПФ4] нет.

[Alex-ITTAS]

Согласны, что профиль *УГ1 или УГ2, ПФ2 или ПФ4 или УК5, [УК1] выглядит более логично. Отметим также, что в #23 рассматривается аналогичный вопрос, но уже с ПФ5. Наше предложение состоит в том, чтобы для средств линейного шифрования в соответствующих профилях разрешить использовать ПФ4 и ПФ5 как полноценные протоколы (т.е. писать их через ИЛИ, а не как необязательное дополнение к другим протоколом "для совместимости со старыми продуктами"). Это позволит, в некотором роде, обеспечивать совместимость реализаций vpn, которые активно используются, а также позволит использовать транспорт ключа (для криптонаборов DHT) и протокол Диффи-Хеллмана (для криптонаборов DHE) безопасным способом.

[zm1ca]

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

Было бы удобно, если бы вы представили обобщённое видение обсуждённых вопросов по средствам канального шифрования (то есть то,
как вы представляете эту часть профиля в целом)