Корректировка профиля about skzi-requirements HOT 7 CLOSED

1. Требования ПФ1 (BSTS и BMQV) и ПФ2 (BPACE) являются, в сущности,
   усиленными вариантами ПФ3 (протокол Диффи-Хеллмана). Принимая во внимания тот факт, что в ПФ3 приводится ссылка на справочное приложение, мы предлагаем разработчикам переходить на более защищённые (от атак "человек посередине") версии протокола формирования общего ключа. Дополнительная защищённость может быть достигнута следующими способами:

• применение сертификатов открытых ключей (ПФ1)
• предварительное распределение секретов (ПФ2)
• сверка общего ключа между абонентами посредством голосовой связи (ZRTP, ПФ3 в профиле 4)

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

2. Не вполне понятна обязательность требования АХ1 или АХ2, просим дополнительных комментариев.

from skzi-requirements.

1. А как добавление УЗ2 к профилю с ПФ3 поможет решить проблему в классическом протоколе Диффи-Хеллмана атака злоумышленника "посередине"? В ПФ3 (приложение А) описан не только классический протокол Диффи-Хеллмана, но и механизмы решения данной проблемы. В чистом виде этот протокол никто не использует. Между тем реализация дополнительных механизмов безопасности (применение сертификатов открытых ключей, предварительное распределение секретов) может хоть и незначительно, но отличаться от ПФ1 и ПФ2.
2. АХ1 и АХ2 для реализации требований ЗО.2 в СТБ 27.

from skzi-requirements.

1. Совершенно верно, никак. Мы подразумеваем (и в одной из редакций так и именовали данный механизм) использование протокола ZRTP в качестве аналога ПФ1 и ПФ2. Что касается изменений, которые разработчики считают необходимыми для внесения при реализации протокола Диффи-Хеллмана: если они действительно привносят удобство без существенного снижения уровня стойкости, может быть стоит сформулировать данные изменения в качестве изменений/дополнений к текущему СТБ 34.101.66?

2.В требовании ЗО.2 СТБ 34.101.27 говорится:

... должны использоваться криптографические, аппаратные или алгоритмические методы.

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

from skzi-requirements.

1. На наш взгляд вносить изменения в СТБ 34.101.66 не стоит. В нем и так уже указано, что: "Для защиты от злоумышленника «посередине» протокол Диффи – Хеллмана должен сопровождаться дополнительными механизмами безопасности. Фактически протокол Диффи — Хеллмана должен являться составной частью некоторого высокоуровневого протокола, который эти механизмы поддерживает..." и т.д.
2. Да, вы правы, добавлять AX1 и AX2 не стоит.

from skzi-requirements.

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

from skzi-requirements.

Я поддерживаю сохранение ПФ3 и исключение АХ1 или AX2 как обязательного требования.

Насколько я понимаю, работа по классу "Средства линейного шифрования" ведется максимально активно. На сегодняшний день класс распадается на 5 подклассов (строчек в таблице 2). Некоторые ячейки в таблице без комментариев (см. #2) понять очень трудно, можно только догадываться.

from skzi-requirements.

По сути, эти 5 строк можно объединить в группы

• на основе предварительно распределенного секрета
• на основе сертификатов
• TLS

• ZRTP (ни сертификатов, ни предварительно распределённого секрета в полной форме)

Естественно было бы объединить маршруты (пока без учёта #10 (comment) )*УГ1 или УГ2, ПФ2 или УК1 или УК5, [ПФ4] и *УГ1 или УГ2, АХ1 или АХ2. предлагаемый способ: https://github.com/bcryptoregulatory/skzi-requirements/pull/21/files

from skzi-requirements.