Comments 35
Можно проверить файл в Acrobat Reader ВС (установив и настроив плагин от КриптоПРО). Также есть несколько сайтов на которых можно бесплатно проверить ЭП в документе, так что независимая проверка обеспечена
И даже подменять файлики нельзя. То есть показать одно а подписать другое нельзя.
И где тут идёт подмена файлов?
Берём PDF добавляем в него контейнер, считаем хеш и отправляем на подпись пользователю, пользователь присылает подпись, мы ее вставляем в этот же самый PDF.
Где подмена?
Есть несколько типовых сценариев подписи pdf:
1. С сервера прилетает файл. Показывается на клиенте. По кнопке Подписать считаем хеш и подписываем.
2. С сервера прилетаем файл. Показываем его. По кнопке Подписать запрашиваем хеш с сервера и подписываем.
3. С сервера прилетает некое изображение документа. По кнопке Подписать запрашиваем хеш и подписываем.
4. По кнопке Подписать запрашиваем хеш и подписываем.
Сценарии идут в порядке понижения законности.
Первый абсолютно законен.
Второй относительно законен, но не имеет смысла. Хеш посчитать быстрее чем отрендерить документ.
Третий незаконен, но иногда бывает. Телефоны плохо дружат с большими файлами. Все выкручиваются как могут.
Четвертый абсолютно незаконен.
У вас статья о четвертом сценарии.
В процессе решения задачу решили усложнить для нас, и уменьшить объем передаваемых данных на клиент. Передавать только hash документа, но не сам документ.
Не надо так делать.
Мы же не в «тёмную» ему хеш отправляем
Ну и, конечно, ссылочку на правовой документ было бы неплохо увидеть
Значит ли это, что если есть решение по варианту 4, но со ссылкой, то это законно?
Если это не законно, то как многие организации (в том числе банки) показывают, например, соглашение о персональных данных или лицензионное соглашение в виде ссылки? Ведь тогда тоже пользователь соглашается с тем, что может не видеть в момент соглашения?
"Может" тут не работает.
Вы даете хеш в темную. Что там за документ подписывается, да черт его знает. Он даже не передается на устройство пользователя. Вот вам циферка. Подпишите ее.
Ссылочку как уже и писал не дам. Я далек от юристов. А это их вопрос. Я только вывод знаю.
Хеш на то и хеш, что по нему можно однозначно определить, соответствует ли он файлу F или нет. Мы даём пользователю доступ к файлу F и отдельно загружаем с сервера хеш X(F). В чем отличие от того, что мы загружаем файл и на стороне клиента вычисляем X(F)? Если подозревать, что сервер сделал хеш другого файла, то это легко может быть проверено… В любом случае А) проведенное автором решение не теряет своей ценности, и с доработками интересно и для случая расчета хеша на стороне клиента: Б) вывод ваших юристов не понял совсем… Если они говорят, что нельзя дать документ на подпись, не представляя к нему доступ, — понятно, без вопросов. Но если речь только о том в каком режиме доступ к файлу организовать — совсем не понятно. Так можно говорить, что пусть файл и скачали мне на сторону клиента для подписи, но я все равно его не выгружал и не открывал документ — значит подписал вслепую и документ не действителен.
Есть файл. Есть хеш и стороны могут доказать, что это хеш файла, есть подпись и стороны могут доказать, что подпись хеша. Файл был доступен контрагенту до подписания. Где слабое звено?
Клиент должен доверять софту. Софт должен заботиться о безопасности. Это все по умолчанию.
Я именно про тонкости организации самого процесса. Про подробности я говорить не готов, не в курсе. Допускаю что юристы просто перестраховались. Маловероятно, но возможно.
Решение само по себе вполне типичное. Проблема только во внедренной ГОСТовой подписи. Весь типовой софт будет ругаться на эти подписи. Но с этим ничего не сделать.
Насколько понимаю пока нет достаточной правоприменительной практики по ЭП.
Меня вообще бесит текущая (года 2 назад точно) ситуация. А вам для чего ЭПЦ нужна? Вот для такого портала такая, а для такого другая.
хэш подменили
И я так и не понял, как в браузере не дать пользователю выбрать не ГОСТ-овский токен
Могу сказать, что это было не очень просто, но в итоге заработало как надо.
вставляем подпись в документ
Отсоединную подпись могут и потерять. И что это такое "зачем мне это файл" многие не понимают. Во всяком случае ФНС использует встроенные
При этом предыдущие подписи должны оставаться валидными.
А что бывает по-другому? Странно.
При отсоединенных подписях проблем нет — каждая новая подпись — независимый файл, никак не влияющий на исходный.
Со встроенной прописью в момент нанесения второй файл технически отличается — в него уже добавлена первая подпись + визуализация этой
для каждого алгоритма определен 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
Про 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 в синхронном
Подписание PDF на JS и вставка подписи на C#, используя Крипто ПРО