XML-подпись

XML-подпись (также называемая XMLDSig , XML-DSig , XML-Sig ) определяет синтаксис XML для цифровых подписей и определена в рекомендации W3C «Синтаксис и обработка XML-подписей» . Функционально он имеет много общего с PKCS #7 , но более расширяем и ориентирован на подписание XML-документов. Он используется различными веб -технологиями, такими как SOAP , SAML и другими.

Подписи XML можно использовать для подписи данных ( ресурсов ) любого типа все, что доступно через URL-адрес , обычно документов XML, но можно подписать . Подпись XML, используемая для подписи ресурса за пределами содержащего его XML-документа, называется отдельной подписью ; если она используется для подписи некоторой части содержащего ее документа, она называется подписью в конверте ; ^[1] если она содержит подписанные данные внутри себя, она называется обертывающей подписью. ^[2]

Структура

XML-подпись состоит из Signature элемент в http://www.w3.org/2000/09/xmldsig# пространство имен. Основная структура выглядит следующим образом:

<Signature>
  <SignedInfo>
    <CanonicalizationMethod />
    <SignatureMethod />
    <Reference>
       <Transforms />
       <DigestMethod />
       <DigestValue />
    </Reference>
    <Reference /> etc.
  </SignedInfo>
  <SignatureValue />
  <KeyInfo />
  <Object />
</Signature>

The SignedInfo Элемент содержит подписанные данные или ссылается на них и указывает, какие алгоритмы используются.
- The SignatureMethod и CanonicalizationMethod элементы используются SignatureValue элемент и включены в SignedInfo чтобы защитить их от взлома.
- Один или несколько Reference элементы указывают ресурс, подписываемый ссылкой URI, и любые преобразования, которые необходимо применить к ресурсу перед подписанием.
  - Transforms содержит преобразования, примененные к ресурсу до подписания. Преобразованием может быть XPath-выражение, которое выбирает определенное подмножество дерева документа. ^[3]
  - DigestMethod определяет алгоритм хеширования перед применением хеширования.
  - DigestValue содержит закодированный в Base64 результат применения алгоритма хеширования к преобразованным ресурсам, определенным в Reference атрибуты элемента.
The SignatureValue содержит результат подписи в кодировке Base64 — подпись, сгенерированную с параметрами, указанными в SignatureMethod элемент - из SignedInfo элемент после применения алгоритма, указанного CanonicalizationMethod.
KeyInfo Элемент опционально позволяет подписывающему лицу предоставить получателям ключ, подтверждающий подпись, обычно в форме одного или нескольких X.509 цифровых сертификатов . Доверяющая сторона должна идентифицировать ключ из контекста, если KeyInfo нет.
The Object элемент (необязательный) содержит подписанные данные, если это охватывающая подпись .

Вопросы проверки и безопасности

процедура, называемая основной проверкой При проверке подписи XML выполняется .

Эталонная проверка: каждая ReferenceДайджест проверяется путем получения соответствующего ресурса и применения к нему любых преобразований, а затем указанного метода дайджеста. Результат сравнивается с записанным. DigestValue; если они не совпадают, проверка не удалась.
: Проверка подписи SignedInfo элемент сериализуется с использованием метода канонизации, указанного в CanonicalizationMethod, ключевые данные извлекаются с помощью KeyInfo или другим способом, и подпись проверяется методом, указанным в SignatureMethod.

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

Поскольку структура подписанного документа может быть подделана, что приведет к атакам «обертывания подписи», процесс проверки должен также охватывать структуру XML-документа. Подписанный элемент и элемент подписи следует выбирать с использованием абсолютного XPath , а не выражения getElementByName методы. ^[4]

Канонизация XML

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

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

Чтобы избежать этих проблем и гарантировать, что логически идентичные документы XML дают идентичные цифровые подписи, преобразование канонизации XML (часто сокращенно C14n ) используется при подписании документов XML (для подписи SignedInfoканонизация обязательна). Эти алгоритмы гарантируют, что семантически идентичные документы создают точно идентичные сериализованные представления.

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

Преимущества

XML-подпись более гибкая, чем другие формы цифровых подписей, такие как Pretty Good Privacy и Cryptographic Message Syntax , поскольку она работает не с двоичными данными , а с информационным набором XML , что позволяет работать с подмножествами данных (это также возможно с помощью двоичные данные нестандартными способами, например кодирование блоков двоичных данных в формате Base64 ASCII), имеющие различные способы связывания подписи и подписанной информации, а также выполнения преобразований. Другая основная концепция — это канонизация, то есть подписывать только «сущность», устраняя бессмысленные различия, такие как пробелы и окончания строк.

Проблемы

Есть критика в адрес архитектуры безопасности XML в целом. ^[5] и пригодность канонизации XML, в частности, в качестве внешнего интерфейса для подписания и шифрования данных XML из-за ее сложности, присущих требований к обработке и плохих характеристик производительности. ^[6]^[7]^[8] Аргумент состоит в том, что выполнение канонизации XML приводит к чрезмерной задержке, которую просто невозможно преодолеть для транзакционных, чувствительных к производительности приложений SOA .

Этими вопросами занимается Рабочая группа по безопасности XML . ^[9]^[10]

Без надлежащей политики и реализации ^[4] использование XML Dsig в SOAP и WS-Security может привести к уязвимостям, ^[11] например упаковка подписи XML. ^[12]

Приложения

Пример применения XML-подписей:

Цифровое подписание XBRL годовых аудиторами отчетов в Нидерландах . сертификат PKIoverheid X.509 , одобренный Королевским национальным институтом дипломированных бухгалтеров [ nl ] Требуется . Электронная подпись имеет юридическую силу. Стандарт обеспечения SBR ^[13] является частью голландской программы стандартной бизнес-отчетности .

См. также

Канонический XML
XML-шифрование
XAdES , расширения XML-DSig для использования с расширенной электронной подписью.
Синтаксис криптографического сообщения

Ссылки

^ «Синтаксис и обработка подписи XML, версия 1.1» .
^ «Синтаксис и обработка подписи XML, версия 1.1» .
^ XML-подпись XPath Filter 2.0
^ Jump up to: ^а ^б Павел Кравчик (2013). «Безопасная проверка SAML для предотвращения атак с использованием XML-подписи» .
^ «Почему безопасность XML нарушена» .
^ Производительность безопасности веб-сервисов
^ Сравнение производительности механизмов безопасности для сетевых услуг
^ Чжан, Джимми (9 января 2007 г.). «Ускорение приложений WSS с помощью VTD-XML» . JavaWorld . Проверено 24 июля 2020 г.
^ Семинар W3C по следующим шагам в области подписи XML и шифрования XML , 2007 г.
^ «Требования к XML Security 2.0 и особенности проектирования» .
^ «Атаки и меры противодействия упаковке элементов подписи XML» (PDF) . Исследовательский отдел IBM . Проверено 7 сентября 2023 г.
^ Юрай Соморовский; Андреас Майер; Йорг Швенк; Марко Кампманн; Мейко Йенсен (2012). «О взломе SAML: будь тем, кем хочешь» (PDF) .
^ «СБР Гарантия» . Проверено 7 сентября 2023 г.

Внешние ссылки

Синтаксис и обработка XML-подписи
Канонический XML
Дополнительные унифицированные идентификаторы ресурсов безопасности XML (URI)
Эксклюзивная канонизация XML
XMLSignatures Привязка Java для XMLBeans и JAXB.
Пошаговый пример создания подписи.

[1] «Синтаксис и обработка подписи XML, версия 1.1» .

[2] «Синтаксис и обработка подписи XML, версия 1.1» .

[3] XML-подпись XPath Filter 2.0

[pk-4] Jump up to: ^а ^б Павел Кравчик (2013). «Безопасная проверка SAML для предотвращения атак с использованием XML-подписи» .

[5] «Почему безопасность XML нарушена» .

[6] Производительность безопасности веб-сервисов

[7] Сравнение производительности механизмов безопасности для сетевых услуг

[8] Чжан, Джимми (9 января 2007 г.). «Ускорение приложений WSS с помощью VTD-XML» . JavaWorld . Проверено 24 июля 2020 г.

[9] Семинар W3C по следующим шагам в области подписи XML и шифрования XML , 2007 г.

[10] «Требования к XML Security 2.0 и особенности проектирования» .

[11] «Атаки и меры противодействия упаковке элементов подписи XML» (PDF) . Исследовательский отдел IBM . Проверено 7 сентября 2023 г.

[12] Юрай Соморовский; Андреас Майер; Йорг Швенк; Марко Кампманн; Мейко Йенсен (2012). «О взломе SAML: будь тем, кем хочешь» (PDF) .

[sbra-13] «СБР Гарантия» . Проверено 7 сентября 2023 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]