Счетчик HotLog

На главнуюЧто я делаю...Программы автора и не только...Творчество
Статьи автораКнига отзывов и предложенийОбо мне, любимомФотоальбом

  
 

Введение в XML Digital Signatures

Глоссарий

PKCS (Public Key Cryptography Standards) – набор стандартов, разработанных лабораторией RSA Data Security. Эти стандарты были разработаны для обеспечения совместимости между различными реализациями алгоритмов криптографии с открытым ключом, поставляемыми различными разработчиками устройств и программного обеспечения.

PKI (Public key infrastructure) - (дословно: инфраструктура открытых ключей). Система цифровых сертификатов, сертификации авторства и регистрации авторства, позволяющая проверить, аутентифицировать и подтвердить авторство обеих сторон, участвующих в электронной транзакции (обмене информацией).
SSL (Secure Socket Layer) - протокол доступа, защищающий информацию от посторонних пользователей.

SSL (Secure Socket Layer) - протокол доступа, защищающий информацию от посторонних пользователей.

URI (Uniform Resource Identifier) — единообразный идентификатор ресурса. URI — это короткая последовательность символов, идентифицирующая абстрактный или физический ресурс. Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.

XML (eXtensible Markup Language) — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML предназначен для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями. XML является упрощённым подмножеством языка SGML.

 

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

Например, Secure Sockets Layer (SSL) предоставляет защищенный обмен точными данными между браузером и Web-сервером, но как только данные получаются сервером, они перестают быть защищенными. Фактически, SSL защищает данные только во время их транспортировки от клиента к серверу, или, иначе говоря, тогда, когда их редко атакуют. Как вы считаете, что выберет хакер: перехват транспортируемых данных для получения доступа к кредитной карте одного человека или внедрение в конечную базу данных, содержащую данные о тысячах кредиток? Проблема усугубляется тем, что конфиденциальная информация путешествует и перенаправляется с сервера на сервер. Если данные сами по себе шифруются, а не только защищается транспортировка, это снижает риск уязвимости незашифрованных данных, оставленных уязвимыми на публичном сервере.

Не менее чем защита конфиденциальности данных важна их долговременная аутентификация (кем они посланы?), целостность данных (менялись ли данные во время транспортировки?) и поддержка неотрекаемости (может отправитель отказаться от своей подписи?); другими словами, функциональность, которую существующие технологии (например, SSL, аутентификация по имени/паролю) обособленно не предоставляют. Общепризнанным способом удовлетворения этих требований для обмена данными является использование цифровых сертификатов для шифрования и подписания данных. Краткое введение в эту концепцию изложено ниже. Термин «инфраструктура открытых ключей» используется для описания процессов, политик и стандартов, который управляет выдачей, поддержкой и отзывом сертификатов, открытых и закрытых ключей, которые требуются для выполнения операций шифрования и подписания.

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

Две новых технологии, созданных для достижения поставленных задач и использующих все преимущества особенностей формата XML – XML-подпись (XML Signature) и XML-шифрование (XML Encryption). XML Signature – результат совместной работы между World Wide Web Consortium (W3C) и Internet Engineering Task Force (IETF), а XML Encryption разработана усилиями W3C.

 

Введение в шифрование открытым ключом

Шифрование открытым ключом позволяет пользователям незащищенных сетей, например, интернета, обмениваться данными с высоким уровнем уверенности, что они никем не будут изменены или к ним будет получен несанкционированный доступ. Это достигается путем изменения данных на основе алгоритма, описываемого парой чисел – так называемых открытого и закрытого ключа. Каждый участник такого обмена данными имеет такую пару ключей. Открытый ключ является доступным, закрытый ключ недоступен для доступа. Хотя ключи математически связаны, невозможно получить закрытый ключ, зная открытый.

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

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

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

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

Большей частью из-за производительных характеристик алгоритма открытого ключа, кодируется не все тело сообщения, а лишь его малая уникальная проекция, называемая «хешем» (hash) или «дайджестом» (digest). Так как алгоритм хеширования чрезвычайно чувствителен к любому изменению тела документа, хеш оригинала позволяет получателю проверить, не был ли изменен документ (путем сравнения присланного хеша и полученного на основе полученных данных). Дополнительно, шифруя хеш с помощью своего закрытого ключа, отправитель позволяет получателю удостовериться в том, что именно он был автором произведенных трансформаций. Хеш документа, зашифрованный закрытым ключом отправителя, в свою очередь служит подписью документа и может открыто передаваться вместе с ним. Получатель проверяет подпись, рассчитывая хеш сообщения и передавая его в алгоритм вместе с подписью, следующей вместе с сообщением, и открытый ключ отправителя. Если результат успешный, получатель может быть уверен в аутентификации отправителя и целостности сообщения.

 

Введение в XML Signatures

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

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

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

  • Быть URI в XML-подписи;
  • Находиться внутри того же узла, где находится XML-подпись (на этом же уровне);
  • Зависеть от подписи (XML-подпись является родителем);
  • Иметь подпись в качестве потомка (XML-подпись является дочерним узлом).

 

Компоненты XML-подписи

Компоненты цифровой XML-подписи

  • Каждый подписываемый элемент имеет свой <Reference>-элемент, определяемый атрибутом URI.
  • Элемент <Transform> определяет упорядоченный список операций, которые были произведены над описываемый ресурсом, прежде чем для него был рассчитан хеш.
  • Элемент <DigestValue> содержит хеш.
  • Элемент <SignatureValue> содержит результат криптования хеша.
  • Элемент <KeyInfo> определяет ключ для проверки подписи. Возможные формы идентификации включают сертификаты, имена ключей, алгоритмы взаимодействия ключей и информацию.

 

Формат подписи

XML-DSIG использует отдельное пространство имен, и мы принимаем, что в наших примерах присутствует следующее объявление:

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

Самый верхний элемент <ds:Signature> довольно прост. В нем содержится информация о том, что было подписано, подпись, ключи, используемые для создания подписи, и место для сохранения произвольных данных:

<element name="Signature" type="ds:SignatureType"/>
    <complexType name="SignatureType">
      <sequence> 
        <element ref="ds:SignedInfo"/> 
        <element ref="ds:SignatureValue"/> 
        <element ref="ds:KeyInfo" minOccurs="0"/> 
        <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/> 
      </sequence>  
      <attribute name="Id" type="ID" use="optional"/>
    </complexType>

Рассмотрим все элементы в порядке возрастания сложности.

 

Атрибут ds:Signature/@Id

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

 

Элемент ds:SignatureValue

Этот элемент содержит саму подпись. Поскольку всегда подписи — это двоичные данные, XML DSIG указывает, что значение подписи — это всегда простой элемент с Base64-кодированным содержимым:

<element name="SignatureValue" type="ds:SignatureValueType"/> 
    <complexType name="SignatureValueType">
      <simpleContent>
        <extension base="base64Binary">
          <attribute name="Id" type="ID" use="optional"/>
        </extension>
      </simpleContent>
    </complexType>

Чтобы интерпретировать SignatureValue, важно понимать содержимое элемента SignedInfo, который будет обсуждаться далее. До тех пор, это всего лишь непрозрачная строка байтов:

<SignatureValue>
        WvZUJAJ/3QNqzQvwne2vvy7U5Pck8ZZ5UTa6pIwR7GE+PoGi6A1kyw==
    </SignatureValue>

 

Элемент ds:Signature/ds:Object

Как мы увидим ниже, XML DSIG может содержать множество элементов. Элемент всегда сможет существовать самостоятельно, как Web-страница или деловой XML-документ, но иногда элемент лучше интерпретировать как метаданные для подписанного «настоящего» содержимого. Например, данные могут быть «собственностью» подписи, как временная метка создания подписи.

Для размещения таких данных в Signature может использоваться элемент ds:Object:

<element name="Object" type="ds:ObjectType"/> 
    <complexType name="ObjectType" mixed="true">
      <sequence minOccurs="0" maxOccurs="unbounded">
        <any namespace="##any" processContents="lax"/>
      </sequence>
      <attribute name="Id" type="ID" use="optional"/> 
      <attribute name="MimeType" type="string" use="optional"/>
      <attribute name="Encoding" type="anyURI" use="optional"/> 
    </complexType>

Атрибут Id позволяет содержать в подписи множество объектов, к каждому из которых можно обращаться независимо. MimeType используется для идентификации данных, чтобы другие обработчики могли их использовать; он не имеет значения для DSIG-обработчика.

Encoding определяет, как подготовить содержимое к обработке; на данное время определено только кодирование base-64.

Вот два объекта (с идентичным содержимым), которые могут использоваться как простые указатели того, когда был подписан документ. Сервис, содержащий их в своей подписи, может быть полезен для конкурсов, аукционов или других проводимых в режиме онлайн действий, которые имеют предельные сроки представления:

<ds:Object Id="ts-bin" Encoding="http://www.w3.org/2000/09/xmldsig#base64">
        V2VkIEp1biAgNCAxMjoxMTowMyBFRFQgMjAwMwo
    </ds:Object>
    <ds:Object Id="ts-text">
        Wed Jun  4 12:11:06 EDT
    </ds:Object>

 

Элемент ds:SignedInfo

Содержимое ds:SignedInfo может быть разделено на две части: информация о SignatureValue и информация о содержимом приложения, — как видно из следующего фрагмента XML Schema:

<element name="SignedInfo" type="ds:SignedInfoType"/> 
   <complexType name="SignedInfoType">
     <sequence> 
       <element ref="ds:CanonicalizationMethod"/>
       <element ref="ds:SignatureMethod"/> 
       <element ref="ds:Reference" maxOccurs="unbounded"/> 
     </sequence>  
     <attribute name="Id" type="ID" use="optional"/> 
   </complexType>

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

<a foo='yes' boo="no"/>
    <a boo="no" foo="yes"  ></a>

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

Чтобы это обработать, содержимое должно быть канонизировано (canonicalized). Канонизация или C14N — это процесс выбора одного пути из всех возможных вариантов выхода, так чтобы отправитель и получатель могли формировать именно такое же байтовое значение. То, какое промежуточное программное обеспечение XML может быть вовлечено в это, значения не имеет.

Элемент ds:SignedInfo/ds:CanonicalizationMethod определяет то, как точно воспроизводить поток байтов. Элемент ds:SignedInfo/ds:SignatureMethod определяет, какой тип подписи — например, Kerberos или RSA — используется для создания подписи. Вместе эти два элемента указывают нам, как создать хэш и как защитить его от изменений.

Вот пример:

<ds:SignedInfo>
        <ds:CanonicalizationMethod
             Algorithm="http://www.w3.org/2001/10/xml-exc-c14n"/>
        <ds:SignatureMethod
             Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        ...

 

Элемент ds:Reference

Элемент ds:SignatureValue содержит подпись, которая охватывает только элемент ds:SignedInfo: в хэш подписи включено только содержимое ds:SignedInfo. Тогда как мы на самом деле подписываем все остальное содержимое? Тонкость и мощь — в элементе ds:Reference.

Из описания схемы элемента ds:SignedInfoType, приведенного выше, подпись может иметь множество ссылок. Это позволяет одной XML DSIG охватывать множество объектов: все части MIME-сообщения, XML-файл и XSLT-сценарий, который преобразовывает его в HTML, и т.д.

Элемент ds:Reference ссылается на другое содержимое. Он включает хэш содержимого, свидетельство того, что хэш был создан (например, SHA1), и определение того, как содержимое должно бы трансформировано перед генерированием хэша. Трансформации обеспечивают поразительную гибкость XML DSIG. Здесь представлен фрагмент Схемы:

<element name="Reference" type="ds:ReferenceType"/>
   <complexType name="ReferenceType">
     <sequence> 
       <element ref="ds:Transforms" minOccurs="0"/> 
       <element ref="ds:DigestMethod"/> 
       <element ref="ds:DigestValue"/> 
     </sequence>
     <attribute name="Id" type="ID" use="optional"/> 
     <attribute name="URI" type="anyURI" use="optional"/> 
     <attribute name="Type" type="anyURI" use="optional"/> 
   </complexType>

Атрибут Type может обеспечить подсказку при обработке, но, в общем, бесполезен.

URI указывает на фактическое содержимое, к которому обращаются. Поскольку это — URI, нам доступна вся мощь Web. Например, я могут подписать содержимое начальной страницы MSDN:

<ds:Reference URI="http://msdn.microsoft.com">
        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <ds:DigestValue>HB7i8RaV7ZvuUlaTzZVx0S3POpU=</ds:DigestValue>
    </ds:Reference>

Можно сослаться на содержимое XML-документа, такое как показанная выше временная метка:

<ds:Reference URI="#ts-text">
        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <ds:DigestValue>pN3j2OeC0+/kCatpvy1dYfG1g68=</ds:DigestValue>
    </ds:Reference>

И, конечно же, можно поместить обе эти ссылки в одну и ту же подпись.

Для подписания SOAP-сообщения с WS-Security чаще всего используется фрагмент URI:

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
        <SOAP:Header>
           <wsse:Security>
                   xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
               ...
               <ds:Signature>
                    ...
                    <ds:SignedInfo>
                        <ds:Reference URI='#Body'>
                            ...
                        </ds:Reference>
                        ...
                    <ds:SignedInfo>
                    ...
               </ds:Signature>
               ...
           </wsse:Security>
        </SOAP:Header>
        <SOAP:Body Id='Body'>
            ...
        </SOAP:Body>
    </SOAP:Envelope>

ds:DigestMethod определяет алгоритм хэширования, а ds:DigestValue — Base64-значение хэша содержимого.

Самая значительная часть элемента ds:Reference — набор преобразований, которые могут появиться. ds:Transforms — это просто список элементов ds:Transform, каждый из которых определяет шаг в процессе обработки. Схема определяет массив преобразований, одна из которых — ds:XPath — имеет определенную структуру:

<element name="Transforms" type="ds:TransformsType"/>
   <complexType name="TransformsType">
     <sequence>
       <element ref="ds:Transform" maxOccurs="unbounded"/>  
     </sequence>
   </complexType>

   <element name="Transform" type="ds:TransformType"/>
   <complexType name="TransformType" mixed="true">
     <choice minOccurs="0" maxOccurs="unbounded"> 
       <any namespace="##other" processContents="lax"/>
       <element name="XPath" type="string"/> 
     </choice>
     <attribute name="Algorithm" type="anyURI" use="required"/> 
   </complexType>

Содержимое результата преобразования будет зависеть от атрибута Algorithm. Например, если простой XML был подписан, тогда, вероятнее всего, будет единственное преобразование, определяющее алгоритм C14N:

<ds:Transforms>
    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n"/>
  </ds:Transforms>

XML DSIG определяет несколько преобразований, включая преобразование XPath, которое облегчает подписание части документа, например, подписание только разметки при игнорировании всего текста:

<ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
            <XPath>not(self::text())</XPath>
        </ds:Transform>
        <ds:Transform
                Algorithm="http://www.w3.org/TR/2001/10/xml-exc-c14n/>
        </ds:Transforms>

Другие оговоренные преобразования включают встроенные таблицы стилей XSLT, декодирование закодированных данных и т.д.

 

Элемент ds:KeyInfo

На данный момент мы знаем, как сослаться на содержимое, преобразовать и хэшировать его, и создать подпись, которая покрывает (защищает) это содержимое. Оно защищено от обратного преобразования: ds:SignatureValue включает ds:SignedInfo, который содержит ds:References, в котором находятся значения хэшей данных приложения. Изменение любого из этих элементов влечет за собой разрушение цепочки математических вычислений, и подпись не будет достоверной.

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

<element name="KeyInfo" type="ds:KeyInfoType"/> 
   <complexType name="KeyInfoType" mixed="true">
     <choice maxOccurs="unbounded">     
       <element ref="ds:KeyName"/> 
       <element ref="ds:KeyValue"/> 
       <element ref="ds:RetrievalMethod"/> 
       <element ref="ds:X509Data"/> 
       <element ref="ds:PGPData"/> 
       <element ref="ds:SPKIData"/>
       <element ref="ds:MgmtData"/>
       <any processContents="lax" namespace="##other"/>
       <!-- (1,1) elements from (0,unbounded) namespaces -->
     </choice>
     <attribute name="Id" type="ID" use="optional"/>
   </complexType>

Как видите, XML DSIG поддерживает разнообразные типы ключей и инфраструктуры ключей, а WS-Security пошла еще дальше. Мы рассмотрим только простое имя и сертификат X.509. ds:KeyName стоит использовать при создании специального приложения для закрытой среды:

<element name="KeyName" type="string"/>

За проецирование имени во внутреннее хранилище и выбор подходящего ключа отвечает процесс, проверяющий достоверность подписи. К обычным значениям ds:KeyName относятся адрес электронной почты или элемент справочника.
Сертификаты X.509 поддерживаются элементом ds:X509Data. Этот элемент позволяет подписывающей стороне встраивать свой сертификат (в Base64) или любую из нескольких альтернативных форм идентификации сертификата: имя субъекта, имя пользователя и серийный номер, идентификатор ключа или что-либо другое. Подписывающая сторона также может включить текущую копию Списка отзыва сертификата (Certificate Revocation List - CRL), чтобы показать, что идентификатор подписывающей стороны был действителен в момент подписания документа. Фрагмент Схемы, приведенный ниже, показывает различные способы идентификации сертификата X.509:

<element name="X509Data" type="ds:X509DataType"/> 
    <complexType name="X509DataType">
      <sequence maxOccurs="unbounded">
        <choice>
          <element name="X509IssuerSerial" type="ds:X509IssuerSerialType"/>
          <element name="X509SKI" type="base64Binary"/>
          <element name="X509SubjectName" type="string"/>
          <element name="X509Certificate" type="base64Binary"/>
          <element name="X509CRL" type="base64Binary"/>
          <any namespace="##other" processContents="lax"/>
        </choice>
      </sequence>
    </complexType>

    <complexType name="X509IssuerSerialType"> 
      <sequence> 
        <element name="X509IssuerName" type="string"/> 
        <element name="X509SerialNumber" type="integer"/> 
      </sequence>
    </complexType>

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

<ds:KeyInfo>
        <ds:KeyName>
            rsalz@datapower.com
        </ds:KeyName>
        <ds:X509Data>
            <ds:X509SubjectName>
                cn=Rich Salz, o=DataPower, c=US
            </ds:X509SubjectName>
            <ds:X509IssuerSerial>
                <ds:IssuerName>
                    ou=Development, o=DataPower, c=US
                </ds:IssuerName>
                <ds:SerialNumber>32</ds:SerialNumber>
            </ds:X509IssuerSerial>
        </ds:X509Data>
    </ds:KeyInfo>

 

Как создать XML-подпись

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

 

1. Определить подписываемые ресурсы.

Это может быть определено в форме Uniform Resource Identifier (URI).

  • "http://www.abccompany.com/index.html" ссылается на HTML-страницу в Web
  • "http://www.abccompany.com/logo.gif" ссылается на GIF-изображение в Web
  • "http://www.abccompany.com/xml/po.xml" ссылается на XML-файл в Web
  • "http://www.abccompany.com/xml/po.xml#sender1" ссылается на определенный элемент XML-файла в Web

 

2. Рассчитать хеш каждого ресурса.

В XML-подписях каждый ресурс, указанный в разделе <Reference>, и его хеш помещается в раздел <DigestValue> таким образом:

<Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm">
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
  <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
</Reference>
<Reference URI="http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml">
  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
  <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> 
</Reference>

Элемент <DigestMethod> определяет алгоритм расчета хеша.

 

3. Собрать элементы Reference.

Собрать элементы <Reference> (с соответствующими хешами) внутри элемента <SignedInfo> следующим образом:

<SignedInfo Id="foobar">
  <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
  <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
  <Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm">
    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
    <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
  </Reference>
  <Reference URI="http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml">
    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> 
  </Reference>
</SignedInfo>

Элемент <CanonicalizationMethod> определяет алгоритм, примененный для канонизации элемента <SignedInfo>. Различные потоки данных могут по-разному отображать одни и те же данные, например, отличия в пробелах. Для предотвращения ошибок верификации набор XML-информации первоначально должен быть канонизирован перед его побитовой обработкой подписания. Элемент <SignatureMethod> определяет алгоритм, примененный для получения значения подписи.

 

4. Подписание.

Рассчитайте хеш элемента <SignedInfo>, подпишите хеш и поместите значение подписи в элемент <SignatureValue>.

<SignatureValue>MC0E LE=</SignatureValue>

 

5. Добавьте информацию о ключе.

Если необходимо добавить ключевую информацию, поместите ее в элемент <KeyInfo>. Здесь ключевая информация содержит сертификат X.509 отправителя, который будет содержать открытый ключ для верификации подписи.

<KeyInfo>
  <X509Data>
    <X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName>
    <X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate>
  </X509Data>
</KeyInfo>

 

6. Закройте элемент Signature.

Поместите элементы <SignedInfo>, <SignatureValue> и <KeyInfo> в элемент <Signature>. Элемент <Signature> представляет собой XML-подпись.

<?xml version="1.0" encoding="UTF-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo Id="foobar">
    <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> 
    <Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm">
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
      <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
    </Reference>
    <Reference URI="http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml">
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> 
    </Reference>
  </SignedInfo>
  <SignatureValue>MC0E~LE=</SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName>
      <X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate>
    </X509Data>
  </KeyInfo>
</Signature>

 

Проверка XML-подписи

Краткое описание как проверять XML-подпись:

  • Проверьте подпись элемента <SignedInfo>. Для этого пересчитайте хеш элемента <SignedInfo> (используя алгоритм расчета хеша, указанный в элементе <SignatureMethod>) и воспользуйтесь открытым ключом для проверки, что значение элемента <SignatureValue> совпадает с хешем элемента <SignedInfo>.
  • Если этот шаг пройден, пересчитайте хешы ссылок, содержащихся в элементе <SignedInfo>, и сравните их со значениями хешей, представленными в каждом элементе <DigestValue> каждого элемента <Reference>.

 

Заключение

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

 

Инструменты

.NET   System.Security.Cryptography.Xml
Java   Java XML Digital Signature API
Delphi   нет

 

Ссылки

  
 

15.09.2007

  
     
Hosted by uCoz