Как подписать документ электронной подписью. Подпись документов, файлов 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() .

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

ML, или расширяемый язык разметки (eXtensible Markup Language), в настоящее время становится стандартным способом транспортировки информации в Web (и не только). Более того, появляются все новые и новые надстройки, в которых применяется синтаксис XML (XML-приложения). Например, к таковым относится упрощенный протокол доступа к объектам SOAP (Simple Object Access Protocol), в котором XML выступает в качестве универсального средства представления параметров вызова удаленных процедур RPC (Remote Procedure Call). Другим примером надстройки является оболочка описания ресурсов RDF (Resource Description Framework). Можно заглянуть на сайт консорциума World Wide Web (W3C), разрабатывающий стандарты в этой области (http://www.w3.org/), и убедиться, что языку XML действительно уделяется повышенное внимание.

Напомним, что основным назначением XML является описание структуры и семантики документа. Основным преимуществом XML по сравнению с другими форматами электронных документов является то, что в нем описание внешнего представления документа отделено от структуры документа и его содержания. XML является гибким языком, который можно использовать для различных целей, при этом он способен обеспечить взаимодействие со многими системами и базами данных. Таким образом, уже сегодня XML используется во многих информационных системах в качестве основного формата обмена данными. Более того, мощный шаг навстречу XML сделали производители систем управления базами данных. Например, корпорация Oracle выпустила утилиту XSU (XML-SQL Utility), которая является надстройкой над JDBC, позволяющей сохранять XML-данные в базе данных и извлекать их оттуда (http://otn.oracle.com/tech/xml/xdk_java/content.html). XSU представляет собой иерархию Java-классов, предназначенную для трансформации данных из таблиц и представлений (views) объектно-реляционной базы данных в формат XML, вставки данных из XML-документов в таблицы и представления и других полезных операций.

Потребность в защите XML-документов

ML — мощное средство, часто применяемое для обмена данными через Интернет. Но, к сожалению, само по себе оно не обеспечивает необходимую защиту данных, которые «перевозит». Иными словами, существуют серьезные проблемы безопасности при применении формата XML (как, впрочем, и при использовании других форматов).

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

• аутентификации взаимодействующих сторон;
• подтверждении подлинности и целостности информации;
• криптографическом закрытии передаваемых данных.

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

Общие сведения об электронной цифровой подписи

ЭЦП и возможность ее подделки

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

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

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

Центр сертификации

Выше мы упоминали термины «секретный ключ» и «открытый ключ». Откуда взялись эти ключи? Их формирует центр сертификации — некоторая структура (организация), которая занимается управлением сертификатами. Сертификат открытого/закрытого ключа представляет собой следующую совокупность данных:

• имя субъекта или объекта системы, однозначно идентифицирующее его в системе;
• открытый/закрытый ключ субъекта или объекта системы;
• дополнительные атрибуты, определяемые требованиями использования сертификата в системе;
• электронная цифровая подпись издателя (центра сертификации), заверяющая совокупность этих данных.

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

Каждому зарегистрированному пользователю информационной системы сертификационный центр (СЦ) формирует два сертификата — сертификат закрытого ключа и сертификат открытого ключа. При этом первый СЦ выдает лично в руки зарегистрированному пользователю (например, на дискете) и никому другому — это и есть «подпись». Второй сертификат — открытый — СЦ публикует в общедоступном хранилище, чтобы любой заинтересованный мог легко его найти.

Формирование и проверка ЭЦП

Отправитель информации с помощью секретного ключа и заранее выбранного по договоренности между абонентами асимметричного алгоритма (алгоритма ЭЦП) шифрует передаваемую информацию, представленную в цифровом виде, и таким образом получает цифровую подпись данных. Далее отправитель информации по открытому каналу связи посылает незашифрованную информацию и полученную вышеописанным способом цифровую подпись получателю.

Получатель сообщения с помощью открытого ключа (который общедоступен) и выбранного по договоренности между абонентами алгоритма ЭЦП рассекречивает цифровую подпись. Далее он сравнивает принятую им незашифрованную информацию и информацию, полученную при расшифровке цифровой подписи. Если цифровая подпись не была подделана и передаваемая открытая информация не искажена, то эти две информации должны полностью совпасть. Если подпись подделана, то принятая открытая информация и информация, полученная при дешифровании, будут существенно различаться (рис. 1).

Хэш-функции

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

Используемая хэш-функция должна уметь преобразовывать сообщение любой длины в бинарную последовательность фиксированной длины. Кроме того, она должна удовлетворять следующим требованиям:

• сообщение после применения хэш-функции должно зависеть от каждого бита исходного сообщения и от порядка их следования;
• по хэшированной версии сообщения нельзя никакими способами восстановить само сообщение.

Общие сведения о шифровании

Шифрование данных и его отличие от ЭЦП

Шифрование информации — взаимно-однозначное математическое (криптографическое) преобразование, зависящее от ключа (секретный параметр преобразования), которое ставит в соответствие блоку открытой информации, представленной в некоторой цифровой кодировке, блок шифрованной информации, также представленной в цифровой кодировке. Шифрование объединяет два процесса: зашифрование и расшифровку информации (рис. 2).

Принципиальное различие методов ЭЦП и шифрования (мы сейчас рассматриваем асимметричные алгоритмы, в которых для шифрования и расшифровки применяются различные, но связанные между собой математически ключи) заключается в том, что при шифровании используется открытый ключ получателя, а при расшифровке — закрытый, тогда как в алгоритме ЭЦП для подписания некоторого сообщения требуется секретный ключ автора, а для проверки ЭЦП — открытый ключ автора сообщения.

Взлом

Теоретически любой шифровальный алгоритм с использованием ключа может быть вскрыт методом перебора всех значений ключа. Если ключ подбирается, требуемая мощность компьютера растет экспоненциально с увеличением длины ключа. Ключ длиной в 32 бит требует 232 (около 109) шагов. Такая задача под силу любому дилетанту и решается на домашнем компьютере. Системы с 40-битным ключом (например, экспортный американский вариант алгоритма RC4) требуют 240 шагов — такие компьютерные мощности имеются в большинстве небольших компаний. Системы с 56-битными ключами (DES) требуют для вскрытия заметных усилий, однако они могут быть легко вскрыты с помощью специальной аппаратуры. Стоимость такой аппаратуры значительна, но доступна для мафии, крупных компаний и правительств. Ключи длиной 64 бит в настоящий момент, возможно, могут быть вскрыты крупными государствами, а уже в ближайшие несколько лет будут доступны для вскрытия преступным организациям, крупным компаниям и небольшим государствам. Ключи длиной 80 бит могут стать уязвимыми в будущем. Ключи длиной 128 бит в обозримом будущем, вероятно, останутся недоступными для вскрытия методом перебора. Можно использовать и более длинные ключи.

Однако длина ключа — это еще не все. Многие шифры можно вскрыть, не перебирая всех возможных комбинаций, а применяя специальный алгоритм (например, с полиномиальной сложностью). Вообще, очень трудно придумать шифр, который нельзя было бы вскрыть при помощи другого способа, более эффективного, чем перебор.

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

Электронная цифровая подпись XML-документов

Работающие с XML уже давно поняли важность механизма контроля над данными, передаваемыми и представляемыми в XML. Основные требования, предъявляемые к передаваемым данным, — аутентификация взаимодействующих сторон и подтверждение подлинности и целостности информации в XML-документе. Такие задачи решает ЭЦП XML-документов.

Спецификации на ЭЦП XML от W3C

Консорциум W3C разрабатывает сейчас спецификацию «XML — Signature Syntax and Processing» («Синтаксис и обработка подписи XML») и другие связанные с этим документы. Пока она имеет статус рекомендации (http://www.w3.org/TR/xmldsig-core/). Этот документ предусматривает подпись как всего XML-документа, так и его части. Для взаимооднозначности процесса подписания XML определяется понятие канонического представления XML-данных. Например, в XML-документе тэги, стоящие на одном и том же уровне в дереве иерархии, могут перемешиваться между собой, создавая таким образом неоднозначность для процесса подписания. Каноническое представление XML — это своеобразная сортировка (а точнее, приведение к простейшему виду), не допускающая таких вольностей. Методы и правила канонизации XML описываются в отдельном документе — «Canonical XML» (http://www.w3.org/TR/xml-c14n), который также имеет статус рекомендации. Другие связанные с подписанием XML-документа материалы доступны по адресу: http://www.w3.org/Signature/ .

Тэг — подпись XML

Рекомендация «XML — Signature Syntax and Processing» определяет, что подпись и информация о ней должны содержаться в тэге , который имеет следующие части (в основном они нужны для верификации подписи):

• метод канонизации (CanonicalizationMethod) определяет конкретный набор правил для упрощения и структурирования экземпляра XML до подписания. Эти сведения обеспечивают надлежащий вид подписываемых данных, чтобы алгоритм проверки дал положительный результат, если содержательные данные не были изменены;
• метод подписи (SignatureMethod) определяет алгоритм подписи дайджеста сообщения. Дайджест сообщения — это уникальная символьная строка фиксированного размера, она является результатом обработки данных с помощью односторонней хэш-функции, задаваемой методом дайджеста;
• метод дайджеста (DigestMethod) — алгоритм составления дайджеста сообщения, подписываемого с помощью заданного метода подписи. Задание определенного метода дайджеста гарантирует обработку данных одним и тем же способом;
• значение дайджеста (DigestValue) — собственно дайджест сообщения, то есть строка фиксированной длины, выдаваемая в результате обработки данных с помощью алгоритма дайджеста. Такая строка является уникальной и необратимой: ее практически невозможно получить из другого содержимого, как и невозможно воссоздать по ней исходные данные. Это как бы отпечаток пальцев для подписываемых данных; положительный результат сравнения значений дайджеста гарантирует целостность содержимого;
• непосредственно подпись (SignatureValue) — это данные, получаемые после обработки методом подписи;
• информация о открытом ключе (KeyInfo) — ключ для верификации ЭЦП. Точнее, не ключ, а сертификат, потому что в нем, кроме самого ключа, могут быть указаны имя владельца и алгоритм ЭЦП.

Естественно, что это не исчерпывающая информация о том, что может содержаться в тэге . Вот простейший пример такой подписи (листинг 1).

Формирование ЭЦП XML

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

Проверка ЭЦП XML

Для проверки подписи нужно выполнить два шага: проверку самой подписи и проверку значения дайджеста.

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

ШифрованиеXML-документов

Спецификации W3C о шифровании XML

Перейдем к шифрованию, которое позволяет нам закрыть (то есть преобразовать в такой вид, при котором будет непонятен смысл) передаваемые данные и восстановить их на принимающей стороне. В консорциуме W3C создана рабочая группа (http://www.w3.org/Encryption/2001/), которая специально занимается вопросами шифрования XML-данных. Спецификация «XML — Encryption Syntax and Processing» («Синтаксис и обработка шифрования XML») сегодня получила статус рекомендации и доступна по адресу: http://www.w3.org/TR/xmlenc-core/ .

Тэг

• метод шифрования (EncryptionMethod) описывает алгоритм шифрования данных. Если этот тэг отсутствует, то алгоритм шифрования должен быть известен принимающей стороне, иначе расшифровка сообщения невозможна;
• шифрованные данные (CipherData) — собственно зашифрованные данные или ссылка на их местоположение. Разнообразие подлежащих шифрованию типов данных и методов их логической организации практически ничем не ограничено;
• информация о ключах (KeyInfo) — сведения о ключах, с помощью которых выполняются шифрование и соответственно дешифрование. Они могут храниться в другом месте и заменяться в экземпляре XML на ссылку URL;
• другая информация (например, о предполагаемых получателях).

Пример тэга представлен на листинге 2 .

Процесс зашифрования и дешифрования

Шифрование данных XML производится традиционными методами криптографии с открытыми ключами. Сначала шифруются сами данные, как правило, с помощью случайно формируемого секретного ключа, который затем тоже кодируется — при помощи открытого ключа предполагаемого получателя. Эта информация упаковывается так, чтобы извлечь секретный ключ и расшифровать данные мог только указанный получатель. Для дешифрования секретного ключа применяется скрытый ключ, а затем происходит дешифрование данных с помощью найденного секретного ключа.

Реализация защиты XML-документов

Мы рассмотрели общие принципы работы электронной цифровой подписи и спецификации, которые выработал консорциум W3C в этой области. Все это хорошо, но что если действительно имеется потребность в реализации описанных схем защиты XML-данных?

Уже сегодня, несмотря на то что стандарты W3C появились совсем недавно, некоторые компании объявили о выпуске своих пакетов (библиотек классов), реализующих и ЭЦП, и шифрование. Рассмотрим возможности некоторых из них.

XML Security Suite (IBM)

Этот пакет, основанный на языке программирования Java, доступен по адресу http://www.alphaworks.ibm.com/tech/xmlsecuritysuite . XML Security Suite является средством, обеспечивающим такие элементы безопасности, как цифровая подпись, шифрование и управление доступом для документов XML. С его помощью можно добиться больших успехов, нежели используя возможности протоколов безопасности транспортного уровня (например, Secure Sockets Layer, SSL).

Этот пакет реализует три технологии:

• ЭЦП основана на спецификации «XML — Signature Syntax and Processing» от W3C и IETF (и на спецификации «Canonical XML»);
• шифрование реализовано на основе спецификации «XML — Encryption Syntax and Processing» от W3C;
• управление доступом для документов XML (XML Access Control Language).

XML Security Suite — это одно из лучших современных средств для защиты XML-документов. Кроме самого архива (JAR) с библиотекой классов, оно включает подробную документацию и примеры, позволяющие быстро сориентироваться в иерархии классов.

XML Security (Apache)

Защита данных на основе XML

Язык разметки заявлений системы безопасности (SAML)

Направление, отличное от защиты XML-данных, но тесно с ним связанное, — это улучшение безопасности и защищенности систем (протоколов) на базе XML. В этом случае при помощи XML защищаются другие документы/системы/приложения. В настоящее время комитет безопасности Организации по развитию стандартов структурирования информации (Organization for the Advancement of Structured Information Standards, OASIS) занимается разработкой языка разметки заявлений системы безопасности (Security Assertion Markup Language, SAML).

Федеральный закон «Об электронной цифровой подписи»

Цели

Давайте немного отвлечемся от законодателей в области Web и рассмотрим Федеральный закон «Об электронной цифровой подписи», который был утвержден Президентом РФ 10 января 2002 года (http://www.internet-law.ru/intlaw/laws/ecp.htm). Принятие этого закона обеспечило правовые условия использования электронной цифровой подписи в электронных документах, при соблюдении которых электронная цифровая подпись в электронном документе признается равнозначной собственноручной подписи в документе на бумажном носителе. Таким образом, заложены основы для создания юридически значимого электронного документооборота.

Условия равнозначности ЭЦП и обычной подписи

Закон определяет основные понятия, используемые в процедуре ЭЦП, такие как сертификат, открытый и закрытый ключи, подтверждение подлинности электронной цифровой подписи (мы их рассматривали ранее) и др. Далее закон определяет условия, при которых электронная цифровая подпись в электронном документе равнозначна подписи в документе на бумажном носителе. Это означает в первую очередь то, что сертификат ключа подписи, относящийся к этой электронной цифровой подписи, не утратил силу на момент проверки или на момент подписания электронного документа. Кроме того, должна быть подтверждена подлинность электронной цифровой подписи и то, что ЭЦП используется в соответствии со сведениями, указанными в сертификате ключа подписи.

Сертификаты и удостоверяющие центры

Закон подробно описывает, из чего состоит сертификат ключа подписи (уникальный регистрационный номер, ФИО владельца, открытый ключ ЭЦП, наименование и местонахождение удостоверяющего центра и др.); сроки и порядок хранения сертификата в удостоверяющем центре. Так, срок хранения сертификата ключа подписи в форме электронного документа в удостоверяющем центре определяется договором между удостоверяющим центром и владельцем сертификата ключа подписи. Что касается хранения, то оно определяется законодательством Российской Федерации об архивах и архивном деле.

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

Закрытые (секретные) ключи

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

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

Отечественные стандарты на алгоритмы ЭЦП

Схема Эль-Гамаля

В 1994 году был принят первый отечественный стандарт в области ЭЦП — ГОСТ Р34.10 — 94 «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма». Он определяет процедуры работы с ЭЦП на основе схемы Эль-Гамаля. Невозможность подделки подписи обусловлена сложностью решения задачи дискретного логарифмирования в поле из р элементов или сложностью заданного большому простому числу р и числам a, b из интервала от 2 до р-1 определения числа х, которое выполняется сравнением:

Ax== bmodp.

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

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

Эллиптическая кривая

Российские ученые в конце концов пришли к выводу, что можно немного усложнить схему Эль-Гамаля и таким образом без дополнительных вычислительных затрат во много тысяч раз увеличить сложность подделки ЭЦП. Новый вариант схемы Эль-Гамаля использует аппарат эллиптических кривых над конечным полем из р элементов, которые определяются как множество пар чисел (х,у) (каждое из них лежит в интервале от 0 до p-1), удовлетворяющих сравнению (числа а и b фиксированы и соответствуют некоторому дополнительному условию):

Y2 == x3 + ax + bmodp.

Другие ресурсы

• Информация об Oracle XML-SQL Utility — http://otn.oracle.com/tech/xml/xdk_java/content.html
• Спецификации SAML — http://www.oasis-open.org/committees/security/
• Спецификация XKMS — http://www.w3.org/TR/xkms/
• Федеральный закон «Об электронной цифровой подписи» —

Не могу придти к общему пониманию механизмов подписи 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 проверку подписи не проходит.

Согласно закону 218-ФЗ «О государственной регистрации недвижимости» электронные XML-документы и отсканированные образы документов необходимо подписывать усиленной квалифицированной электронной подписью . Все программы серии «Полигон», «Полигон Про» и программа «Подпись Про» подписывают именно такой подписью.

Для подписания:

Получите ключ подписи (сертификат) в Удостоверяющем центре. Список аккредитованных удостоверяющих центров опубликован на сайте Росреестра (Список удостоверяющих центров). Получить сертификат можно в нашем Удостоверяющем центреООО «Программный центр» .

Вместе с подписью приобретите и установите на компьютер программу КриптоПро CSP (она содержит требующиеся российские стандарты подписи), которую также можно приобрести в нашем Удостоверяющем центре ООО «Программный центр» .

Другие программы для подписи не требуются: КриптоАРМ (возможности КриптоАРМ в части подписи аналогичны возможностям программ серии «Полигон», «Полигон Про» и программы «Подпись Про»).

Программные модули платформы «Полигон Про»

Подписать электронный документ в программе «Полигон Про»

Чтобы подписать XML-файл выполните следующее:

• Сформируйте электронный документ без ошибок.

Подписать XML-файл можно сразу в окне «Просмотр XML », для этого на панели инструментов нажмите кнопку – «Подписать XML-файл» .

• После нажатия откроется окно со списком установленных сертификатов. Выберите нужный и нажмите «ОК» .

• Программа выполнит подписание основного документа и выдаст сообщение об успешном выполнении.

В той же папке, что и подписанный файл, будет сформирован файл подписи с тем же именем, с расширением *.sig .

Подписать группу файлов в программе «Полигон Про»

В программе имеется возможность подписать группу файлов одновременно. Для этого выполните следующее:

• На ленте программного модуля на вкладке «Главная» нажмите кнопку и из подменю выберите . Откроется окно с выбором файлов проекта (по умолчанию все файлы проекта выбраны).



Если в списке присутствуют файлы, которые подписывать не нужно, снимите с них галочки.

• Нажмите кнопку «Подписать» . Откроется окно со списком установленных сертификатов. Выберите нужный и нажмите «ОК» .



Программа выполнит подписание всех документов и выдаст сообщение об успешном выполнении.



Если возникнут ошибки при подписании, будет выведен протокол проверки с предупреждениями и/или ошибками. Для корректного подписания требуется исправить ошибки.

Подписать файл в программных модулях платформы «Полигон Про»

В программе имеется возможность подписать абсолютно любой файл.



Откроется окно со списком установленных сертификатов. Выберите нужный и нажмите «ОК ».



• Программа выполнит подписание документов и выдаст сообщение об успешном выполнении.



В той же папке, что и подписанный файл, будет сформирован файл подписи с тем же именем, с расширением *.sig .


Проверить электронную подпись в программе «Полигон Про»

Если Вы получили подписанный файл извне и хотели бы проверить, не был ли он изменен, либо просто проверить правильность сформированной подписи файла, выполните следующие действия:

• На ленте программного модуля во вкладке «Главная » в подменю кнопки «Подписать все » нажмите на кнопку «Проверить… ».



• Выберите файл, содержащий подпись (с расширением *.sig ), который необходимо проверить, либо подписанный файл.

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



• Откроется протокол с информацией, правильно ли был подписан документ, кем и когда.



Программа «Подпись Про»

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

Как подписать файл электронно-цифровой подписью?

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

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

криптопровайдер «КриптоПро CSP»;

«Крипто АРМ» – эта программа необходима только тогда, когда у Вас не используются программы серии "Полигон", эта программа в части подписания идентична программам серии "Полигон", поэтому она не нужна; для подписания файлов программами серии "Полигон" смотрите предыдущую страницу инструкции; подписывать можно как программами серии "Полигон", так и программой КриптоАРМ, если Вы считаете, что это будет удобнее, чем использовать имеющиеся возможности программ серии "Полигон" ;

Каждый файл (XML, скан печатного документа и файлы приложений) необходимо подписать, так как орган кадастрового учета принимает только пары файлов: оригинальный файл и файл подписи к нему. Чтобы подписать файл необходимо выбрать его в окне проводника и нажать правой кнопкой мыши (ПКМ), появится контекстное меню, в нем следует выбрать пункт «КриптоАРМ», а затем «Подписать… ».







Затем убедиться в правильности имени файла







Важно! установить переключатель в положение «DER-кодировка », папку для выходных файлов указать по своему усмотрению. Нажать кнопку «Далее ». В следующем окне назначить параметры подписи




В этом окне самым важным является указать галочку «Сохранить подпись в отдельном файле ». Нажмите кнопку «Далее ». В следующем окне нажмите кнопку «Выбрать »




откроется окно выбора сертификата




в нем выберите сертификат Вашего ключа (смотрите по имени владельца). После выбора нажмите кнопку «ОК » и «Далее ». В последнем окне перед подписанием документа нажмите кнопку «Готово ».

Важно! Для каждого файла необходимо сделать файл подписи, так как принимается только пара: оригинальный файл (xml или другой) + подпись к нему (sig-файл).

Согласно закону 218-ФЗ «О государственной регистрации недвижимости» электронные XML-документы и отсканированные образы документов необходимо подписывать усиленной квалифицированной электронной подписью . Все программы серии «Полигон», «Полигон Про» и программа «Подпись Про» подписывают именно такой подписью.

Для подписания:

Получите ключ подписи (сертификат) в Удостоверяющем центре . Список аккредитованных удостоверяющих центров опубликован на сайте Росреестра (Список удостоверяющих центров). Получить сертификат можно в нашем Удостоверяющем центре ООО «Программный центр» .

Вместе с подписью приобретите и установите на компьютер программу КриптоПро CSP (она содержит требующиеся российские стандарты подписи), которую также можно приобрести в нашем Удостоверяющем центре ООО «Программный центр» .

Примечание: другие программы для подписи не требуются : КриптоАРМ (возможности КриптоАРМ в части подписи аналогичны возможностям программ серии«Полигон », «Полигон Про » и программы «Подпись Про »).

Примечание: если ключ подписи Вами был получен в Удостоверяющем центре до выхода закона 63-ФЗ "Об электронной подписи" (до 01.07.2013 г.), то такой ключ действует до 01.01.2014 года. Его необходимо заменить на новый для использования в 2017 году. Это связано с тем, что по новому закону в подписи должен быть номер свидетельства СНИЛС (Пенсионного фонда РФ).

Программные модули платформы «Полигон Про»

Подписать электронный документ в программных модулях платформы «Полигон Про»

Чтобы подписать XML-файл выполните следующее:

Примечание: если будут обнаружены ошибки, то ниже структуры XML-файла будет выведен протокол проверки электронного документа с предупреждениями и/или ошибками. Рекомендуется исправить ошибки, а также обратить внимание на предупреждения.

Аналогично можно подписать XML-файл сразу из окна «Просмотр XML », для этого в панели инструментов нажмите на кнопку - « Подписать XML -файл » .

• После нажатия откроется окно со списком установленных сертификатов. Выберите нужный и нажмите « ОК » .

• Далее программа выполнит подписание основного документа и выдаст сообщение об успешном выполнении.

Примечание: в той же папке, что и подписанный файл, будет сформирован файл подписи с тем же именем, с расширением *. sig .

Подписать группу файлов в программных модулях платформы «Полигон Про»

В программе имеется возможность подписать группу файлов одновременно, для этого выполните следующее:

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

• Нажмите на кнопку « Подписать » , после чего откроется окно со списком установленных сертификатов. Выберите нужный и нажмите « ОК » .

• Далее программа выполнит подписание всех документов и выдаст сообщение о подписании.

Примечание: если возникнут ошибки при подписании, будет выведен протокол проверки с предупреждениями и/или ошибками. Для корректного подписания требуется исправить ошибки.

Подписать файл в программных модулях платформы «Полигон Про»

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

• Главная » в подменю кнопки «Подписать все » нажмите на кнопку - «Подписать… », после чего откроется окно выбора файла.

• В открывшемся окне выберите файл, который требуется подписать, и нажмите кнопку «Открыть ».

Откроется окно со списком установленных сертификатов. Выберите нужный и нажмите «ОК ».

• Далее программа выполнит подписание выбранного документа и выдаст сообщение о готовности.

Примечание: в той же папке что и подписанный файл будет сформирован файл подписи с тем же именем, с расширением * . sig .

Проверить электронную подпись в программных модулях платформы «Полигон Про»

Если Вы получили подписанный файл извне и хотели бы проверить, не был ли изменен полученный файл после его подписания, либо просто проверить правильность сформированной подписи файла, выполните:

На ленте программного модуля во вкладке «Главная » в подменю кнопки «Подписать все » нажмите на кнопку «Проверить… ».

Выберите файл содержащий подпись (с расширением *. sig ), который необходимо проверить, либо при необходимости подписанный файл. Если эти два файла находятся в разных папках, то программа выдаст окно с предупреждением, где необходимо нажать на кнопку «Повтор » и выбрать исходный файл.

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

Программа «Подпись Про»

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

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

Как подписать файл электронно-цифровой подписью?

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

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

криптопровайдер «КриптоПро CSP»;

«Крипто АРМ» - эта программа необходима только тогда, когда у Вас не используются программы серии "Полигон", эта программа в части подписания идентична программам серии "Полигон", поэтому она не нужна; для подписания файлов программами серии "Полигон" смотрите предыдущую страницу инструкции; подписывать можно как программами серии "Полигон", так и программой КриптоАРМ, если Вы считаете, что это будет удобнее, чем использовать имеющиеся возможности программ серии "Полигон" ;

Каждый файл (XML, скан печатного документа и файлы приложений) необходимо подписать, так как орган кадастрового учета принимает только пары файлов: оригинальный файл и файл подписи к нему. Для того, чтобы подписать файл необходимо выбрать его в окне проводника и нажать правой кнопкой мыши (ПКМ), появится контекстное меню, в нем следует выбрать пункт «КриптоАРМ», а затем «Подписать… ».

Затем убедиться в правильности имени файла

Важно! установить переключатель в положение «DER-кодировка », папку для выходных файлов указать по своему усмотрению. Нажать кнопку «Далее ». В следующем окне назначить параметры подписи

В этом окне самым важным является указать галочку «Сохранить подпись в отдельном файле ». Нажмите кнопку «Далее ». В следующем окне нажмите кнопку «Выбрать »

откроется окно выбора сертификата

в нем выберите сертификат Вашего ключа (смотрите по имени владельца). После выбора нажмите кнопку «ОК » и «Далее ». В последнем окне перед подписанием документа нажмите кнопку «Готово ».

Важно! Для каждого файла необходимо сделать файл подписи, так как принимается только пара: оригинальный файл (xml или другой) + подпись к нему (sig-файл).