XML加密與XML簽章簡介的具體介紹
- 黄舟原創
- 2017-03-21 16:49:172093瀏覽
簡介
XML 已經成為一種用於在網際網路上交換資料的有價值機制。 SOAP，這種發送 XML 訊息的方式，促使進程以一種前所未有的方式相互通信，而 UDDI 看起來正在快速成為整合 Web 服務的供應商和用戶的標準；服務本身是 XML 以WSDL （即「Web 服務描述語言」）形式所描述的。如果沒有 XML，將不可能有這種靈活性和能力，並且，正如許多人所說的，將有必要發明元語言。
安全性性愛領域是另一個快速成長的領域。在不同團體之間建立信任的傳統方法在公共因特網上已不合適，實際上，在大型 LAN 和 WAN 上也不合適。在這些情況下，基於非對稱密碼術的信任機制可能非常有用，但實際上，部署和金鑰管理的便利性、互通性的範圍和提供的安全性遠不如各種的「公鑰基礎設施」（Public Key Infrastructures (PKI)）的熱情的供應商曾經讓我們相信的那樣。處理層次資料結構，以及具有機密、存取權限或完整性等不同需求的資料的子集特別困難。另外，具有不同於 XML 文件的現今標準安全性控制的應用程式一點都不簡單。
目前，有些團體正積極投入檢視這些問題和發展標準的活動。其中主要的相關開發是 XML 加密和相關的 XML 簽名、“可擴展訪問控制語言（XACL）”和相關的“安全性斷言標記語言（SAML — 以前是互為競爭對手的 AuthML 和 S2ML 的結合）” 。所有這些都由 OASIS 和「XML 密鑰管理規範（XKMS）」所驅動。本文將 介紹 XML 加密和 XML 簽章。
「XML 安全性套件」
部分原因是由於這些標準仍處於發展階段，因此，開發人員可用的工具集和函式庫的數量仍然有限，但十分確信的一點是，這正在開始發生變化。 IBM 已經向「Java 社群流程（JCP）」提交了兩種相關的「Java 規格請求（JSR）」。它們是 JSR-105、「XML 數位簽章 API」和 JSR-106、「數位加密 API」。
「IBM 東京研究實驗室」在 1999 年開發了「XML 安全性套件」作為 XML 簽署的原型實作。它包含一些自動產生 XML 數位簽章、實現 W3C 的「規範」XML 工作草案，以及透過 XML 加密的實驗性實作來提供元素級加密的實用程式。它還提供一種在應用到 XML 文件時處理安全性特定要求的方式。也引入了「可擴充存取控制語言（XACL）」的 XML 模式定義。
developerWorks 有一篇 Doug Tidwell 著的文章詳細講述了該套件，可在 alphaWorks 站點獲得該套件的最新版本。 （請參閱參考資料。）
XML 加密和 XML 簽章
象其它任何文件一樣，可以將 XML 文件整篇加密，然後安全地傳送給一個或多個接收方。例如，這是 SSL 或 TLS 的常見功能，但更令人感興趣的是如何對相同文件的不同部分進行不同處理的情況。 XML 的一個有價值的好處是可以將一整篇 XML作為一個操作發送，然後在本地保存，從而減少了網路通訊量。但是，這就帶來了一個問題：如何控制不同元素組的授權檢視。商家可能需要知道客戶的名稱和地址，但是，無需知道任何正在使用的信用卡的各種詳細信息，就像銀行不需要知道購買貨物的詳細信息一樣。可能需要防止研究人員看到有關個人醫療記錄的詳細信息，而管理人員可能正好需要那些詳細信息，但是應該防止他們查看醫療歷史；而醫生或護士可能需要醫療詳細信息和一些（但不是全部）個人資料。
密碼術現在所做的遠不止於隱藏訊息。訊息摘要確定文字完整性，數位簽章支援發送方認證，相關的機制用於確保任何一方日後無法拒絕有效交易。這些都是遠端交易必不可少的元素，現在，用於處理整個文件的機制開發得相當好。
有了一般的加密，將 XML 文件整體數位化簽章不是問題。然而，當需要對文件的不同部分（可能由不同的人）簽名，以及需要與選擇性的方法一起來這樣做時，就會出現困難。也許不可能或不值得強制不同部分的加密工作由特定人員按特定順序進行，然而成功地處理文件的不同部分將取決於是否知道這一點。此外，由於數位簽章斷言已經使用了特定專用金鑰來認證，所以要小心簽署人是以純文字形式查看文件項目的，這可能意味著對由於其它原因而加密的部分內容進行了解密。在另一種情況下，作為更大集合中的一部分，可能會對已經加密過的資料進行進一步加密。在牽涉單一 XML 文件（可能由一些不同的應用程式和不同的使用者處理在工作流程序列中使用的 Web 表單或一系列資料）的事務集中考慮的不同可能性越多，就越可能看到巨大的潛在複雜性。
還有其它問題。 XML 語言的強項之一是，搜尋是明確的，無二義性的：DTD 或 Schema 提供了相關語法的資訊。如果將包含標記在內的文件的一部分作為整體加密，就會喪失搜尋與那些標記相關的資料的能力。此外，如果標記本身被加密，那麼一旦洩漏，它們將被利用對採用的密碼術進行純文字攻擊。
這些是工作小組正在考慮的一些面向。
XML 加密範例
XML 加密語法的核心元素是 EncryptedData 元素，該元素與 EncryptedKey 元素一起用來將加密金鑰從發起方傳送到已知的接收方，EncryptedData 是從 EncryptedType 抽象型別衍生出來的。要加密的資料可以是任意資料、XML 文件、XML 元素或 XML 元素內容；加密資料的結果是包含或引用密碼資料的 XML 加密元素。當加密元素或元素內容時，EncryptedData 元素會取代 XML 文件加密版本中的該元素或內容。當加密的是任意資料時，EncryptedData 元素可能成為新 XML 文件的根，或可能成為一個子代元素。當加密整個 XML 文件時，EncryptedData 元素可能成為新文件的根。此外，EncryptedData 不能是另一個 EncryptedData 元素的父代或子代元素，但是實際加密的資料可以是包含現有 EncryptedData 或 EncryptedKey 元素的任何內容。
加密工作草稿給了一些範例來展示：加密的顆粒度如何根據要求的不同而不同，以及可能出現什麼結果。清單 1 中的程式碼片段顯示了帶有信用卡和其它個人資訊的未加密 XML 文件。在某些情況下（例如，隱藏支付機制的資訊），可能希望加密除客戶名稱以外的所有訊息，清單 2 的程式碼片段示範如何這樣做。
清單 1. 顯示 John Smith 的銀行帳戶、5000 美元限額、卡號和有效期限的資訊
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
##
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData>
</EncryptedData>
</PaymentInfo>
##清單 2. 除名稱之外全部被加密的加密文件
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<CipherData><Ciphervalue>A23B45C56</Ciphervalue>
</CipherData>
</EncryptedData>
</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>#但是，在其它情況下，可能只需要隱藏一些敏感內容 — 可能來自商家或其它第三方 —清單 3 示範了這一點。 （請注意，顯示了與加密內容相關的標記名。）
#清單 3. 只隱藏了信用卡號的加密文件
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'>
<CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData>
</EncryptedData>
可能還有必要加密文件中的所有信息，清單 4 示範了這一點。
清單 4. 隱藏了完整內容的加密文件
[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>###### CipherData 可以封裝，也可以引用原始加密數據。在第一種情況下，Cipher###value### 元素的內容顯示原始數據，而在第二種情況，使用 CipherReference 元素，這包括了一個指向加密數據位置的 URI。 ###规范的 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内讲述.
以上是XML加密與XML簽章簡介的具體介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！