Комментарии 38
Спасибо за пост. Когда уже будет ГОСТ в ванильном OpenSSL?
Давно уже есть начиная с версии 1.1. Я не знаю зачем автор это делает. Практически во всех дистрибутивах есть эти движки.
Уточните пожалуйста, я не до конца понял.
То есть можно использовать обычные сборки openssl доступные через apt и все так же будет работать?
Конечно. К примеру так
https://www.altlinux.org/%D0%93%D0%9E%D0%A1%D0%A2_%D0%B2_OpenSSL
То что альт написано не обращайте внимание. Настраивается точно так же везде.
Спасибо!
То что альт написано не обращайте внимание. Настраивается точно так же везде.
username@localhost:~$ openssl version
OpenSSL 1.1.1f 31 Mar 2020
username@localhost:~$ sudo apt-get install openssl-gost-engine
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package openssl-gost-engineЧЯДН?
для начала не говорите какой у вас дистрибутив.
Настраивается точно так же везде
Вы уж определитесь: везде точно так же, или есть отличия от дистрибутива к дистрибутиву. Речь про Ubuntu 20.04
Я то все верно говорю. А вот вы могли бы и догадаться что пакет может менять свое название. В Ubuntu 20.04 этот пакет вот
В вашем случае это будет
apt search libengine-gost-openssl
Sorting... Done
Full Text Search... Done
libengine-gost-openssl1.1/focal 1.1.0.3-1 amd64
Loadable module for openssl implementing GOST algorithms
apt install libengine-gost-openssl1.1Дальше настройка идентична тому что написано в доке альта. Только не прописывайте путь до библиотеки. Это не требуется
Дальше настройка идентична тому что написано в доке альта
Не будет. Утилиты control в составе пакета нет, поэтому подключение движка нужно делать через скрипт (кстати, ошибку 37922 уже пофиксили, но это не поможет). Код скрипта gost-for-openssl требует изменений, ну и дальше что-нибудь точно вылезет.
Короче говоря, приведенный способ обработки напильником мало похож на установку готового пакета. Вот вам и ответ, почему автор использует докер-образ.
Но за наводку в любом случае спасибо, буду посматривать.
Будет. Смотрите старый способ. Там надо банально в /etc/ssl/openssl.cnf добавить конфигурацию движка.
[openssl_def]
engines = engine_section
[engine_section]
gost = gost_section
[gost_section]
engine_id = gost
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSetДальше оно просто работает.
openssl engine gost -c
(gost) Reference implementation of GOST engine
[gost89, gost89-cnt, gost89-cnt-12, gost89-cbc, grasshopper-ecb, grasshopper-cbc, grasshopper-cfb, grasshopper-ofb, grasshopper-ctr, md_gost94, gost-mac, md_gost12_256, md_gost12_512, gost-mac-12, gost2001, gost-mac, gost2012_256, gost2012_512, gost-mac-12]Вот вам чуть более точная дока с Росалаба
http://wiki.rosalab.ru/ru/index.php/OpenSSL_%D0%B8_%D0%93%D0%9E%D0%A1%D0%A2
Здравствуйте!
Не подскажете, как называется данный пакет для aline linux?
Пробовал искать, но безрезультатно.
Остаётся собирать из репозитория?
Сохранил в закладки, спасибо!
По хорошему мы сами должны генерить закрытый ключ и отдавать УЦ только сертификат на подпись. Дабы закрытый ключ знал только владелец сертификата.
Интересно, есть УЦ которые так умеют?
И как тогда правильно самому сгенерировать сертификат?)
Калуга Астрал точно так умеют
А теперь самый интересный вопрос. С какими полями надо сформировать сертификат для получения усиленной квалифицированной подписи физику?
К сожалению так и не смог найти нормальной инструкции. (я умею создавать сертификаты, просто непонятно какие поля в этом сертификате должны быть)
Заявка на выпуск сертификата для юридического лица формируется с использованием личного кабинета на их сайте.
По поводу физических лиц не знаю порядка, думаю порядок подобный.
Физическое лицо
Набор атрибутов следующий
CN — ФИО (Иванов Иван Иванович)
SN — Фамилия (Иванов)
G — Имя Отчество (Иван Иванович)
C — Страна (RU)
S — Регион (77 Москва)
L — Город (Москва)
SNILS — СНИЛС
INN — ИНН
E — email
По хорошему мы сами должны генерить закрытый ключ и отдавать УЦ только сертификат на подпись. Дабы закрытый ключ знал только владелец сертификата.
Тут проблема в том, что УЦ этот вопрос тоже интересует. И если им просто приносить сертификат на подпись — они не могут проверить, генерировал ли ключик владелец и никому его не показывал, или ему помогли 'добрые' люди, предоставив услугу или облегчающий процедуру софт, но в процессе оставившие копию ключика себе.
Если посмотреть на SSL-сертификаты, то там УЦ, как правило, всегда принимают сертификат на подпись без предоставления закрытого ключа. И цена компрометации закрытого ключа порой выше чем у ЭП :)
Было бы здорово если бы УЦ предоставляли оба варианта. Генерят сами или подписывают сертификат клиента.
В комментариях ниже увидел, что оказывается пары ключей должны создаваться только сертифицированным ПО. Это немного усложняет дело, однако проблема все равно остается.
Насчет того, что 'не должно' — совсем не уверен. Имеет смысл не создавать условия, которыми могут воспользоваться мошенники, 'помогающие' условным бабушкам работать с сайтом Госуслуг и налоговой.
А потом при помощи тех ключей, что они сами генерировали (можно даже на сертфицированном ПО) подписывающих документы на продажу чего-то, чем бабушка владеет.
Почему эти «помощники» не могут взять так же «помочь» после выпуска сертификата УЦ? (т.е. просто скопировать себе, или вообще ключ подменить, если пользователь все равно сам не умеет)
Могут, конечно. Но в большинстве случаев человек будет знать, что он что-то важное (в УЦ это же объяснили, нет?) кому-то отдает.
А УЦ — это тоже еще одна потенциальная дыра в безопасности, откуда я знаю, что они при генерации ключа копию себе не оставили?
Речь идет о массовом обслуживании. Я думаю, что для подавляющего большинства людей риск того, что ключ сопрут из облепленной со всех сторон пломбами спец-машинки HSM — меньше, чем его сопрет прямо с их компа какой-нибудь зловред. Например, вроде бы никто не боится того, что ключики, что внутри чипа банковской карты живут, будут сохранены и использованы для изготовления клона карты (вряд ли они прямо внутри карты генерируются — она настолько дешевая, что банки их без особой оплаты сейчас раздают)
А настоящие параноики должны пользоваться именно хардварными токенами, которые генерирую ключи прямо внутри себя и потом их наружу не отдают.
… верифицированной ЭЦП. Попробуем же сэкономить время и деньги и по максимуму избежать платных проприетарных и аппаратных решений.
А какже тогда требование по использованияю сертифицированных СКЗИ? Я конечно понимаю, что контрагент всё равно не узнает каким ПО подписывался документ.
Если дело дойдет до споров, а потом до суда, то да, для легитимности электронной подписи необходимо, чтобы она создавалась при помощи сертифицированного ПО. Другое дело как доказать, что вот эта конкретная подпись была создана при помощи сертифицированного ПО, а вот эта — при помощи несертифицированного. Ну как минимум лицензия на сертифицированное ПО необходима.
Статья отличная, покажу юристам, если будут интересные комментарии — отпишусь
А пока просто оставлю это здесь
Электронный документооборот в России
Комментарии юриста as-is
Просто исходя из этой статьи подпись типа все равно проверять надо на госуслугах как я поняла… а то что у меня стоит это тензор — спец оператор
Проверить подпись можно много где, как локально так и на сайте госуслуг, например.
Всё. Можно отправлять контрагенту документ и соответствующий sig файл.
Но это только с контрагентами, по трудовым не пройдёт
Физик и так эцп юзают, но подписывать нужно в одной системе, для этого и нужен спец оператор, который в случае конфликта подтвердит факт подписания
Пара вопросов по логистике процесса.
Удостоверяющий Центр выдал нам ключ и сертификат в одном PKCS#12 файле auth.p12
А можете подсказать какой УЦ выдает ключи так? Разве им не выгоден вендор-лок? Можно ли купить такой токен удаленно, через госуслуги или любым способом, чтобы не ходить лишний раз?
Когда я получал ЭЦП как физик, они выдавали всякие токены, которые работали только с Windows XP или типа того.
Я исхожу из того, что у нас в наличии есть linux и docker. Можно даже не локально — вполне можно закинуть наш документ куда-нибудь на хостинг и подключиться по SSH
Давно уже есть начиная с версии 1.1. Я не знаю зачем автор это делает. Практически во всех дистрибутивах есть эти движки.
Так можно просто поставить обычный официальныйopen-ssl от мейнтейнеров и все?
Зачем тогда автор пиарит свой образ?
2) Я не являюсь автором того docker образа (Автор в статье по ссылке — getId. По моему опыту в ванильном OpenSSL есть только старый ГОСТ, который уже не актуален, но не исключаю, что мы с автором той статьи отстали от жизни.
По моему опыту в ванильном OpenSSL есть только старый ГОСТ, который уже не актуален
Это делает проверку через госуслуги или другие системы невозможной, или просто нужно на всякий случай?
Зависит от требований получателя документа.
Немножко понимания как всё это устроено можно почерпнуть из соседней статьи:
https://m.habr.com/ru/post/502992/
В докер-образе видимо побольше этих ГОСТов. [gost89, gost89-cnt, gost89-cnt-12, gost89-cbc, grasshopper-ecb, grasshopper-cbc, grasshopper-cfb, grasshopper-ofb, grasshopper-ctr, magma-cbc, magma-ctr, id-tc26-cipher-gostr3412-2015-kuznyechik-ctracpkm, md_gost94, gost-mac, md_gost12_256, md_gost12_512, gost-mac-12, magma-mac, grasshopper-mac, id-tc26-cipher-gostr3412-2015-kuznyechik-ctracpkm-omac, gost2001, gost-mac, gost2012_256, gost2012_512, gost-mac-12, magma-mac, grasshopper-mac, id-tc26-cipher-gostr3412-2015-magma-ctracpkm-omac, id-tc26-cipher-gostr3412-2015-kuznyechik-ctracpkm-omac]
По сравнению с тем что в системе (Ubuntu 21)
[gost89, gost89-cnt, gost89-cnt-12, gost89-cbc, grasshopper-ecb, grasshopper-cbc, grasshopper-cfb, grasshopper-ofb, grasshopper-ctr, md_gost94, gost-mac, md_gost12_256, md_gost12_512, gost-mac-12, gost2001, gost-mac, gost2012_256, gost2012_512, gost-mac-12]
НО! Они все не помогают для ключа полученного в декабре 21 года в Тензоре.
Крипто-Про не видит закрытого ключа, openssl в сборке находит целых ноль байт.
Схема VipNet Windows10 -> PFX -> openssl ....
Вопрос: а в каком ГОСТе сейчас ключи выдают? Или это в виндах что-то нахимичили с шифрованием?
ЭЦП по ГОСТ на GNU/Linux с помощью OpenSSL