Комментарии 28
Выглядит как бесполезные рюшечки. Что мешает злоумышленнику добавить картинку на каждую страницу, что бы выглядело примерно так же. Или подписать своим сертификатом.
Документы должны проверяться при получении по хэшу файла что бы можно было проверять чем угодно, а не только адобом. Примерно также как в tortoisehg оверлеи на иконки файлов или через в контекстое меню.
Да и pdf не самый лучший формат файлов. Особенно когда без разбора сканируют в pdf в цвете и чумовых разрешениях.
Документы должны проверяться при получении по хэшу файла что бы можно было проверять чем угодно, а не только адобом. Примерно также как в tortoisehg оверлеи на иконки файлов или через в контекстое меню.
Да и pdf не самый лучший формат файлов. Особенно когда без разбора сканируют в pdf в цвете и чумовых разрешениях.
kovserg, злоумышленник не сможет подделать подпись PDF, так как, во-первых он не сможет добавить в Adobe Reader вкладку «Подписи». Во вторых поле с подписью в теле PDF документа не является просто «рюшечкой» или картинкой, это специальное поле, при клике на которое, отрабатывает crypto модуль Reader-а, интегрированный с CryptoAPI операционной системы. Нам отображается результат проверки подписи и статус сертификата, в том числе строится путь сертификации с использованием хранилища корневых доверенных сертификатов операционной системы (среды исполнения), а соответственно и автора документа, мы можем точно определить.
Но механизм Adobe работы с электронной подписью – это скорее тема для целой отдельной статьи.
Но механизм Adobe работы с электронной подписью – это скорее тема для целой отдельной статьи.
Что мне мешает сделать сертификат и подписать точно так же (но используя похожие буквы например apple.com )
Вы можете себе сделать самоподписной сертификат или поднять свой мини удостоверяющий центр и выпустить в нем сертификат. Но доверенным он в среде других пользователей не будет. Следовательно и подпись на документе будет считаться у них недействительной. Что бы Ваша подпись считалась действительной, сертификат Вам нужно получить в доверенном Центре сертификации, корневой сертификат, которого предустановлен в среду другого пользователя, например в ОС Windows, JRE. Или пользователь, который Вам доверяет, должен взять у Вас корневой сертификат Вашего Центра сертификации и установить в свое хранилище корневых доверенных.
А чего не использовали модуль криптоПро PDF?
Вполне можно купить лицензию на криптографический провайдер CSP и купить отдельное standalone приложение КриптоПро PDF, такая связка позволит обеспечивать юридическую значимость электронных документов.
Но в данной статье речь шла о том, как купить лицензию только на криптографический провайдер и встроить возможность электронной подписи в информационную систему собственной разработки.
Но в данной статье речь шла о том, как купить лицензию только на криптографический провайдер и встроить возможность электронной подписи в информационную систему собственной разработки.
Почему не просто файл filename.ext.sign — в котором лежит подпись. Зачем привязываться к pdf? А если это например архив с большим количеством файлов разного типа?
Электронная подпись в формате PDF рассматривалась, как один из способов, который примечателен, например, визуализацией.
Для масштабного электронного документооборота или в случае с архивами, конечно больше подходит отсоединенная подпись в формате PKCS#7.
Для масштабного электронного документооборота или в случае с архивами, конечно больше подходит отсоединенная подпись в формате PKCS#7.
Не совсем точно. «Электронная подпись в формате PDF» — это обывательский термин, который лишь отражает тот факт, что в теле PKCS#7 (в нашем случае «Подписанные данные») содержится PDF-файл, так же там содержится «штамп времени» и, по-умолчанию, сертификат подписанта. В итоге, мы имеем обычное PKCS#7-сообщение. Кстати, я в свое время просто формировал PKCS#7-сообщение по всем требованиям (в разделе «подписываемые данные» пихал содержимое pdf-ки), расширение файлу делал ".pdf" и PDF-ридеры нормально открывали этот файл и верифицировали электронную подпись.
Вот ссылка, подтверждающая мои доводы.
Вот ссылка, подтверждающая мои доводы.
Kolyuchkin, интересное замечание, спасибо!
Я только что попробовал проделать тоже самое.
Сформировал присоединенную подпись в формате PKCS#7, в SignedData поместил байты PDF документа.
Присвоил файлу контейнеру с подписью расширение PDF и он действительно открылся в Adobe Reader.
Но в нем нет панели Подписи. Нет поля с подписью в теле документа. И не может быть.
Так как процесс формирования подписи иной.
В PKCS#7 мы помещаем неизменный PDF внутрь контейнера CMS.
В случае подписи PDF документа, он сам служит контейнером, который модифицируется.
Ваш эксперимент говорит о том, что умный Adobe Reader умеет читать CMS контейнеры.
В приложенном Вами PDF документе есть одна единственная подпись в формате PDF, но ее сформировали не Вы, а разработчик Adobe:
Я только что попробовал проделать тоже самое.
Сформировал присоединенную подпись в формате PKCS#7, в SignedData поместил байты PDF документа.
Присвоил файлу контейнеру с подписью расширение PDF и он действительно открылся в Adobe Reader.
Но в нем нет панели Подписи. Нет поля с подписью в теле документа. И не может быть.
Так как процесс формирования подписи иной.
В PKCS#7 мы помещаем неизменный PDF внутрь контейнера CMS.
В случае подписи PDF документа, он сам служит контейнером, который модифицируется.
Ваш эксперимент говорит о том, что умный Adobe Reader умеет читать CMS контейнеры.
В приложенном Вами PDF документе есть одна единственная подпись в формате PDF, но ее сформировали не Вы, а разработчик Adobe:
В документе по предложенной мной ссылке содержится мануал, как Adobe подписывает документы (с. 56).
Я это делал (в качестве эксперимента) лет 5 назад, когда еще свой УЦ делали. Возможно Adobe что то поменяли в своих алгоритмах. А Вы в CMS помещали цепочку сертификатов и списки отозванных сертификатов?
Но в нем нет панели Подписи. Нет поля с подписью в теле документа. И не может быть.
Я это делал (в качестве эксперимента) лет 5 назад, когда еще свой УЦ делали. Возможно Adobe что то поменяли в своих алгоритмах. А Вы в CMS помещали цепочку сертификатов и списки отозванных сертификатов?
Сертификаты в CMS помещаю всегда, а CRL нет. Так как CRL имеют свой ограниченный срок жизни и могут резко стать неактуальными, считаю, что при проверке, надежнее CRL и Delta CRL скачивать по адресам из атрибута сертификата CDP и кэшировать до выхода нового. Можно обратить внимание на OCSP, но так резко увеличивается количество запросов в сеть.
А что Вас смущает в ограниченном сроке жизни CRL? Ведь процедура проверки электронной подписи базируется на доказательстве того, что, во-первых, электронная подпись корректна и, во-вторых, что сертификат подписанта был действующим на момент подписи.
Эксперименты с PDF мы проводили для «архивного хранения» электронных документов — тогда мы в тело PKCS#7-сообщения вкладывали еще и OCSP-ответы и TSS-ответы.
Эксперименты с PDF мы проводили для «архивного хранения» электронных документов — тогда мы в тело PKCS#7-сообщения вкладывали еще и OCSP-ответы и TSS-ответы.
В сроках жизни CRL меня ничего не смущает.
В ответ на Ваши умозаключения приведу свои, тем более что, по-моему, они во многом схожи.
Допустим достаточно солидный временной интервал между тем, как пользователь отправил в УЦ запрос на отзыв своего сертификата, например, в связи с компрометацией закрытого ключа. И моментом, когда УЦ добавит этот сертификат в список отозванных сертификатов и опубликует новый CRL.
Такой разрыв может дать возможность недобросовестному пользователю попытаться отказаться от своей подписи, заявить, что это подписывал уже не он.
Это допустимо, если его подпись не содержала метку времени от доверенного TSP сервера.
Как защищаться от такой ситуации – это архивное хранение и наша архивная электронная подпись с доверенной меткой времени, которую мы поставим на документ пользователя в момент получения.
Думаю, что дальнейшее обсуждение этих деталей будет иметь отдаленной отношения к теме статьи.
В ответ на Ваши умозаключения приведу свои, тем более что, по-моему, они во многом схожи.
Допустим достаточно солидный временной интервал между тем, как пользователь отправил в УЦ запрос на отзыв своего сертификата, например, в связи с компрометацией закрытого ключа. И моментом, когда УЦ добавит этот сертификат в список отозванных сертификатов и опубликует новый CRL.
Такой разрыв может дать возможность недобросовестному пользователю попытаться отказаться от своей подписи, заявить, что это подписывал уже не он.
Это допустимо, если его подпись не содержала метку времени от доверенного TSP сервера.
Как защищаться от такой ситуации – это архивное хранение и наша архивная электронная подпись с доверенной меткой времени, которую мы поставим на документ пользователя в момент получения.
Думаю, что дальнейшее обсуждение этих деталей будет иметь отдаленной отношения к теме статьи.
Exchan-ge, в моей деятельности основное направление это собственная разработка информационных систем. К проприетарным механизмам электронной подписи имею достаточно косвенное отношение.
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.
«о преимуществах формата PDF в качестве документа с электронной подписью»
Прокомментируйте, пожалуйста эту новость:
«Американские софтверные компании Microsoft и Adobe объявили о расширении сотрудничества, в рамках которого будет реализована интеграция продуктов.
Решение по работе с электронными подписями Adobe Sign встроено в приложения Microsoft Office 365 и будет работать преимущественно в облачной инфраструктуре Microsoft Azure. Это должно обеспечить быструю и безопасную работу электронной подписи в приложениях Office 365, включая Microsoft Word, PowerPoint и Outlook»
Прокомментируйте, пожалуйста эту новость:
«Американские софтверные компании Microsoft и Adobe объявили о расширении сотрудничества, в рамках которого будет реализована интеграция продуктов.
Решение по работе с электронными подписями Adobe Sign встроено в приложения Microsoft Office 365 и будет работать преимущественно в облачной инфраструктуре Microsoft Azure. Это должно обеспечить быструю и безопасную работу электронной подписи в приложениях Office 365, включая Microsoft Word, PowerPoint и Outlook»
Exchan-ge, в моей деятельности основное направление это собственная разработка информационных систем. К проприетарным механизмам электронной подписи имею достаточно косвенное отношение.
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.
TiesP, «действующий сертификат на СКЗИ» имеется в виду Сертификат соответствия, выданный в ФСБ России разработчику СКЗИ. Сертификаты на продукты КриптоПро можно посмотреть здесь
Интересно, а вот эти хитрые манипуляции не делают полученную систему не соответсвующей пункту 63-ФЗ:
ст. 5
4. Квалифицированной электронной подписью является электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:
...
2) для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.
Или достаточно одного маленького куска CryptoPro JCP в проекте и уже "используются" нужные СЭП?
Здравствуйте!
Совершенно верно, манипуляции с библиотекой itextpdf_patched-5.1.3.jar крайне сомнительны с точки зрения прохождения проверок регуляторов и в случае разбора конфликтных ситуаций. Но статье 6 лет. С тех пор появилась библиотека itextpdf_patched-5.5.5.jar, которую включают в состав сборок КриптоПро JavaCSP. Надеюсь там ни чего патчить уже не надо, но сам я не проверял. PDF подпись так и осталась мало популярной для использования в автоматизированных системах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как на Java c помощью КриптоПро подписать документ PDF