Detaillierte Einführung in die XML-Verschlüsselung und XML-Signatureinführung

Einführung

XML hat sich zu einem wertvollen Mechanismus für den Datenaustausch im Internet entwickelt. SOAP, eine Möglichkeit zum Versenden von XML-Nachrichten, ermöglicht die Kommunikation von Prozessen untereinander auf beispiellose Weise, und UDDI scheint sich schnell zum Standard für die Integration von Anbietern und Benutzern von Webdiensten zu entwickeln; die Dienste selbst sind XML und beschrieben in der Form WSDL (d. h. „Web Services Description Language“). Ohne XML wäre diese Flexibilität und Leistungsfähigkeit nicht möglich, und wie viele gesagt haben, wäre es notwendig, eine Metasprache zu erfinden.

SicherheitDer sexuelle Bereich ist ein weiterer schnell wachsender Bereich. Herkömmliche Methoden zum Aufbau von Vertrauen zwischen verschiedenen Gruppen sind im öffentlichen Internet und in der Tat in großen LANs und WANs nicht mehr angemessen. In diesen Fällen können Vertrauensmechanismen, die auf asymmetrischer Kryptographie basieren, sehr nützlich sein, aber in der Praxis sind die einfache Bereitstellung und Schlüsselverwaltung, der Umfang der Interoperabilität und die bereitgestellte Sicherheit den verschiedenen „Public-Key-Grundlagen“ weit unterlegen Die begeisterten Anbieter von Infrastructures (PKI) haben uns überzeugt. Besonders schwierig ist der Umgang mit hierarchischen Datenstrukturen und Teilmengen von Daten mit unterschiedlichen Anforderungen wie Vertraulichkeit, Zugriffsrechten oder Integrität. Darüber hinaus sind Anwendungen mit anderen Sicherheitskontrollen als dem heutigen Standard für XML-Dokumente alles andere als einfach.

Derzeit beschäftigen sich mehrere Gruppen aktiv mit der Untersuchung dieser Probleme und der Entwicklung von Standards. Die wichtigsten damit verbundenen Entwicklungen sind die XML-Verschlüsselung und zugehörige XML-Signaturen, die „Extensible Access Control Language (XACL)“ und die zugehörige „Security Assertion Markup Language (SAML – eine Kombination der ehemaligen Konkurrenten AuthML und S2ML)“. All dies wird durch OASIS und die XML Key Management Specification (XKMS) gesteuert. In diesem Artikel werden die XML-Verschlüsselung und die XML-Signatur vorgestellt.

„XML Security Suite“
Dies liegt zum Teil daran, dass sich diese Standards noch in der Entwicklungsphase befinden, sodass die Anzahl der Toolsets und Bibliotheken, die Entwicklern zur Verfügung stehen, noch begrenzt, aber sehr begrenzt ist zuversichtlich Der Punkt ist, dass sich dies allmählich ändert. IBM hat zwei verwandte „Java Specification Requests (JSR)“ beim „Java Community Process (JCP)“ eingereicht. Dies sind JSR-105, „XML Digital Signature API“ und JSR-106, „Digital Encryption API“.
„IBM Tokyo Research Laboratory“ entwickelte 1999 die „XML Security Suite“ als prototypische Implementierung von XML-Signaturen. Es enthält Dienstprogramme zur automatischen Generierung digitaler XML-Signaturen, zur Implementierung des „kanonischen“ XML-Arbeitsentwurfs des W3C und zur Bereitstellung einer Verschlüsselung auf Elementebene durch eine experimentelle Implementierung der XML-Verschlüsselung. Es bietet auch eine Möglichkeit, sicherheitsspezifische Anforderungen bei der Anwendung auf XML-Dokumente zu handhaben. Außerdem wird eine XML-Schemadefinition für die Extensible Access Control Language (XACL) eingeführt.

developerWorks hat einen Artikel von Doug Tidwell, der die Suite im Detail beschreibt, und die neueste Version der Suite ist auf der alphaWorks-Website verfügbar. (Siehe Ressourcen.)

XML-Verschlüsselung und XML-Signatur
Wie jedes andere Dokument kann ein XML-Dokument vollständig verschlüsselt und dann sicher an einen oder mehrere Empfänger gesendet werden. Dies ist beispielsweise ein gemeinsames Merkmal von SSL oder TLS. Interessanter ist jedoch, dass verschiedene Teile desselben Dokuments unterschiedlich behandelt werden. Ein wertvoller Vorteil von XML besteht darin, dass ein gesamtes XML in einem Vorgang gesendet und dann lokal gespeichert werden kann, wodurch der Netzwerkverkehr reduziert wird. Dies wirft jedoch die Frage auf, wie die autorisierte Anzeige verschiedener Elementgruppen gesteuert werden kann. Der Händler muss möglicherweise den Namen und die Adresse des Kunden kennen, muss jedoch nicht die Details einer verwendeten Kreditkarte kennen, ebenso wie eine Bank nicht die Details des Warenkaufs kennen muss. Forscher müssen möglicherweise daran gehindert werden, Details über die Krankenakten einer Person einzusehen, während Administratoren möglicherweise genau diese Details benötigen. Sie sollten jedoch daran gehindert werden, die Krankengeschichte einer Person einzusehen, während ein Arzt oder eine Krankenschwester möglicherweise medizinische Details und einige (aber nicht alle) persönlichen Daten benötigt Material.

Kryptografie kann jetzt viel mehr als nur Informationen verbergen. Der Digest der Nachricht bestimmt die Textintegrität, die digitale Signatur unterstützt die Absenderauthentifizierung und zugehörige Mechanismen werden verwendet, um sicherzustellen, dass keine Partei später eine gültige Transaktion ablehnen kann. Dies sind alles wesentliche Elemente von Remote-Transaktionen, und die Mechanismen zur Verarbeitung ganzer Dokumente sind mittlerweile recht gut entwickelt.

Bei normaler Verschlüsselung ist das digitale Signieren des gesamten XML-Dokuments kein Problem. Allerdings treten Schwierigkeiten auf, wenn verschiedene Teile eines Dokuments unterzeichnet werden müssen (vielleicht von verschiedenen Personen) und dies in Verbindung mit einem selektiven Ansatz erfolgen muss. Es ist möglicherweise nicht möglich oder sinnvoll, die Verschlüsselung verschiedener Teile durch bestimmte Personen in einer bestimmten Reihenfolge zu erzwingen. Der erfolgreiche Umgang mit verschiedenen Teilen eines Dokuments hängt jedoch davon ab, dies zu wissen. Da digitale Signaturen zudem bestätigen, dass sie mithilfe eines bestimmten privaten Schlüssels authentifiziert wurden, müssen Sie darauf achten, dass der Unterzeichner das Dokumentelement im Klartext anzeigt. Dies kann dazu führen, dass Teile des Inhalts entschlüsselt werden, die aus anderen Gründen verschlüsselt wurden. In einem anderen Fall können bereits verschlüsselte Daten als Teil eines größeren Satzes weiter verschlüsselt werden. Je mehr unterschiedliche Möglichkeiten Sie in einem Transaktionssatz in Betracht ziehen, der ein einzelnes XML-Dokument umfasst (möglicherweise verarbeitet von einigen verschiedenen Anwendungen und verschiedenen Benutzern, einem Webformular oder einer Reihe von Daten, die in einer Workflow-Sequenz verwendet werden), desto wahrscheinlicher ist es, dass Sie sehen enorme potenzielle Komplexität.

Es gibt noch andere Fragen. Eine der Stärken der XML-Sprache besteht darin, dass die Suche eindeutig ist: Eine DTD oder ein Schema liefert Informationen über die Syntax. Wenn ein Teil eines Dokuments, einschließlich Tags, als Ganzes verschlüsselt ist, können Sie nicht mehr nach Daten suchen, die sich auf diese Tags beziehen. Wenn außerdem die Tokens selbst verschlüsselt sind, können sie, wenn sie durchsickern, ausgenutzt werden, um Klartextangriffe auf die verwendete Kryptografie durchzuführen.

Dies sind einige der Aspekte, die die Arbeitsgruppe berücksichtigt.

XML-Verschlüsselungsbeispiel
Das Kernelement der XML-Verschlüsselungssyntax ist das EncryptedData-Element, das zusammen mit dem EncryptedKey-Element verwendet wird, um den Verschlüsselungsschlüssel vom Initiator an den bekannten Empfänger zu übertragen , EncryptedData wird vom abstrakten Typ EncryptedType abgeleitet. Bei den zu verschlüsselnden Daten kann es sich um beliebige Daten, XML-Dokumente, XML-Elemente oder XML-Elementinhalte handeln; das Ergebnis der verschlüsselten Daten ist ein XML-Verschlüsselungselement, das kryptografische Daten enthält oder darauf verweist. Wenn ein Element oder Elementinhalt verschlüsselt wird, ersetzt das EncryptedData-Element das Element oder den Inhalt in der verschlüsselten Version des XML-Dokuments. Beim Verschlüsseln beliebiger Daten kann das EncryptedData-Element zum Stamm eines neuen XML-Dokuments oder zu einem untergeordneten Element werden. Beim Verschlüsseln eines gesamten XML-Dokuments wird das EncryptedData-Element möglicherweise zum Stammverzeichnis des neuen Dokuments. Darüber hinaus kann EncryptedData kein übergeordnetes oder untergeordnetes Element eines anderen EncryptedData-Elements sein, aber die tatsächlich verschlüsselten Daten können alles sein, was ein vorhandenes EncryptedData- oder EncryptedKey-Element enthält.

Der Verschlüsselungsarbeitsentwurf zeigt anhand einiger Beispiele, wie die Granularität der Verschlüsselung je nach Anforderungen variiert und welche Konsequenzen dies haben kann. Der Codeausschnitt in Listing 1 zeigt ein unverschlüsseltes XML-Dokument mit Kreditkarten- und anderen persönlichen Informationen. In einigen Fällen (z. B. beim Ausblenden von Informationen zum Zahlungsmechanismus) möchten Sie möglicherweise alle Informationen außer dem Kundennamen verschlüsseln. Der Codeausschnitt in Listing 2 zeigt, wie das geht.

Liste 1. Informationen zu John Smiths Bankkonto, 5000-Dollar-Limit, Kartennummer und Ablaufdatum anzeigen

  <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>

Listing 2. Verschlüsselte Dokumente, bei denen alles außer dem Namen verschlüsselt ist

<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>

In anderen Fällen gibt es jedoch möglicherweise nur einige sensible Inhalte, die verborgen werden müssen – vielleicht vor einem Händler oder andere Dritte – Listing 3 zeigt dies. (Beachten Sie, dass Tag-Namen im Zusammenhang mit verschlüsselten Inhalten angezeigt werden.)

Listing 3. Verschlüsseltes Dokument, bei dem nur die Kreditkartennummer ausgeblendet ist

  <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>

Es kann auch notwendig sein, alle Informationen im Dokument zu verschlüsseln, wie Listing 4 zeigt.

Liste 4. Verschlüsseltes Dokument mit ausgeblendetem Inhalt

 <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>

CipherData können gekapselt oder rohverschlüsselt referenziert werden Daten. Im ersten Fall zeigt der Inhalt des Ciphervalue-Elements die Rohdaten an, während im zweiten Fall ein CipherReference-Element verwendet wird, das einen URI enthält, der auf den Speicherort der verschlüsselten Daten verweist.

规范的 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内讲述.

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in die XML-Verschlüsselung und XML-Signatureinführung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!