Delphi xml канонизация

XMLDSig: формат подписи XML

Опубликовано:
29 августа 2012 в 19:02

На одном из идущих в настоящее время проектов решалась задача подписания (наложения ЭП — электронной подписи) 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» — идентификатор подписываемых данных.

Читайте так же:

Delphi имя файла без расширения

Далее нужно подготовить структуру Security и включить её в Header.

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

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

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

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

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

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

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

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

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

Cертификат для тесподписания можно получить на тестовом центре сертификации КриптоПРО.

Delphi xml канонизация

rvc44
Автор

Сообщений: 2207
Откуда: Тамбов

Здесь www.w3.org описано что такое каноникализация XML-документа. Каноникализация — это приведение документа к каноническому виду в соответствии со строго определенными правилами, не допускающими вольных трактовок в наименованиях тэгов, элементах и атрибутах XML-документов. Во многих современных языках, таких как java, есть уже готовые классы-каноникализаторы. Достаточно создать экземпляр такого класса и подать ему на вход xml-документ:
Для Delphi существует библиотека Clever Internet Suite фирмы CleverComponents, в которой содержится необходимая процедура каноникализации TclXmlCanonicalizer. На сайте фирмы CleverComponents размещена очень подробная статья, написанная Сергеем Широковым, «SOAP security: digital signature»: www.clevercomponents.com, в которой объясняется как работает Canonicalizer, приведены примеры и дана прямая ссылка на его исходники на Delphi: www.clevercomponents.com. Также, по адресу www.xml.com доступна статья «XML Canonicalization» by Bilal Siddiqui, с 15-тью примерами XML-файлов, подробно разъясняющая что такое Каноникализация, и как это работает! Так что, вооружившись этим материалом можно попробывать написать свой Каноникализатор на VFP.

P.S. Важное замечание: Для системы межведомственного электронного взаимодействия (СМЭВ) каноникализация подписываемых ЭЦП XML-документов должна применяться в обязательном порядке!

Влад Колосов

Сообщений: 22664
Откуда: Ростов-на-Дону

Разве DOM XML не делает проверку на well formed XML?
Или речь идет о переформатировании?

rvc44
Автор

Сообщений: 2207
Откуда: Тамбов

Я полагаю, всё-таки переформатирование! Посмотри сам!

rvc44
Автор

Сообщений: 2207
Откуда: Тамбов

Влад Колосов

Сообщений: 22664
Откуда: Ростов-на-Дону

rvc44
Автор

Сообщений: 2207
Откуда: Тамбов

Влад Колосов

Сообщений: 22664
Откуда: Ростов-на-Дону

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

Igor Korolyov

Я думаю что так делать не следует по целой массе причин (начиная с того что это будет пустая трата кучи времени — и повторно — при изменениях в базовой компоненте. Идеального софта не существует, и если компонента поддерживается, то в её код обязательно будут вносится изменения, и тебе придётся их дублировать в фоксовый порт). А вот сделать из дельфовской компоненты утилитку — exe, или (лучше) COM сервер — т.е. по сути «завернуть» ту компоненту в вид пригодный для использования из фокса — чтобы он собственно и проводил эту операцию — это было бы неплохо.

rvc44
Автор

Сообщений: 2207
Откуда: Тамбов

Igor Korolyov

Очевидно, в книжках по дельфи

rvc44
Автор

Сообщений: 2207
Откуда: Тамбов

Всё-таки мне удалось реализовать на чистом VFP ЭЦП не только в формате pkcs7 (c вложенными сертификатами, атрибутами ЭЦП), но и в формате XMLDSig (значение зашифрованного хеша = CryptSignHash), причем обе разновидности, т.е. как enveloping signature, так и enveloped signature, для СМЭВ по ГОСТ Р 34.11-94/ГОСТ Р 34.10-2001. О разновидностях XMLDSig популярно написано здесь: www.di-mgt.com.au.
Пока реализовывал XMLDSig по ГОСТу разобрался и написал еще реализацию XMLDSig по алгоритму RSA-SHA1. Теперь занимаюсь каноникализацией, которая однозначно предполагает переформатирование документа. Пытаюсь перевести код с Delphi, поскольку вопреки сложившемуся мнению в каноникализации нет ничего страшного. Там всего не более 8 конкретных преобразований над XML-документом, которые необходимо выполнить.

Читайте так же:

Индивидуальные средства защиты от статического электричества

Вот возник вопрос, как перевести данный код на VFP:
Здесь типом oRootNode является IXMLDOMNode (увы, типизации нет в VFP),
т.е. допустимы выражения: oRootNode.childNodes.item(i) или oRootNode.nodeName

Только через определение TYPE(oRootNode) / VARTYPE(oRootNode) ?

rvc44
Автор

Сообщений: 2207
Откуда: Тамбов

Наконец-то мне удалось завершить и отладить реализацию запросов через СМЭВ в ПФР (в качестве транспорта используется создаваемый объект XMLHTTP). Система СМЭВ и обратная сторона успешно проверяют мою ЭЦП по ГОСТ Р 34.11-94. Я очень благодарен всем, кто помогал мне в этом своими советами, особенно Игорю Королёву! Каноникализация (или C14N) оказалась вещью очень привиредливой. При отправке неправильно каноникализированного XML-запроса в СМЭВ, не пройдет проверка ЭЦП и обязательно возвратится ошибка:
При реализации каноникализации следует учитывать тот факт, что все атрибуты XML-тэгов делятся на два вида: 1) нэймспейсы, или по русски пространства имен в XML и 2) просто обычные атрибуты. Неймспейс отличается от обычного атрибута тэга тем, что начинается с префикса xmlns. Необходимо при помощи XML DOM выстроить в алфавитном порядке сначала (!) все неймспейсы, а вслед за ними (также по алфавиту) обычные атрибуты. Сортировка всех атрибутов вперемешку с неймспейсами приведет к неверному результату каноникализации! Важно учесть ещё одно правило, не реализованное в CleverComponents (по крайней мере, я этого там не нашел): если в подписываемом XML-узле (или XML-узле по которому рассчитывается хэш) есть ссылка на неймспейс вышестоящего (родительского) узла, то данный неймспейс родительского узла необходимо вставить в качестве атрибута-неймспейса для подписываемого узла. Если это не сделать, то каноникализация также не заработает! Это, пожалуй, основные моменты, на которые следует обратить внимание при реализации каноникализации. Много интересного про каноникализацию можно почитать по приведенным ссылкам из предыдущих постов.

XMLDSig: формат подписи XML

Опубликовано:
29 августа 2012 в 19:02

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

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

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

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

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

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

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

Читайте так же:

Ldap search php

Библиотека SIRCrypt

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

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

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

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

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

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

Далее нужно подготовить структуру Security и включить её в Header.

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

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

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

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

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

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

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

Cертификат для тесподписания можно получить на тестовом центре сертификации КриптоПРО.

Что такое правильная XML эксклюзивная канонизация?

Я использую xmlseclibs , чтобы попытаться подписать документ SOAP, но он, похоже, не канонизирует вещи таким же образом в зависимости от того, подписываю ли я или проверяю.

Я приведу вам пример. Это XML я пытаюсь подписать:

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

Читайте так же:

Serial port php

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

Однако, когда он идет для проверки подписи, это каноническая форма, которую он вычисляет для проверки (опять же, я добавил новые строки здесь):

Таким образом, как вы можете видеть, эта версия опускает атрибут xmlns:saml из элемента , в то время как первый не делает. (Обратите внимание,что это отличается от атрибута xmlns:samlp , который включен в оба.) Это кажется довольно ясно, как ошибка в xmlseclibs, но тем не менее это тот, который я был бы рад исправить сам, если бы я просто знал, какая каноническая форма была правильной. Должен ли этот атрибут быть опущен исключительной канонизацией? Или он должен быть включен? Какая из них является правильной исключительной канонической формой?

2 Ответа

Так же как и правильная каноническая форма!

Подпись XML имеет объявление пространства имен, которое идет после атрибутов, не относящихся к пространству имен, что нарушает правило порядка документов:

Узлы пространства имен имеют меньшую позицию порядка документов, чем узлы атрибутов.

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

Я не знаю достаточно о xmlseclibs, чтобы сказать, почему это происходит, но это определенно неправильно по обоим пунктам. FWIW функция c14n на моем DOM здесь говорит:

eta: я только что посмотрел на xmlseclibs.php в SVN, и это непросто исправить, поскольку его нынешний подход в корне ошибочен. Он пытается создать “canonicalised” DOM и затем сериализует его с обычным старым saveXML() . Поскольку существуют правила сериализации C14N о порядке атрибутов и экранировании символов, которым saveXML не обещает следовать, это никак не может сработать.

Вы создаете документ DOM неправильно и пытаетесь использовать недопустимое дерево в памяти. Либо сериализуйте и используйте сериализованный результат, либо правильно создайте объявления пространства имен в дереве перед попыткой подписи. Смотрите отчет об ошибке для получения дополнительной информации: http://code.google.com/p/xmlseclibs/issues/detail?id=6

Использование XML в среде Delphi

Использование СOM в среде Delphi

Последнее время много внимания уделяется построение систем электронного бизнеса, или как их еще называют — B2B (business to business). Учитывая рекомендации по построению обменных потоковых систем координирующего интернет-технологий органа — WWW Consortium: акцент сделан в сторону XML-технологий и построение систем обмена XML-документами.

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

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

Во всех системах обмен, как правило, строится по одинаковой схеме, с использованием HTTP запросов. В качестве протокола защиты информации применяется протокол SSL (но это отдельная тема).

Один из возможных вариантов обработки XML сообщения является построение BIN/CGI (ISAPI)-приложений или COM (серверных) компонент, формирующих или обрабатывающих XML-документы.

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

Один из наиболее эффективных вариантов реализации — использование существующего XML-парсера, поддерживающего DOM модель. Такой парсер является дистрибутивной поставкой Win`98 или составной частью IE 4,7 и выше (для Win`95) и представляет COM сервер, находящийся в библиотеке msxml.dll.

Модель компонентных объектов (COM) — представляет инкапсулированные данные и методы в единую сущность и способ доступа к ним через систему интерфейсов. Средствами Delphi достаточно просто осуществить доступ к классам COM-объекта (в одном COM-сервере может быть включено несколько классов). Доступ к объектам осуществляется путем инициализации экземпляра класса через систему интерфейсов. Описание интерфейсов осуществляется языком определения интерфейсов (IDL), которое возможно осуществить средствами среды автоматически.

Средствами Delphi осуществляется импорт из COM-сервера msxml.dll, строится файлы описания интерфейса IDL и файл бинарного описания типов библиотеки — TLB. Данная операция осуществляется через системное меню: Project | Type Library Import: (рисунок 1). Далее появляется диалоговое окно (рисунок 2), в котором необходимо выбрать COM-объект (в нашем случае объект зарегистрирован под именем «Microsoft.XMLDom (Version 2.0)» ) и создать TLB-файл (кнопка Create Unit). Используя TLB-файл, среда генерирует «паскалевский» файл описания COM-сервера — MSXML_TLB.pas

В файле MSXML_TLB.pas описаны все интерфейсы, константы и соклассы COM-сервера.

Для доступа к объектам COM-элемента, необходимо в директиве USES добавить имя файла описания библиотеки (MSXML_TLB.pas). Ниже представлена простейшая программа, использующая DOM стандартный анализатор msxml.dll, которая загружает XML-документ и отображает его в элементе текстового поля Memo1.

Концепция DOM — объектная модель документа

Каждый XML документ представляется в виде набора множества объектов (классов), с помощью которых возможен доступ к отдельным элементам (полям объекта). DOM — интерфейс описывает доступ как к простым объектам типа DOMString или CharacterData, так и к частям или отдельным элементам XML документа: DOMFragmentElement, DOMNode, DOMElement.

голоса

Рейтинг статьи

Delphi xml канонизация

XMLDSig: формат подписи XML

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

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

Библиотека SIRCrypt

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

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

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

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

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

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

Delphi xml канонизация

XMLDSig: формат подписи XML

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

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

Библиотека SIRCrypt

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

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

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

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

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

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

Что такое правильная XML эксклюзивная канонизация?

2 Ответа

Похожие вопросы:

Использование XML в среде Delphi

Использование СOM в среде Delphi

Концепция DOM — объектная модель документа