ИТТАС:Предложение 2: Изменить профиль для ПФ3.

[bcryptoregulatory]

ИТТАС:Предложение 2: Изменить профиль для ПФ3.

[zm1ca]

Требование У32 было включено в связи с необходимостью предъявить общие требования к программным криптографическим контейнерам. Считаем необходимым сохранить в требованиях идеи, заложенные в СТБ 34.101.78-2019 (раздел 11).

Предлагается добавить в таблицу 1 механизм УЗ3 "защита ключа по паролю" СТБ 34.101.45 (приложение Е), а в качестве пароля использовать высокоэнтропийный ключ, который защищается с помощью алгоритма разделения секрета. Таким образом, строка примет вид: УГ1 или УГ2, ПФЗ, УК1, У31, УЗ3

для отдельного рассмотрения : с целью сохранения идеи построения программного контейнера, можно дополнительно ссылаться на СТБ 34.101.78 (п.11.1)

[zm1ca]

Поскольку вопрос непосредственно затрагивает использование идеи программного криптографического контейнера, интересно услышать мнение @agievich

[agievich]

Да, действительно в контейнере BPKI (СТБ 34.101.78) может храниться либо ключ Bign, либо ключ Bels. Идентификатор для хранения ключа Bake формально не предусмотрен. Но личный ключ Bake можно использовать в алгоритмах bign-sign (см. п. 5.4 СТБ 34.101.66). Поэтому этот ключ вполне можно хранить в контейнере с идентификатором BignAlgorithmIdentifier. При описании механизма УЗ2 можно ввести разрешение.

Второй вариант, как и предлагалось, -- новый механизм УЗ3 "Защита ключа по паролю". Фактически, это расширение УЗ2, в котором тип защищаемого ключа более вариативен. Рабочий вариант, но технологически более сложный: нужно объяснить, объявить дополнительные идентификаторы, etc. Более того, УЗ3 поглощает У32, делая УЗ2 ненужным. Не очень удачно. Я за первый вариант -- уточнение УЗ2, разрешение на защиту ключей Bake.

[NikGomel]

Введение УЗ3 предполагает не только хранения ключей Bake, а для защиты всех долговременных критических объектов СКЗИ. При этом планируется ввести и формат для хранения такого объекта, в виде структуры шифрованных данных СТБ 34.101.23.

[Alex-ITTAS]

Согласны, что использование для ключа bake криптоконтейнера, определенного в СТБ 34.101.78, требует на данный момент минимальных усилий (не нужно объяснений, объявления дополнительных идентификаторов и т.д.) .
Хотелось бы в рамках данного issue обсудить и более общий вопрос относительно криптоконтейнеров.
В некоторых программных средствах в криптоконтейнере может храниться, например, psk-ключ, ключ и синхропосылка генератора псевдослучайных чисел. Считаем, что следует определиться с форматом хранения и данных объектов.
Использование шифрованных данных согласно СТБ 34.101.23 для формата криптоконтейнера требует уточнений: какой компонент в RecipientInfo следует выбирать (kekri, pwri или ori); в каком формате в компоненте encryptedContent следует хранить непосредственно ключ. Если не дать необходимых уточнений, то совместимости не будет и в таком тяжеловесном формате, как шифрованные данные, нет необходимости. Тогда можно просто потребовать, чтобы криптоконтейнер (произвольного формата) защищался на ключе, а ключ защиты разделялся на частичные секреты (по аналогии с криптоконтейнером СТБ 34.101.78). Возможно так и следует поступить. Альтарнативой является использование для хранения каждого объекта отдельных криптоконтейнеров СТБ 34.101.78, но при этом также требуются уточнения, введение идентификаторов.

[agievich]

Разумное (и подпадающее под стабильные механизмы) решение по защите критических данных произвольной природы:

1. Критические данные зашифровываются (bign-keytransport) на открытом ключе владельца. Формат после защиты -- конвертованные данные СТБ 34.101.23. Или даже свободный формат, ведь здесь вопрос о совместимости не стоит.
2. Личный ключ владельца погружается в контейнер СТБ 34.101.78 (идентификатор -- BignAlgorithmIdentifier). Ключ защиты контейнера защищается через разделение секрета.

[Alex-ITTAS]

В tls и vpn при использовании криптонабора DHE_PSK_BIGN долговременными ключами, которые нужно хранить, являются только секретные psk-ключи и, возможно, ключ и синхропосылка генератора псевдослучайных чисел. При этом надобности в личных и открытых ключах нет. Поэтому решение по зашифрованию psk-ключей на открытом ключе будет избыточным, требующим реализации алгоритмов транспорта ключа, организации хранения безопасным способом открытого ключа, т.е. теряется смысл использования криптонабора с psk-ключами.
Считаем, что решение по использование bign-keytransport не совсем подходящее.

[agievich]

Я отвечал на общий вопрос, пытаясь не выйти за рамки стандартных механизмов.

Хотелось бы в рамках данного issue обсудить и более общий вопрос относительно криптоконтейнеров. В некоторых программных средствах в криптоконтейнере может храниться, например, psk-ключ, ключ и синхропосылка генератора псевдослучайных чисел. Считаем, что следует определиться с форматом хранения и данных объектов.

Не считаю, что следует определяться с форматами контейнеров и алгоритмами их защиты. Эти криптоиженерные вопросы, которые относятся к экспорту критических объектов за пределы криптографической границы. Ответы на вопросы дает СТБ 34.101.27. Если ответы не устраивают, просьба давать предложения вот здесь: https://github.com/bcrypto/skzi. Стандарт будет модернизироваться.

[zm1ca]

учтено в #25