Начало работы с безопасностью XML

XML

Спецификация XML [ XML ] определяет синтаксис и правила использования тегов для структурирования информации. Любой может определить словарь тегов и атрибутов элементов, чтобы структурировать интересующую информацию. Следуя правилам, определенным в спецификации XML, они могут создавать «правильно сформированный» XML, XML, который может обрабатываться общими инструментами XML. Они также могут явно определять структуру документов, которые они определили, путем создания схемы XML или определения типа документа (DTD). Это позволяет проверять документы.

Языки XML, созданные разными людьми, могут быть объединены. Если вы, например, определяете язык для выражения адресов, а я определяю язык для заказов на покупку, я могу повторно использовать ваш язык адресов в своем языке заказов на покупку. Чтобы связать элементы с соответствующими схемами и избежать конфликтующих элементов, можно использовать пространства имен XML. Пространства имен XML связывают теги с уникальными идентификаторами (URI) и могут использоваться, чтобы избежать неоднозначности [ Пространства имен ]. Правильно сформированный XML-документ может быть обработан с использованием общих XML-инструментов, включая анализаторы, которые понимают общие правила синтаксиса и обработки XML. Преимущество состоит в том, что использование этих инструментов не зависит от конкретного словаря, определенного в конкретном документе. Это означает, что после создания общих инструментов они могут использоваться для многих приложений XML. Это позволяет повторно использовать инструменты и обучение, еще одно преимущество XML.

Многие языки XML уже определены, включая XHTML для создания веб-страниц, DocBook для создания технической документации, RSS для распространения контента (синдикация), RDF для представления информации, MathML для разметки математики, BRML для бизнес-отчетов и многие другие.

В следующем примере показан язык для управления медицинскими записями в офисе, включая такие элементы XML, как <PatientRecord> , <Name> и <Diagnosis> . Также показано использование пространства имен XML, связанного с лабораторией, чтобы разрешить элемент <lab:Diagnosis> , который не конфликтует с элементом office <Diagnosis> .

 <PatientRecord  xmlns="http://www.medical.org/"  xmlns:lab="http://www.lab.org/">     <Name>John Doe</Name>     <Account>123456</Account>     <Visit date="10pm March 10, 2002">          <Diagnosis>Broken second metacarpal</Diagnosis>          <lab:Diagnosis>            <lab:Xray>encoded xray image</lab:Xray>          </lab:Diagnosis>     </Visit>  </PatientRecord> 
  Пример 1. Образец XML-документа с пространствами имен XML
  Безопасность 
  Безопасность жизненно важна для онлайн-бизнеса.  Технологии, разработанные для удовлетворения требований безопасности, развивались, но требования оставались относительно постоянными.  Эти требования включают аутентификацию, авторизацию, целостность, подпись, конфиденциальность, конфиденциальность и управление цифровыми правами и кратко изложены ниже: 
  Аутентификация - кто это? 
  Определите личность или роль стороны, пытающейся выполнить какое-либо действие, например, получить доступ к ресурсу или участвовать в транзакции.  Роль может быть подходящей для многих сторон, например «Персонал отдела кадров». 
  Авторизация - Что они могут сделать? 
  Определите, разрешено ли какой-либо стороне выполнять запрошенное действие, такое как просмотр веб-страницы, смена пароля или обязательство организации совершить транзакцию на 10 миллионов долларов. 
  Целостность - убедитесь, что информация не повреждена 
  Убедитесь, что информация не изменилась, либо из-за злого умысла, либо случайно.  Это может быть информация, передаваемая по сети, например, из веб-браузера на веб-сервер, информация, хранящаяся в базе данных или файловой системе, или информация, передаваемая в сообщении веб-служб и обрабатываемая посредниками, чтобы привести несколько примеров. 

          

            
        

  Подпись - создание и проверка электронных подписей, аналогичных рукописным подписям 
  Произведите или подтвердите электронную подпись, предназначенную для эквивалента рукописной подписи.  Такая подпись может использоваться для различных целей, таких как утверждение, подтверждение получения, принятие или соглашение. 
  Конфиденциальность - сделать контент нечитаемым для посторонних лиц 
  Убедитесь, что контент может быть просмотрен только законными сторонами, даже если другие механизмы контроля доступа обойдены.  Конфиденциальность обычно связана с технологиями шифрования, хотя другие подходы, такие как стеганография (сокрытие информации), могут служить аналогичной цели. 
  Конфиденциальность - ограничить доступ и использование информации, позволяющей установить личность 
  Персонально идентифицируемая информация требуется физическим лицам и компаниям для оказания услуг для данного лица.  В качестве примера можно привести кабинет врача, в котором требуются медицинские карты для отслеживания состояния здоровья пациента.  Конфиденциальность относится к контролю за тем, что делается с этой информацией и передается ли она другим лицам без ведома или согласия человека.  Конфиденциальность может управляться сочетанием технических и юридических средств.  Технология конфиденциальности может использоваться для защиты конфиденциальности, но не может предотвратить ненадлежащий обмен информацией. 
  Управление цифровыми правами - ограничение использования и обмена контентом в соответствии с лицензионными соглашениями 
  Убедитесь, что контент используется в соответствии с лицензионными соглашениями.  Как правило, правила доступа включаются в контент, а средства принудительного контроля интегрируются с клиентами, необходимыми для использования контента. 
  Традиционно, технологии безопасности требуют, чтобы приложения были «включены» для обеспечения безопасности или инфраструктуры открытых ключей (PKI).  Это часто включает интеграцию специализированного кода безопасности с приложением для удовлетворения требований безопасности.  Это создало медленный, громоздкий и негибкий процесс настройки.  Альтернативой является создание универсальных инструментов XML и универсальной безопасности XML, а затем разрешить их использование с различными приложениями XML.  Это позволяет применять универсальные фильтры безопасности XML к произвольному контенту, не требуя обширной настройки для каждого приложения, снижая затраты и задержку. 


  Безопасность XML 
  Стандарты безопасности XML предоставляют набор технических стандартов, отвечающих требованиям безопасности.  Эти стандарты предназначены для соответствия общим парадигмам XML.  Стандарты безопасности XML используют существующие стандарты XML, а также улучшают стандарты XML следующим образом: 
  Стандарты безопасности XML определяют словари XML для представления информации о безопасности, используя для определения технологии XML, такие как схема XML.  Примером является элемент <KeyInfo> определенный в рекомендации цифровой подписи XML для переноса информации ключа подписи или шифрования.  Это определение используется в ряде спецификаций.  Спецификации определяют общее значение для словарей XML. 
  Стандарты безопасности XML используют другие существующие стандарты XML, где это возможно, чтобы использовать текущие усилия XML.  Например, цифровая подпись XML позволяет выражениям XPath извлекать части XML для обработки (определено в [ XMLDigSig ] и расширено в [ XPathFilter ]). 
  Стандарты безопасности XML разработаны для обеспечения гибкости и расширяемости аспектов XML.  Они позволяют применять защиту к документам XML, элементам XML и их содержимому, а также к произвольным двоичным документам.  Они поддерживают расширение словарей XML за счет использования пространств имен XML и расширяемых определений схемы XML. 
  Технологии XML Security могут применяться для конечной безопасности, что особенно важно, когда сообщения XML направляются через ряд посредников обработки.  Постоянная безопасность связана с контентом, а не с транспортным каналом.  Безопасность остается с контентом.  Технологии XML Security могут использоваться вместе с технологиями безопасности транспорта, такими как SSL / TLS. 
  Технологии XML Security по возможности повторно используют существующие криптографические технологии и технологии безопасности, не изобретая колесо.  Например, сертификаты X.509 V3 [ X509Cert ] используются без переопределения при необходимости - они просто кодируются в текстовом формате.  Существующие алгоритмы, такие как алгоритм дайджеста SHA1, также включены в мир стандартов безопасности XML, связав с ними уникальные идентификаторы URI и определив, как они могут использоваться в моделях обработки XML-безопасности. 
  В следующих разделах представлен обзор основных стандартов безопасности XML, разработанных для обеспечения XML-совместимой технологии, отвечающей требованиям безопасности.  Затем следуют некоторые важные стандарты безопасности XML для применения этой технологии в таких областях, как веб-службы и управление цифровыми правами. 
  Основные стандарты безопасности XML 

          

            
        

  Основные стандарты безопасности XML: 
  Цифровая подпись XML для целостности и подписи, 

  XML-шифрование для конфиденциальности, 

  XML Key Management (XKMS) для управления ключами, 

  Язык разметки утверждений безопасности (SAML) для проверки подлинности и авторизации, и 

  Язык разметки контроля доступа XML (XACML) для определения правил авторизации. 
  Рекомендация XML Digital Signature особенно важна;  поскольку, как первая рекомендация по XML-безопасности, она установила подход, а также определенную лексику, разделяемую другими стандартами.  (Элемент <KeyInfo> определенный в рекомендации «Цифровая подпись XML», является элементом, используемым, например, другими стандартами.) Функциональность подписи также важна для целостности контента, поэтому цифровые подписи XML также включены в другие стандарты безопасности. 
  Каждый стандарт определяет словарь XML, необходимый для описания информации о безопасности, необходимой для этого аспекта безопасности, а также правила обработки, необходимые для понимания того, как применять стандарт. 
  Целостность и подписи: цифровая подпись XML (XML DigSig) 
  Цель и преимущества 
  Цифровые подписи полезны для двух целей: 
  Для обеспечения постоянной целостности контента, и 

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

          

            
        

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

  Произвольные документы, в том числе двоичные документы, 

  Составные документы, включая несколько документов и / или элементов XML и содержимое элементов, 

  Свойства должны быть включены с подписью, 

  Контр-подписи (подписи, которые включают другие подписи) 
  Кроме того, рекомендация «Подпись XML» поддерживает применение нескольких подписей XML к документу XML или к различным разделам документа, поддерживая различные варианты использования.  Спецификация цифровой подписи XML и связанные с ней спецификации ( канонизация XML ) также определяют методы, позволяющие надежно проверять подпись даже с изменениями, разрешенными в XML, такими как пробелы.  Причиной для беспокойства является то, что криптографические алгоритмы имеют дело с точным текстом, но XML допускает некоторую гибкость.  Каноникализация используется для уменьшения вариаций, чтобы все приложения XML Security могли взаимодействовать. 
  Элемент XML <Signature> может обрабатываться различными способами в зависимости от желаемого приложения.  Он может быть помещен в документ отдельно от того, что подписано.  Это известно как «отдельная» подпись, и используется при подписании не XML-контента.  Когда содержимое XML подписано, элемент <Signature> может быть добавлен в XML.  Это удобно, так как подписи могут быть связаны внутри контента и оставаться встроенными вместе с ним, что позволяет легко отслеживать их.  При помещении в документ XML элемент <Signature> может быть добавлен к документу, подписанному под элементом документа («конвертная» подпись).  В некоторых случаях полезно поместить подписываемый контент в элемент <Signature> , например, в качестве свойства подписи («обволакивающая» подпись). 
  Например, если подпись добавляется в <PatientRecord> в качестве конверта с подписью, элемент <Signature> будет дочерним по отношению к <PatientRecord> следующим образом: 
 <PatientRecord xmlns="http://www.medical.org/">    <Name>John Doe</Name>    <Account> 123456 </Account>    <Visit date="10pm March 10, 2002">        <Diagnosis> Broken second metacarpal </Diagnosis>    </Visit>    <Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>        ...    </Signature>  </PatientRecord> 
  Пример 2 - Завершенная подпись
  Когда подпись добавляется в документ как часть документа, он меняет документ.  Чтобы проверить подпись, необходимо сравнить исходный документ без подписи.  Рекомендация «Цифровая подпись XML» определяет механизм удаления <Signature> как часть процесса проверки. 
  Другая возможность - создать новый XML-документ с элементом документа <Signature> и поместить подписанный элемент как дочерний элемент элемента <Signature> .  Обычно это зарезервировано для информации, связанной с подписью, такой как цель подписи, например: 
 <Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>    <SignedInfo> ... </SignedInfo>    <SignatureValue> ... </SignatureValue>    <Object>        <SignatureProperties>            <p:Purpose xmlns:p="http://www.myexample.com/schemas">              Approval            </p:Purpose>        </SignatureProperties>    </Object>  </Signature> 
  Пример 3 - Обволакивающая подпись


  Ключевые идеи 

          

            
        

  Следующие понятия являются ключевыми для понимания цифровых подписей XML: 
  Подпись действительна, только если подписанный контент не изменился.  Этот контент представлен с использованием короткого дайджеста фиксированной длины, предназначенного для изменения при изменении контента.  Таким образом, подпись будет действительна только в том случае, если дайджест, использованный для создания подписи, совпадает с дайджестом, использованным для его проверки позже.  Верификатор может создать дайджест, чтобы увидеть, совпадает ли он. 
  Элемент XML <Signature> - это структура XML, которая содержит значение криптографической подписи в элементе <SignatureValue> а также структуру XML, которая была подписана, структуру <SignedInfo> .  Это означает, что содержимое структуры <SignedInfo> не должно изменяться, чтобы подпись была действительной. 
  Подписывающее лицо создает  <Reference> для каждого элемента, который должен быть включен в подпись.  Каждый <Reference> содержит дайджест элемента и уникальный идентификатор (URI) для элемента.  Он также определяет, как воссоздать дайджест, указав алгоритм и другую необходимую информацию.  Каждая ссылка является частью структуры <SignedInfo> . 
  Чтобы проверить подпись, получатель должен проверить каждую <Reference> , независимо генерируя один и тот же дайджест для элемента.  Верификатор может использовать URI, чтобы помочь найти элемент, и информацию об алгоритме, чтобы знать, как генерировать дайджест.  Если элемент не изменился, дайджест должен быть таким же. 
  Ссылка может относиться ко всему, что использует URI, включая не XML-контент, такой как графические и текстовые файлы.  Не требуется получать элемент, используя URI, но это часто полезно.  Специальная форма URI может использоваться для ссылки на элементы XML в том же документе, что и подпись, что позволяет передавать подписи вместе с содержимым XML для подписи. 
  <Ссылка> может указывать одно или несколько преобразований, которые будут применены к элементу перед созданием дайджеста.  Одним из применений является подписание частей документа XML, о которых известно, что они не меняются, например, таких как шаблон.  Это может быть сделано путем определения преобразования для извлечения части документа, которая должна быть подписана, например, с использованием стандартных выражений XML XPath. 
  Алгоритмы дайджеста требуют, чтобы содержимое было одинаковым для создания одного и того же дайджеста.  Даже незначительное изменение, которое не меняет значения, например добавление дополнительного пробела, приведет к аннулированию дайджеста.  XML, с другой стороны, допускает некоторые изменения в синтаксисе текста XML без изменения документа.  Другими словами, два XML-документа могут считаться одинаковыми, даже если они не имеют одинаковый текст.  Например, один документ XML может использовать одинарные кавычки для атрибута, а другой - двойные кавычки.  Это то же самое, что синтаксический анализатор XML, но сильно отличается от алгоритма дайджеста.  Существует целый список таких потенциальных проблем для дайджестов.  Чтобы обойти эту проблему, можно использовать преобразование Canonicalization, которое преобразует любой XML-документ в форму, используя единый набор правил, например всегда используя определенный тип цитаты для атрибутов. 
  Примеры 
  После создания цифровая подпись XML может храниться отдельно от подписанного контента (отдельной подписи) или может быть встроена в подписанный контент XML (конвертная подпись).  Фактически, подписанный контент также может быть помещен в саму подпись (конверт с подписью).  Чтобы продолжить с более ранним примером PatientRecord, предположим, что весь PatientRecord должен быть подписан офисом врачей, и подпись должна поддерживаться как часть PatientRecord.  Это приведет к следующему результату, показывающему макет подписи XML: 
 <PatientRecord xmlns="http://www.medical.org/">  <Name>John Doe</Name>  <account id="acct">123456</Account>  <Visit date="10pm March 10, 2002">    <Diagnosis>Broken second metacarpal</Diagnosis>    <lab:Diagnosis>      <lab:Xray>xhzhez</lab:Xray>    </lab:Diagnosis>  </Visit>  <Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>     <!-- the SignedInfo element and all it contains         is what is signed -->    <SignedInfo>       <!-- Canonicalization is used to ensure           that XML is handled consistently           by different XML processors           in light of white space and other           variations. -->      <CanonicalizationMethod algorithm="URI for algorithm" />       <!-- the SignatureMethod is protected           by the signature, avoiding substitution           attacks and defines how the signature           is created  -->      <SignatureMethod  Algorithm="http://www.w3.org/2000/07/xmldsig#rsa-sha1" />       <!-- each item to be signed, XML document,           portion of XML document or arbitrary           content is represented using a           Reference. Each Reference contains           a digest of the item, a URI to           refer to the item, and possibly           transforms to apply to the item           before creating the digest  -->      <Reference URI="">        <Transforms  Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />        <DigestMethod  Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />        <DigestValue>          Short, fixed-length "fingerprint" of referenced item        </DigestValue>      </Reference>    </SignedInfo>    <SignatureValue>      encoded output of signature algorithm    </SignatureValue>     <!-- Optional KeyInfo used to convey key         information needed to verify         signature -->    <KeyInfo>      <KeyName>Sally Smith's Integrity Key</KeyName>    </KeyInfo>     <!-- optional Object to allow additional         information to be associated with         signature, such as meta information         for example (time and purpose of         signing) -->    <Object>      <SignatureProperties>        <p:Purpose xmlns:p="http://www.myexample.com/schemas">          Integrity        </p:Purpose>      </SignatureProperties>    </Object>  </Signature>  </PatientRecord> 
  Пример 4 - Подробный пример подписи XML
  Обратите внимание, что существует одна ссылка с URI "", что означает "этот документ".  Если только элемент <Account> должен быть подписан, на него можно ссылаться, используя значение атрибута id, следующим образом: <Reference URI="#acct"> .  Если атрибута id не было (возможно, подпись не ожидалась), можно использовать выражение XPath, которое выдает следующее <Reference> : 
 <Reference URI="">    <Transforms>        <Transform  Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">            <XPath>                /PatientRecord/account            </XPath>        </Transform>        <Transform  Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />    </Transforms>    <DigestMethod  Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />    <DigestValue> kjsdf </DigestValue>  </Reference> 
  Пример 5 - ссылочное преобразование с использованием XPath


  Конфиденциальность: XML Encryption (XML Enc) 
  Цель и преимущества 
  Рекомендация по шифрованию XML определяет словарь XML и правила обработки, позволяющие применять конфиденциальность к различным материалам.  XML Encryption служит для обеспечения конфиденциальности информации как во время передачи, так и при ее хранении.  Другие технологии обеспечения конфиденциальности, такие как уровень защищенных сокетов (SSL) / безопасность транспортного уровня (TLS) или виртуальные частные сети (VPN), обеспечивают конфиденциальность только во время передачи информации, а не во время ее хранения на сервере. 
  Владелец контента может зашифровать его, чтобы сделать его конфиденциальным.  Это сделает содержимое неразборчивым до его расшифровки.  Шифрование обычно выполняется с использованием шифрования с симметричным ключом, поскольку это эффективный метод даже для больших документов.  Симметричный ключ шифрования использует один и тот же ключ как для шифрования, так и для дешифрования.  Чтобы отправить конфиденциальную информацию получателю, отправитель должен также предоставить симметричный ключ получателю, но никому другому.  Это может быть трудно без контакта с человеком. 
  Чтобы избежать этой проблемы и облегчить обмен конфиденциальным контентом с несколькими людьми, была разработана асимметричная криптография или криптография с открытым ключом.  Криптография с открытым ключом использует согласованную пару ключей, один для шифрования и один для дешифрования.  Это позволяет отправителю шифровать с использованием открытого ключа получателя, который может быть широко распространен.  Расшифровка требует использования закрытого ключа получателя, известного только им.  Это помогает решить проблему установления конфиденциальной связи.  Поскольку криптография с открытым ключом менее эффективна, чем симметричная криптография, они обычно используются вместе.  Симметричный ключ используется для шифрования содержимого, а затем симметричный ключ шифруется с использованием криптографии с открытым ключом.  И зашифрованный контент, и зашифрованный симметричный ключ затем отправляются получателю. 
  Подводя итог, отправитель может конфиденциально отправлять контент, используя следующие шаги: 
  Зашифруйте содержимое с помощью симметричного ключа 

  Зашифруйте симметричный ключ, используя открытый ключ получателя. 

          

            
        

  Упакуйте зашифрованный контент, зашифрованный ключ и необходимую информацию об алгоритме 

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

  Расшифруйте симметричный ключ своим закрытым ключом 

  Расшифруйте содержимое симметричным ключом 
  Характеристики 
  Рекомендация по шифрованию XML определяет структуру и правила обработки для шифрования и дешифрования XML.  Он определяет словарь XML для упаковки всей информации, необходимой для обработки зашифрованного контента, такой как алгоритм и параметры шифрования, информация о ключах и зашифрованный контент.  Рекомендация по шифрованию XML поддерживает следующие функции: 
  Содержимое XML и не XML может быть зашифровано, что дает широкое применение рекомендации. 
  Конфиденциальность может применяться на тонком уровне детализации к XML-контенту.  Он может применяться к элементам XML и содержимому элементов XML, а также ко всем документам XML.  Это полезно для защиты частей сообщений протокола XML, которые будут маршрутизироваться через промежуточные процессоры. 
  XML Encryption создает правильно сформированный XML из правильно сформированного XML.  Это позволяет шифровать части содержимого XML, а затем обрабатывать их средствами XML. 
  Шифрование XML совместимо и может использоваться вместе с цифровыми подписями XML. 
  Шифрование XML позволяет шифровать симметричный ключ, который может быть упакован с зашифрованным содержимым. 
  XML Encryption поддерживает различные алгоритмы и методы шифрования. 
  Ключевые идеи 
  Когда элемент XML или его содержимое зашифрованы, он заменяется элементом <EncryptedData> . 
  Когда содержимое не в формате XML зашифровано, результатом является новый документ XML, содержащий элемент <EncryptedData> . 
  Элемент <EncryptedData> может включать атрибут Type, чтобы помочь получателю расшифровать его.  Этот тип может указывать на то, что элемент XML или содержимое элемента было зашифровано, или предоставлять тип другой информации, такой как, например, изображения.  Это делается с использованием существующего стандарта для почтовых вложений, известного как типы MIME. 
  Элемент <EncryptedData> определяет алгоритм, используемый для шифрования, предоставляет зашифрованный контент и может включать информацию, необходимую для определения ключа, необходимого для дешифрования. 
  Симметричный ключ, используемый для шифрования контента, может передаваться в элементе <EncryptedKey> . 
  XML Encryption поддерживает выбор подходящих алгоритмов шифрования и определяет идентификаторы XML для общих случаев и может быть расширен для других. 
  Определения для определения ключевой информации основаны на определениях цифровой подписи XML и расширены. 
  Определяемые пользователем свойства могут быть связаны с зашифрованным элементом, таким как отметка времени или ссылка на журнал. 
  Фактический зашифрованный текст, результат шифрования, указывается с использованием элемента <CipherData> .  Это может содержать фактические зашифрованные данные в <CipherValue> или ссылку URI на зашифрованные данные, которые хранятся в другом месте ( <CipherReference> ).  Ссылка полезна, когда зашифрованные данные имеют большой размер и не нужны большинству сторон, например, посредникам по обработке. 
  Важной проблемой безопасности XML является взаимодействие цифровых подписей XML и шифрования XML.  Предположим, вы получили документ с подписью XML и элементом <EncryptedData> как <EncryptedData> ниже: 
 <PatientRecord  xmlns="http://www.medical.org/"  xmlns:lab="http://www.lab.org/">    <Name> John Doe </Name>    <Account> 123456 </Account>    <EncryptedData Type='element'>        ...    </EncryptedData>    <Signature>        <SignedInfo>            <Reference URI="">                ...            </Reference>        </SignedInfo>    </Signature>  </PatientRecord> 
  Пример 6 - Зашифрованный и подписанный документ
  В этом случае подпись указывает, что она применяется ко всему документу  <PatientRecord> , поскольку URI <Reference> равен "" .  Возникает вопрос: подпись или шифрование были первыми?  Это важно знать, поскольку подпись может быть проверена как правильная, только если содержимое не изменилось.  Если часть документа была зашифрована после подписания, подпись не будет проверяться, если зашифрованная часть не будет расшифрована первой.  Знание порядка шифрования и дешифрования необходимо для того, чтобы знать, как проверить подпись.  Рекомендация XML Encryption Transform [ XMLDecTrans ] определяет решение.  При подписании подписывающее лицо должно указать, какие элементы <EncryptedData> присутствуют как часть подписи.  Это позволяет верификатору подписи явно знать, какие элементы <EncryptedData> должны быть расшифрованы перед проверкой подписи. 
  При шифровании XML возникают дополнительные проблемы с безопасностью, в частности, связанные с «атаками с открытым текстом».  Если известно, что конкретный текст был зашифрован, например элемент (например, <Visit> ), это может облегчить нарушение шифрования.  Поскольку XML является многословным, а имена элементов могут быть известны из определения схемы словаря XML, более вероятно, что атаки с открытым текстом возможны.  В результате, при выборе алгоритмов шифрования и их параметров необходимо соблюдать особую осторожность, чтобы предотвратить использование этой информации в целях конфиденциальности. 
  Примеры 
  Использование элементов  <EncryptedData> и <EncryptedKey> можно обобщить, используя предыдущий пример, в котором информация об учетной записи зашифрована для обеспечения конфиденциальности.  Дополнительная информация о частях EncryptedData и EncryptedKey этого примера поясняется в рекомендации кандидата на шифрование XML [ XML Enc ]: 
 <PatientRecord  xmlns="http://www.medical.org/"  xmlns:lab="http://www.lab.org/tests">  <Name>John Doe</Name>  <EncryptedData  Type='http://www.w3.org/2001/04/xmlenc#Element'  xmlns='http://www.w3.org/2001/04/xmlenc#'>    <EncryptionMethod  Algorithm='http://www.w3.org/2001/04/xmlenc#3des-cbc'/>    <ds:KeyInfo  xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>      <EncryptedKey Id='EK'  xmlns='http://www.w3.org/2001/04/xmlenc#'>        <EncryptionMethod  Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />        <ds:KeyInfo  xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>          <ds:KeyName>            Dr Kutter's public key pair          </ds:KeyName>        </ds:KeyInfo>         <CipherData>          <CipherValue>xyzabc</CipherValue>        </CipherData>         <CarriedKeyName>          Dr Kutter's symmetric key        </CarriedKeyName>      </EncryptedKey>       <ds:KeyName>        Dr Kutter's symmetric key      </ds:KeyName>    </ds:KeyInfo>     <CipherData>      <CipherValue>a17xj2z</CipherValue>    </CipherData>  </EncryptedData>   <Visit date="10pm March 10, 2002">    <Diagnosis>      Broken second metacarpal    </Diagnosis>     <lab:Diagnosis>      <lab:Xray>xhzhez</lab:Xray>    </lab:Diagnosis>  </Visit>   <Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>    <SignedInfo>      <SignatureMethod  Algorithm="http://www.w3.org/2000/07/xmldsig#rsa-sha1" />       <!-- signature on entire PatientRecord           before encryption is default interpretation -->      <Reference URI="">        <Transforms  Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />        <DigestMethod  Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />        <DigestValue>kjsdf</DigestValue>      </Reference>    </SignedInfo>     <SignatureValue>xjksdasd</SignatureValue>     <KeyInfo>      <KeyName>Sally Smith's Integrity Key</KeyName>    </KeyInfo>  </Signature>  </PatientRecord> 
  Пример 7 - подробный пример шифрования XML

          

            
        


  Управление ключами: Спецификация управления ключами XML (XKMS) 
  Цель и преимущества 
  Спецификация управления ключами XML (XKMS) [ XKMS ] определяет протоколы для служб управления открытыми ключами.  Управление открытым ключом включает в себя создание пары открытого и закрытого ключей, связывание этой пары ключей с идентификационными данными и другими атрибутами, а также представление этой пары ключей в различных форматах, таких как имя ключа, цифровой сертификат или параметры ключа, для приведу несколько примеров.  Технология открытых ключей является неотъемлемой частью цифровых подписей XML, шифрования XML и других приложений безопасности.  При подписании закрытый ключ используется для подписи, а открытый ключ - для проверки подписей.  При шифровании открытый ключ используется для шифрования, а закрытый ключ используется для расшифровки.  В любом случае закрытый ключ должен храниться под контролем владельца, а открытый ключ может быть передан другим лицам.  XKMS предназначен для управления совместным использованием открытого ключа, чтобы обеспечить проверку подписи и шифрование для получателей. 
  Управление открытым ключом обычно требует этапа регистрации, на котором генерируется пара ключей и выдается какой-то токен, чтобы связать открытый ключ с идентификационной информацией и другими атрибутами владельца.  Этот этап регистрации обычно включает в себя своего рода должную осмотрительность, чтобы снизить риски неправильного связывания открытого ключа, поскольку люди будут полагаться на пару ключей позже.  Управление также включает возможность отмены связи информации с парой ключей в случае изменения обстоятельств, таких как кража закрытого ключа или изменение атрибутов владельца (например, больше не сотрудника).  Аналогично, информация, связанная с парой ключей, может быть обновлена.  Традиционно такие привязки управлялись с помощью цифровых сертификатов X.509, специализированных протоколов и инфраструктур открытых ключей.  XKMS определяет форматы сообщений XML для поддержки запросов и ответов для управления открытым ключом, включая регистрацию, отзыв и обновления.  Это устраняет необходимость в приложениях для поддержки других специализированных протоколов регистрации и управления открытыми ключами. 
  После завершения регистрации пару открытых ключей можно использовать для подписи и проверки или шифрования и дешифрования.  Элемент <KeyInfo>, определенный в рекомендации цифровой подписи XML, может использоваться для предоставления получателю цифровой подписи или зашифрованного блока данных информации о ключе, необходимом для обработки этого содержимого.  Эта информация может принимать различные формы, такие как имя ключа, цифровой сертификат, содержащий открытый ключ, набор параметров ключа или URI, указывающий, где получить открытый ключ.  Учитывая разнообразие вариантов предоставления информации о ключе получателю, приложению может быть сложно обработать и найти ключ.  Помимо сложности предвидения всех форматов, некоторые, например сертификаты X.509, требуют специального криптографического кода и логики для обработки.  XKMS предоставляет формат сообщения XML, позволяющий этой обработке выполнять службу, которая будет сортировать различные параметры, определять тот, который был использован, и предоставлять ключевую информацию получателю в полезной форме. 
  Характеристики 
  Спецификация управления ключами XML (XKMS) определяет три спецификации: 


  Спецификация службы регистрации ключей XML (XKRSS), 
  Спецификация информационной службы ключей XML (XKISS) 
  Привязки к протоколу 

  Эти спецификации определяют XML-запрос и ответные сообщения, необходимые для регистрации и управления информацией, связанной с открытыми ключами, и для обеспечения соответствия требованиям безопасности. 
  Служба регистрации поддерживает связывание информации с парой открытых ключей, либо сгенерированной сервером, либо клиентом.  Привязка связывает информацию с парой ключей, создавая элемент <KeyBinding> .  Эта привязка может иметь период действия, связанный с ним, и может быть переиздана или аннулирована.  Закрытый ключ, связанный с привязкой ключа, также может быть восстановлен, если локальная копия уничтожена (например, когда операционная система требует переустановки). 
  Служба ключевой информации позволяет клиенту запрашивать информацию, связанную с элементом <KeyInfo> .  Это может включать в себя: 

  Найти — разрешить элемент <KeyInfo>, чтобы получить запрошенную информацию о ключе. 

  Проверка — найдите информацию о ключе и предоставьте подтверждение действительности привязки к паре ключей. 

  Запрос ключевой информации может указывать форму ключевой информации, которая должна быть возвращена.  Например, он может запросить, чтобы <KeyName> и <KeyValue> были определены из элемента <KeyInfo> .  В рамках этого процесса сервер может выполнить проверку, чтобы подтвердить достоверность привязки к ключу. 
  Спецификация привязок протокола определяет механизмы для удовлетворения требований безопасности, включая механизмы, обеспечивающие конфиденциальность, целостность и безопасность сообщений.  Это включает в себя следующие определения: 

  Двухфазный протокол, чтобы избежать повторных атак 
  Протокол ожидания ответа 
  Использование безопасности полезной нагрузки 
  Использование безопасности на транспорте, такой как SSL / TLS 
  Использование безопасности веб-сервисов (см. Ниже) 

  Ключевые идеи 
  Важные моменты о спецификации XKMS: 

  Эта спецификация определяет сообщения протокола XML для передачи регистрации ключей и запросов информации на доверительный сервер и для передачи ответов от сервера.  Спецификация определяет привязку этих сообщений к протоколу XML (SOAP) и определяет отношения между сообщениями с использованием языка определения веб-служб (WSDL). 
  <ds:KeyInfo> клиенту службе доверия, сводя к минимуму сложность клиента.  То, как реализуется служба доверия, зависит от службы, но одна из возможностей — выступать в качестве внешнего интерфейса для инфраструктуры открытых ключей (PKI). 
  Спецификация информационной службы ключей XML (XKISS) включает функциональность онлайн-статуса, эквивалентную функциональности в традиционных протоколах PKI OCSP, как часть функциональности Validate. 
  Регистрация поддерживает требования к производству смарт-карт, включая массовую обработку и ожидающие ответы. 
  Спецификация поддерживает использование цифровых подписей XML для целостности сообщений и аутентификации.  В спецификации также определяются другие механизмы аутентификации, поддержка подтверждения владения ключами и другие функции безопасности. 
  Запрос Locate или Validate может включать в <KeyInfo> элемент <RespondWith> элемент <RespondWith> .  Элемент <RespondWith> используется для указания того, к <KeyInfo> должен быть разрешен элемент <KeyInfo> , возможно, более чем к одному элементу.  Например, запрос <KeyInfo> может содержать сертификат X.509, а <RespondWith> может указывать, что KeyName и KeyValue должны быть возвращены.  Возможности включают KeyName, KeyValue и Certificate, Certificate Chain (набор сертификатов, необходимых для отслеживания подписи доверенной стороне) среди возможностей, описанных в спецификации. 
  <KeyBinding> используется для связи информации с ключом.  Это то, что возвращается в ответе Locate или Validate.  Каждый <KeyBinding> включает в себя <KeyBinding> <ValidityInterval> (NotBefore, NotOnOrAfter) и может также включать <KeyInfo> , <ProcessInfo> (непрозрачные данные), <KeyUsage> и <UseKeyWith> . 

  Определение использования ключа намеренно ограничено шифрованием, подписью и обменом ключами. 

  <KeyBinding> <UseKeyWith> определяет, для какого приложения и сущности приложения предназначен ключ.  Например, ключ может подходить только для аутентификации сервера SSL.  В этом случае приложением является HTTPS, а идентификатором является URL-адрес сервера.  Приложения, перечисленные в спецификации, включают S / MIME, HTTPS, SMTP, IPSec, PKIX и другие. 

  Примеры 
  Клиент может сгенерировать пару ключей и пожелать зарегистрировать ее на доверенном сервере, как в этом примере.  (Полные примеры приведены в спецификации XKMS): 
 <RegisterRequest  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"  Service="http://test.xmltrustcenter.org/XKMS"  RequestId="hZMRGyATbUL4H7rYOanR6Q=="  xmlns="http://www.w3.org/2002/03/xkms#">  <RespondWith>X509Cert</RespondWith>  <Prototype Id="tX4Y83grmj/eIVoeYNuTNg==">    <KeyInfo>      <ds:KeyValue>        <ds:RSAKeyValue>          <ds:Modulus>            zvbTdKsTprGAKJdgi7ulDR0eQBptL...          </ds:Modulus>          <ds:Exponent> AQAB </ds:Exponent>        </ds:RSAKeyValue>      </ds:KeyValue>    </KeyInfo>     <KeyUsage>Signature</KeyUsage>    <UseKeyWith      Application="urn:ietf:rfc:2633"      Identifier="[email protected]" />  </Prototype>  <Authentication>    <ProofOfPossession>      <ds:Signature>        signing with the private key        demonstrates possession of it      </ds:Signature>    </ProofOfPossession>  </Authentication>  </RegisterRequest> 
  Пример 8 - Запрос на регистрацию XKMS
  Сервер отвечает информацией, запрошенной с помощью <RespondWith> : 
 <RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"                Service="http://test.xmltrustcenter.org/XKMS"                ResultMajor="Success"                RequestId="hZMRGyATbUL4H7rYOanR6Q=="                ResponseId="k9gyjDdhLLV1vbF7RzJjIw=="                xmlns="http://www.w3.org/2002/03/xkms#">    <KeyBinding Id="LVrJqd26QzO9GWJD0usQwg==">        <KeyInfo>           <KeyName>Sally Smith key</KeyName>        </KeyInfo>        <KeyUsage>Signature</KeyUsage>        <UseKeyWith Application="urn:ietf:rfc:2633"        Identifier="[email protected]" />    </KeyBinding>  </RegisterResult> 
  Пример 9 - Ответ регистра XKMS
  Клиент может запросить подтверждение личности: 
 <ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"                 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"                 Service="http://test.xmltrustcenter.org/XKMS"                 RequestId="zzjmNi9YL+dnkRXzDoqPoQ=="                 xmlns="http://www.w3.org/2002/03/xkms#">    <RespondWith>KeyName</RespondWith>    <RespondWith>KeyValue</RespondWith>    <RespondWith>Multiple</RespondWith>    <KeyBindingQuery Id="T/QMi7gGuKCcNWPi120A/w==">        <Keyoo