XML加密和XML簽名的示例分析

這篇文章主要為大家展示了“XML加密和XML簽名的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“XML加密和XML簽名的示例分析”這篇文章吧。

簡介
 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&#39;> 
         <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>

清單 2. 除名稱之外全部被加密的加密文檔

<PaymentInfo xmlns='http://example.org/paymentv2&#39;> 
         <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>

但是，在其它情況下，可能只需要隱藏一些敏感內容 — 可能來自商家或其它第三方 — 清單 3 演示了這點。（請注意，顯示了與加密內容相關的標記名。）

清單 3. 只隱藏了信用卡號的加密文檔

  <PaymentInfo xmlns='http://example.org/paymentv2&#39;> 
         <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>

可能還有必要加密文檔中的所有信息，清單 4 演示了這點。

清單 4. 隱藏了全部內容的加密文檔

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

CipherData 可以封裝，也可以引用原始加密數據。在第一種情況下，Ciphervalue 元素的內容顯示原始數據，而在第二種情況，使用 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 文檔和前面所述的情況中的相關事情，由誰來實施哪些訪問特權。

以上是“XML加密和XML簽名的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！