Как подписать документ электронной подписью. Как подписать документ с помощью эцп Как подписать эцп xml файл

На сегодняшний день, когда практически весь документооборот становится безбумажным, подписание документов с помощью — обыденное дело.

В сфере государственных закупок электронной подписью подписывают поданные заявки. Это дает заказчикам гарантию, что они имеют дело с реальными участниками. Также контракты, которые заключаются по итогам госзакупок, вступают в действие только после визирования с помощью ЭЦП.

Также цифровая подпись необходима в таких ситуациях:

  1. Отчетность для контролирующих органов. Можно сдать ее в электронном виде таким службам, как ФНС, Росстат, ПФР и ФСС. Это значительно упрощает передачу информации и повышает правильность: большинство сервисов предлагают автоматическую проверку на ошибки.
  2. Электронный документооборот (ЭДО). Одно из самых распространенных применений, так как подписанное таким способом письмо соответствует бумажному с печатью и визой. Позволяет перейти на безбумажный документооборот как внутри компании, так и за ее пределами.
  3. Государственные услуги. Гражданин РФ может визировать подаваемые заявления в ведомства через портал госуслуг, участвовать в общественных инициативах, пользоваться личным кабинетом на сайте ФНС, даже оформлять кредит.
  4. В качестве доказательств можно использовать счет-фактуры, договоры, официальные письма, подписанные электронно. Согласно АПК РФ, такой документ является аналогом бумажного с собственноручной визой.

Какие бывают электронные подписи

ЭЦП — это «штамп», который позволяет идентифицировать ее владельца, а также удостовериться в целостности подписанного документа. Типы ЭЦП и порядок их оформления утверждены . Он установил, что подписи бывают трех видов:

  1. Простая. Распространена для подписания писем или спецификаций, подтверждается с использованием паролей, кодов и иных средств, чаще всего используется в системах корпоративного ЭДО.
  2. Усиленная . Получается в процессе криптографической обработки информации и использования закрытого ключа. Позволяет установить, кто подписал документ, а также факт внесения изменений после подписания.
  3. Усиленная . Аналогична неквалифицированной, но для ее создания и проверки используются наработки криптозащиты, сертифицированные ФСБ РФ. Такие ЭП выдаются только аккредитованными

Завизировать документ можно несколькими способами. Рассмотрим наиболее часто встречающиеся.

Подписываем с помощью программного комплекса «КриптоПРО CSP»

Как подписать электронной подписью документ Ворд (MS Word)

1. Открываем нужный файл, жмем в меню «Файл» — «Сведения» — «Добавить электронную подпись (КРИПТО-ПРО)».

2. Выбираем нужную ЭП, добавляем комментарий, если нужно, и жмем «Подписать».

3. Если нет ошибок, то система показывает окно с успешным подписанием.

Если установлен плагин КриптоПРО Office Signature

1. Открываем нужный файл, выбираем «Файл», затем — «Добавить цифровую подпись».

2. Аналогично предыдущему варианту, выбираем необходимую ЭП, добавляем, если нужен, комментарий и жмем «Подписать».

3. Если нет ошибок, то система показывает сообщение, что документ успешно подписан.

Как подписать электронной подписью документ PDF (Adobe Acrobat PDF)

1. Открываем необходимый PDF-файл, нажимаем на панели «Инструменты» и видим ярлык «Сертификаты». Выбираем его.

2. Нажимаем на «Поставить цифровую подпись» и выбираем область на файле, где будет располагаться отметка о подписании.

4. Откроется окно с предварительным видом штампа. Если все верно, то нажимаем «Подписать».

5. Система выдаст оповещение об успешном подписании. На этом все.

Подписание программным комплексом «КриптоАРМ»

При таком способе есть возможность шифрования всех современных форматов, а также архивов.

Итак, разберемся, как подписать документ ЭЦП с помощью «КриптоАРМ».

1. Открываем программу «КриптоАРМ» и выбираем самый первый пункт действий — «Подписать».

2. Внимательно изучаем инструкцию Мастера созданий ЭП. Нажимаем «Далее».

3. Жмем на «Выбор файла», переходим к нужному файлу, щелкаем по нему и жмем «Далее».

4. Выбираем подписываемый файл, нажимаем «Далее».

5. Видим окно «Выходной формат». Если нет обязательных требований, то кодировку оставляем как есть. Можно сохранить в формат ZIP (для отправки по e-mail) или выбрать место сохранения конечного результата. Жмем «Далее».

6. В «Параметрах» можно выбрать свойство, добавить комментарий, а также выбрать присоединенную ЭП (присоединяется к исходному файлу) или отсоединенную (сохраняется отдельным файлом), а также дополнительные параметры по желанию. Когда все готово, жмем «Далее».

7. Теперь необходимо выбрать сертификат, для этого жмем «Выбрать», указываем необходимый сертификат и жмем «Далее».

8. На следующем этапе видим итоговое окно с кратким описанием данных. Если в следующий раз файлы будут подписываться в таком же порядке, то можно сохранить профиль. Жмем «Готово».

9. Если нет ошибок, то система выдаст сообщение об успешном подписании.

В данном разделе предлагается для скачивания программы XML Конвертер / XML Конструктор / XML Отчёты / Просто Подписать / XML Контакт — Росреестр.

Примеры формирования электронных версий документов с помощью программы XML Конструктор и их печатных аналогов с помощью программы XML Отчёты можно скачать в разделе . Также предлагаем посмотреть раздел , в котором вы найдете различные бесплатные утилиты, библиотеки и другое.

Программа XML Конвертер настроена для преобразования XML-файлов/документов Росреестра таких как кадастровые выписки, кадастровые планы территории в другие, удобные для использования форматы, такие как MIF/MID, DXF, CSV, TXT, HTML.

Программа XML Конструктор настроена на создание электронных версий в формате XML, таких документов для кадастровой деятельности как межевые планы, технические планы, карта(план) и др., а также уведомлений о залоге движимого имущества и уведомлений согласно закону FATCA.

Программа XML Отчёты настроена на преобразование электронных документов для кадастровой деятельности таких как межевые планы, технические планы, карта(план) в соответствующие печатные (бумажные) аналоги.

Программа Просто Подписать предназначена для создания и проверки электронных цифровых подписей (ЭЦП).

Программа XML Контакт-Росреестр предназначена для взаимодействия с веб-сервисом Росреестра, т.е. создания заявлений на постановку на кадастровый учет земельных участков и объектов недвижимости, запросов сведений кадастра, получения результатов по данным заявлениям и запросам.

Все программы (кроме Просто Подписать и XML Контакт-Росреестр) имеют демонстрационный режим длительностью 30 дней, позволяющий использовать функционал программ без ограничений. После истечения периода действия демонстрационного режима полагается либо приобрести полные версии программ, либо прекратить их использование. Программа Просто Подписать является бесплатной программой и не имеет ограничений в использовании. Программа XML Контакт-Росреестр находится на стадии бета-тестирования и в настоящее время ее использование бесплатно.

ВАЖНО! Для преобразования с помощью программы XML Конвертер или XML Конструктор XML файлов большого размера нужно скачать и установить внешний обработчик запросов XQuery и перед преобразованием указывать его в соответствующем поле программы. В настоящее время поддерживается два свободно распространяемых обработчика запросов AltovaXML 2010 (разработчик www.altova.com) и Saxon-HE 9.5 (разработчик www.saxonica.com). Скачать их можно с сайта производителя или с данного сайта по ниже приведенным ссылкам:

ВАЖНО! Перед тем как приступить к работе с программами необходимо ознакомиться с инструкциями. Особенно это важно для программы XML Конструктор, т. к. перед работой необходимо понять принцип работы данной программы. Инструкции находятся в той же папке, что и исполнительный файл программы, т. е. для XML Конструктора в папке «c:\ProgramFiles\XMLCON\XMLConstructor\XMLConstructor-help.rtf». Вызвать инструкцию можно через ярлык из главного меню программ Windows, т. е. для XML Конструктора «Пуск->Программы->XMLКонструктор->XML Конструктор — Инструкция». Для программы XML Конструктор инструкция также доступна через меню Справка.

На одном из идущих в настоящее время проектов решалась задача подписания (наложения ЭП - электронной подписи) XML документов, а именно SOAP-пакетов. Рекомендованным форматом был OASIS Standard 200401 с профилем X.509 Certificate Token Profile . Эти документы описывают применение созданного www-консорциумом (W3C) формата электронных подписей XML (XMLDSig - XML Digital Signature) в SOAP-сообщениях. XML-подписи, как и другие виды ЭП, поддерживают аутентификацию, целостность данных и неотрекаемость от подписания данных.

Отмечу несколько особенностей формата XMLDSig:

1. Объектом подписания может служить не весь XML-документ, а только его часть, т.е. определённый узел. Согласно OASIS Standard 200401 подписываемым объектом является тело (узел Body ) SOAP-сообщения.

2. Различные части XML-документа могут быть подписаны несколькими исполнителями.

3. XML-подпись может находиться на разных уровнях по отношению к подписываемому объекту:

  • в структуре подписи может находиться URI (унифицированный идентификатор ресурса);
  • XML-подпись может находиться на одном уровне с подписываемым узлом;
  • XML-подпись может находиться внутри подписываемого узла;
  • подписываемый узел может находиться внутри структуры XML-подписи.

4. Для проверки действительности ЭП необходим доступ к объекту подписания.

Структура SOAP-коверта

В общем случае сообщение состоит из заголовка и тела: Header и Body . Header содержит метаданные, а Body данные. XML-подпись помещается в узел Header .

Криптографические алгоритмы и каноникализация.

Для решения задачи были использованы ГОСТ Р 34.11-94 - российский криптографический стандарт вычисления хеш-функции и ГОСТ Р 34.10-2001 - стандарт электронной подписи.

В силу гибкости правил составления XML, одна и та же структура документа и одна и та же часть информации могут быть представлены различными XML-документами. Рассмотрим два документа:

С логической точки зрения они равнозначны, то есть имеют одинаковую XML-схему. Но XML-файлы этих листингов не содержат одну и ту же последовательность символов, что повлечёт разные результаты, например, при получении значения хэша.

Во избежание подобных разночтений были приняты строгие правила форматирования и требования к содержанию XML-сообщений. Процесс приведения XML-документов к унифицированному (каноническому) виду называют каноникализацией (англ. Canonicalization). Примерами правил может быть применение определённой схемы кодирования (UTF-8), нормализация значений атрибутов, использование двойдых кавычек для значений атрибутов, определённый порядок атрибутов и объявлений пространств имён, и др. Каноникализация XML бывает нескольких видов, которые отличаются составом правил. Побробнее о процессе каноникализации можно прочитать в официальной спецификации W3C (русскоязычные статьи на эту тему можно найти и )

Библиотека SIRCrypt

Для реализации подписания XML в DIRECTUM была написана COM-библиотека, внутри которорй описаны 3 класса: Hasher , Signer и XMLCanonicalizer для получения хэша, значения ЭП и каноникализации XML-документов соответственно.

Для функционирования библиотеки требуется Crypto PRO CSP (тестировалась на версии Crypto PRO CSP 3.6.6497 KC2 ) и .NET (минимально 2.0).

Регистрация библиотеки выполняется выполнением следующей команды:

> regasm.exe "путь к dll" /codebase /tlb

Объект Hasher для вычисления хэша по ГОСТ

Содержит поля Content (тип "строка") и HashValueAsBase64 (тип "строка"), а также метод для вычисления значения хэш-функции Hash() . Для вычисления необходимо означить Content , вызвать метод Hash() , в результате которого в поле HashValueAsBase64 запишется значение хэш-функции в Base64.

Объект Signer для получения значения ЭП по ГОСТ

Содержит поля Content (тип "строка"), ContainerName (тип "строка"), CertificateAsPEM (тип "строка"), BESignatureValueAsBase64 (тип "строка"), метод Sign() . После инициализации объекта необходимо означить Content (данные для подписания), ContainerName (имя контейнера закрытого ключа сертификата), вызвать метод Sign() . После чего в поле CertificateAsPEM попадёт соответствующий закрытому ключу сертификат в Base64, а в поле BESignatureValueAsBase64 значение подписи в виде Base64-строки.

Объект XMLCanonicalizer для каноникализации XML

Содержит поля XMLContent (тип "строка"), CanonicalXML (тип "строка"), метод C14NExc() . Для получения канонической формы XML нужно означить XMLContent , вызвать C14NExc() , получить результат из поля CanonicalXML .

Структура XML-подписи

Создание подписи выглядит следующим образом: сначала формируется основа soap-пакета, узлы Header и Body . Body заполняется данными и добавляется атрибут wsu:ID="Body" - идентификатор подписываемых данных.

Заполнение структуры Security происходит в следующем порядке:

  1. Берётся значение хэш-функции от узла Body в каноническом виде и помещается в узел DigestValue.
  2. Узел SignedInfo приводится к каноническому виду, подписывается ЭП. Результат в формате Base64-строки попадает в узел SignatureValue .
  3. Открытый ключ сертификата, которым было выполнено подписание помещается в узел BinarySecurityToken в формате строки Base64.

Для того, чтобы проверить сформированную таким образом ЭП необходимо проделать все действия в обратном порядке, а именно:

  1. получить каноническую форму элемента SignedInfo .
  2. С использованием резльтата предыдущего шага проверить, действительно ли значение ЭП из узла SignatureValue с помощью открытого ключа сертификата. На данном этапе проверяется только корректность ЭП, что не гарантирует неизменность данных.
  3. Если проверка действительности ЭП пройдена успешно, сравнивается хэш из узла DigestValue и хэш от узла с данными. Если они неравны, то подписанные данные изменены и вся ЭП недействительна.

Пример использования

Пакет разработки и библиотека

Примеры подписания XML на ISBL (сценарий): dev.zip (5,95 Кб)

Для постоянного использования код, выполняющий типовое подписание готового SOAP-конверта, вынесен в функцию SignSOAP() .

Для подписания используется сертификат из личного хранилища сертификатов текущего пользователя.

С того момента, как оборот деловых документов и переписки в электронном режиме стал набирать популярность, крайне необходимым стал процесс определения подлинности электронного файла и его подписания. Работа с электронно-цифровой подписью и файлами различного формата уже стала привычным делом нашей жизни. Но у тех, кто сталкивается с подобным действием впервые, неизбежно возникает вопрос, как подписать файл ЭЦП. В зависимости от варианта создания различается и способ проставления данной подписи. Поэтому нужно разобрать особенности каждого из способов.

Заверка текстов, созданных в XML

Если вам предстоит подписать отчет, составленный в XML, то стоит учитывать, что существует несколько вариантов для осуществления этого действия.

  1. Вы можете использовать новый компонент Microsoft Office – InfoPath 2003 года для формирования ЭЦП в XML-формате.
  2. Создание автографа, как для обычного формата. При этом вам нужно будет использовать программу КриптоПро.

Нередко для подписания отчетов с таким форматом в его тэге необходимо создание дополнительного атрибута. В него от символьной строчки, длина которой изменяется и которая содержит значение атрибутов, заносится цифровая подпись. Подобный подход, который является достаточно интересным, но, тем не менее, вполне приемлемым, также можно встретить достаточно часто.

Работа с форматом PDF

Часто возникает вопрос, как подписать файл электронной подписью, если документ создан в формате PDF. Для того, чтобы формировать и проверять ЭЦП документации, созданной в формате PDF, компанией «КриптоПро» была разработана программа «КриптоПро PDF». Данный продукт является способом формирования, а также проверки ЭЦП для писем, которые были созданы в программах Adobe Acrobat, Adobe Reader.

Достаточно важным фактом является то, что «КриптоПро» является бесплатной программой, то есть для ее использования вам не придется осуществлять оплату за предоставленные услуги. Чтобы пользоваться данной программной, вам потребуется ее установить, и уже после этого вы сможете проверять документы.

Подписываем многофайловые отправления

Иногда возникает вопрос, как подписывать фалы ЭЦП, если отправление содержит не один, а несколько актов. В таком случае вы можете формировать свой заверительный автограф отдельно для каждого из них.

Если же такой вариант по каким-либо причинам невозможен, вы можете создать дополнительный элемент текстового типа, куда впоследствии и запишете идентификационные параметры документа, а также – показатели хэш-функций каждого отдельного файла в документе. Это упростит работу и вам, и получателю письма.

Не могу придти к общему пониманию механизмов подписи xml-документов. Буду благодарен за помощь разобраться)

Ситуация у меня такая:

1) есть удостоверяющий центр, выпущенные сертификаты которого проставляются на серверах в хранилище windows.. в личные, доверенные и так далее..не суть.

При логине в приложение пользователь подписывает случайно сгенерированную строку выбранным им сертификатом. На сервере эта подпись проходит проверку:

CAPICOM.SignedData _signedData = new CAPICOM.SignedData(); _signedData.Verify(signedData, false, CAPICOM_SIGNED_DATA_VERIFY_FLAG.CAPICOM_VERIFY_SIGNATURE_AND_CERTIFICATE); if (_signedData.Content != data) throw new Exception("Контент подписи не совпадает с полученным контентом"); var _certificate = _signedData.Certificates; // сертификат пользователя

Так мы получаем сертификат пользователя (открытый ключ). Важно то, что подпись пройдет проверку только в том случае, если соответствующий открытый ключ сертификата стоит на сервере в хранилище сертов. Это нам и нужно, пускать только тех, чьи серты мы сами выпускали) Здесь вроде понятно.

2) теперь нужно, чтобы эти же пользователи подписывали своими сертами xml-и. Моё ПО на клиенте генерит сами xml-и и подписывает их указанным пользователем сертификатом:

Public static void SignXml(XmlDocument xmlDoc, /*RSA*/AsymmetricAlgorithm Key) { SignedXml signedXml = new SignedXml(xmlDoc); signedXml.SigningKey = Key; Reference reference = new Reference(); reference.Uri = "";//подпись всего xml-документа XmlDsigEnvelopedSignatureTransform env = new XmlDsigEnvelopedSignatureTransform(); reference.AddTransform(env); signedXml.AddReference(reference); KeyInfo keyInfo = new KeyInfo(); keyInfo.AddClause(CryptService.GetKeyInfoClause(Key)); // RSA or GOST signedXml.KeyInfo = keyInfo; signedXml.ComputeSignature(); XmlElement xmlDigitalSignature = signedXml.GetXml(); xmlDoc.DocumentElement.AppendChild(xmlDoc.ImportNode(xmlDigitalSignature, true)); }

XmlDocument doc = new XmlDocument(); doc.PreserveWhitespace = true; doc.Load(path); SignedXml sx = new SignedXml(doc); XmlNodeList nodeList = doc.GetElementsByTagName("Signature"); sx.LoadXml((XmlElement)nodeList); return sx.CheckSignature();

Код работает, но у меня возникают вопросы с пониманием: в таком случае можно подписать xml абсолютно любым сертификатом, не выпущенным нашим УЦ, и так как инфа об открытом ключе хранится в самом подписанном xml, подпись проходит проверку. Этот вариант мне не подходит. У метода CheckSignature есть перегрузка с параметром типа AsymmetricAlgorithm , который проверит сертификат подписи на существование в хранилище, проверит его валидность, срок действия и так далее. Это мне и нужно, но я не знаю заранее какой из пользователей прислал подписанный xml.

Скажите пожалуйста: как проверять подпись xml или как её правильно создавать, чтобы проверку подписи проходили только те xml-и, которые подписаны только нашими сертификатами (которые установлены в хранилище)?

P.s. и в чем вообще смысл держать в xml и саму подпись, и открытый ключ для расшифровки подписи? Если при подписи убрать строку signedXml.KeyInfo = keyInfo; , то xml проверку подписи не проходит.

Понравилось? Лайкни нас на Facebook