Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>·>Ну выгрузишь ты... и? Как убедишься? Возьмёшь другую программу, которую тебе кто-то подсунул? Или посчитаешь на бумажке?
ЕМ>Могу взять одну из десятков разных программ, могу написать свою, могу и на бумажке подсчитать. Могу это сделать сразу, а могу отложить до момента, когда возникнет спор. Но все эти возможности у меня будут, а при нынешнем подходе — нет ни одной.
Ты лично — может и можешь. Программы же как правило рассчитаны на широкую аудиторию и таких как ты — единицы. Делать лишние кнопочки ради чего? Как я понимаю, в лучшем случае ты можешь потребовать исходники на предмет поиска закладок... Не знаю как этот процесс организован, честно говоря. Думаю зависит от отрасли и конкретных правил.

ЕМ>·>А откуда ты вообще убеждён, что sha-256 не подделывается? Тебе дяди в интернете так сказали или ты сам проводил анализ алгоритма?
ЕМ>А откуда я вообще убежден, что работаю с финансовой системой, а не с компьютерной игрой? Давайте тогда рассматривать и эту возможность.
Вот потому я и упомянул психологию. Что рассматривать — зависит от человека.

ЕМ>·>В итоге и остаётся уповать на всю инфраструктуру доверия, аудиты, надзорные органы и прочую бюрократию...
ЕМ>Вы реально не видите разницы между слепым доверием и контролируемым?
С технической т.з. достаточно того, чтобы был доступ к исходникам и возможность проверить, что бинарик который ты используешь собран именно из этих исходников. Не знаю насколько это требование выполяется...
Для неспециалистов контролируемое доверие практически невозможно, остаётся лишь выбор кому слепо доверять.

Здравствуйте, rudzuk, Вы писали:

R>https://minprom.ru/uslugi/licenziya-fsb-na-kriptografiyu/process-oformleniya-licenzii-fsb-na-kriptografiyu/

Прочитал по диагонали вместе с ПП — ощущение такое, что сертифицируется только некое ядро, непосредственно выполняющее криптографические операции, а обвязка, вместе с UI, под лицензирование не подпадает.

На это указывает и то, что организации, использующие ЭЦП в том или ином виде, регулярно меняют UI. Сомневаюсь, что при каждом изменении они заново получают лицензию ФСБ на всю систему в целом.

Здравствуйте, vsb, Вы писали:

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

Что значит "пользователь видел документ со своей подписью"? Ему на экране показали текст документа, а где гарантия, что подписан будет именно этот текст, а не другой? А сейчас еще в моде положения вроде "принимая условия настоящего Соглашения, Клиент также принимает условия Договора Присоединения N 2, Приложения N 7 и Специального Дополнения N 15". Все эти Приложения и Дополнения лежат где-то отдельно, и не идентифицируются никак иначе, кроме как по номерам/датам. Случаев, когда сервер отдавал старую версию файла, или администратор путал имена/реквизиты, предостаточно.

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

vsb>исходя из моего случая я знаю, что это будет делать ровно 0 пользователей. Требований таких никто не ставит.

Да и ради бога. Еще раз напоминаю аналогию с бумагой: требований внимательно читать весь текст вместе со сносками тоже никто не ставит, и в действительности его почти никто не читает. Зато многие потом плачутся, что лучше б они прочитали.

vsb>Мне вообще не очевидно, что суд будет разбираться в этой криптографической возне.

А что останется делать суду, если спор таки возникнет?

Здравствуйте, ·, Вы писали:

·>в лучшем случае ты можешь потребовать исходники на предмет поиска закладок...

Даже если бы это было возможно — предлагаете искать закладки (и просто косяки) в каждой версии каждого исходника? На порядки проще регламентировать саму процедуру подписания.

Еще раз напоминаю аналогию с почтовыми посылками. Можно проверять всю цепочку обработки и перевозки посылок от пункта отправления до пункта назначения. А можно ограничиться составлением описи вложения при отправке, и проверкой их соответствия при доставке. Проще на порядки, а надежность примерно та же.

·>Для неспециалистов контролируемое доверие практически невозможно, остаётся лишь выбор кому слепо доверять.

"Контролируемое" — это в том числе и "проверяемое". Если один просто утверждает о своей честности, а другой вдобавок предлагает простой способ ее проверить, кому из них следует доверять больше?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ну вот я сделал декларацию в Налогоплательщик ЮЛ, подписал ее и выгрузил в их транспортный контейнер. Он получился какой-то микроскопический (4 кб). Внутри еще несколько файлов размером в единицы килобайт. Из описания (packageDescription.xml), что декларация лежит в сжатом и зашифрованном виде в одном из файлов. А шифруется она, как я понял из документации к транспортному контейнеру, открытым ключом ФНС. То есть, расшифровать ее на стороне отправителя невозможно. Тогда как можно проверить ее содержимое?
Так один из файлов — он и есть декларация. Она разве зашифрована?
Если да, то да, никак не посмотреть.

Здравствуйте, Евгений Музыченко, Вы писали:

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

ЕМ>Что значит "пользователь видел документ со своей подписью"? Ему на экране показали текст документа, а где гарантия, что подписан будет именно этот текст, а не другой?

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

EM>А сейчас еще в моде положения вроде "принимая условия настоящего Соглашения, Клиент также принимает условия Договора Присоединения N 2, Приложения N 7 и Специального Дополнения N 15". Все эти Приложения и Дополнения лежат где-то отдельно, и не идентифицируются никак иначе, кроме как по номерам/датам. Случаев, когда сервер отдавал старую версию файла, или администратор путал имена/реквизиты, предостаточно.

ЕМ>Дайджесты вроде SHA-256 хороши тем, что элементарно вычисляются из документа, а вот способов подогнать документ под известный дайджест пока не известно.

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

vsb>>исходя из моего случая я знаю, что это будет делать ровно 0 пользователей. Требований таких никто не ставит.

ЕМ>Да и ради бога. Еще раз напоминаю аналогию с бумагой: требований внимательно читать весь текст вместе со сносками тоже никто не ставит, и в действительности его почти никто не читает. Зато многие потом плачутся, что лучше б они прочитали.

На мой взгляд ситуация другая. Ты описываешь ситуацию, когда одна сторона занимается фактическим мошенничеством, мухлюя с подписями. А мелкий (в разумных пределах) шрифт это не мошенничество.

vsb>>Мне вообще не очевидно, что суд будет разбираться в этой криптографической возне.

ЕМ>А что останется делать суду, если спор таки возникнет?

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

Здравствуйте, vmpire, Вы писали:

V>Так один из файлов — он и есть декларация.

Который из? Я там ничего из знакомых форматов не вижу.

V>Она разве зашифрована?

<документ кодТипаДокумента="01" типДокумента="декларация" типСодержимого="xml" сжат="true" зашифрован="true" идентификаторДокумента="f6c97d067a3f4cd8bd7f4e178e60f1c8"
исходноеИмяФайла="NO_USN_5404_5404_540406742845_20210430_A90A0EAF-B6E5-4B4E-81BE-C392C92C7814.xml">
<содержимое имяФайла="4b95f11def36431fbd11bcca4cdcd190.bin"/>
<подпись имяФайла="5edd449128eb401cb53d290542d0a0c5.bin" роль="абонент"/>
</документ>

V>Если да, то да, никак не посмотреть.

О том и речь. То есть, я отправил нечто, за содержание чего формально должен отвечать, но возможности это контролировать у меня нет.

Здравствуйте, vsb, Вы писали:

vsb>Я же показал выше пример. Там XML с уже внедрённой подписью.

А где в том XML сам документ, или какие-либо данные, однозначно определяющие его содержание?

vsb>Ну да, такое делается без проблем — туда же, в этот подписываемый документ добавляешь хеш и всё.

Ну вот, в Вашем примере я такого хэша не увидел.

vsb>Ты описываешь ситуацию, когда одна сторона занимается фактическим мошенничеством, мухлюя с подписями.

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

ЕМ>>А что останется делать суду, если спор таки возникнет?

vsb>Подозреваю, что поверит тому, у кого адвокаты будут убедительней вещать.

А если адвокаты одной стороны будут абстрактно вещать "у нас все честно, возможность ошибки или подмены исключена!", а адвокаты другой стороны продемонстрируют на практике ситуацию, в которой возможна как ошибка, так и подмена?

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

Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>Я же показал выше пример. Там XML с уже внедрённой подписью.

ЕМ>А где в том XML сам документ, или какие-либо данные, однозначно определяющие его содержание?

Внутри тега <document>.

vsb>>Ну да, такое делается без проблем — туда же, в этот подписываемый документ добавляешь хеш и всё.

ЕМ>Ну вот, в Вашем примере я такого хэша не увидел.

Там такой задачи не стояло.

vsb>>Ты описываешь ситуацию, когда одна сторона занимается фактическим мошенничеством, мухлюя с подписями.

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

Считается, что ПО работает как положено и не мухлюет.

ЕМ>>>А что останется делать суду, если спор таки возникнет?

vsb>>Подозреваю, что поверит тому, у кого адвокаты будут убедительней вещать.

ЕМ>А если адвокаты одной стороны будут абстрактно вещать "у нас все честно, возможность ошибки или подмены исключена!", а адвокаты другой стороны продемонстрируют на практике ситуацию, в которой возможна как ошибка, так и подмена?

Я думаю, если это можно продемонстрировать на практике, то это обычный баг и до суда дело вряд ли дойдёт. А если это злонамеренная атака со стороны разработчиков сайта, то ничего продемонстрировать не выйдет, т.к. оно сработает "неправильно" один раз, а в последующем будет работать правильно.

ЕМ>А еще давайте представим, что мы обсуждаем некую уязвимость в ОС или известном приложении. Я указываю на то, что уязвимость есть, но до сих пор никем не используется, хотя может быть использована при желании. Несколько человек мне возражает, что, раз ее до сих пор ее никто не использовал, то и париться нечего; вот как появится эксплойт, тогда и надо будет начинать думать. Какую сторону займет каждый из моих нынешних оппонентов?

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

Здравствуйте, rudzuk, Вы писали:

R>В России услуги в области криптографии подлежат обязательной сертификации. Сертификация, как бы, гарантирует.

Суровость российских законов ... (с)

Есть такая система, ГИС ЖКХ. Все организации ЖКХ обязаны выгружать в неё минимум раз в месяц данные. Пути два: Excel через браузер или SOAP с подписанием контейнера электронной подписью. Подавляющее большинство разработчиков программ для ЖКХ предлагает интеграцию через SOAP. При этом лицензии на криптографию нет почти ни у кого из них. И всем пофигу. В т.ч. и государственной системе, поскольку её идеологи и создатели только рады рапортовать об всё увеличивающихся количествах интеграций с ними. А то, что эта интеграция незаконная — им не интересно.

Здравствуйте, sfsoft, Вы писали:

s> Есть такая система, ГИС ЖКХ. Все организации ЖКХ обязаны выгружать в неё минимум раз в месяц данные. Пути два: Excel через браузер или SOAP с подписанием контейнера электронной подписью. Подавляющее большинство разработчиков программ для ЖКХ предлагает интеграцию через SOAP. При этом лицензии на криптографию нет почти ни у кого из них. И всем пофигу. В т.ч. и государственной системе, поскольку её идеологи и создатели только рады рапортовать об всё увеличивающихся количествах интеграций с ними. А то, что эта интеграция незаконная — им не интересно.

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

Здравствуйте, rudzuk, Вы писали:

R>Насколько я помню, если криптография применяется в рамках обеспечения собственных бизнес-процессов, то ее сертифицировать не требуется. Если бы компания разрабатывала ПО для клиентов и предлагала им некие криптографические средства, то такое ПО необходимо было бы сертифицировать.

Ни то, ни другое. ПО, в которое встраивается криптографическое средство, предлагается клиентам (организациям ЖКХ). Без лицензии ФСБ никуда.

Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Регулярно сталкиваясь с различными формами применения различных ЭЦП, прихожу к выводу, что большинство из них никуда не годится.
Экспертом ни в криптографии, ни в кибербезопасности я не являюсь; однако, сформулированную вами проблему считаю актуальной. В тех сценариях, где формирование и подписание документа интегрированы.

По идее, бороться с этим можно только принудительно разделив формирование договора и подписание его.
Идея — в том, что тот, кто может быть заинтересован в подмене документа, доступа к подписанию не имеет. Всё, что он может — сформировать для вас черновик документа.
Затем вы идёте в стороннюю независимую программу или сервис, просматриваете там черновик, и подписываете его. Контрагенту отправляете уже подписанный документ — и он независимым от вас способом удостоверяется, что вы тоже не внесли никаких внезапностей в черновик.
Ключ к успеху — то, что не контрагент от вашего имени отправляет документ на подписание, и уж тем более он не работает с вашей подписью.
Независимая программа или сервис не заинтересована в том, чтобы что-то там подменять на ходу. Она работает не в интересах конкретного контрагента, а в интересах "экосистемы".

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Где-нибудь реализована система подписывания, позволяющая максимально контролировать процесс и результат доверенными/проверенными средствами?

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

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

В этой конструкции, кстати, отпадает потребность в веб-бухгалтерии. Учет вполне можно вести локальными инструментами.

Здравствуйте, Слава, Вы писали:

С>Чувствую я, что не доверяете вы государственным органам. Может быть, вы и в вакцину не верите? (которые вакцины обычно 10-15 лет делались, а тут меньше чем за год что-то сварили и всем впаривают)

Я даже компилятору не доверяю, не то, что государственным органам. Компилятор, по крайней мере, нельзя подкупить, он если и лажает, так вполне искренне.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Если в форме для подписания документа появятся его дайджест и кнопка "Сохранить",

...то тебе точно так же придется поверить, что подписан именно тот документ, дайджест которого появился в форме. Форма подачии информации на экран компьютера никак не влияет на процесс подписи.

Только аппаратное устройство для подписи со своим экраном, на котором будет отображаться подписываемый документ, и своей кнопкой "подписать", избавит от необходимости доверять компьютерному ПО.

Здравствуйте, vsb, Вы писали:

vsb>т.е. при желании человек может посмотреть конкретный условно читаемый документ, который он подписывает.

Что мешает показать пользователю один документ, а подписать другой, кроме отсутствия мотивации это делать?

vsb>Вот, кстати, это был бы хороший функционал для браузера — сохранять весь трафик с сервером в криптографически-верифицируемые файлы. Но не видел такого. Идея для стартапа (:

Идея для стартапа: сделать универсальную подписывалку, работающую отдельно от сайтов, генерирующих подписываемый контент, и несущую юридическую ответственность за последствия.

Даже понятно, как продавать: надо создать ситуацию, когда пользователь подписал не то, что он думал, что подписывает, и через то пострадал. И поднять по поводу этой ситуации много шума. После чего — собирать удои с напуганных параноиков.

Здравствуйте, Pzz, Вы писали:

vsb>>т.е. при желании человек может посмотреть конкретный условно читаемый документ, который он подписывает.

Pzz>Что мешает показать пользователю один документ, а подписать другой, кроме отсутствия мотивации это делать?

Теоретически помешает криптотокен, который будет требовать нажатия кнопки на каждое подписывание. Практически — такого не видел у нас.

vsb>>Вот, кстати, это был бы хороший функционал для браузера — сохранять весь трафик с сервером в криптографически-верифицируемые файлы. Но не видел такого. Идея для стартапа (:

Pzz>Идея для стартапа: сделать универсальную подписывалку, работающую отдельно от сайтов, генерирующих подписываемый контент, и несущую юридическую ответственность за последствия.

Вот кстати хотел сделать. Но остановило то, что 99% юзеров даже не объяснить, зачем это делать. А оставшихся 1% не обьяснить зачем платить за такое. По крайней мере в Казахстане. В России может что и выйдет.

Pzz>Даже понятно, как продавать: надо создать ситуацию, когда пользователь подписал не то, что он думал, что подписывает, и через то пострадал. И поднять по поводу этой ситуации много шума. После чего — собирать удои с напуганных параноиков.

Здравствуйте, Pzz, Вы писали:

ЕМ>>Где-нибудь реализована система подписывания, позволяющая максимально контролировать процесс и результат доверенными/проверенными средствами?

Pzz>Я не понимаю, как она вообще может быть реализована нелокально. Т.е., веб-бухгалтерия должна позволять скачать готовых документ для подписи, потом он подписывается локальными инструментами, и подписаный документ закачивается для отправки (или отправляется посредством любого другого транспорта). Сертификат при этом хранится у пользователя, в виде файла или USB-устройства.

Закачивать обратно достаточно только подпись. Документ скачивается целиком, да — чтобы пересмотреть его и затем подсчитать его контрольную сумму по локальной проверенной копии, но потом эта сумма шифруется и передаётся. Перекомпоновать такой контейнер из документа (подменив) и его подписи любой может, но подпись не сойдётся, поэтому закачивать обратно уже не нужно.

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

Здравствуйте, sfsoft, Вы писали:

S>Суровость российских законов ... (с)

S>Есть такая система, ГИС ЖКХ.

А мне больше нравится пример с фирмами и бухгалтером.
Многие отчеты руководитель должен подписать только лично — своей эцп к примеру. Часто недостаточно выдать доверенность на это буху, т.е.
доки подписанные эцп бухгалтера завертываются.
Понятно, что каждый отчет подписывать руководителю муторно.
Какой делается выход — правильно эцп руководителя копируется на комп бухгалтеру, который подписывает и отправляет отчеты.
То что бухгалтер не использует эцп для взятия кредитов и прочего — это чисто его добрая воля.