Introduction détaillée au chiffrement XML et à la signature XML

Introduction

XML est devenu un mécanisme précieux pour l'échange de données sur Internet. SOAP, un moyen d'envoyer des messages XML, permet aux processus de communiquer entre eux d'une manière sans précédent, et UDDI semble devenir rapidement la norme pour intégrer les fournisseurs et les utilisateurs de services Web eux-mêmes au format XML ; et Décrit sous la forme de WSDL (c'est-à-dire « Web Services Description Language »). Sans XML, cette flexibilité et cette puissance ne seraient pas possibles et, comme beaucoup l'ont dit, il serait nécessaire d'inventer un métalangage.

SécuritéLe domaine sexuel est un autre domaine en croissance rapide. Les méthodes traditionnelles d'établissement de la confiance entre différents groupes ne sont plus appropriées sur l'Internet public, ni même sur les grands réseaux locaux et étendus. Dans ces cas, les mécanismes de confiance basés sur la cryptographie asymétrique peuvent être très utiles, mais en pratique, la facilité de déploiement et de gestion des clés, la portée de l'interopérabilité et la sécurité fournie sont bien inférieures aux différentes « fondations de clés publiques ». Les vendeurs enthousiastes d'Infrastructures (PKI) nous l'avaient laissé croire. Il est particulièrement difficile de gérer des structures de données hiérarchiques et des sous-ensembles de données ayant des exigences différentes telles que la confidentialité, les droits d'accès ou l'intégrité. De plus, les applications dotées de contrôles de sécurité différents de ceux de la norme actuelle pour les documents XML sont tout sauf simples.

Actuellement, plusieurs groupes participent activement à l'examen de ces questions et à l'élaboration de normes. Les principaux développements associés sont le cryptage XML et les signatures XML associées, le "Extensible Access Control Language (XACL)" et le "Security Assertion Markup Language (SAML - une combinaison des anciens concurrents AuthML et S2ML)". Tout cela est piloté par OASIS et la spécification de gestion de clés XML (XKMS). Cet article présentera le cryptage XML et la signature XML.

"XML Security Suite"
Cela s'explique en partie par le fait que ces normes sont encore en phase de développement, de sorte que le nombre d'outils et de bibliothèques disponibles pour les développeurs est encore limité, mais très confiant Le fait est que cela commence à changer. IBM a soumis deux « demandes de spécification Java (JSR) » au « Java Community Process (JCP) ». Il s'agit de JSR-105, « XML Digital Signature API » et JSR-106, « Digital Encryption API ».
Le "IBM Tokyo Research Laboratory" a développé la "XML Security Suite" en 1999 comme prototype d'implémentation de signatures XML. Il contient des utilitaires qui génèrent automatiquement des signatures numériques XML, implémentent le projet de travail XML « canonique » du W3C et fournissent un cryptage au niveau des éléments grâce à une implémentation expérimentale du cryptage XML. Il fournit également un moyen de gérer les exigences spécifiques à la sécurité lorsqu'elles sont appliquées aux documents XML. Une définition de schéma XML pour le langage de contrôle d'accès extensible (XACL) est également introduite.

developerWorks a un article de Doug Tidwell décrivant la suite en détail, et la dernière version de la suite est disponible sur le site alphaWorks. (Voir Ressources.)

Chiffrement XML et signature XML
Comme tout autre document, un document XML peut être chiffré dans son intégralité puis envoyé en toute sécurité à un ou plusieurs récepteurs. Il s’agit d’une fonctionnalité courante de SSL ou TLS, par exemple, mais ce qui est plus intéressant est la manière dont différentes parties d’un même document sont traitées différemment. Un avantage précieux du XML est qu'un XML entier peut être envoyé en une seule opération puis enregistré localement, réduisant ainsi le trafic réseau. Cependant, cela soulève une question : comment contrôler la visualisation autorisée des différents groupes d'éléments. Le commerçant peut avoir besoin de connaître le nom et l’adresse du client, mais n’a pas besoin de connaître les détails de la carte de crédit utilisée, tout comme la banque n’a pas besoin de connaître les détails des marchandises achetées. Il peut être nécessaire d'empêcher les chercheurs de consulter les détails du dossier médical d'un individu, tandis que les administrateurs peuvent avoir besoin de ces détails précis, mais ils doivent être empêchés de consulter les antécédents médicaux, alors qu'un médecin ou une infirmière peut avoir besoin de détails médicaux et de certains (mais pas tous) personnels ; matériel.

La cryptographie fait désormais bien plus que cacher des informations. Le message digest détermine l'intégrité textuelle, la signature numérique prend en charge l'authentification de l'expéditeur et les mécanismes associés sont utilisés pour garantir qu'aucune partie ne puisse rejeter ultérieurement une transaction valide. Ce sont tous des éléments essentiels des transactions à distance, et les mécanismes de traitement de documents entiers sont désormais assez bien développés.

Avec un cryptage normal, signer numériquement l'intégralité du document XML ne pose pas de problème. Toutefois, des difficultés surviennent lorsque différentes parties d’un document doivent être signées (peut-être par différentes personnes) et lorsque cela doit être fait en conjonction avec une approche sélective. Il n'est peut-être pas possible ou utile de forcer le cryptage de différentes parties à être effectué par des personnes spécifiques dans un ordre spécifique, mais le succès de la gestion des différentes parties d'un document dépendra de cette connaissance. De plus, étant donné que les signatures numériques affirment qu'elles ont été authentifiées à l'aide d'une clé privée spécifique, veillez à ce que le signataire visualise l'élément de document en texte brut, ce qui peut impliquer de déchiffrer des parties du contenu qui ont été chiffrées pour d'autres raisons. Dans un autre cas, des données déjà chiffrées peuvent être davantage chiffrées dans le cadre d’une collection plus vaste. Plus vous envisagez de possibilités différentes dans un ensemble de transactions impliquant un seul document XML (éventuellement traité par quelques applications différentes et différents utilisateurs, un formulaire Web ou une série de données utilisées dans une séquence de flux de travail), plus vous avez de chances de voir énorme complexité potentielle.

Il y a d'autres questions. L'un des points forts du langage XML est que les recherches sont sans ambiguïté : une DTD ou un schéma fournit des informations sur la syntaxe pertinente. Si une partie d'un document, y compris les balises, est chiffrée dans son ensemble, vous perdez la possibilité de rechercher des données liées à ces balises. De plus, si les jetons eux-mêmes sont cryptés, en cas de fuite, ils peuvent être exploités pour effectuer des attaques en texte brut sur la cryptographie utilisée.

Ce sont quelques-uns des aspects que le groupe de travail considère.

Exemple de chiffrement XML
L'élément central de la syntaxe de chiffrement XML est l'élément EncryptedData, qui est utilisé avec l'élément EncryptedKey pour transmettre la clé de chiffrement de l'initiateur au destinataire connu. , EncryptedData est dérivé du type abstrait EncryptedType. Les données à chiffrer peuvent être n'importe quelle donnée, document XML, élément XML ou contenu d'élément XML ; le résultat du chiffrement des données est un élément de chiffrement XML qui contient ou fait référence aux données cryptographiques. Lorsqu'un élément ou le contenu d'un élément est chiffré, l'élément EncryptedData remplace l'élément ou le contenu dans la version chiffrée du document XML. Lors du chiffrement de données arbitraires, l'élément EncryptedData peut devenir la racine d'un nouveau document XML ou un élément descendant. Lors du chiffrement d'un document XML entier, l'élément EncryptedData peut devenir la racine du nouveau document. De plus, EncryptedData ne peut pas être un élément parent ou enfant d'un autre élément EncryptedData, mais les données chiffrées réelles peuvent être tout ce qui inclut un élément EncryptedData ou EncryptedKey existant.

Le projet de travail sur le chiffrement donne quelques exemples pour démontrer comment la granularité du chiffrement varie en fonction des exigences et quelles pourraient en être les conséquences. L'extrait de code du listing 1 montre un document XML non crypté contenant une carte de crédit et d'autres informations personnelles. Dans certains cas (par exemple, en masquant les informations sur le mécanisme de paiement), vous souhaiterez peut-être chiffrer toutes les informations à l'exception du nom du client, et l'extrait de code du listing 2 montre comment procéder.

Liste 1. Afficher les informations sur le compte bancaire de John Smith, la limite de 5 000 $, le numéro de carte et la date d'expiration

  <PaymentInfo xmlns=&#39;http://example.org/paymentv2&#39;> 
         <Name>John Smith<Name/> 
         <CreditCard Limit=&#39;5,000&#39; Currency=&#39;USD&#39;> 
           <Number>4019 2445 0277 5567</Number> 
           <Issuer>Bank of the Internet</Issuer> 
           <Expiration>04/02</Expiration> 
         </CreditCard> 
       </PaymentInfo>

Liste 2. Documents cryptés avec tout crypté sauf le nom

<PaymentInfo xmlns=&#39;http://example.org/paymentv2&#39;> 
         <Name>John Smith<Name/> 
         <EncryptedData Type=&#39;http://www.w3.org/2001/04/xmlenc#Element&#39; 
          xmlns=&#39;http://www.w3.org/2001/04/xmlenc#&#39;> 
             <CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData> 
         </EncryptedData> 
       </PaymentInfo>

Cependant, dans d'autres cas, il se peut qu'il n'y ait que certains contenus sensibles qui doivent être masqués - peut-être d'un commerçant ou autres tiers – la liste 3 le démontre. (Notez que les noms de balises liés au contenu crypté sont affichés.)

Liste 3. Document crypté avec uniquement le numéro de carte de crédit masqué

  <PaymentInfo xmlns=&#39;http://example.org/paymentv2&#39;> 
         <Name>John Smith<Name/> 
         <CreditCard Limit=&#39;5,000&#39; Currency=&#39;USD&#39;> 
           <Number> 
             <EncryptedData xmlns=&#39;http://www.w3.org/2001/04/xmlenc#&#39; 
              Type=&#39;http://www.w3.org/2001/04/xmlenc#Content&#39;> 
                 <CipherData><Ciphervalue>A23B45C56</Ciphervalue> 
                 </CipherData> 
             </EncryptedData> 
           </Number> 
           <Issuer>Bank of the Internet</Issuer> 
           <Expiration>04/02</Expiration> 
         </CreditCard> 
       </PaymentInfo>

Il peut également être nécessaire de chiffrer toutes les informations contenues dans le document, comme le démontre le listing 4.

Liste 4. Document crypté avec tout le contenu masqué

 <EncryptedData xmlns=&#39;http://www.w3.org/2001/04/xmlenc#&#39; 
        Type=&#39;http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml&#39;> 
                <CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData> 
       </EncryptedData>

Les données chiffrées peuvent être encapsulées ou référencées cryptées brutes données. Dans le premier cas, le contenu de l'élément Ciphervalue affiche les données brutes, tandis que dans le second cas, un élément CipherReference est utilisé, qui comprend un URI pointant vers l'emplacement des données chiffrées.

规范的 XML
对应用了密码散列算法的消息进行最轻微的更改也会产生不同的值。这为消息完整性方面提供了信任，并适于通常用法，但是也引入了进一步的复杂性 — 两个 XML 文档虽然在逻辑上相等，但可能在确切文本比较中不同。象行定界符、空标记、在属性中使用十六进制而不是名称以及在特定情况下存在注释或注释变体这样的事情都可以成为文档的逻辑结构不受影响而实际彼此不同的实例。规范的 XML 规范描述了一种生成文档的物理表示（也成为范式）的方法，该范式解释允许的变体，以便如果两个文档具有同一范式，则认为两个文档在给定应用程序上下文中是逻辑相等的。

对于加密、特别是数字签名来说，这尤为重要，因为很明显，逻辑上相同的文本变体不应该表示文档的完整性及其发送方的认证是可疑的。用不同工具（譬如，解析器）生成不同文本（并因而生成不同消息摘要）进行处理时也可能发生这样的事。因此，在生成签名和验证计算期间，应该在范式上进行消息摘要。如果摘要匹配，这将确定：即使文本形式可能不同，它们在其上计算的范式也匹配。

XML 签名示例
可以将 XML 签名应用到任意数据内容。那些应用到相同 XML 文档中数据的签名称为封装或被封装的签名，而那些数据在签名元素外部的签名称为 分离签名。清单 5 取自签名候选推荐文档，它是一个简单分离签名的实例。

清单 5. 一个简单分离签名的示例

 [s01] <Signature Id="MyFirstSignature" 
                xmlns="http://www.w3.org/2000/09/xmldsig#">  
          [s02]   <SignedInfo>  
          [s03]   <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/ 
                  REC-xml-c14n-20010315"/>  
          [s04]   <SignatureMethod Algorithm="http://www.w3.org/2000/09/ 
                  xmldsig#dsa-sha1"/>  
          [s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">  
          [s06]     <Transforms>  
          [s07]       <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n- 
                      20010315"/>  
          [s08]     </Transforms>  
          [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/ 
                       xmldsig#sha1"/>  
          [s10]     <Digestvalue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</Digestvalue>  
          [s11]   </Reference>  
          [s12] </SignedInfo>  
          [s13]   <Signaturevalue>MC0CFFrVLtRlk=</Signaturevalue>  
          [s14]   <KeyInfo>  
          [s15a]    <Keyvalue> 
          [s15b]      <DSAKeyvalue>  
          [s15c]        <p></p><Q></Q><G></G><Y></Y>  
          [s15d]      </DSAKeyvalue>  
          [s15e]    </Keyvalue>  
          [s16]   </KeyInfo>  
          [s17] </Signature>

实际签名的信息是位于 s02 行和 s12 行之间，即 SignedInfo 元素。在签名的部分中包含用于计算 Signaturevalue 元素的算法的引用，而那个元素本身位于签名部分之外（在 s13 行上）。s04 行上的 SignatureMethod 引用的是将规范的 SignedInfo 转换成 Signaturevalue 所用的算法。它是密钥相关的算法和摘要算法（在这里是 DSA 和 SHA-1）的组合，可能还具有象填充这样的操作。KeyInfo 元素（在这里位于 s14 行和 s16 行之间 — 该元素是可选的）指出用来验证签名的密钥。

转换
正如前面所提到的，加密、签名、修改和可能进行的更多签名所发生的顺序有很多种可能性。用户可能需要向已经部分加密或部分签名的表单字段中输入更多数据，并且需要能够在不妨碍以后的验证和解密的前提下这样做。为解决这种情况，W3C 最近发布了一个有关 XML 签名的解密转换工作草案。（请参阅参考资料。）

下面这个示例摘自那个文档，它演示了如何建议文档接收方采用正确的解密和签名验证顺序。第一个代码段显示了要签名的文档部分 — order 元素；其中，第 7 行到第 11 行的 cardinfo 元素是关于个人和财务方面的详细信息，它是纯文本，但也存在一些加密数据（第 12 行）。

清单 6. XML 文档中的 order 元素

[01] <order Id="order"> 
          [02]   <item> 
          [03]     <title>XML and Java</title> 
          [04]     <price>100.0</price> 
          [05]     <quantity>1</quantity> 
          [06]   </item> 
          [07]   <cardinfo> 
          [08]     <name>Your Name</name> 
          [09]     <expiration>04/2002</expiration> 
          [10]     <number>5283 8304 6232 0010</number> 
          [11]   </cardinfo> 
          [12]   <EncryptedData Id="enc1"xmlns="http://www.w3.org/ 
                 2001/04/xmlenc#"></EncryptedData> 
          [13] </order>

清单 7. 经过签名和进一步加密、且现在显示转换信息的 order 文档

[01] <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
          [02]   <SignedInfo> 
          [03]      
          [04]     <Reference URI="#order"> 
          [05]       <Transforms> 
          [06]         <Transform Algorithm="http://www.w3.org/2001/04/ 
xmlenc#decryption"> 
          [07]           <DataReference URI="#enc1" 
                          xmlns="http://www.w3.org/2001/04/xmlenc#"/> 
          [08]         </Transform> 
          [09]         <Transform Algorithm="http://www.w3.org/TR/2000/ 
                       CR-xml-c14n-20001026"/> 
          [10]       </Transforms> 
          [11]        
          [12]     </Reference> 
          [13]   </SignedInfo> 
          [14]   <Signaturevalue></Signaturevalue> 
          [15]   <Object> 
          [16]     <order Id="order"> 
          [17]       <item> 
          [18]         <title>XML and Java</title> 
          [19]         <price>100.0</price> 
          [20]         <quantity>1</quantity> 
          [21]       </item> 
          [22]       <EncryptedData Id="enc2" 
                     xmlns="http://www.w3.org/2001/04/xmlenc#"></EncryptedData> 
          [23]       <EncryptedData Id="enc1" 
                     xmlns="http://www.w3.org/2001/04/xmlenc#"></EncryptedData> 
          [24]     </order> 
          [25]   </Object> 
          [26] </Signature>

        第 1 行到 第 26 行的 Signature 元素现在包含前面的 order 元素（位于第 16 行到第 24 行），和以前的加密纯文本 cardinfo（显示在第 22 行这一行中）。有两个转换引用：解密（第 6 行到第 8 行）和规范化（第 9 行）。解密转换指示签名验证器解密除 DataRef 元素中第 7 行指定的数据之外的所有加密数据。解密了第 22 行中的 EncryptedData 元素之后，规范化 order 元素并且恰当地验证签名。

       其它相关语言和规范
    隐藏 XML 文档中的敏感信息、建立完整性以及认证这些文档的不同部分的来源主要通过遵循加密和签名规范中列出的步骤来处理的，在引用的 W3C 草案中描述该规范（请参阅参考资料）。另外，还有其它紧密相关的领域，例如认证用户或系统、标识授权级别和管理密钥，所有这些都与 XML 安全性相关。

       SAML 是一个由 OASIS 驱动的模型，它尝试融合相互竞争的 AuthML 和 S2ML 规范，使认证和授权信息的互换便于进行。“可扩展访问控制标记语言”是与 SAML 紧密相关的，但它更着重于特定 XML 文档的上下文中的面向主题特权对象的安全性模型，它也由 OASIS 指导，又是被称为 XACML 或 XACL（即使在同一些文档中）。通过用 XACL 编写规则，策略制订者可以定义，对于特定 XML 文档和前面所述的情况中的相关事情，由谁来实施哪些访问特权。
       关于SAML的详细内容,我将在下一篇Blog内讲述.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!