Регулярно сталкиваясь с различными формами применения различных ЭЦП, прихожу к выводу, что большинство из них никуда не годится.
Когда человек вручную подписывает бумажный документ, он имеет его перед глазами, и может прочитать, то есть — идентифицировать. А при подписании документов ЭЦП (как простой, так и квалифицированной) в личных кабинетах банков, на Госуслугах, на сайтах госконтор и коммерческих организаций, чаще всего предлагается подписать кота в мешке — то есть, документ, который пользователь не имеет возможности идентифицировать.
Пользователь, которому навязана система подписания, которую он не имеет возможности контролировать, вполне может оспаривать подлинность "подписанного" таким образом документа. Кому-нибудь попадались примеры оспаривания? Какие приводились аргументы, чем заканчивалось?
По уму, при электронном подписании пользователю должна предъявляться контрольная сумма документа (например, SHA-256), с возможностью выгрузить текст документа и убедиться, что контрольная сумма правильна. Пока я ничего подобного нигде не видел. В лучшем случае, текст просто отображается на экране, а при нажатии "Подписать" происходят неочевидные преобразования, на результат которых накладывается ЭЦП. В худшем случае документ, который требуется подписать, уже где-то подготовлен, и автоматически извлекается, преобразуется, пакуется и т.п., и нет возможности контролировать правильность этих операций.
То есть, фактически я не сам подписываю документ, а поручаю сделать это софту, передавая ему свою ЭЦП, и вынужден полностью доверять правильности работы софта. Поле для искажений, как случайных, так и злонамеренных, достаточно широкое.
Где-нибудь реализована система подписывания, позволяющая максимально контролировать процесс и результат доверенными/проверенными средствами?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Регулярно сталкиваясь с различными формами применения различных ЭЦП, прихожу к выводу, что большинство из них никуда не годится. ЕМ>Где-нибудь реализована система подписывания, позволяющая максимально контролировать процесс и результат доверенными/проверенными средствами?
Чувствую я, что не доверяете вы государственным органам. Может быть, вы и в вакцину не верите? (которые вакцины обычно 10-15 лет делались, а тут меньше чем за год что-то сварили и всем впаривают)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Регулярно сталкиваясь с различными формами применения различных ЭЦП, прихожу к выводу, что большинство из них никуда не годится.
... ЕМ>Где-нибудь реализована система подписывания, позволяющая максимально контролировать процесс и результат доверенными/проверенными средствами?
ЕМНИП, в росреестре подпись делаешь сам и загружаешь отдельно файл документа и файл его подписи.
Ещё в налоговой в одном из вариантов подачи декларации формируется зип файл с документом и его подписью, его можно выгрузить и проверить.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Где-нибудь реализована система подписывания, позволяющая максимально контролировать процесс и результат доверенными/проверенными средствами?
Когда я реализовывал такую систему, у меня в интерфейсе была маленькая кнопочка, которая показывала XML-документ после подписания и перед загрузкой. В нём в принципе всё очевидно было, что-то вроде
т.е. при желании человек может посмотреть конкретный условно читаемый документ, который он подписывает.
Но в целом согласен, никаких стандартов я тут не видел, полный разброд и шатание, все полагаются на то, что система работает без глюков (в том числе преднамеренных). При желании злой разработчик легко может устроить что угодно, хоть ДКП на квартиру подписать, причём никто это проверить не сможет, т.к. злой JS будет выдан конкретному человеку, а не всем подряд. Разве что wireshark-ом дампить пакеты и логгировать сессионные ключи из браузера (даже не знаю, насколько это сложно), но кто это делает.
Вот, кстати, это был бы хороший функционал для браузера — сохранять весь трафик с сервером в криптографически-верифицируемые файлы. Но не видел такого. Идея для стартапа (:
Здравствуйте, vmpire, Вы писали:
V>Ещё в налоговой в одном из вариантов подачи декларации формируется зип файл с документом и его подписью, его можно выгрузить и проверить.
Ну вот я сделал декларацию в Налогоплательщик ЮЛ, подписал ее и выгрузил в их транспортный контейнер. Он получился какой-то микроскопический (4 кб). Внутри еще несколько файлов размером в единицы килобайт. Из описания (packageDescription.xml), что декларация лежит в сжатом и зашифрованном виде в одном из файлов. А шифруется она, как я понял из документации к транспортному контейнеру, открытым ключом ФНС. То есть, расшифровать ее на стороне отправителя невозможно. Тогда как можно проверить ее содержимое?
Здравствуйте, vsb, Вы писали:
vsb>Когда я реализовывал такую систему, у меня в интерфейсе была маленькая кнопочка, которая показывала XML-документ после подписания и перед загрузкой.
А каким образом удостоверялось то, что в итоге было подписано именно это содержимое, а не какое-то другое?
vsb>Разве что wireshark-ом дампить пакеты и логгировать сессионные ключи из браузера (даже не знаю, насколько это сложно), но кто это делает.
Это и слишком сложно, и явно избыточно. По уму, достаточно сделать аналогию описи вложения при отправлении посылки, где максимально подробно описываются вкладываемые предметы. Для файлов вполне годится любой надежный дайджест (например, SHA-256). Для вящей проверяемости текст нужно сперва сохранять в файле максимально простого формата (лучше всего чисто текстового), по которому вычислять хэш, и уже затем открывать файл для показа.
Простой формат файла важен для идентификации содержимого. При использовании PDF, DOC и других может оказаться, что в системе пользователя не отображается какой-нибудь абзац, сноска или что-то еще.
>А при подписании документов ЭЦП (как простой, так и квалифицированной) в личных кабинетах банков, на Госуслугах, на сайтах госконтор и коммерческих организаций, чаще всего предлагается подписать кота в мешке — то есть, документ, который пользователь не имеет возможности идентифицировать.
А как насчет массового тысячами штук подписания документов? Где человек вообще не участвует?
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
ЕМ>Если эти документы генерируются программно, то и меры по идентификации должны приниматься тоже чисто программные.
И в том и другом случае человек имеющий доступ к коду программы может совершить злонамеренные действия. Даже если человек руками подписывает можно его загипнотизировать, запугать. Должны быть и есть наверное механизмы оспорить подпись через суд.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, s_aa, Вы писали:
_>И в том и другом случае человек имеющий доступ к коду программы может совершить злонамеренные действия. Даже если человек руками подписывает можно его загипнотизировать, запугать.
Я ж не говорю, что знаю панацею на все возможные случаи. Я о том, что сейчас выдается за "надежное удостоверение", чаще всего представляет собой ужас разной степени ужасности.
_>Должны быть и есть наверное механизмы оспорить подпись через суд.
Конечно, они есть. И в бОльшей части случаев оспорить ее не то, что просто, а очень просто. И конторы, использующие кривые модели, выезжают исключительно на том, что против них никто всерьез не выступал, а пора бы.
ЕМ>Конечно, они есть. И в бОльшей части случаев оспорить ее не то, что просто, а очень просто. И конторы, использующие кривые модели, выезжают исключительно на том, что против них никто всерьез не выступал, а пора бы.
Подавляющее большинство пользуется этим механизмом добросовестно и всех устраивает. Можно конечно довести это все до абсурда, когда просто невозможно станет этим пользоваться. И кому в результате станет лучше?
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> Пользователь, которому навязана система подписания, которую он не имеет возможности контролировать, вполне может оспаривать подлинность "подписанного" таким образом документа.
В России услуги в области криптографии подлежат обязательной сертификации. Сертификация, как бы, гарантирует.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> R>В России услуги в области криптографии подлежат обязательной сертификации. Сертификация, как бы, гарантирует.
ЕМ> Что именно сертифицируется, например, в системе "банк-клиент"? И считается ли ее использование "услугой криптографии", оказываемой банком клиенту?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> По уму, при электронном подписании пользователю должна предъявляться контрольная сумма документа (например, SHA-256), с возможностью выгрузить текст документа и убедиться, что контрольная сумма правильна.
Это никак не решается с т.з. психологии. Ну выгрузишь ты... и? Как убедишься? Возьмёшь другую программу, которую тебе кто-то подсунул? Или посчитаешь на бумажке? А откуда ты вообще убеждён, что sha-256 не подделывается? Тебе дяди в интернете так сказали или ты сам проводил анализ алгоритма?
В итоге и остаётся уповать на всю инфраструктуру доверия, аудиты, надзорные органы и прочую бюрократию...
Здравствуйте, s_aa, Вы писали:
_>Подавляющее большинство пользуется этим механизмом добросовестно и всех устраивает.
Проблема в том, что механизм заявляется, как высоконадежный, в то время как высоконадежны там лишь отдельные элементы, а вся система, как известно, не надежнее своего самого слабого звена.
_>Можно конечно довести это все до абсурда, когда просто невозможно станет этим пользоваться.
Зачем до абсурда? Я уже описал, как могла бы выглядеть система с достаточной надежностью (и они такие даже есть, только не в "бытовом" секторе). Если в форме для подписания документа появятся его дайджест и кнопка "Сохранить", кого это отпугнет, и кто больше не сможет этим пользоваться?
Здравствуйте, ·, Вы писали:
·>Это никак не решается с т.з. психологии.
Напротив, это достаточно легко решается с любой разумной степенью надежности.
·>Ну выгрузишь ты... и? Как убедишься? Возьмёшь другую программу, которую тебе кто-то подсунул? Или посчитаешь на бумажке?
Могу взять одну из десятков разных программ, могу написать свою, могу и на бумажке подсчитать. Могу это сделать сразу, а могу отложить до момента, когда возникнет спор. Но все эти возможности у меня будут, а при нынешнем подходе — нет ни одной.
·>А откуда ты вообще убеждён, что sha-256 не подделывается? Тебе дяди в интернете так сказали или ты сам проводил анализ алгоритма?
А откуда я вообще убежден, что работаю с финансовой системой, а не с компьютерной игрой? Давайте тогда рассматривать и эту возможность.
·>В итоге и остаётся уповать на всю инфраструктуру доверия, аудиты, надзорные органы и прочую бюрократию...
Вы реально не видите разницы между слепым доверием и контролируемым?
Здравствуйте, Евгений Музыченко, Вы писали:
vsb>>Когда я реализовывал такую систему, у меня в интерфейсе была маленькая кнопочка, которая показывала XML-документ после подписания и перед загрузкой.
ЕМ>А каким образом удостоверялось то, что в итоге было подписано именно это содержимое, а не какое-то другое?
Да никак в принципе. В теории я считаю, что ключ должен лежать в крипто-токене, который должен требовать нажатия физической кнопки на каждую операцию. На практике у нас такого не было.
vsb>>Разве что wireshark-ом дампить пакеты и логгировать сессионные ключи из браузера (даже не знаю, насколько это сложно), но кто это делает.
ЕМ>Это и слишком сложно, и явно избыточно. По уму, достаточно сделать аналогию описи вложения при отправлении посылки, где максимально подробно описываются вкладываемые предметы. Для файлов вполне годится любой надежный дайджест (например, SHA-256). Для вящей проверяемости текст нужно сперва сохранять в файле максимально простого формата (лучше всего чисто текстового), по которому вычислять хэш, и уже затем открывать файл для показа.
ЕМ>Простой формат файла важен для идентификации содержимого. При использовании PDF, DOC и других может оказаться, что в системе пользователя не отображается какой-нибудь абзац, сноска или что-то еще.
Если речь о том, чтобы пользователь сам всё это делал, то с таким пользователи не разберутся. Нужно, чтобы всё работало само.
Здравствуйте, vsb, Вы писали:
vsb>В теории я считаю, что ключ должен лежать в крипто-токене, который должен требовать нажатия физической кнопки на каждую операцию.
Это уже совершенно отдельный вопрос. К идентификации подписываемого документа он не относится.
vsb>Если речь о том, чтобы пользователь сам всё это делал, то с таким пользователи не разберутся. Нужно, чтобы всё работало само.
Нужно не чтобы пользователь делал, а чтобы он мог делать. Не хочет — пусть не делает, его проблемы. Читать сноски в печатных документах тоже никто не заставляет, но при отсутствии такой возможности сразу же возникает основание для спора.
Здравствуйте, Евгений Музыченко, Вы писали:
vsb>>В теории я считаю, что ключ должен лежать в крипто-токене, который должен требовать нажатия физической кнопки на каждую операцию.
ЕМ>Это уже совершенно отдельный вопрос. К идентификации подписываемого документа он не относится.
Относится. Если пользователь видит документ со своей подписью и он нажимал кнопку один раз, значит других подписей не было и отправится именно этот документ.
vsb>>Если речь о том, чтобы пользователь сам всё это делал, то с таким пользователи не разберутся. Нужно, чтобы всё работало само.
ЕМ>Нужно не чтобы пользователь делал, а чтобы он мог делать. Не хочет — пусть не делает, его проблемы. Читать сноски в печатных документах тоже никто не заставляет, но при отсутствии такой возможности сразу же возникает основание для спора.
Может быть. Ну исходя из моего случая я знаю, что это будет делать ровно 0 пользователей. Требований таких никто не ставит. Поэтому делать такое можно, но это будет пустая трата времени. В масштабе страны для массового пользователя, возможно, будет по-другому. Хотя в любом случае нужны какие-то прецеденты. Мне вообще не очевидно, что суд будет разбираться в этой криптографической возне.
