Подпись XML - XML Signature

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

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

Структура

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

<Signature>  <SignedInfo>    <Метод канонизации />     />    <Reference>       <Преобразует />        />        />    </Reference>    <Ссылка /> и Т. Д. </SignedInfo>   />   />  <Объект /></Signature>
  • В SignedInfo Элемент содержит или ссылается на подписанные данные и указывает, какие алгоритмы используются.
    • В ПодписьМетод и КанонизацияМетод элементы используются Подпись элемент и включены в SignedInfo чтобы защитить их от взлома.
    • Один или больше Ссылка элементы определяют ресурс, подписываемый ссылкой URI, и любые преобразования, которые должны быть применены к ресурсу до подписания.
      • Трансформирует содержит преобразования, примененные к ресурсу до подписания. Преобразование может быть выражением XPath, которое выбирает определенное подмножество дерева документа.[1]
      • DigestMethod определяет алгоритм хеширования перед применением хеша.
      • DigestValue содержит Base64 закодированный результат применения хеш-алгоритма к преобразованным ресурсам, определенным в Ссылка атрибуты элемента.
  • В Подпись элемент содержит Base64 результат закодированной подписи - подпись, сгенерированная с параметрами, указанными в ПодписьМетод элемент - из SignedInfo элемент после применения алгоритма, указанного в КанонизацияМетод.
  • KeyInfo элемент необязательно позволяет подписывающей стороне предоставить получателям ключ, который проверяет подпись, обычно в форме одного или нескольких X.509 цифровые сертификаты. Проверяющая сторона должна идентифицировать ключ из контекста, если KeyInfo нет.
  • В Объект элемент (необязательно) содержит подписанные данные, если это обволакивающая подпись.

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

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

  1. Ссылочная проверка: Каждый Ссылкадайджест проверяется путем получения соответствующего ресурса и применения к нему любых преобразований, а затем указанного метода дайджеста. Результат сравнивается с записанным DigestValue; если они не совпадают, проверка не выполняется.
  2. Проверка подписи: В SignedInfo элемент сериализуется с использованием метода канонизации, указанного в КанонизацияМетод, ключевые данные извлекаются с помощью KeyInfo или другими способами, и подпись проверяется с использованием метода, указанного в ПодписьМетод.

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

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

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

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

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

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

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

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

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

вопросы

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

Эти вопросы решаются в Рабочая группа по безопасности XML.[7][8]

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

Приложения

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

Смотрите также

Рекомендации

  1. ^ http://www.w3.org/TR/xmldsig-filter2/ XML-подпись XPath Filter 2.0
  2. ^ а б Павел Кравчик (2013). «Безопасная проверка SAML для предотвращения атак с переносом XML-подписи».
  3. ^ Почему нарушена безопасность XML
  4. ^ Производительность безопасности веб-служб
  5. ^ Сравнение производительности механизмов безопасности для сетевых служб
  6. ^ Чжан, Джимми (9 января 2007 г.). «Ускорение приложений WSS с помощью VTD-XML». JavaWorld. Получено 2020-07-24.
  7. ^ Семинар W3C по следующим шагам для подписи XML и шифрования XML, 2007
  8. ^ Требования безопасности XML 2.0 и соображения по проектированию
  9. ^ http://domino.research.ibm.com/library/cyberdig.nsf/papers/73053F26BFE5D1D385257067004CFD80/$File/rc23691.pdf
  10. ^ Юрай Соморовский; Андреас Майер; Йорг Швенк; Марко Кампманн; Мейко Дженсен (2012). «О взломе SAML: будь тем, кем хочешь быть» (PDF).
  11. ^ https://www.sbr-nl.nl/english/what-is-sbr/assurance/ SBR Assurance, правительство Нидерландов, 2018 г.

внешняя ссылка