ggo,
реализованная в SmevTransformSpi трансформация нормализует по заданным правилам XML документ перед тем, как будет посчитан его хэш и поставлена электронная подпись.
Так что трансформация может быть какой угодно и на основные функции ЭП — защита от подмены информации и однозначное установление ее автора, трансформация не влияет.
Пара важных дополнений:
1) Я привел пример, как сначала подписать SOAP запрос, который можно еще корректировать в его части не подлежащей подписанию, а затем отправить.
Мне поступил вопрос, как на лету сделать бесшовный вызов веб сервиса СМЭВ с подписанным запросом и так же проверить ответ.
Хочу посоветовать мощную статью Aleksey Sushko на Old council Apache CXF и ЭЦП для SOAP сообщений СМЭВ
В этой статье про квинтэссенцию использования технологии расширения SOAP запросов — WS-Security, Apache WSS4J и реализации JAX-WS — Apache CXF и все это на ГОСТ алгоритмах.
Мне в свое время очень помогло, за что еще раз спасибо Алексею.
2) Я сообщил в ФГУП НИИ «Восход» об опечатке в документе Методические рекомендации по работе с ЕСМЭВ версия 3.4.0.3.
mustiks, алгоритмы из старых стандартов пока не запрещают.
Если Вы будете применять их сугубо для внутреннего использования, то это сколько угодно.
Переход на новые стандарты касается тех, кому нужна юридически значимая квалифицированная усиленная электронная подпись.
Для такой подписи должен выполняться ряд условий, в частности:
— Сертификат открытого ключа проверки подписи должен быть выдан в аккредитованном удостоверяющем центре.
— Средство криптографической защиты информации должно иметь действующий сертификат ФСБ
Аккредитованные УЦ обязаны перейти на новые стандарты.
Разработчики СКЗИ для получения в ФСБ сертификата соответствия обязаны реализовать у себя криптографию по новым стандартам.
С технической точки зрения цель перехода — повышение уровня криптографической стойкости и улучшение эксплуатационных характеристик.
mihmig, HDImageStore — это нативное хранилище СКЗИ КриптоПро, оно зашифровано и защищено паролем. Конечно, его надежность сильно проигрывает HSM модулям, тем более с неизвлекаемыми ключами, например, JaСarta.
А по поводу того, что любой пользователь может их скопировать с сервера. Так, во-первых, хранилище JKS или cacerts это тоже файлы. А во-вторых для защиты серверов обычно применяются организационные и технические меры защиты.
Нет. Без установки в ОС ГОСТового криптографического провайдера Adobe Reader скажет, что «Произошла ошибка при форматировании или в информации, содержащейся в данной подписи». Так же ни Adobe Reader, ни сама ОС не будет понимать ГОСТ сертификаты, строить цепочки и доверять им.
В сроках жизни CRL меня ничего не смущает.
В ответ на Ваши умозаключения приведу свои, тем более что, по-моему, они во многом схожи.
Допустим достаточно солидный временной интервал между тем, как пользователь отправил в УЦ запрос на отзыв своего сертификата, например, в связи с компрометацией закрытого ключа. И моментом, когда УЦ добавит этот сертификат в список отозванных сертификатов и опубликует новый CRL.
Такой разрыв может дать возможность недобросовестному пользователю попытаться отказаться от своей подписи, заявить, что это подписывал уже не он.
Это допустимо, если его подпись не содержала метку времени от доверенного TSP сервера.
Как защищаться от такой ситуации – это архивное хранение и наша архивная электронная подпись с доверенной меткой времени, которую мы поставим на документ пользователя в момент получения.
Думаю, что дальнейшее обсуждение этих деталей будет иметь отдаленной отношения к теме статьи.
Вполне можно купить лицензию на криптографический провайдер CSP и купить отдельное standalone приложение КриптоПро PDF, такая связка позволит обеспечивать юридическую значимость электронных документов.
Но в данной статье речь шла о том, как купить лицензию только на криптографический провайдер и встроить возможность электронной подписи в информационную систему собственной разработки.
Сертификаты в CMS помещаю всегда, а CRL нет. Так как CRL имеют свой ограниченный срок жизни и могут резко стать неактуальными, считаю, что при проверке, надежнее CRL и Delta CRL скачивать по адресам из атрибута сертификата CDP и кэшировать до выхода нового. Можно обратить внимание на OCSP, но так резко увеличивается количество запросов в сеть.
Kolyuchkin, интересное замечание, спасибо!
Я только что попробовал проделать тоже самое.
Сформировал присоединенную подпись в формате PKCS#7, в SignedData поместил байты PDF документа.
Присвоил файлу контейнеру с подписью расширение PDF и он действительно открылся в Adobe Reader.
Но в нем нет панели Подписи. Нет поля с подписью в теле документа. И не может быть.
Так как процесс формирования подписи иной.
В PKCS#7 мы помещаем неизменный PDF внутрь контейнера CMS.
В случае подписи PDF документа, он сам служит контейнером, который модифицируется.
Ваш эксперимент говорит о том, что умный Adobe Reader умеет читать CMS контейнеры.
В приложенном Вами PDF документе есть одна единственная подпись в формате PDF, но ее сформировали не Вы, а разработчик Adobe:
TiesP, «действующий сертификат на СКЗИ» имеется в виду Сертификат соответствия, выданный в ФСБ России разработчику СКЗИ. Сертификаты на продукты КриптоПро можно посмотреть здесь
Exchan-ge, в моей деятельности основное направление это собственная разработка информационных систем. К проприетарным механизмам электронной подписи имею достаточно косвенное отношение.
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.
Exchan-ge, в моей деятельности основное направление это собственная разработка информационных систем. К проприетарным механизмам электронной подписи имею достаточно косвенное отношение.
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.
Электронная подпись в формате PDF рассматривалась, как один из способов, который примечателен, например, визуализацией.
Для масштабного электронного документооборота или в случае с архивами, конечно больше подходит отсоединенная подпись в формате PKCS#7.
Вы можете себе сделать самоподписной сертификат или поднять свой мини удостоверяющий центр и выпустить в нем сертификат. Но доверенным он в среде других пользователей не будет. Следовательно и подпись на документе будет считаться у них недействительной. Что бы Ваша подпись считалась действительной, сертификат Вам нужно получить в доверенном Центре сертификации, корневой сертификат, которого предустановлен в среду другого пользователя, например в ОС Windows, JRE. Или пользователь, который Вам доверяет, должен взять у Вас корневой сертификат Вашего Центра сертификации и установить в свое хранилище корневых доверенных.
kovserg, злоумышленник не сможет подделать подпись PDF, так как, во-первых он не сможет добавить в Adobe Reader вкладку «Подписи». Во вторых поле с подписью в теле PDF документа не является просто «рюшечкой» или картинкой, это специальное поле, при клике на которое, отрабатывает crypto модуль Reader-а, интегрированный с CryptoAPI операционной системы. Нам отображается результат проверки подписи и статус сертификата, в том числе строится путь сертификации с использованием хранилища корневых доверенных сертификатов операционной системы (среды исполнения), а соответственно и автора документа, мы можем точно определить.
Но механизм Adobe работы с электронной подписью – это скорее тема для целой отдельной статьи.
реализованная в SmevTransformSpi трансформация нормализует по заданным правилам XML документ перед тем, как будет посчитан его хэш и поставлена электронная подпись.
Так что трансформация может быть какой угодно и на основные функции ЭП — защита от подмены информации и однозначное установление ее автора, трансформация не влияет.
Всем привет!
Пара важных дополнений:
1) Я привел пример, как сначала подписать SOAP запрос, который можно еще корректировать в его части не подлежащей подписанию, а затем отправить.
Мне поступил вопрос, как на лету сделать бесшовный вызов веб сервиса СМЭВ с подписанным запросом и так же проверить ответ.
Хочу посоветовать мощную статью Aleksey Sushko на Old council
Apache CXF и ЭЦП для SOAP сообщений СМЭВ
В этой статье про квинтэссенцию использования технологии расширения SOAP запросов — WS-Security, Apache WSS4J и реализации JAX-WS — Apache CXF и все это на ГОСТ алгоритмах.
Мне в свое время очень помогло, за что еще раз спасибо Алексею.
2) Я сообщил в ФГУП НИИ «Восход» об опечатке в документе Методические рекомендации по работе с ЕСМЭВ версия 3.4.0.3.
Как бы теперь кого нибудь невиновного с Хабры не забрали… )
А если серьезно: то за всю банковскую сферу ответить не могу, в моей деятельности больше всего приходится иметь дело с ГОСТ эллиптикой.
К сожалению попробовать ed25519 пока не доводилось.
Правильно говорит Scratch в своей статье: Curve25519, EdDSA и Poly1305: Три обделенных вниманием криптопримитива.
Спасибо за напоминание про эту область. Обязательно хотя бы для себя попробую покопать.
Группа PТК-CМЭВ и ПАО «Ростелеком» ответили, что
Если Вы будете применять их сугубо для внутреннего использования, то это сколько угодно.
Переход на новые стандарты касается тех, кому нужна юридически значимая квалифицированная усиленная электронная подпись.
Для такой подписи должен выполняться ряд условий, в частности:
— Сертификат открытого ключа проверки подписи должен быть выдан в аккредитованном удостоверяющем центре.
— Средство криптографической защиты информации должно иметь действующий сертификат ФСБ
Аккредитованные УЦ обязаны перейти на новые стандарты.
Разработчики СКЗИ для получения в ФСБ сертификата соответствия обязаны реализовать у себя криптографию по новым стандартам.
С технической точки зрения цель перехода — повышение уровня криптографической стойкости и улучшение эксплуатационных характеристик.
Спасибо за информацию!
Действительно появилась еще одна ссылка на УЦ, которая функционирует.
В статье актуализировал:
Сам тоже собирался этот вопрос держать под наблюдением.
А по поводу того, что любой пользователь может их скопировать с сервера. Так, во-первых, хранилище JKS или cacerts это тоже файлы. А во-вторых для защиты серверов обычно применяются организационные и технические меры защиты.
В ответ на Ваши умозаключения приведу свои, тем более что, по-моему, они во многом схожи.
Допустим достаточно солидный временной интервал между тем, как пользователь отправил в УЦ запрос на отзыв своего сертификата, например, в связи с компрометацией закрытого ключа. И моментом, когда УЦ добавит этот сертификат в список отозванных сертификатов и опубликует новый CRL.
Такой разрыв может дать возможность недобросовестному пользователю попытаться отказаться от своей подписи, заявить, что это подписывал уже не он.
Это допустимо, если его подпись не содержала метку времени от доверенного TSP сервера.
Как защищаться от такой ситуации – это архивное хранение и наша архивная электронная подпись с доверенной меткой времени, которую мы поставим на документ пользователя в момент получения.
Думаю, что дальнейшее обсуждение этих деталей будет иметь отдаленной отношения к теме статьи.
Но в данной статье речь шла о том, как купить лицензию только на криптографический провайдер и встроить возможность электронной подписи в информационную систему собственной разработки.
Я только что попробовал проделать тоже самое.
Сформировал присоединенную подпись в формате PKCS#7, в SignedData поместил байты PDF документа.
Присвоил файлу контейнеру с подписью расширение PDF и он действительно открылся в Adobe Reader.
Но в нем нет панели Подписи. Нет поля с подписью в теле документа. И не может быть.
Так как процесс формирования подписи иной.
В PKCS#7 мы помещаем неизменный PDF внутрь контейнера CMS.
В случае подписи PDF документа, он сам служит контейнером, который модифицируется.
Ваш эксперимент говорит о том, что умный Adobe Reader умеет читать CMS контейнеры.
В приложенном Вами PDF документе есть одна единственная подпись в формате PDF, но ее сформировали не Вы, а разработчик Adobe:
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.
Но в этой новости вижу два положительных момента:
1. Функционал Adobe Sign настолько хорош, что его решило использовать Microsoft.
2. Пользуются спросом и развиваются механизмы, назовем их «индивидуальной» электронной подписи в привычных контейнерах офисных документов, как в случае с PDF документами, Microsoft Office документами, PowerPoint и Outlook, когда пользователь подписал — пользователь визуально проверил.
А вот по поводу работы с подписью в облачной инфраструктуре. Могу сказать, что с точки зрения российского законодательства, такую подпись уже нельзя будет считать квалифицированной, по крайне мере, в настоящее время.
Для масштабного электронного документооборота или в случае с архивами, конечно больше подходит отсоединенная подпись в формате PKCS#7.
Но механизм Adobe работы с электронной подписью – это скорее тема для целой отдельной статьи.