Как стать автором
Обновить

Комментарии 35

НЛО прилетело и опубликовало эту надпись здесь
Есть немного кода, который я из статьи убрал, там генерируется видимая подпись. У нас она выглядит как прямоугольная печать. Различные PDF-просмотровщики позволяют так же проверить подпись. Но с ГОСТ всё сложно, нужны плагины
Наличие «видимой подписи» как раз ничего не доказывает юридически. Это картинка, которую может кто угодно нафотошопить. Доказательством подписания документа является прохождение проверки ЭП в нем сертифицированной (кажется ФСБ) программой.

Можно проверить файл в Acrobat Reader ВС (установив и настроив плагин от КриптоПРО). Также есть несколько сайтов на которых можно бесплатно проверить ЭП в документе, так что независимая проверка обеспечена
НЛО прилетело и опубликовало эту надпись здесь

А как с обычной подпись на бумаге? Вы отдаете документ и третье лицо само разбирает есть ли, чья подпись. В случае ЭП ему (третьему лицу) много проще — они может проверить кто именно подписал

Вы в курсе что это все абсолютно незаконно? Нельзя подписывать ЭПЦ пользователя то что пользователь не видит.
И даже подменять файлики нельзя. То есть показать одно а подписать другое нельзя.
Можно подробнее насчёт показать одно, а подписать другое. Где вы такое усмотрели?
И где тут идёт подмена файлов?
Берём PDF добавляем в него контейнер, считаем хеш и отправляем на подпись пользователю, пользователь присылает подпись, мы ее вставляем в этот же самый PDF.
Где подмена?
Есть закон. Ссылку не дам, но формулируется так: «Пользователь может подписать только тот документ который он видит.»

Есть несколько типовых сценариев подписи pdf:
1. С сервера прилетает файл. Показывается на клиенте. По кнопке Подписать считаем хеш и подписываем.
2. С сервера прилетаем файл. Показываем его. По кнопке Подписать запрашиваем хеш с сервера и подписываем.
3. С сервера прилетает некое изображение документа. По кнопке Подписать запрашиваем хеш и подписываем.
4. По кнопке Подписать запрашиваем хеш и подписываем.

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

У вас статья о четвертом сценарии.
В процессе решения задачу решили усложнить для нас, и уменьшить объем передаваемых данных на клиент. Передавать только hash документа, но не сам документ.

Не надо так делать.
До и после подписания юзер может выгрузить файл и посмотреть его
Мы же не в «тёмную» ему хеш отправляем
Ну и, конечно, ссылочку на правовой документ было бы неплохо увидеть
Если пользователь может выгрузить файл до подписания «as is», значит он технически может рассчитать на своей машине хеш и убедиться при помощи «независимых решений», что он подписал строго тот файл, который скачал.
Значит ли это, что если есть решение по варианту 4, но со ссылкой, то это законно?

Если это не законно, то как многие организации (в том числе банки) показывают, например, соглашение о персональных данных или лицензионное соглашение в виде ссылки? Ведь тогда тоже пользователь соглашается с тем, что может не видеть в момент соглашения?

Да и вообще почти все вне общения с государством используют не ГОСТ подпись. Много чего работает, пока юристы к этому прикапываться не начнут.


У тс гост подпись. Значит государство очень рядом. И надо соответствовать.

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


Ссылочку как уже и писал не дам. Я далек от юристов. А это их вопрос. Я только вывод знаю.

Хеш на то и хеш, что по нему можно однозначно определить, соответствует ли он файлу F или нет. Мы даём пользователю доступ к файлу F и отдельно загружаем с сервера хеш X(F). В чем отличие от того, что мы загружаем файл и на стороне клиента вычисляем X(F)? Если подозревать, что сервер сделал хеш другого файла, то это легко может быть проверено… В любом случае А) проведенное автором решение не теряет своей ценности, и с доработками интересно и для случая расчета хеша на стороне клиента: Б) вывод ваших юристов не понял совсем… Если они говорят, что нельзя дать документ на подпись, не представляя к нему доступ, — понятно, без вопросов. Но если речь только о том в каком режиме доступ к файлу организовать — совсем не понятно. Так можно говорить, что пусть файл и скачали мне на сторону клиента для подписи, но я все равно его не выгружал и не открывал документ — значит подписал вслепую и документ не действителен.
Есть файл. Есть хеш и стороны могут доказать, что это хеш файла, есть подпись и стороны могут доказать, что подпись хеша. Файл был доступен контрагенту до подписания. Где слабое звено?

Я не про подмену хеша говорю. Ее организовать можно в любом случае. Для клиента нет адекватного способа проверить до подписания что именно он подписывает.
Клиент должен доверять софту. Софт должен заботиться о безопасности. Это все по умолчанию.

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

Решение само по себе вполне типичное. Проблема только во внедренной ГОСТовой подписи. Весь типовой софт будет ругаться на эти подписи. Но с этим ничего не сделать.
Пообщались с нашим юристом, он сказал что всё хорошо.
Насколько понимаю пока нет достаточной правоприменительной практики по ЭП.
Я вообще не понимаю что там почему и как с юридической стороны. Есть сомнения спрашиваю. Делаю как скажут. Если этот вопрос еще раз возникнет уточню еще раз обязательно.

Меня вообще бесит текущая (года 2 назад точно) ситуация. А вам для чего ЭПЦ нужна? Вот для такого портала такая, а для такого другая.
У нас двусторонне подписание между госом и физиком или юриком

хэш подменили

Да, конечно. Только вопрос цены
Как все просто выглядит. Я реализовывал подпись документов docx на фронтенде, написанном на питоне — вот там была жесть. Хеш посчитай, xml нормализуй, хеш отзеркалируй и т.п. И самое гнусное — нигде нет нормальной документации для этого действа.
И я так и не понял, как в браузере не дать пользователю выбрать не ГОСТ-овский токен
простой фильтрацией certAlgorithmFriendlyName.match ГОСТ или GOST насколько я понял имя зависит от языкового пакета Windows или что там установлено на клиенте
Выглядит просто, но собрать это всё вместе чтоб работало… команда работала, искала материалы, по крупицам собирала информацию в доступных источниках.
Могу сказать, что это было не очень просто, но в итоге заработало как надо.
подписывать файл присоединенной подписью мало смысла, пк на котром откроют пдф будет говорить об ошибке сертификата, так как почти ни у кого нет крипто про и рлагина. Отсоединенную сразу ругать не будет и можно в сопровожиловке отправить за проверкой на госуслуги
Так тут речь о встреченной подписи:
вставляем подпись в документ
да, подпись вставляем прямо в PDF
хм… у нас предполагается двусторонее подписание. Слишком сложно все эти подписи за собой таскать, да и как простому пользователю объяснить, что вот этот файлик и есть твоя подпись. А вот когда в PDF-нике есть фиолетовая печать с ФИО это всем понятно

Отсоединную подпись могут и потерять. И что это такое "зачем мне это файл" многие не понимают. Во всяком случае ФНС использует встроенные

При этом предыдущие подписи должны оставаться валидными.

А что бывает по-другому? Странно.

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

Встроенные позволяют подписывать уже подписанный документ. С отсоединенными такое провернуть сложно. Так чтобы первая подпись затеряться где-нибудь потом не смогла.
О преимуществах встроенной подписи не спорю.
Коллега спрашивал «бывает ли чтобы 2 подпись делала первую невалидной» — с кривыми руками при работе со встроенными подписями — легко. Это не отменяет принципиальных плюсов встроенных
А чем отличается такая подпись от подписи c простым OpenSSL?
для информации:
для каждого алгоритма определен OID
cpdn.cryptopro.ru/content/csp40/html/group___pro_c_s_p_ex_DP8.html

algo = yield pubKey.Algorithm;
algvalue=yield algo.Value;
if (algvalue===«1.2.643.7.1.1.1.1»)
hashAlg=cadesplugin.CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2012_256;

еще могут возникнуть проблемы если на клиенте старый плагин или браузер, поэтому желательно проверить
var canPromise = !!window.Promise;
var canAsync = !!cadesplugin.CreateObjectAsync;

описано здесь cpdn.cryptopro.ru/content/cades/plugin-activation.html
За Oid большое спасибо, поправим. Это действительно более правильный способ. Сделал через строку, т.к. не знал как получить Oid на клиенте.

Про Promise в начале статьи писал, что для IE пришлось реализовывать отдельный скрипт и делать так
$(function() {
    try {
        eval("(function *(){})");
        window.generatorSupported = true;
    } catch (err) {
        window.generatorSupported = false;
    }

    let scriptUrl;
    if (generatorSupported) {
        scriptUrl = "/Scripts/cryptography.js?v=2.24.0";
    } else {
        scriptUrl = "/Scripts/cryptography_ie.js?v=2.24.0";
    }
    $.ajax({
        dataType: "script",
        cache: true,
        url: scriptUrl,
        success: window.fillCryptographyObjectParams,
    });
});


И соответственно в cryptography.js работа в асинхронном режиме, а в cryptography_ie в синхронном
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории