WikiDer > Подпись XML
Подпись 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 процедура вызывала Основная проверка следует.
- Ссылочная проверка: Каждый
Ссылка
дайджест проверяется путем получения соответствующего ресурса и применения к нему любых преобразований, а затем указанного метода дайджеста. Результат сравнивается с записаннымDigestValue
; если они не совпадают, проверка не выполняется. - Проверка подписи: В
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-подписей:
- Цифровая подпись XBRL ежегодные отчеты к аудиторы в Нидерланды. А PKIoverheid Сертификат X.509, утвержденный Королевский национальный институт дипломированных бухгалтеровnl , необходимо. Электронная подпись имеет обязательную юридическую силу. В SBR Assurance стандарт[11] является частью голландского Стандартная бизнес-отчетность программа.
Смотрите также
- Канонический XML
- XML-шифрование
- XAdES, расширения XML-DSig для использования с расширенной электронной подписью
- Синтаксис криптографического сообщения
Рекомендации
- ^ http://www.w3.org/TR/xmldsig-filter2/ XML-подпись XPath Filter 2.0
- ^ а б Павел Кравчик (2013). «Безопасная проверка SAML для предотвращения атак с переносом XML-подписи».
- ^ Почему нарушена безопасность XML
- ^ Производительность безопасности веб-служб
- ^ Сравнение производительности механизмов безопасности для сетевых служб
- ^ Чжан, Джимми (9 января 2007 г.). «Ускорение приложений WSS с помощью VTD-XML». JavaWorld. Получено 2020-07-24.
- ^ Семинар W3C по следующим шагам для подписи XML и шифрования XML, 2007
- ^ Требования безопасности XML 2.0 и соображения по проектированию
- ^ http://domino.research.ibm.com/library/cyberdig.nsf/papers/73053F26BFE5D1D385257067004CFD80/$File/rc23691.pdf
- ^ Юрай Соморовский; Андреас Майер; Йорг Швенк; Марко Кампманн; Мейко Дженсен (2012). «О взломе SAML: будь тем, кем хочешь быть» (PDF).
- ^ https://www.sbr-nl.nl/english/what-is-sbr/assurance/ SBR Assurance, правительство Нидерландов, 2018 г.
внешняя ссылка
- Синтаксис и обработка подписи XML
- Канонический XML
- Дополнительные универсальные идентификаторы ресурсов безопасности XML (URI)
- Эксклюзивная канонизация XML
- XMLSignatures Привязка Java для XMLBeans и JAXB.
- Пошаговый пример о том, как создается подпись.