Цифровая подпись PDF документов - PullRequest
0 голосов
/ 21 октября 2019

Обновление 2:

Я загрузил образец в https://1drv.ms/u/s!Al69FgQ8jwmZbgiBMXLLM4j5sbU?e=vyGF4m

Можете ли вы проверить. Я застрял на последнем шаге. Тем не менее, пожалуйста, подтвердите, если другие оценки верны.

Обновление 1:

Я подтвердил поток. Так что я в этом уверен.

В рамках этого потока документов с цифровой подписью в формате PDF мы хотим использовать стороннее оборудование для предоставления подписанного хэша PDF. Вот шаги:

  1. Существует сторонняя внутренняя система, которая будет генерировать PDF-документ из слова.
  2. Этот PDF будет отправлен в другой сервис, который сгенерирует хэш-значение этого PDF
  3. Это значение хеша будет отправлено внешней службе, чтобы спеть хеш с закрытым ключом.
  4. внешняя система отправит подписанный хэш и сертификат открытого ключа, с помощью которого внутренняя служба добавит подпись в документ PDF.

У меня есть следующие вопросы.

  1. В пункте 1 выше внутренняя служба создает PDF вместе с блоком подписи. Нужно ли создавать блок подписи? как это откладывается подписание?
  2. Если это так, как служба в пункте 2 может получить исходное содержимое документа PDF для генерации хеша.

мы использовали существующий PDF, имеющий подпись ииспользуя iText 7, чтобы получить оригинальный контент. Этот метод правильный? FormB.PDF имеет подпись, и, удаляя поле signaure1, мы получаем оригинальный контент. Будет ли этот процесс работать и рекомендуется ли это?

Мы также пытались использовать метод pdfsigner.getRangeStream (), но он не совсем понятен в документации и пока неясен. Пожалуйста, помогите

package com.abc.sd;

import java.io.IOException;
import java.security.NoSuchAlgorithmException;
import java.util.List;

import com.itextpdf.forms.PdfAcroForm;
import com.itextpdf.kernel.pdf.PdfDocument;
import com.itextpdf.kernel.pdf.PdfReader;
import com.itextpdf.kernel.pdf.PdfWriter;
import com.itextpdf.signatures.SignatureUtil;

public class ItextPdf7 {

    public static void main(String [] args) throws IOException, NoSuchAlgorithmException {
        String filePath ="C:\\\\abc\\\\test\\\\FormB.pdf";
        PdfReader reader = new PdfReader(filePath);
        PdfDocument pdfDoc = new PdfDocument(reader);
        PdfAcroForm form = PdfAcroForm.getAcroForm(pdfDoc, false);
        SignatureUtil signUtil = new SignatureUtil(pdfDoc);
        List<String> names = signUtil.getSignatureNames();
        System.out.println("Signature Name>>>"+names);
      //  System.out.println("Singature Data>>"+signUtil.readSignatureData("Signature1"));


        PdfReader reader1 = new PdfReader(filePath);
        PdfDocument pdfDoc1 = new PdfDocument(reader1, new PdfWriter("C:\\\\\\\\abc\\\\\\\\test\\\\\\\\unsigned_latest_iext7.pdf"));
        PdfAcroForm form1 = PdfAcroForm.getAcroForm(pdfDoc1, true);
        form1.flattenFields();
        pdfDoc1.close();


    }

}

******************************

Мы ищем подписать PDF документ . Вот шаги, насколько я понимаю.

  1. Потребитель отправит дайджест документа PDF в Центральную систему. Дайджест PDF исключит раздел подписи

  2. Центральная система отправит дайджест (подписанный с использованием закрытого ключа / открытого ключа потребителя? Не уверен) потребителю

  3. потребительская система добавит дайджест в раздел подписи PDF-документа (может быть вместе с открытым ключом ??)

Не могли бы вы помочь в следующем.

  1. Если мое понимание верно с вышеупомянутым потоком? Поможет любое небольшое справочное руководство / ссылка или любая блок-схема.

  2. С .Net и Java, какие библиотеки могут выполнять эту работу? И с открытым исходным кодом, и с платной. Будет ли здесь актуален iTextSharp?

  3. Как будет проходить проверка, если клиент откроет PDF? Если есть какие-либо конкретные действия, необходимые для подписания документа?

Plz help.

1 Ответ

1 голос
/ 11 ноября 2019

Здесь очень много аспектов и подвопросов, как в тексте вопроса, так и в комментариях к нему. Этот ответ освещает, но некоторые из них после первого представления некоторых фонов.

Некоторые фоны

Встроенная подпись PDF подразумевает наличие ряда структур в PDF:

  • Поле формы подписи AcroForm. Это поле формы может иметь аннотацию виджета (визуализацию, которая может содержать любую информацию, которую вы хотите вставить в нее), но не обязательно иметь ее.

  • Значение в этой форме подписиполе. В отличие от других полей формы, значение поля подписи - это не просто строка, а словарь пар ключ-значение. Содержание зависит от типа подписи. В случае взаимодействующих типов, тем не менее, всегда есть запись Contents , значение которой является двоичной строкой, содержащей фактическую подпись PKCS1 / PKCS7 / CMS / RFC3161 или отметку времени, которая охватывает весь файл, кроме этой двоичной строки.

    PDF signature sketch

    (Эскиз немного вводит в заблуждение: разделители шестнадцатеричных строк '<' и '>' являются , а не частьподписанных данных.)

  • В случае типа adbe.x509.rsa_sha1 запись Contents содержит подпись PKCS1. Словарь значения подписи дополнительно должен содержать запись Cert , содержащую сертификат подписи.

  • В случае типа ETSI.RFC3161 Содержимое Запись содержит маркер времени RFC 3161.

  • Для типов ETSI.CAdES.detached , adbe.pkcs7.detached и adbe.pkcs7.sha1 запись Contents содержит контейнер подписи CMS. Поскольку контейнер подписи может содержать сертификат подписи, нет необходимости в записи Cert для сертификата подписи.

    Контейнер подписи CMS может содержать структуру «подписанных атрибутов». Если это так, один из этих атрибутов должен быть хэшем подписанных байтов PDF (см. Выше, всего, кроме Contents value ) и фактические байты подписи, заключенные в контейнер, подписывают этиподписанные атрибуты. Разрешен ли вариант без подписанных атрибутов и какие атрибуты требуются дополнительно, зависит от точного типа подписи.

  • В случае ETSI.CAdES.detached контейнер CMS должен содержать подписанные атрибуты. Кроме того, один из подписанных атрибутов должен быть атрибутом подписи-сертификата ESS или подписи-сертификата-v2, ссылающимся на сертификат подписавшего.

    Информация о LTV в этом случае может быть добавлена ​​позже в пошаговом режиме. при обновлении до PDF они не должны присутствовать в подписанном PDF.

  • В случае adbe.pkcs7.detached и adbe.pkcs7.sha1 там вообще не нужно подписывать атрибуты. Тем не менее, в зависимости от точной политики подписания (предписанной законом или договором), тем не менее, могут потребоваться подписанные атрибуты и, в частности, подписанный атрибут сертификата подписи ESS.

    Эти типы подписей уже определены в ISO 32000-1. Если политика подписи основана только на ISO 32000-1, информация о LTV должна храниться в атрибуте adbe-revocationInfoArchival, который должен быть атрибутом со знаком.

Требуется ли сертификат подписи перед подписанием?

В комментариях вы ссылаетесь на электронную книгу iText «PDF и цифровые подписи», в которой, как представляется, сказано, что достаточно получить сертификат подписи вместе с подписью.

В свете объясненных предпосылоквыше, однако, мы понимаем, что

  • В случае adbe.x509.rsa_sha1 подписей, сертификат подписи должен быть в значении Cert словаря словаря значений подписи. Поскольку эта запись отсутствует в записи Contents , этот сертификат является частью подписанных данных. Таким образом, он должен быть известен до подписания.

  • В случае ETSI.CAdES.detached подписанные атрибуты должны содержать ESSАтрибут подписи-сертификата или подписи-сертификата-v2. Этот атрибут ссылается на сертификат подписавшего. Таким образом, он должен быть известен до подписания.

  • В случае adbe.pkcs7.detached и adbe.pkcs7.sha1 это зависит от фактической политики подписи, которой нужно придерживаться, требуется ли атрибут подписи-сертификата ESS или подписи-сертификата-v2. Таким образом, это зависит от того, должен ли сертификат подписи быть известен до подписания.

    В случае политики подписи, основанной только на ISO 32000-1, информация LTV должна храниться в подписанном атрибуте, если ввсе, и для получения информации LTV, очевидно, нужно знать сертификаты, для которых они пытаются получить их, в частности сертификат подписавшего.

Чтобы ответить на вопрос в заголовке этой темы,поэтому: только в контексте слабой политики подписи вы можете избежать знания неизвестного сертификата перед подписанием, если вам не нужно добавлять информацию LTV.

А в случае подписей PAdES?

В комментарии вы упоминаете, что необходимо использовать PAdES и LTV . Значит ли это, что вам нужен сертификат подписавшего перед подписанием?

Ну, это зависит.

Если с использованием PAdES означает использование базовых профилей PAdES или расширенных профилей PAdES (BES / EPES), вам необходимо создать ETSI.CAdES.detached подписи. Таким образом, вам нужно сертификат подписывающего лица перед подписанием.

Но если для этого требуется только профиль PAdES для цифровых подписей CMS в PDF (по сути, профиль совместимости ISO 32000-1), вы не нужно сертификат подписывающего лица перед подписанием.

Но этот профиль, в частности, подразумевает: Если он присутствует, любая информация об отзыве должна быть подписанным атрибутом подписи PDF. Таким образом, для «PAdES и LTV» вам снова нужно сертификат подписывающего лица перед подписанием.

...