Форум КриптоПро
»
Общие вопросы
»
Общие вопросы
»
Шифрование на пароле + корректность встраивания СКЗИ
Статус: Участник
Группы: Участники
Зарегистрирован: 07.08.2012(UTC)
Сообщений: 13
Сказал(а) «Спасибо»: 1 раз
|
Доброго всем дня!
Хочется проконсультироваться, у представителей КРИПТО-ПРО (да и просто сведущих), по следующему вопросу:
Мы отправили систему на тематические исследования "Встраивание СКЗИ в систему ... и оценка ее влияния на СКЗИ".
В системе предусмотрены следующие методы шифрования:
- на основе сертификата
- на пользовательском пароле.
Все шло хорошо пока не позвонили из ФСБ (8 центр) и не отметили следующее замечание:
необходимо исключить функциональную возможность шифрования на пользовательском пароле, ввиду его не стойкости + этот метод не рекомендован к использованию документацией на СКЗИ КриптоПро CSP 3.6.
Я аргументировал, в пользу оставить все как есть, тем что это опциональность системы (хочешь пользуешься хочешь - нет). Также предлагал написать в нашей документации что, например, при использовании шифрования в системе не допускается применение шифрования "на пароле" для защиты документов, содержащих сведения ограниченного распространения ...
В итоге договориться не получилось и они через лабораторию прислали официальное письмо о необходимости исключения шифрования на пароле.
Вопросы:
1. В какой документации (название, пункт) на КриптоПро CSP 3.6 не рекомендовано использование шифрования на пароле (смотрел Формуляр, Руководство администратора - не нашел, или не увидел)?
2. Кто-то может сталкивался с подобной ситуацией и приводил более весомые аргументы, которые приняли в ФСБ?
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 07.08.2012(UTC)
Сообщений: 13
Сказал(а) «Спасибо»: 1 раз
|
В дополнение,
Алгоритм шифрования на пароле в общих чертах следующий:
1. Имеются данные, которые необходимо зашифровать. Так же имеется пароль, который ввел пользователь для шифрования данных.
2. Генерируется случайный сессионный ключ для шифрования. Для генерации случайного ключа используется КриптоПро
3. На сгенерированном случайном сессионном ключе шифруются защищаемые данные.
4. Сессионный ключ шифруется на пароле, введенном пользователем.
5. Зашифрованные данные и зашифрованный сессионный ключ сохраняются в базе данных.
|
|
|
|
|
|
Статус: Администратор
Группы: Администраторы, Участники
Зарегистрирован: 28.12.2007(UTC)
Сообщений: 350
Откуда: ООО "КРИПТО-ПРО"
Поблагодарили: 6 раз в 5 постах
|
Можете пояснить подробности п. 4 - какими функциями CryptoAPI это делаете?
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 07.08.2012(UTC)
Сообщений: 13
Сказал(а) «Спасибо»: 1 раз
|
К сожалению, я не могу развернуто ответить на поставленный вопрос. Единственное, что наши программисты отметили, п.4 завязан на функцию CPDeriveKey.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва
Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
|
Возможно вам поможет эта информация. В прошлом году в ТК-26 шла работа над рядом документов, среди которых PKCS#5 для ГОСТ, так вот восьмёрка вполне себе согласилась с вот таким вот абзацем:
++++++++++++++++++++++++++
для выработки ключа из пароля следует использовать функцию диверсификации PBKDF2 (P, S, c, dkLen) c использованием в качестве PRF функции HMAC_GOSTR3411 в соответствии с RFC4357.
DK = PBKDF2 (P, S, c, dkLen)
Функции:
HMAC_GOSTR3411 (K, text)–функция выработки HMAC ГОСТ Р 34.11-94 на ключе K отданных text (см. RFC 4357, раздел 3).
Параметры:
P - пароль. Символьная строка в кодировке Unicode UTF-8.
S -случайноезначение salt – см.[1].
с - число итераций алгоритма.
dkLen- требуемая размерность выходной последовательности в байтах.
Выход:
DK, производный ключ длины dkLen байт.
+++++++++++++++++++++
Осталось это всё переложить на вызовы CSP (если получится).
|
 1 пользователь поблагодарил Sergey M. Murugov за этот пост.
|
|
|
|
Статус: Администратор
Группы: Администраторы, Участники
Зарегистрирован: 28.12.2007(UTC)
Сообщений: 350
Откуда: ООО "КРИПТО-ПРО"
Поблагодарили: 6 раз в 5 постах
|
Если CrypDeriveKey (CPDeriveKey) - то всё просто. В документе ЖТЯИ.00050-03 90 05 Руководство программиста про эту функцию есть примечание: "Если на вход подаётся фиксированный набор данных, то функция создаёт один и тот же ключ. В этом случае создаваемый ключ можно использовать только для шифрования данных или экспорта ключей на ключевые носители. Использовать его для шифрования данных или экспорта ключей, помещаемых на диск или передаваемых по каналу связи, не рекомендуется." Сергей, я не совсем понял. Если на вход даётся случайное число - то как и где его сохранить для того, чтобы повторно сделать такой же ключ? Отредактировано пользователем 24 мая 2013 г. 15:20:49(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,770   Сказал «Спасибо»: 579 раз
Поблагодарили: 2307 раз в 1807 постах
|
Автор: Василий Дементьев 
Сергей, я не совсем понял.
Если на вход даётся случайное число - то как и где его сохранить для того, чтобы повторно сделать такой же ключ? salt? в создаваемом файле, в начале.  |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 07.08.2012(UTC)
Сообщений: 13
Сказал(а) «Спасибо»: 1 раз
|
Василий,
Да, но ведь это не запрет в чистом виде, по идее, у нас система предупреждает если пользователь вводит "простой" пароль, т.е. нами рекомендуется (прямо в окне ввода пароля) применение 8 символьного пароля с наличием цифр и знаков верхнего и нижнего регистра одновременно. Ну это так, к слову.
Спасибо за ссылку на документ. К сожалению, в ФСБ не считают необходимым давать названия документов, на которые они ссылаются.
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 07.08.2012(UTC)
Сообщений: 13
Сказал(а) «Спасибо»: 1 раз
|
Сергей, выработка ключа - да, но приняли ли они то, что потом объект, зашифрованный на таком ключе, будет передан по каналам связи?
У нас проблема именно в этом - зашифрованный на пароле сессионный ключ (на котором шифруется документ) передается в базу (для сохранения) по каналам связи.
|
|
|
|
|
|
Статус: Администратор
Группы: Администраторы, Участники
Зарегистрирован: 28.12.2007(UTC)
Сообщений: 350
Откуда: ООО "КРИПТО-ПРО"
Поблагодарили: 6 раз в 5 постах
|
Цитата:но ведь это не запрет в чистом виде но и на разрешение не сильно похоже :) Вот вам и не разрешили. Моё мнение - правильно не разрешили. С чисто математической точки зрения стойкость случайного ключа 256 бит порядка 10 в 77-й, а у вас только порядка 10 в 16-й. Цитата:salt? в создаваемом файле, в начале Но тогда, чтобы обеспечить приличную защиту ключа, пароль должен быть такой длины, что на практике будет неудобно. Не говоря уже о том, что нужны будут исследования безопасности самой процедуры ввода пароля.
|
|
|
|
|
|
Форум КриптоПро
»
Общие вопросы
»
Общие вопросы
»
Шифрование на пароле + корректность встраивания СКЗИ
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
