Comments (9)
Требование У32 было включено в связи с необходимостью предъявить общие требования к программным криптографическим контейнерам. Считаем необходимым сохранить в требованиях идеи, заложенные в СТБ 34.101.78-2019 (раздел 11).
Предлагается добавить в таблицу 1 механизм УЗ3 "защита ключа по паролю" СТБ 34.101.45 (приложение Е), а в качестве пароля использовать высокоэнтропийный ключ, который защищается с помощью алгоритма разделения секрета. Таким образом, строка примет вид: УГ1 или УГ2, ПФЗ, УК1, У31, УЗ3
для отдельного рассмотрения : с целью сохранения идеи построения программного контейнера, можно дополнительно ссылаться на СТБ 34.101.78 (п.11.1)
from skzi-requirements.
Поскольку вопрос непосредственно затрагивает использование идеи программного криптографического контейнера, интересно услышать мнение @agievich
from skzi-requirements.
Да, действительно в контейнере 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.
from skzi-requirements.
Введение УЗ3 предполагает не только хранения ключей Bake, а для защиты всех долговременных критических объектов СКЗИ. При этом планируется ввести и формат для хранения такого объекта, в виде структуры шифрованных данных СТБ 34.101.23.
from skzi-requirements.
Согласны, что использование для ключа bake криптоконтейнера, определенного в СТБ 34.101.78, требует на данный момент минимальных усилий (не нужно объяснений, объявления дополнительных идентификаторов и т.д.) .
Хотелось бы в рамках данного issue обсудить и более общий вопрос относительно криптоконтейнеров.
В некоторых программных средствах в криптоконтейнере может храниться, например, psk-ключ, ключ и синхропосылка генератора псевдослучайных чисел. Считаем, что следует определиться с форматом хранения и данных объектов.
Использование шифрованных данных согласно СТБ 34.101.23 для формата криптоконтейнера требует уточнений: какой компонент в RecipientInfo следует выбирать (kekri, pwri или ori); в каком формате в компоненте encryptedContent следует хранить непосредственно ключ. Если не дать необходимых уточнений, то совместимости не будет и в таком тяжеловесном формате, как шифрованные данные, нет необходимости. Тогда можно просто потребовать, чтобы криптоконтейнер (произвольного формата) защищался на ключе, а ключ защиты разделялся на частичные секреты (по аналогии с криптоконтейнером СТБ 34.101.78). Возможно так и следует поступить. Альтарнативой является использование для хранения каждого объекта отдельных криптоконтейнеров СТБ 34.101.78, но при этом также требуются уточнения, введение идентификаторов.
from skzi-requirements.
Разумное (и подпадающее под стабильные механизмы) решение по защите критических данных произвольной природы:
- Критические данные зашифровываются (
bign-keytransport
) на открытом ключе владельца. Формат после защиты -- конвертованные данные СТБ 34.101.23. Или даже свободный формат, ведь здесь вопрос о совместимости не стоит. - Личный ключ владельца погружается в контейнер СТБ 34.101.78 (идентификатор --
BignAlgorithmIdentifier
). Ключ защиты контейнера защищается через разделение секрета.
from skzi-requirements.
В tls и vpn при использовании криптонабора DHE_PSK_BIGN долговременными ключами, которые нужно хранить, являются только секретные psk-ключи и, возможно, ключ и синхропосылка генератора псевдослучайных чисел. При этом надобности в личных и открытых ключах нет. Поэтому решение по зашифрованию psk-ключей на открытом ключе будет избыточным, требующим реализации алгоритмов транспорта ключа, организации хранения безопасным способом открытого ключа, т.е. теряется смысл использования криптонабора с psk-ключами.
Считаем, что решение по использование bign-keytransport
не совсем подходящее.
from skzi-requirements.
Я отвечал на общий вопрос, пытаясь не выйти за рамки стандартных механизмов.
Хотелось бы в рамках данного issue обсудить и более общий вопрос относительно криптоконтейнеров. В некоторых программных средствах в криптоконтейнере может храниться, например, psk-ключ, ключ и синхропосылка генератора псевдослучайных чисел. Считаем, что следует определиться с форматом хранения и данных объектов.
Не считаю, что следует определяться с форматами контейнеров и алгоритмами их защиты. Эти криптоиженерные вопросы, которые относятся к экспорту критических объектов за пределы криптографической границы. Ответы на вопросы дает СТБ 34.101.27. Если ответы не устраивают, просьба давать предложения вот здесь: https://github.com/bcrypto/skzi. Стандарт будет модернизироваться.
from skzi-requirements.
учтено в #25
from skzi-requirements.
Related Issues (20)
- Генерация ключей HOT 4
- Средства управления открытыми ключами HOT 2
- Требования к средствам линейного шифрования HOT 2
- Средства генерации личных и открытых ключей HOT 1
- ИТТАС: Предложение 5: Изменить профиль для средства линейного шифрования с ПФ5. HOT 3
- Изменение формата таблиц HOT 8
- Требование [Ф2] не входит в область применения средств предварительного шифрования HOT 3
- Избыточные требования к алгоритмам криптографического токена HOT 2
- Неполная ссылка на BPACE в ПА1 HOT 1
- Убрать иностранные криптографические алгоритмы из требования ПИ HOT 2
- Требование [Ф2] для криптографического токена неоднозначно HOT 1
- Необходимость Ф1 и Ф3 HOT 3
- Защита контейнера при условии HOT 8
- Связка АП2 + АХ1 или АХ2 HOT 3
- Неполная классификация типов СКЗИ: не хватает средства защиты от НСД для ключевой информации HOT 6
- Предлагается создать профиль требований для УЦ и РЦ HOT 4
- Генерация ключей HOT 4
- Требования к терминалу HOT 1
- Привести таблицы в соответствие с 77 приказом
- Помощник для составления заявок HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from skzi-requirements.