Раньше я использовал КриптоАрм для создания подобных подписей CadesXLong своим личным сертификатом.



Но потом после понимания своей беззащитности перед буткитами и различными новостями о злоупотреблениях ЭЦП вплоть до хищений собственности, боюсь получать свой сертификат. А зачем он нужен, если в сорце написано, что (c) Copyright мое ФИО, место жительства, можно добавить и паспортные данные, all rights reserves, blah-blah ...


Вообще-то конечно неплохо было бы идентифицировать своим личным сертификатом, если бы хотя бы решили проблему безопасного его использования, я поднимал эти вопросы еще более года назад:

https://www.cryptopro.ru...aspx?g=posts&t=18830

https://www.cryptopro.ru...aspx?g=posts&t=18369

https://www.cryptopro.ru...aspx?g=posts&t=16670

https://forum.rutoken.ru/topic/3275/

и другие ветки.

Но не уверен, что уже что-то решили в плане работоспособности SafeTouch PRO особенно с последними версиями карт Rutoken ECP 3.

Мои считыватели SafeTouch PRO глючили со страшной силой при попытке их использования даже с уже не самыми современными смарткартами "Rutoken ECP 2". КриптоПРО вис и отказывался дальше работать, приходилось перезапускать сервисы. Хотя с другими обычными считывателями все работало нормально.

Хотя в принципе "Rutoken ECP2 Touch" вероятно решает те же самые проблемы, что и SafeTouch PRO:
https://safe-tech.ru/en/safetouch-pro/
причем намного надежнее в контексте именно создания подписи файла, а не для банков.

Вообщем я тогда разочаровался в этом и забросил. Возможно новая современная прошивка может решить проблемы. Еще как ее выпросить у SafeTech, тоже целая история.

Потом вскрывать, паять, прошивать, окирпичивать :)

Некогда пока ...

Отредактировано пользователем 24 июня 2022 г. 3:55:11(UTC)  | Причина: Не указана

c 5 версией в составе есть графический аналог "Инструменты КриптоПРО".

Спасибо, почистил.

Добрый день, можно узнать, с чем именно вы несогласны?



Что значит не менялся? Файл как раз мог и поменяться (например какой-то "хитрец" мог попытаться заменить в файле Copyrigth на свой), но подписанным оригинальной подписью считается только оригинальная подписанная версия файла. ЭЦП - это в первую очередь доказательство подписания оригинального файла обычно квалифицированным сертификатом (юридически значимым аналогом собстенноручной подписи).



В нашей схеме подпись (проявление волевого согласия с содержимым) вторична или даже не важна. Важно время проставления подписи, потому что по закону к доказательствам авторства могут относиться (образно своими словами) доказательства существования материала (с проставленным Copyright) на определенную дату.
У кого раньше доказуемо был в наличии материал и кто проставил на нем свой (c) Copyright, тому легче доказывать, что он и является автором. Схема с подписанием ЭЦП или депонированием нотариусам как раз и решает данную задачу.


Верно, не придираясь к формулировкам.


IMHO доверие именно к законности выданного сертификата относительно вторично (кроме идентификации Васи в случае разбора полетов), если сертификат соответствует необходимым техническим параметрам, то этого уже достаточно, чтобы понять в какое время существовала подписанная версия файла, абсолютно неважно кем подписанная, важно содержимое и насколько достоверно установлено время генерации подписи.
Проблема может быть толькоо в том, что какие-либо отклонения в валидности сертификата, могут вызвать и проблемы при проверке подписей, что вызовет недоверие к дате генерации подписи, это уже серьезный недостаток конечно. Важно, чтобы сертификат был выдан УЦ, к которому есть доверие. Образно, если даже жуликам удастся получить личный сертификат (на другое лицо) в очень авторитетном УЦ типа СКБ Контур, то
подписи, созданные таким сертификатом все же продолжают показывать на существование определенной версии файла в определенное время, хоть и по всем остальным параметрам такая подпись будет выглядеть очень негативно при рассмотрении подобной ситуации и недействительной в случае попытки подписания ей договора в качестве стороны сделки.



Кто же запретит Васе что-либо подписывать? Важна ведь не юридическая значимость его в качестве подписанта документа как некого договора и проявления его согласия с содержимым текста, а его участие в качестве свидетеля существования некого текста. Насколько помню, при генерации подписи можно задать текстовое поле к подписи, в нем можно указать, что подписант согласен с тем, что подписываемый файл существует в момент подписания, но подписант не является стороной договора.

Образно, шел Вася по шоссе и нашел какие-то документы с текстами, он берет другой листик бумаги, пишет на нем, что в такое-то время он нашел документы, и ставит свою подпись в качестве свидетеля. Можно еще сшить такие листы вместе и на прошивку наклеить пломбу, на которой поставить собственноручную подписиь Васи. Тоже самое происходит и при подписании чужих файлов. Можно аналогично даже создавать текстовый файл с осмотром файлов, где указывать наименования файлов, кратко содержимое и хэш коды файлов. Потом подписывать такой witness of evidence подписью Васи. Сгенерировать хэши осматриваемых файлов без наличия этих файлов для Васи затруднительно (или вернее невозможно), по крайне мере если он не работает в АНБ или не обладает доступом к машине времени.



Вася может создать документ, как описано одним пунктом выше. Но IMHO даже подписание чужого документа по крайне мере доказывает, что в определенное время Вася действительно видел файл в его оригинальном подписанном виде, хоть формально его подпись такого файла и не добавляет ему каких-либо прав или обязанностией в контексте содержимого документа.

Отредактировано пользователем 24 июня 2022 г. 18:08:48(UTC)  | Причина: Не указана

Добрый день.
Да, я теперь понял, что у Вас нестандартный подход - использовать штампы времени для доказательства существования файла. С этим есть потенциальные проблемки в плане того, что 1) можно заранее нагенерить штампы времени на значительное количество хэшей, то есть "впрок"; 2) многое зависит от стойкости и длины хэша. Например, в случае crc32 относительно легко получить файл с нужным значением просто дописав 4 байта к комментарию в файле. Аналогично и с другими хэшами, дописав столько же байтов сколько длина хэша можно в большинстве случаев найти нужное значение хэша. Просто актуальные хэши занимают очень много времени для подбора хэша. Это в свою очередь проводит зависимость от вычислительной мощности вычислительных машин. Вечный хэш невозможен, так как компьютеры постепенно наращивают мощность. Когда-нибудь и гост-2012 512 бит будет подбираться на раз.Если в двух словах, то с боязнью средств ЭЦП. Скажу, что если у Вас есть карта в банке, то Вы наверняка уже подписали договор с банком где мелкими-мелкими буквами прописано, что пин-код и данные карты или коды подтверждения в веб-клиенте банка равносильны ЭЦП. Все, "коготок увяз". Ладно, это оффтопик.Я немного про другое - после того как файл подписан, если его изменить, подпись будет нарушена и его придется переподписывать еще раз. То есть, заменив копирайт, хитрец не сможет выдать Вашу оригинальную подпись с измененным файлом. Другими словами, подпись прошедшая проверку свидетельствует что файл в том же состоянии, что и на момент подписания. Это используется неявно при передаче файлов через каналы связи, например, при документообороте это доказывает, что полученный отчет не является искаженным/измененным/битым при передаче.Если Вы имеете ввиду тот момент где КриптоАРМ дает список из значений типа "Подписано", "Согласовано" и т.д., то данное поле: во-первых, не текстовое, а oid (кодированная циферка), то есть кроме заданных значений туда нельзя ничего вписать. Во-вторых, я честно не видел нигде нормативного основания для данного поля, т.е. какой-нибудь суд может не принять поле в рассмотрение и вместо "Согласовано" считать это как окончательное подписание. В-третьих, Вы конечно можете добавить еще и "свое" текстовое поле, но для него также надо подвести нормативные основания.

Способы 2 и 3 достаточно интересные. Насчет способа 4 я честно сомневаюсь - в том смысле, что блокчейн конечно идея очень интересная (в том плане, что запулить сами исходники в блокчейн со своим копирайтом было бы еще надежнее), но с другой стороны, майнинг это явно тупиковое направление развития. Проблемы я бы сказал такие: 1) собственный блокчейн (с малым количество пользователей и короткого размера) начинать смысла не имеет, так как короткую цепочку относительно легко можно поменять, пересчитать заново и заменить на всем небольшом количестве клиентов; 2) размер полной базы блокчейнов сам по себе является проблемой; 3) привлечение широких масс сделано через криптовалюты, что влечет "честную" привязку к энергопотреблению. Энергомощности не резиновые, то есть всегда прогнозировалось их постепенное наращивание. Говорю это из знакомства с людьми, которые как раз прогнозируют нагрузки на электростанции в нашей области. К появлению нового фактора резко повышающего мощности потребления не готовы ни линии, ни подстанции, ни электростанции. Думаю, было бы интереснее от полной цепочки отступить в сторону DHT (распределенной таблицы хэшей) из торрентов.