что в линуксе нет системного хранилища сертификатов.

а куда оно делось-то? в принципе, вместо nss раньше можно было подсунуть p11-kit. там библиотечка совместимая c libnssckbi, но работает с нормальным системным списком CA, плюс можно подключать любые юзерские хранилища. это нормальная замена весьма сомнительному nss. но последние версии браузеров стали выпендриваться и не жрут подмену p11. по идее, надо просто разбираться, что там в nss понапихали и обновлять p11-kit.

Закрытость кода, реализующего криптографию - это обязательное требование для сертификации в РФ.

Похоже на домыслы. Покажите документ и пункт в нем.

Только если попадет русскоговорящему разработчику. Я бы на это не расcчитывал.

тот разработчик, кого я знаю лично, во-первых далек от криптографии, во-вторых не настроен как-то рассматривать или толкать эти патчи в нужном направлении, до проявления активности от самого ТС

Каким-то образом по электронной подписи можно определить, на сертифицированным ПО она сделана или нет?

По отпечатку вроде нет. А в сертификате чётко прописан программно-аппаратный комплекс удостоверяющего центра.

это чтобы пользователь сертифицированного ПО не мог его модифицировать

vendor lock?

это чтобы пользователь сертифицированного ПО не мог его модифицировать

LD_PRELOAD

Точно должен? Или может? Т.к. ФСБ сертифицирует не алгоритм, они его вам и так дадут, а его реализация. А реализовать ты можешь хоть на асме. То что у FOSS сообщества не хватит денег и упертости для сертификации своей реализации, проблема таки не ФСБ.

Сертифицируют даже не реализацию, а экземпляры софты, к которым причем предъявляются определенные требования, вот в чем прикол. Поэтому повторяю, что FOSS в РФ в принципе не может сертифицировать что-то. Только фирма, которая будет распространять сертифицированные бинарники.

Похоже на домыслы. Покажите документ и пункт в нем.

Было это уже лет 8 назад. И документы где-то искать сейчас влом, да еще не уверен, что они выложены на сайты.

Смысл там не в том, что open source запрещено сертифицировать, а в том, что пользователю передается. Передается бинарник без исходного кода и это уже насколько помню принципиальный момент. Даже если чисто формально его исходник совпадает 1:1 с исходником где-то на гитхабе.

vendor lock?

Нет, просто игрища в безопасность в понимании тех, кто составлял такие пункты.

Для субъекта тоже отдельное поле есть, но почти всегда прописывали туда КриптоПро CSP продаваемой версии. Тензор мне выдал такой, хотя должны были вписать «Рутокен ЭЦП», т.к. был он в качестве СКЗИ, и с Криптопро даже не совместим был.

Какие такие еще электронные подписи? Когда чиновники МВД Казахстана оформляли мне удостоверение личности в графе место рождения вместо г. Целиноград указали - г. Астана...

До безопасности вообще ещё очень далеко, как до коммунизма. Особенно в вебе. Почти отошли от подписывания с копированием закрытого ключа. Ключи выдают уже не на дискете, а на носителе с собственным СКЗИ, но он используется только как хранилище, а обрабатывается на программном СКЗИ.

УЦ не занимаются только обработкой запросов на сертификат, а занимаются всем, и в какой-то момент имеют возможность скопировать ключ, или просто использовать её. Некоторые могут работать по нормальной схеме, но только обновление, а не получение.

Подписывание всегда происходит не глядя. Если локально подменить подписываемое сложней, то в вебе только полное доверие. Некоторые предложили железные решения с экранчиками, но они показывают только пару строк текста определённого формата и при определённых условиях.

Каким-то образом по электронной подписи можно определить, на сертифицированным ПО она сделана или нет?

По сертификату, которым проводилось подписание. В сертификате должны быть поля (oid-ы) subjectsigntool (СКЗИ на котором генерировалась ключевая пара владельца сертификата) и issuersigntools (данные об СКЗИ УЦ, сертификате самого УЦ и сертификате ФСБ СКЗИ УЦ). Так что определить можно и нужно

он используется только как хранилище

В большинстве случаев Да! Но не всегда - используйте токен/смарт карты PKCS#11 с ГОСТ-криптографией и все будет нормально

Тензор мне выдал такой, хотя должны были вписать «Рутокен ЭЦП», т.к. был он в качестве СКЗИ,

В СУД!

Тензор мне выдал такой, хотя должны были вписать «Рутокен ЭЦП», т.к. был он в качестве СКЗИ,

В СУД!

Цель?

Для субъекта тоже отдельное поле есть, но почти всегда прописывали туда КриптоПро CSP продаваемой версии.

WTF? Что за УЦ такое странное? Или ты путаешь? У нас ЭП выданы ГАУ РО РЦИС, УФК по Ростовской области, ООО УЦ Белинфоналог и у всех +- указан ФИО, его ИНН, СНИЛС, организация и мб его должность.

А есть поле «Средство электронной подписи» и у меня там написано «КриптоПро CSP», в другом сертификате есть другое поле «Средство электронной подписи и УЦ издателя» там написано «Средство электронной подписи: „КриптоПро CSP“ (версия 3.6) (исполнение 2) Заключение на средство ЭП: № 149/7/6-241 от 05.06.2018 Средство УЦ: „Программно-аппаратный комплекс „Юнисерт-ГОСТ“. Версия 2.1“ Заключение на средство УЦ: № 149/7/6-241 от 05.06.2018».

Насколько я помню, то если в сертификате выданным аккредитованым Минсвязью РФ УЦ на физ. лицо нет ФИО, ИНН и СНИЛС физ. лица, то данная подпись юр. силы не имеет.

Пользовался. Pksc11 пока с трудом работает с сертифицированными. Даже в windows. На госуслуги заходит, а вот на что-то ещё уже можно особо не надеяться. Пока им пользуются те, кому требуются неизвлекаемые ключи, но как только криптопро csp 5 со изкоробочным pksc11 сертифицирует, он может заполнить эту нишу на десктопе. Свободному ПО это не очень поможет.

тот разработчик, кого я знаю лично, во-первых далек от криптографии, во-вторых не настроен как-то рассматривать или толкать эти патчи в нужном направлении

Про какие патчи речь ? Не понял. Я хз как там в LO по крайне мере в АОО всегда всякую фигню делали плагинами, или что уже в LO механизм плагинов убрали ?

WTF? Что за УЦ

Тензор. Остальные поля субъекта нормально заполнены, а вот криптопро как средство был видимо в шаблоне жестко прописан. Я пару недель у них выпытывал вообще про возможность получить подпись не для криптопро. Так толком и не ответили, но всё же нормальный, неизвлекаемый ключ сделали. Работал через библиотеки pkcs11 от производителя.

Цель?

Сертификат фактически не действителен!!!

Плагинами можно дополнить функциональность, а обсуждаемая функциональность «вшита».

чиновники МВД Казахстана

А на них в Казахстане КНБ (Комитет Национальной Безопасности) есть = http://www.knb.kz

чиновники МВД Казахстана

mvd.gov.kz

mvd.gov.kz

http://mvd.gov.kz/portal/page/portal/mvd/MVD

или что уже в LO механизм плагинов убрали ?

расширения никуда не делись, но речь в данном случае, как я понял, о том, что есть проблема в базовом исходном коде в самом Либре, и вот ее-то и надо исправить

Имеется в виду открытый сертификат? То есть его надо передавать вместе с электронной подписью? То есть, вместе с подписанным документом? А в файл подписанного документа сертификат вставояется в обязательном пррядке? Или его надо отдельным файлом прикладывать?

Вроде, юридически сертификат -неотъемлимая часть ЭП. Обычно инструметны вставляют и его. Не знаю насколько стандартизированы форматы, но на госуслугах можно проверить только прикреплённые и откреплённые в формате pkcs7. Конечно в сертификате может быть написано одно, а на деле другое. СКЗИ пока никак не заверяют, что именно они выполнили операцию. Решение не техническое.

Не понял, а что они хотят тогда добавить ?

вот ее-то и надо исправить

Исправить ? Хм. Кого то в багзилле чтоли забанили ( или хз что там у них )

Нет, просто игрища в безопасность в понимании тех, кто составлял такие пункты.

- security by obscurity

По сертификату, которым проводилось подписание. В сертификате должны быть поля (oid-ы) subjectsigntool (СКЗИ на котором генерировалась ключевая пара владельца сертификата) и issuersigntools (данные об СКЗИ УЦ, сертификате самого УЦ и сертификате ФСБ СКЗИ УЦ). Так что определить можно и нужно

На самом деле ничто не мешает любому ПО точно также заполнить все эти поля. Сертификат удостоверяет подлинность, сгенерированных с его использованием ключей, а не программ.

- security by obscurity

На самом деле нельзя основывать безопасность на закрытости, но сама по себе закрытость как вспомогательная мера все же повышает безопасность.

Правда в случае клиентского софта в этом вообще никакого смысла не вижу.

На самом деле ничто не мешает любому ПО точно также заполнить все эти поля.

А вот тут вы не правы. Поля заполняются в УЦ! И УЦ несет ответственность за правильность их заполнения. Точно также как паспортный стол несет ответственность за достоверность заполнению паспорта при его выдачи.Почитайте ЗДЕСЯ

Да все верно, но вопрос был не о том кто какую ответственность несет, а можно ли по цифровой подписи как-то узнать сертифицированной ли программой она создана. Чисто технически. Так вот правильный ответ, что нет, нельзя узнать. УЦ может при желании заполнить эти поля в любой программе, клиент при желании может использовать тоже любую программу. И это принципиально никак не доказуемо только по подписи. Разумеется, если используются такие же алгоритмы.

можно ли по цифровой подписи как-то узнать сертифицированной ли программой она создана

Ответ одназначен - нет, нельзя! Тут вы правы.

Хотя если спрашивающему было фактически интересно есть ли инфа про программу, то да есть, вы тоже правы.

Исправить ? Хм. Кого то в багзилле чтоли забанили ( или хз что там у них )

кто-то просто странный, вот и всё

И это принципиально никак не доказуемо только по подписи.

Хотя, если у вас закрытый ключ хранится на токене/смарткарте PKCS#11 с поддержкой соответствующей криптографии (в нашем разговоре ГОСТ), в частности собственно функция подписания, и ключ не извлекаем, то саму подпись можно сделать только на этом токене (на этом СКЗИ). Подчеркиваю ключ неизвлекаем не в смысле всяких виндовых и аля с ними CSP, а неизвлекаем с аппаратного токена PKCS#11. Теперь по сертификату находим его владельца и убеждаемся что именно он сделал подпись НА своем ТОКЕНЕ!!!!

умеет также подписывать ЭЦП уже имеющийся ПДФ файл

Притворяется. После этого документ проходит проверку только в самом же LibreOffice или из командной строки через pdfsig, но не Adobe Reader DC. Adobe Reader видит, что файл поврежден, пытается восстановить, при этом ломает подпись.

И это принципиально никак не доказуемо только по подписи.

Хотя, если у вас закрытый ключ хранится на токене/смарткарте PKCS#11 с поддержкой соответствующей криптографии (в нашем разговоре ГОСТ), в частности собственно функция подписания, и ключ не извлекаем, то саму подпись можно сделать только на этом токене (на этом СКЗИ). Подчеркиваю ключ неизвлекаем не в смысле всяких виндовых и аля с ними CSP, а неизвлекаем с аппаратного токена PKCS#11. Теперь по сертификату находим его владельца и убеждаемся что именно он сделал подпись НА своем ТОКЕНЕ!!!!

Ну ты же отправил на эту тему багрепорт в ЛибреОфис правда?

Нет, но помню, что собирался и нашел такой же. А вот сейчас найти не могу :(

проходит проверку только в самом же LibreOffice

Adobe Reader (и другие просмотрщики, которые могут работать с ЭП) видит, что файл подписан, и пытается проверить, но если у него нет поддержкисоответствующих алгоритмов, то он и скажет что подпись плохая. Подпись не ломается, а проверяется.

Я не про gost, а про алгоритмы, которые в LibreOffice по умолчанию.

Короче, вот подписанный в LibreOffice pdf-файл на поиграться: https://my.pcloud.com/publink/show?code=XZR7BM7ZDBIi4djImW0m8nyJ8kCWGyfY5e47

Вот что про него говорит pdfsig:

Digital Signature Info of: /tmp/TestSign.pdf
Signature #1:
  - Signer Certificate Common Name: (null)
  - Signer full Distinguished Name: E=patrakov@gmail.com
  - Signing Time: Nov 03 2018 00:01:49
  - Signing Hash Algorithm: SHA-256
  - Signature Type: adbe.pkcs7.detached
  - Signed Ranges: [0 - 19705], [69707 - 70656]
  - Total document signed
  - Signature Validation: Signature is Valid.
  - Certificate Validation: Certificate is Trusted.

Я в курсе, что COMODO не входит в список удостоверяющих центров, которым Adobe Reader доверяет по умолчанию. Но ошибка выдается «1 page(s) modified», а не про недоверенный УЦ.

Если делать подпись не в LibreOffice, а через PortableSigner или jSignPdf, то ошибка вылезает именно про недоверенный УЦ. Тестовый файл от jSignPDF: https://my.pcloud.com/publink/show?code=XZ7XBM7ZvrcIKeQMcfjcjqGjEt9Xt5V94fKX

Сведения:

Digital Signature Info of: /tmp/TestSignJava.pdf
Signature #1:
  - Signer Certificate Common Name: (null)
  - Signer full Distinguished Name: E=patrakov@gmail.com
  - Signing Time: Nov 03 2018 00:14:55
  - Signing Hash Algorithm: SHA-256
  - Signature Type: adbe.pkcs7.detached
  - Signed Ranges: [0 - 160], [30162 - 50782]
  - Total document signed
  - Signature Validation: Signature is Valid.
  - Certificate Validation: Certificate is Trusted.

Т.е. те же алгоритмы, тот же сертификат, разный результат проверки.

Поскольку найти дубликат бага все еще не могу, зарепортил.

https://bugs.documentfoundation.org/show_bug.cgi?id=121133

А откуда идёт вот это требование писать «детали» сертификата зелёным цветом?

про алгоритмы, которые в LibreOffice по умолчанию.

Судя по вашим скриншотам речь идет об разных подпясях, сделанных на одном и том же сертификате. Первая подптсь сделана Signing Time: Nov 03 2018 00:01:49 для блока Signed Ranges: [0 - 19705], [69707 - 70656]. Вторая подпись сделана Signing Time: Nov 03 2018 00:14:55 для блока Signed Ranges: [0 - 160], [30162 - 50782]

Одна из них является добавленной полписью. Пришлите документ - посмотрим.

А опенофис?

умеет открывать, по умолчанию в Draw.

По моему, только в draw и умеет.

И еще, частенько корежит пдф до неузнаваемости.

А это не одно и тоже? Я просто не в курсе истории переименований.