#cryptography #certificate #digital-signature #digital-certificate
#криптография #сертификат #цифровая подпись #цифровой сертификат
Вопрос:
Представьте веб-приложение, которое позволяет вам подписывать документы в цифровой форме (с помощью персональных цифровых сертификатов pkcs12, выпущенных доверенными центрами сертификации) и помечать документы в формате PDF с помощью Java-апплета или Active X. Очевидно, что это должно произойти на компьютере пользователя, потому что закрытый ключ сертификата хранится локально.
Итак, как только PDF подписан и помечен временем, он загружается на сервер. Имеет ли загруженный файл те же функции, что и созданный локально? Есть ли смысл говорить об «исходной версии файла»?
Я немного смущен этим.
Исправление: я имею в виду цифровую подпись документа закрытым ключом персонального цифрового сертификата (должен быть pkcs7, pkcs12), чтобы убедиться, что он действительно был подписан кем-то, а не кем-то другим.
Комментарии:
1. Юридическая проблема, безусловно, зависит от законов вашей юрисдикции. И я не уверен, что это хорошая тема для обсуждения здесь.
2. это не все о юридической действительности: «Имеет ли загруженный файл те же функции, что и созданный локально?» и «Имеет ли смысл говорить об «исходной версии файла?» вопросы, которые меня больше интересуют, отредактируют заголовок.
3. @nemesisdesign Считается ли загруженный документ оригиналом для юридических целей, зависит от местного законодательства. Вам следует проконсультироваться с юристом: Stack Exchange не заменяет юридическую консультацию, подобную этой.
4. заголовок отредактирован. Вопрос сейчас не в юридической силе. Пожалуйста, предложите что-нибудь, если вы знаете ответ.
5. @nemesisdesign считается ли что-либо исходным файлом, полностью зависит от контекста. Вы можете скрыть тот факт, что у вас есть юридическая мотивация, но вы просите людей интерпретировать слово без какой-либо системы отсчета. Это абсолютно неопровержимо.
Ответ №1:
Если под «исходной версией файла» вы подразумеваете, что вы намерены «заморозить» документ, чтобы никто никогда не мог вносить в него изменения снова — это невозможно и не является целью цифровой подписи. Любой может просто «вырезать» подпись, встроенную в документ, никто не заметит.
Защита документа от последующих изменений включает в себя какой-то механизм DRM. Например, «водяные знаки», включающие стеганографию, используются для защиты фотографий, чтобы никто не мог заявить права собственности на фотографию, даже после ее изменения. Но технология еще не очень развита, большинство алгоритмов можно легко взломать.
Это означает, что понятие «исходная версия файла», скажем, в судебном споре, является чем-то, что вовлеченные стороны должны согласовать в согласии. Невозможно доказать происхождение без согласия или доверенной третьей стороны, которая подтвердит целостность документа, например, если у них есть независимая копия документа.
Кроме того, загрузка файла не должна изменять его содержимое. Файл будет иметь те же свойства, что и локальный, включая подпись, которая была добавлена на стороне клиента.
Подпись будет только подтверждать подлинность и целостность документа. Если для вашего приложения жизненно важно иметь возможность определить, что полученный подписанный документ на самом деле является ожидаемым, я бы посоветовал вам сделать следующее:
- Создайте PDF на сервере
- Создайте хэш документа (тот же алгоритм, который будет использоваться апплетом подписи)
- Отправьте PDF-файл клиенту
- Позвольте клиенту подписать его и отправить обратно
- Сравните хэш клиента с ранее вычисленным на сервере
- Подтвердите подпись
Проверка подписи обеспечит целостность и аутентичность, сравнение хэшей гарантирует вам, что подписанный документ, который вы получили на сервере, действительно является подписанной версией исходного документа, ранее созданного.
Что касается временных меток с использованием локальных часов: они бесполезны, их очень легко обмануть. То, что вы на самом деле должны использовать, — это криптографически защищенные временные метки, совместимые с RFC 3161, выпущенные доверенной третьей стороной. В настоящее время это единственный надежный способ включить понятие времени в подписи PDF. Для этого также есть встроенная поддержка, например, в Adobe Reader. Поскольку эти услуги, как правило, недоступны бесплатно, имело бы смысл добавить такую временную метку на сервер после получения подписанного документа. Они добавляются как неподписанный атрибут в подпись CMS (Adobe все еще говорит о PKCS7), поэтому он не нарушает подпись и может быть безопасно добавлен после создания подписи.
Ответ №2:
Хорошо, давайте попробуем ответить на ваш вопрос (насколько я понимаю).
У вас есть какое-то программное обеспечение, которое использует некоторый закрытый ключ (и часы) для добавления подписи к файлу.
Эта подпись зависит от содержимого файла и, таким образом, гарантирует, что подписывающий знал (или мог знать) содержимое файла в момент его подписания. (Есть несколько способов получить «слепые подписи», но я предполагаю, что здесь это не так.)
Загрузка подписанного файла в любом месте здесь ничего не меняет.
О временной метке: владелец ключа может ввести любую временную метку, которую он хочет, — так что это помогает только в том случае, если вы хотите доказать знание документа в какой-то момент времени против владельца ключа, а не если вы являетесь владельцем ключа и хотите доказать, что вы подписали в какой-то момент времени, а не раньше или позже. (Кроме того, вы уверены, что его часы не искажены?)
О том, имеет ли это юридическое значение, вам придется спросить своего адвоката. Это может зависеть от
- юрисдикция, в которой произошла подпись, и та, в которой вы хотите, чтобы подписанный документ был действительным
- имел ли владелец ключа возможность фактически прочитать документ перед подписанием
- действительно ли у владельца ключа был выбор подписи или нет.
Если вы используете какой-либо апплет или элемент управления ActiveX в браузере пользователя, я бы не был полностью уверен, что последние два пункта действительно выполняются.