Comments 5
Да, оставлю за скобками юридическую основу работы с гостовскими ключами, так как юридическая значимость работы с этими ключами появляется после удовлетворения ряда требований.
Полагаю, что юридическая основа появится только тогда, когда компетентные органы сертифицируют bouncycastle или подобные open source библиотеки (причем и сами продукты на таких библиотеках), но это видимо не случится никогда (не будут они ломать монополизм своего же КриптоПро, т.е. рубить "сук на котором"). Использование ГОСТ - алгоритмов имеет смысл видимо только для получения квалифицированной электронной подписи.
Всё верно написали. КриптоПро - фактически монополист. Разработчики КриптоПро JCP в своем продукте используют bouncycastle (изучал их тесты в этой библиотеке, полюбопытсвуйте). По моему мнению, дело не в сертификации самой библиотеки а в сертификации "окружения". У самой КриптоПро - есть конкуренты, но слабые (не погружался в эту тему и не хочу никого обидеть. Фиксирую просто, что конкуренты есть). Можно сгенерить сертификаты в КриптоПро, выгрузить их. Можно настроить openssl для работы с гостовскими алгоритмами. Но как правило за пределами КриптоПро их сертификаты не работают. Их поддержка мне напрямую ответила что keystore они не поддерживают и не собираются. И скорее всего не будет работать и то, что вы сделаете за пределами самой КриптоПро и каким-то образом туда заимпортируете (например через openssl). Надо прилагать некие усилия (конвертировать платной утилитой или некие патчи накатывать). Я полюбопытствовал и не нашел "красивых" решений. Сама bouncycastle - красива :). С гостовскими алгоритмами можно рботать (см тесты которые я приложил), но по моим ощущениям всё совсем негибко. А просто использовать и шифровать данные RSA и AES (без ГОСТ) - легко и понятно.
Всё верно написали. КриптоПро - фактически монополист.
Видимо с кнопкой "Ответить" промазали. Это ведь к "Полагаю, что юридическая основа появится только тогда, ... " было.
Библиотека bouncycastle используется в open source BPMS (СЭД и др.) https://runawfe.ru/
см. стр. 250: http://conf-eekm.ru/wp-content/uploads/2024/02/Инжиниринг-предприятий.-Т.-1-3.pdf
Однако именно невозможность сертификации (см. первый пост) подобного для использования КЭП - "ставит крест" на широком распространении простых и бесплатных (community edition, хотя есть и проф.) решений для юридически значимого документооборота, например, для кадрового электронного документооборота.
Сообщением выше кнопкой промахнулся. Нужно было "ответить" :)
Опять не поспорю. Добавлю только, что для юридической значимости нужно соблюсти ряд требований. Не только иметь возможность использовать совершенные технологии криптоалгоритмов, но и соблюсти ряд условий.
Например, для подписи использовать сертификат, выданный доверенным центром сертификации(мой самоподписанный сертификат только меня самого удовлетворит :) ). Но самое главное: подписать документ в среде, которая будет гарантировать и время подписания (синхронизируется с серверами времени извне и время подписи нельзя подделать) и самого владельца подписи. Тут-то и появляются практически безалтернативные среды, которые серифицированы. Подписи такие, упаковывают в специальные контейнеры. Если нужно гарантировать работу с такой подписью чере много лет то это, например CAdES-A v3.
А вот внутри организации можно свои правила вводить. В тех же СЭД широко используется простая электронная подпись - если пользователь аутенфицирован, то его все действия подтверждены этим фактом, например, именно такой-то согласовал внутри организации такой-то документ в контексте конкретной СЭД. Но можно чуть-чуть улучшить алгоритмы: использовать не сигнатуру MD5, а более надежную сигнатуру подписи RSA. Конфидицальные документы шифровать для доступа определенной группы(чтобы текст документов был виден только этой группе, например членам правления, а не всем админам ПРОД-а, хоть они и подписывают документы о "неразглашении" :) ). Вот тогда примеры реализации, как в этой статье например, могут быть полезны разработчикам. А нужны ли гостовские алгоритмы для шифрования внутри оргнанизации без доступа извне со всей этой огромной конструкцией типа крипта-про - тоже вопрос. Кому-то точно не нужны.
Добавлю только, что для юридической значимости нужно соблюсти ряд требований.
Возможно есть путаница: юридически значимый - это совсем не обязательно долговременного хранения. Например, автостраховка с электронной подписью - юридически значима, но не долговременного хранения.
Для долговременного хранения, например, 10 лет есть два варианта: TSP + длинный сертификат (скорее теория) и "TSP + OCSP", см. 3. Основной «подводный камень» КЭДО и иного ЭДО.
А вот внутри организации можно свои правила вводить. В тех же СЭД широко используется простая электронная подпись -
Возможно тоже не совсем верно. Часто на простую подпись налагаются требования регуляторов, например, по КЭДО (ТК, 578н и др.), т.е. "свои правила" вводить не получится, если они противоречат законам, а законы, в т.ч. и №472 часто вообще не однозначны.
Электронная подпись, шифрование данных с помощью RSA, AES. Реализация на Kotlin, Micronaut, bouncycastle