Главная » Java, Web, XML » Безопасность на уровне XML

0

Для того чтобы зашифровать не всё SOAP-послание, а только его отдельные части, придется перейти на уровень языка XML и пойти привычным путем — ввести дополнительные элементы XML, описывающие зашифрованную часть послания.

Разработка средств описания зашифрованных XML-документов и их отдельных частей ведется консорциумом W3C давно и независимо от протокола SOAP и Web-служб, причем этим занимается сразу несколько рабочих групп.

•          Рабочая группа, определяющая правила описания шифрования документов XML, выпустила предварительную версию рекомендации "XML Encryption Syntax and Processing". Будем называть ее короче "XML Encryption". Ее можно посмотреть по адресу http://www.w3.org/TR/2002/xmIenc-core/.

подписи, a RFC 3076 — так называемую каноническую форму XML (Canonical XML).

? Третья рабочая группа рассматривает работу с цифровыми сертификатами и разрабатывает правила обмена ключами шифрования. Она разработала спецификацию XKMS (XML Key Management Specification) и работает над ее второй версией. Ее можно посмотреть на сайте http://www.w3.org/TR/xlms2/.

Рассмотрим подробнее эти рекомендации и спецификации.

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

Документы XML или их отдельные элементы шифруются с использованием обычных алгоритмов криптографии. Задача состоит в том, чтобы выделить зашифрованную часть документа и описать способ ее шифрования.

Рекомендация "XML Encryption" вводит новый XML-элемент <EncryptedData> и вложенные в него элементы. Все элементы определены в пространстве имен с идентификатором http://www.w3.Org/2001/04/xmlenc#. Они описывают метод шифрования, сам зашифрованный элемент и тому подобную информацию. При помощи элемента <EncryptedData> можно зашифровать группу вложенных XML-элементов, отдельный элемент или только его содержимое.

Допустим, что в некотором XML-документе есть элементы

<person>

<nuitib>XY-123456-27</numb>

</person>

и нам надо зашифровать элемент                   содержащий секретный номер

абонента. Это можно сделать двумя способами.

Первый способ — зашифровать только содержимое элемента:

<person> <numb>

<EncryptedData Type="http: //www. w3 . org/2001/04/xmlenc#Content">

< ! — вложенные элементы с зашифрованным номером —> </EncryptedData> </numb> </person>

Второй способ — зашифровать весь элемент <person>

<EncryptedData Type="http: //www. w3 . org/2001 /04/xmlenc#Element">

<!— вложенные элементы с зашифрованным элементом —> </EncryptedData>

</person>

Обратите внимание на то, как изменился атрибут                   — вместо заключи

тельного указания "content" атрибут содержит слово "Element".

Вообще же у элемента <EncryptedData> четыре необязательных атрибута:

?         атрибут id содержит идентификатор элемента <EncryptedData>, полезный для последующих ссылок на элемент;

?         атрибут туре содержит тип зашифрованной информации в виде строки URI;

?         атрибут MimeType указывает MIME-тип зашифрованной информации обычной строкой или строкой URI;

?         атрибут Encoding указывает кодировку содержимого в виде строки URI.

Остальные атрибуты описывают идентификаторы пространств имен; очень

часто они выглядят так:

<EncryptedData

xmlns="http://www.w3.org/2001/04/xrnlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=

"http: //www.w3 . org/2001/04/xmlenc#xenc-schema.xsd">

В элемент <EncryptedData> вкладываются четыре элемента.

?         Элемент <EncryptionMethod Algorithm=""> ОПИСЫВаеТ^горитм ШИфрОвания своим обязательным атрибутом Algorithm. В этот элемент можно вложить элемент <KeySize>, содержащий длину ключа.

и другие элементы, например, для записи параметров алгоритма RSA- ОАЕР специально предназначен вложенный элемент <OAEPparams>. Элемент <EncryptionMethod> можно опустить, если алгоритм шифрования был оговорен заранее.

?         Элемент <ds: Keylnfо> описывает применяемые ключи шифрования. Как видно из его префикса, он определен в пространстве имен с идентификатором Это пространство имен цифровой подписи, оно описано в следующем разделе. Дополнительно в этот элемент можно вложить элемент <EncryptedKey>, описывающий метод шифрования ключа, если ключ шифруется, и элемент

описывающий метод обмена ключами.

?         Элемент <cipherData> описывает сами зашифрованные данные.

? Элемент <EncryptionProperties> содержит дополнительную информа- Щ1Ю ВО вложенных В него элементах <EncryptionProperty>.

Из этих элементов обязателен только элемент <cipherData>. Именно в нем, во вложенном в него элементе          содержится зашифрованная

информация. Это двоичная информация, но она записывается в кодировке Base64.

Таким образом, минимальный состав элемента <EncryptedData> примерно таков:

<EncryptedData xmlns="http: //www. w3. org/2001/04/xmlenc#">

<CipherData>

<CipherValue>

BNjivf7gTOXRRhdgB5h4JSxHJ7dlZudnZBrg= </CipherValue>

</CipherData> </EncryptedData>

Вместо элемента <ciphervalue> В элемент <CipherData> можно вложить элемент <cipherReference uri="">, указывающий расположение зашифрованных данных своим атрибутом URI — строкой URI. В элемент <CipherReference> МОЖНО ВЛОЖИТЬ элемент <Transforms>, а В него — один или несколько элементов                                    описывающих методы

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

<EncryptedData

<CipherReference

<Transforms>

<ds:Transform Algorithm=

"http://www.w3.Org/2000/09/xmldsig#base64"/>

</Transforms>

</CipherReference> </EncryptedData>

Структура элемента <EncryptedKey>, описывающего зашифрованный ключ, повторяет структуру элемента <EncryptedData> с добавлением элемента

В                                                              элементы

и/или элементы <DataReference URI=""> своим атрибутом URI указывают идентификаторы (значения атрибутов элементов, использующих описываемый зашифрованный ключ.

Элемент <AgreementMethod> описывает способ генерации ключей и обмена ими. Сторона, генерирующая ключ, описывается вложенным элементом

а сторона, получающая ключ — вложенным элементом <RecipientKeylnfo>. Факт пересылки ключа отмечается вложенным элементом <KA-Nonce>, чтобы не сгенерировать дважды один и тот же ключ.

Полная схема вложенности элементов показана в листинге 8.1. – Листинг 8.1. Вложенность элементов шифрования

<EncryptedData Id=""[?] Type=""[?] MimeType="" [?J Encoding=""[?] xmlns="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.w3.org/2001/04/xmlenc#xenc-schema.xsd">

<EncryptionMethod Algorithnt=""> [?] <KeySize> [?] <OAEPparams> [?]

<ds: DigestMethod Algorithm=""> [?] </EncryptionMethod>

<ds:KeyInfo> [?] <ds:KeyName> (?]

<ds:RetrievalMethod URI="" Type=""> [?] <EncryptedKey> [?]

<EncryptionMethod Algorithm=""> [?]

<CipherData>

<CipherReference URI=""> | <CipherVa^lue> <Transforms>

<ds:Transform Algorithm^’ "> </Transforms>

</CipberReferen.ce>

</CipherData>

<ReferenceList> [?]

<KeyReference uri=""> [*] <DataReference uri=""> [*] </ReferenceList>

</EnLcryptedKey>

<AgreementMethod Algorithm^'[?]

<KA-Nonce> [?]

<ds: DigestMethod Algorithm="">

<OriginatorKeyInfo> [?] <RecipientKeyInfo> [?]

</Ag reementMethod>

</cls:KeyIhlfc»

<CipherData>

<CipherReference uri=""> 1 <ciphervaiue> <Transforms>

<ds: Transform AlgorithiF" </Transforms>

</Ciph]erR?feren]ce> </CipberData» <En.cryptionPtoperties» [?]

<Encryptioniroperty> [+] </EncryptionProperties>

</EncryptedCata>

Цифровая подпись документа XML

Правила создания цифровой подписи документа XML определены в рекомендации RFC 3275. Суть рекомендации в том, что создаются дайджесты подписываемой информации, они вкладываются в элемент вместе с нужными пояснениями. Затем создается дайджест этого элемента, который подписывается цифровой подписью. Элемент <signedinfo> определен в спецификации RFC 3275.

Все это вкладывается в корневой элемент цифровой подписи <signature>, тоже определенный в рекомендации RFC 3275. Непосредственно в элемент <signature> вкладывается два обязательных элемента                                      и

а также необязательный элемент                                                   и нуль или

несколько элементов <object>. Все элементы определены в пространстве имен с идентификатором http://www.w3.Org/2000/09/xmldsig#.

Элемент                      как следует из его названия, описывает способ по

лучения цифровой подписи. Это выполняется двумя обязательными вложенными элементами <CanonicalizationMethod> И <SignatureMethod>. Кроме того, элемент <signedinfo> описывает подписываемую информацию, это делается третьим обязательным вложенным элементом <Reference>.

Элемент                                           указывает способ приведения элемен

та <signedlnfo> к каноническому виду XML. Способ указывается обязательным атрибутом Algorithm. В этот элемент можно вложить произвольные элементы, характерные для данного метода приведения к каноническому виду.

Элемент                                 указывает алгоритм шифрования элемента

<SignedInfo>. Алгоритм указывается обязательным атрибутом Algorithm, например:

<SignatureMethod

Algorithm=http://www.w3,org/2000/09/xmldsig#dsa-shal />

Здесь указан комбинированный алгоритм шифрования DSA-SHA1.

В элемент <signatureMethod> можно вложить произвольные элементы, характерные для выбранного алгоритма шифрования.

Элемент                   может появиться несколько раз, поскольку подписы

ваемая информация может состоять из нескольких документов XML, документов HTML или их частей, файлов с графическими изображениями, звуковых файлов и других ресурсов. Каждый ресурс, которым может быть и часть документа, описывается своим элементом <Reference> и указывается атрибутом этого элемента, например: <Reference URI="http: / /www. some .com/pub/inv.xml#ident">

В этом примере создается дайджест части внешнего документа inv.xml. Полученная цифровая подпись (detached signature) хранится отдельно от подписанного документа.

Цифровая подпись может быть вложена в сам подписываемый документ (enveloped signature). В этом случае ссылка будет выглядеть так: <Reference URI="#ident">

Для каждого ресурса создается свой дайджест.

Каждый элемент <Reference> содержит необязательный вложенный элемент <Transforms>, задающий вложенными элементами <Transform> методы предварительного преобразования подписываемого ресурса, например, преобразование к каноническому виду   Кроме того, элемент

<Reference> должен содержать два обязательных элемента: элемент <DigestMethod> указывает алгоритм получения дайджеста обязательным атрибутом Algorithm, а элемент <Digestvalue> содержит дайджест в кодировке Base64. Например:

<Reference URl="file:/D:/sign.xml"> <Transforms>

<Transform Algorithm=

"http://www.w3.org/TR/2001/REC-xml-cl4n-20010315"/> </Transforms>

<DigestMethod Algorithm="http://www.w3,org/2000/09/xmldsig#shal" /> <DigestValue>j 61wx3rvEPOOvKtMup4NbeVu8nk=</DigestValue>

Здесь для получения дайджеста файл а sign. xml выбран алгоритм SHA-1. Файл sign.xml предварительно приводится к каноническому виду XML.

Элемент                          содержит цифровую подпись в кодировке Base64.

Элемент               описывает информацию об открытом ключе, с помощью

которого проверяется подпись. Ключом может быть и цифровой сертификат. Элемент <Keyinfo> может отсутствовать, если получателю известен ключ. Информация содержится во вложенных элементах, некоторые элементы определены спецификацией. Это элементы <KeyName>, <KeyValue>, <RetrievalMethod>, <X509Data>, <PGPData>, <SPKIData>, <MgmtData>. АвТОры цифровых подписей могут добавить другие элементы.

Элементы <object> определяют дополнительные свойства цифровой подписи, например, дату и время подписания, элементами <signatureProperty>, <Manifest> и другими элементами.

Листинг 8.2 показывает схему вложенности элементов, описывающих цифровую подпись.

; Листинг 8.2. Вложенность элементов цифровой подписи

<Signature Id="" [?]>

<SignedInfo>

<CanonicalizationMethod Algorithm=""> <SignatureMethod Algorithm=""> <Reference URI="" [?] > [+]

<Transforms> [?]

<Transform Algorithm=""> [+] </Transforms>

<DigestMethod Algorithm=""> <DigestValue>

</Reference> </SignedInfo> <SignatureValue>

<KeyInfo> [?]

(<KeyName> | <KeyValue> | <RetrievalMethod> 1 <X509Data> I <PGPData> 1 <SPKIData> 1 <MgmtData>) [+]

</KeyInfo>

<Object Id ="" [?]> [*]

<SignatureProperties>

<SignaturePrcperty Target=""> [+] </SignaturePToperties>

<Manifest>

<Reference> [+] </Manifest>

</Object>

</Signature>

Канонический вид XML

При создании цифровой подписи имеет значение каждый символ подписываемого документа. Даже разное количество пробелов между словами приведет к разным цифровым подписям. Для того чтобы цифровая подпись зависела только от содержания документа, но не от его оформления, документ сначала приводится к каноническому виду, а потом подписывается. Метод приведения к каноническому виду указывается атрибутом элемента <CanonicalizationMethod>.

Канонический вид документа XML и правила приведения к нему описаны в рекомендации RFC 3076, называемой "Canonical XML". По рекомендации RFC 3076 документ записывается в кодировке UTF-8, все ссылки разрешаются, пробельные символы нормализуются, заголовки XML удаляются, пустые элементы записываются парой из открывающего и закрывающего тега, записываются значения по умолчанию всех опущенных атрибутов и так далее. Если приведение к каноническому виду выполнено по этой рекомендации, то элемент <CanonicalizationMethod> должен выглядеть так:

<CanonicalizationMethod

Algorithm="http://www.w3.org/TR/2001/REC-xml-cl4n-20010315" />

Литература:

Хабибуллин И. Ш. Разработка Web-служб средствами Java. — СПб.: БХВ-Петербург, 2003. — 400 с: ил.

По теме:

  • Комментарии