Привет! Я сотрудник Альфа-Банка и занимаюсь разработкой программного обеспечения со встроенными средствами криптографической защиты информации.
В данной статье хочу рассказать о следующих вещах:
- преимуществах формата PDF в качестве документа с электронной подписью;
- платформе Java, библиотеке itextpdf и СКЗИ КриптоПро CSP, как инструментах подписи;
- о том, с какими трудностями пришлось столкнуться, о доработке itextpdf;
- привести пример кода, выполняющего несколько подписей;
- поговорить о целесообразности использования формата PDF в качестве документа с подписью.
В современном информационном мире значимость электронной подписи и предоставляемых ею основных сервисов (целостность данных, и неотрекаемость авторства) сложно переоценить. Государственные органы, физические и юридические лица широко применяют электронную подпись в потоках обмена информацией между собой.
Согласно законодательству, электронная подпись может придать документам юридическую силу, равную по значимости бумажному носителю, подписанному собственноручной подписью и скрепленного печатью правомочного лица.
Преимущества PDF
В качестве контейнера для хранения разнообразной информации в дружественном для человека представлении формат PDF по праву завоевал свою популярность. Его получится открыть в любой ОС. Документ PDF может содержать не только текстовые и табличные данные, но и аудио и видеозаписи, инженерную графику, трехмерные модели. Для дополнительной обработки PDF-документов в данный формат включен такой мощный инструмент как поддержка JavaScript для изменения содержимого в формах и полях по наступлению какого-то события или выполнению действия пользователя.
Инструменты Adobe Systems (разработчика формата PDF) поддерживают использование электронной подписи. В отличие от сообщений с присоединенной усиленной электронной подписью стандарта PKCS#7 и его усовершенствования CAdES, для просмотра документа PDF с подписью не требуется дополнительное специальное ПО. Кроме криптографического провайдера, который требуется во всех случаях.
Т.е. инструменты Adobe позволяют визуализировать электронную подпись в документе.
При подписании документа PDF можно задать параметры визуализации, указать номер страницы, размер блока с подписью, имя поля, куда ее поместить, добавить графическое изображение, например, логотип компании, скан собственноручной подписи руководителя и печати организации.
При просмотре таких документов, кроме визуализации в теле документа, программы Acrobat и Adobe Reader отображают вкладку «Подписи» с сопутствующей информацией: значок, показывающий статус проверки подписи, сведения о том, был ли изменен документ, результат проверки сертификата открытого ключа, время последней проверки, страницу и поле, содержащие электронную подпись.
Инструменты подписи
Использовалась версия Java: «1.8.0_111» HotSpot(TM) 64-Bit Server VM (build 25.111-b14).
В качестве сертифицированного средства защиты информации от лицензированного разработчика применяем криптографический провайдер КриптоПро CSP v4.0 и КриптоПро JCP – v.2.0, с установкой модуля КриптоПро Java CSP v.4.0
Почему КриптоПро JCP – v.2.0, с модулем КриптоПро Java CSP v.4.0?
Потому, что провайдер КриптоПро JCP после длительного несертифицированного периода получил сертификат соответствия от регулятора до 31.12.2018, а дальше, по информации от разработчика, с сертификацией может вновь возникнуть неопределенность. Модуль КриптоПро Java CSP v.4.0 не выполняет в себе криптографических преобразований и является по сути API к провайдеру КриптоПро CSP, с очередной сертификацией которого вопросов нет. Здесь нужно сказать, что действующий сертификат на СКЗИ не обязателен при условии использования криптографического провайдера исключительно для внутренних целей.
В соответствии со спецификацией Java Cryptography Architecture (JCA), в своем приложении я указываю и использую функции криптографического провайдера: JCSP. После установки КриптоПро, данный провайдер отображается в списке всех доступных в файле ../java/jdk1.8.x_xxx/jre/lib/security/java.security, где можно настраивать, который из них предпочтительнее для использования по умолчанию, если явно не указано в приложении:
#
# List of providers and their preference orders (see above):
#
security.provider.1=ru.CryptoPro.JCSP.JCSPНе забываем, что должны быть сняты экспортные ограничения платформы Java, которые блокируют работу криптографических провайдеров с российскими алгоритмами шифрования.
Для этого в ../java/jdk1.8.x_xxx/jre/lib/security необходимо заменить файлы local_policy.jar и US_export_policy.jar на предоставленные по адресу: Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 Download
и содержащие в default_local.policy и default_US_export.policy:
grant {
// There is no restriction to any algorithms.
permission javax.crypto.CryptoAllPermission;
};
Применение библиотеки iText itextpdf.com для работы с PDF документами на Java было продиктовано провайдером КриптоПро.
В составе КриптоПро JCP поставляется файл Git patch для библиотеки iTextpdf версии 5.1.3 —
jcp-2.0.xxxxx\Doc\itextpdf\ itextpdf_5.1.3.gost.user.patch
Патч адаптирует itextpdf к работе с провайдером КриптоПро. Необходимо скачать исходный код библиотеки версии 5.1.3, затем с помощью командной строки Bash системы управления версиями Git применить патч: git apply --stat itextpdf_5.1.3.gost.user.patch
Далее нужно собрать полученную библиотеку из обновленного исходного кода и подключить к приложению.
В составе КриптоПро JCP можно найти много примеров в файле samples-sources.jar. В частности, там есть примеры подписи и проверки ЭП PDF-документов. (\PDF\SignVerifyPDFExample.java).
Проблемы и трудности сборки
После успешного обновления исходного кода itextpdf в нем появляются зависимости на пакеты ru.CryptoPro.JCP и ru.CryptoPro.reprov.x509.
Без них проект с исходным кодом itextpdf_5.1.3.gost не соберется.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project itextpdf: Compilation failure: Compilation failure:
[ERROR] \github\iTextpdf_5.1.3_patched_cryptopro_bc1.50\src\main\java\com\itextpdf\text\pdf\PdfPKCS7.java:[138,23] error: package ru.CryptoPro.JCP does not exist
[ERROR] \github\iTextpdf_5.1.3_patched_cryptopro_bc1.50\src\main\java\com\itextpdf\text\pdf\PdfPKCS7.java:[139,31] error: package ru.CryptoPro.reprov.x509 does not exist
Нужно взять из поставки КриптоПро 2.0 файлы JCP.jar и JCPRevTools.jar и поместить в каталог JRE, которую использует Maven: Java\jdk1.8.0_111\jre\lib\ext. Само собой, они должны быть и в classPath приложения.
Итак, библиотека собрана, подключаем ее в приложение. И тут возникает основная проблема. iTextpdf_5.1.3 содержит зависимость на Bouncy Castle версии 1.46 – библиотеку с открытым кодом, реализующую криптографический провайдер и поддержку ASN.1 структур.
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bctsp-jdk15</artifactId>
<version>1.46</version>
<type>jar</type>
<scope>compile</scope>
<optional>true</optional>
</dependency>
Поставка КриптоПро JCP 2.0 в свою очередь имеет зависимости на Bouncy Castle версии 1.50 bcpkix-jdk15on-1.50 и bcprov-jdk15on-1.5, соответственно, они помещаются в jre/lib/ext при установке КриптоПро.
В итоге при запуске своего приложения и метода подписания PDF мы получаем ошибку:
Exception in thread "main" java.lang.NoClassDefFoundError: org/bouncycastle/asn1/DEREncodable
at com.itextpdf.text.pdf.PdfSigGenericPKCS.setSignInfo(PdfSigGenericPKCS.java:97)
at com.itextpdf.text.pdf.PdfSignatureAppearance.preClose(PdfSignatureAppearance.java:1003)
at com.itextpdf.text.pdf.PdfSignatureAppearance.preClose(PdfSignatureAppearance.java:904)
at com.itextpdf.text.pdf.PdfStamper.close(PdfStamper.java:194)
at ru.alfabank.ccjava.trustcore.logic.SignatureProcessor.pdfSignature(SignatureProcessor.java:965)
at ru.alfabank.ccjava.trustcore.logic.SignatureProcessor.main(SignatureProcessor.java:1363)
Caused by: java.lang.ClassNotFoundException: org.bouncycastle.asn1.DEREncodable
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 6 more
Каждый разработчик Java сталкивался с таким исключением в потоке main и знает, что можно потратить много времени на разбор проблемы, и как все исправить. Суть исключения NoClassDefFoundError следующая – оно выбрасывается, когда виртуальная машина Java во время исполнения приложения не может найти конкретный класс, который был доступен на этапе компиляции.
Что получается – библиотека iTextpdf_5.1.3 имеет зависимость от более старого провайдера Bouncy Castle, а для новых версий iTextpdf нет патча от КриптоПро.
Конкретно в поставке КриптоПро JCP 2.0 зависимости на новую версию Bouncy Castle имеет библиотека CAdES.jar. Если удалить из JRE эту библиотеку или вовсе отказаться от поддержки формирования CAdES подписей при установке КриптоПро JCP 2.0, то проблема будет решена.
Но что если поддержка CAdES должна остаться?
Чтобы избавиться от конфликта библиотек, необходимо предпринять следующие шаги:
- заменяем в исходном коде библиотеки iTextpdf_5.1.3_patched_cryptopro зависимость org.bouncycastle 1.46 на версию 1.50.
<dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-ext-jdk15on</artifactId> <version>1.50</version> </dependency> <dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk15on</artifactId> <version>1.50</version> </dependency> <dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcmail-jdk15on</artifactId> <version>1.50</version> </dependency> - вносим исправления в проект iTextpdf_5.1.3_patched_cryptopro, руководствуясь документом Bouncy Castle «Porting from earlier BC releases to 1.47 and later»
- чтобы поправить те места iTextpdf_5.1.3_patched_cryptopro, где дело не ограничивалось новыми названиями классов и методов Bouncy Castle, а явно были изменены конструкции в методах, скачиваем исходный код itextpdf 5.5.5, который имеет зависимость на Bouncy Castle 1.50, вдумчиво переносим реализацию методов оттуда.
Как итог, проект iTextpdf_5.1.3_patched_cryptopro_bc1.50 начинает собираться. Конфликт разрешен, КриптоПро и itextpdf ссылаются на одну версию org.bouncycastle 1.50.
Исходный код iTextpdf_5.1.3_patched_cryptopro_bc1.50 выложен в GitHub: iTextpdf_5.1.3_patched_cryptopro_bc1.50
Пример кода, несколько подписей PDF
Пример использования КриптоПро и iTextpdf_5.1.3_patched_cryptopro_bc1.50 выглядит следующим образом:
/**
*
* @param aliases
* - имена контейнеров с ключами ЭП
* @param data
* - массив байтов с документом PDF
* @param pdfVersion
* - номер версии формата PDF
* @return
* @throws SignatureProcessorException
*/
public static byte[] samplePDFSignature(String[] aliases, byte[] data, char pdfVersion) throws SignatureProcessorException {
ByteArrayOutputStream bais = new ByteArrayOutputStream();
HashMap<X509Certificate, PrivateKey> currSignAttrMap = new HashMap<X509Certificate, PrivateKey>();
for (String alias : aliases) {
X509Certificate certificate = (X509Certificate) signAttributesMap1.get(alias)[0];
PrivateKey privateKey = (PrivateKey) signAttributesMap1.get(alias)[1];
currSignAttrMap.put(certificate, privateKey);
if (certificate == null) {
throw new SignatureProcessorException(PDF_SIGNATURE_ERROR + CERTIFICATE_NOT_FOUND_BY_ALIAS);
}
if (privateKey == null) {
throw new SignatureProcessorException(PDF_SIGNATURE_ERROR + PRIVATE_KEY_NOT_FOUND_BY_ALIAS);
}
}
try {
FileInputStream fis = new FileInputStream(new File(FILE_PATH));
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] buf = new byte[1024];
int n = 0;
while ((n = fis.read(buf, 0, buf.length)) != -1) {
baos.write(buf, 0, n);
}
fis.close();
byte[] im = baos.toByteArray();
X509Certificate innerCA = obtainCertFromTrustStoreJKS(false, INNER_CA);
PdfStamper stp = null;
PdfReader reader = null;
int pageNumber = 1;
for (Entry<X509Certificate, PrivateKey> entry : currSignAttrMap.entrySet()) {
if (bais.toByteArray().length == 0) {
reader = new PdfReader(data);
} else {
reader = new PdfReader(bais.toByteArray());
bais = new ByteArrayOutputStream();
}
stp = PdfStamper.createSignature(reader, bais, pdfVersion); //'\0'
Certificate[] certPath = new Certificate[] {entry.getKey(), innerCA};
PdfSignatureAppearance sap = stp.getSignatureAppearance();
sap.setProvider("JCSP"); //JCP
sap.setCrypto(entry.getValue(), certPath, null,
PdfSignatureAppearance.CRYPTOPRO_SIGNED);
Image image = Image.getInstance(im);
sap.setImage(image);
sap.setVisibleSignature(new Rectangle(150, 150), pageNumber, null);
pageNumber++;
stp.close();
bais.close();
reader.close();
}
} catch (RuntimeException e) {
throw new SignatureProcessorException(PDF_SIGNATURE_ERROR + ExceptionUtils.getFullStackTrace(e));
} catch (IOException e) {
throw new SignatureProcessorException(PDF_SIGNATURE_ERROR + ExceptionUtils.getFullStackTrace(e));
} catch (DocumentException e) {
throw new SignatureProcessorException(PDF_SIGNATURE_ERROR + ExceptionUtils.getFullStackTrace(e));
} catch (CertificateEncodingException e) {
throw new SignatureProcessorException(PDF_SIGNATURE_ERROR + ExceptionUtils.getFullStackTrace(e));
} catch (Exception e) {
throw new SignatureProcessorException(PDF_SIGNATURE_ERROR + ExceptionUtils.getFullStackTrace(e));
}
return bais.toByteArray();
}
Метод принимает на вход список имен контейнеров с ключами электронной подписи, байты PDF-документа и номер версии формата PDF. Согласно указанным именам, ключи и сертификаты извлекаются из кэша. Подгружается изображение для визуализации подписи.
Создается объект с корневым сертификатом для формирования пути сертификации, который требуется методу setCrypto класса com.itextpdf.text.pdf.PdfSignatureAppearance.
В цикле выполняется подпись страниц PDF-документа ключами, имена которых были переданы в метод.
Для демонстрации выполнены две подписи — валидная и невалидная с недействительным сертификатом.
Вкладка «Подписи» выглядит следующим образом:
Применение электронной подписи PDF-документов
На мой взгляд, подпись непосредственно в PDF формате является частным случаем. Такой штамп в самом файле предназначен скорее для визуализации ЭП с целью проверки ее глазами. Это удобно и эффектно, когда речь идет о небольшом количестве документов, где не требуется автоматизация, а роль проверяющего выполняет оператор.
С интенсивным процессом обмена большим количеством электронных документов, оператор не справится. В этом случае информационная система выполняет автоматизацию, и необходимость в красивой визуализации отпадает. Соответственно излишне тратить ресурсы информационной системы и электронных каналов, на передачу объемных PDF файлов и обработку изображений штампа.
Практичнее формировать электронную подпись в виде отдельного файла или оборачивать файл и подпись в один контейнер стандарта PKCS#7 (CAdES). Этот стандарт с присоединенной или отсоединенной подписью отлично подойдет для большого документооборота между информационными системами.
Тот же документ PDF можно подписать по стандарту CAdES отсоединенной подписью, в итоге будет два файла — сам PDF и контейнер с подписью.
Вспомним проблемы, с которыми пришлось столкнуться при подписании на Java. Вывод — формат PDF сейчас плохо поддерживается КриптоПро в части прикладного программного интерфейса для Java. Существующую библиотеку itextpdf пришлось править самостоятельно.
В сфере деятельности, связанной с разработкой коммерческого программного обеспечения со встроенными СКЗИ, такой подход недопустим, патчи, обновления и доработки должны выполняться организацией-лицензиатом. Поэтому приведенный в посте способ подписи PDF-документа можно применять с целью демонстрации возможностей и для внутреннего использования.
Полезные ссылки
Комментарии (22)
kovserg
11.09.2017 22:21Почему не просто файл filename.ext.sign — в котором лежит подпись. Зачем привязываться к pdf? А если это например архив с большим количеством файлов разного типа?
vburmistrov Автор
11.09.2017 23:01+1Электронная подпись в формате PDF рассматривалась, как один из способов, который примечателен, например, визуализацией.
Для масштабного электронного документооборота или в случае с архивами, конечно больше подходит отсоединенная подпись в формате PKCS#7.Kolyuchkin
12.09.2017 10:11+1Не совсем точно. «Электронная подпись в формате PDF» — это обывательский термин, который лишь отражает тот факт, что в теле PKCS#7 (в нашем случае «Подписанные данные») содержится PDF-файл, так же там содержится «штамп времени» и, по-умолчанию, сертификат подписанта. В итоге, мы имеем обычное PKCS#7-сообщение. Кстати, я в свое время просто формировал PKCS#7-сообщение по всем требованиям (в разделе «подписываемые данные» пихал содержимое pdf-ки), расширение файлу делал ".pdf" и PDF-ридеры нормально открывали этот файл и верифицировали электронную подпись.
Вот ссылка, подтверждающая мои доводы.vburmistrov Автор
12.09.2017 11:28+1Kolyuchkin, интересное замечание, спасибо!
Я только что попробовал проделать тоже самое.
Сформировал присоединенную подпись в формате PKCS#7, в SignedData поместил байты PDF документа.
Присвоил файлу контейнеру с подписью расширение PDF и он действительно открылся в Adobe Reader.
Но в нем нет панели Подписи. Нет поля с подписью в теле документа. И не может быть.
Так как процесс формирования подписи иной.
В PKCS#7 мы помещаем неизменный PDF внутрь контейнера CMS.
В случае подписи PDF документа, он сам служит контейнером, который модифицируется.
Ваш эксперимент говорит о том, что умный Adobe Reader умеет читать CMS контейнеры.
В приложенном Вами PDF документе есть одна единственная подпись в формате PDF, но ее сформировали не Вы, а разработчик Adobe:
Kolyuchkin
12.09.2017 11:44В документе по предложенной мной ссылке содержится мануал, как Adobe подписывает документы (с. 56).
Но в нем нет панели Подписи. Нет поля с подписью в теле документа. И не может быть.
Я это делал (в качестве эксперимента) лет 5 назад, когда еще свой УЦ делали. Возможно Adobe что то поменяли в своих алгоритмах. А Вы в CMS помещали цепочку сертификатов и списки отозванных сертификатов?vburmistrov Автор
12.09.2017 12:03+1Сертификаты в CMS помещаю всегда, а CRL нет. Так как CRL имеют свой ограниченный срок жизни и могут резко стать неактуальными, считаю, что при проверке, надежнее CRL и Delta CRL скачивать по адресам из атрибута сертификата CDP и кэшировать до выхода нового. Можно обратить внимание на OCSP, но так резко увеличивается количество запросов в сеть.
Kolyuchkin
12.09.2017 12:21А что Вас смущает в ограниченном сроке жизни CRL? Ведь процедура проверки электронной подписи базируется на доказательстве того, что, во-первых, электронная подпись корректна и, во-вторых, что сертификат подписанта был действующим на момент подписи.
Эксперименты с PDF мы проводили для «архивного хранения» электронных документов — тогда мы в тело PKCS#7-сообщения вкладывали еще и OCSP-ответы и TSS-ответы.vburmistrov Автор
12.09.2017 16:22В сроках жизни CRL меня ничего не смущает.
В ответ на Ваши умозаключения приведу свои, тем более что, по-моему, они во многом схожи.
Допустим достаточно солидный временной интервал между тем, как пользователь отправил в УЦ запрос на отзыв своего сертификата, например, в связи с компрометацией закрытого ключа. И моментом, когда УЦ добавит этот сертификат в список отозванных сертификатов и опубликует новый CRL.
Такой разрыв может дать возможность недобросовестному пользователю попытаться отказаться от своей подписи, заявить, что это подписывал уже не он.
Это допустимо, если его подпись не содержала метку времени от доверенного TSP сервера.
Как защищаться от такой ситуации – это архивное хранение и наша архивная электронная подпись с доверенной меткой времени, которую мы поставим на документ пользователя в момент получения.
Думаю, что дальнейшее обсуждение этих деталей будет иметь отдаленной отношения к теме статьи.
vburmistrov Автор
11.09.2017 23:40+1Exchan-ge, в моей деятельности основное направление это собственная разработка информационных систем. К проприетарным механизмам электронной подписи имею достаточно косвенное отношение.
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.
Exchan-ge
11.09.2017 23:40«о преимуществах формата PDF в качестве документа с электронной подписью»
Прокомментируйте, пожалуйста эту новость:
«Американские софтверные компании Microsoft и Adobe объявили о расширении сотрудничества, в рамках которого будет реализована интеграция продуктов.
Решение по работе с электронными подписями Adobe Sign встроено в приложения Microsoft Office 365 и будет работать преимущественно в облачной инфраструктуре Microsoft Azure. Это должно обеспечить быструю и безопасную работу электронной подписи в приложениях Office 365, включая Microsoft Word, PowerPoint и Outlook»vburmistrov Автор
11.09.2017 23:41Exchan-ge, в моей деятельности основное направление это собственная разработка информационных систем. К проприетарным механизмам электронной подписи имею достаточно косвенное отношение.
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.Exchan-ge
12.09.2017 11:07Спасибо!
Хотелось бы узнать более подробно о механизме «индивидуальной» электронной подписи — но в формате «для чайников» (степень осведомленности об этой возможности у большинства опытных пользователей — близка к нулю).
TiesP
12.09.2017 10:06А можете пояснить фразу "действующий сертификат на СКЗИ не обязателен при условии использования криптографического провайдера исключительно для внутренних целей". Например, если организация хочет подписывать электронной подписью какие-нибудь "Складские перемещения" и т.д. вместо ручной подписи — то для этого разве не нужен ключ/токен?
vburmistrov Автор
12.09.2017 10:21TiesP, «действующий сертификат на СКЗИ» имеется в виду Сертификат соответствия, выданный в ФСБ России разработчику СКЗИ. Сертификаты на продукты КриптоПро можно посмотреть здесь
kovserg
Выглядит как бесполезные рюшечки. Что мешает злоумышленнику добавить картинку на каждую страницу, что бы выглядело примерно так же. Или подписать своим сертификатом.
Документы должны проверяться при получении по хэшу файла что бы можно было проверять чем угодно, а не только адобом. Примерно также как в tortoisehg оверлеи на иконки файлов или через в контекстое меню.
Да и pdf не самый лучший формат файлов. Особенно когда без разбора сканируют в pdf в цвете и чумовых разрешениях.
vburmistrov Автор
kovserg, злоумышленник не сможет подделать подпись PDF, так как, во-первых он не сможет добавить в Adobe Reader вкладку «Подписи». Во вторых поле с подписью в теле PDF документа не является просто «рюшечкой» или картинкой, это специальное поле, при клике на которое, отрабатывает crypto модуль Reader-а, интегрированный с CryptoAPI операционной системы. Нам отображается результат проверки подписи и статус сертификата, в том числе строится путь сертификации с использованием хранилища корневых доверенных сертификатов операционной системы (среды исполнения), а соответственно и автора документа, мы можем точно определить.
Но механизм Adobe работы с электронной подписью – это скорее тема для целой отдельной статьи.
kovserg
Что мне мешает сделать сертификат и подписать точно так же (но используя похожие буквы например apple.com )
vburmistrov Автор
Вы можете себе сделать самоподписной сертификат или поднять свой мини удостоверяющий центр и выпустить в нем сертификат. Но доверенным он в среде других пользователей не будет. Следовательно и подпись на документе будет считаться у них недействительной. Что бы Ваша подпись считалась действительной, сертификат Вам нужно получить в доверенном Центре сертификации, корневой сертификат, которого предустановлен в среду другого пользователя, например в ОС Windows, JRE. Или пользователь, который Вам доверяет, должен взять у Вас корневой сертификат Вашего Центра сертификации и установить в свое хранилище корневых доверенных.
kovserg
«Вы мало знаете о добрых феях»
boris_britva
А чего не использовали модуль криптоПро PDF?
vburmistrov Автор
Вполне можно купить лицензию на криптографический провайдер CSP и купить отдельное standalone приложение КриптоПро PDF, такая связка позволит обеспечивать юридическую значимость электронных документов.
Но в данной статье речь шла о том, как купить лицензию только на криптографический провайдер и встроить возможность электронной подписи в информационную систему собственной разработки.