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

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

簡(jiǎn)介
 XML 已經(jīng)成為一種用于在因特網(wǎng)上交換數(shù)據(jù)的有價(jià)值機(jī)制。SOAP，這種發(fā)送 XML 消息的方式，促使進(jìn)程以一種前所未有的方式相互通信，而 UDDI 看起來(lái)正在快速成為整合 Web 服務(wù)的供應(yīng)商和用戶的標(biāo)準(zhǔn)；服務(wù)本身是 XML 以 WSDL （即“Web 服務(wù)描述語(yǔ)言”）形式描述的。如果沒(méi)有 XML，將不可能有這種靈活性和能力，并且，正如許多人所說(shuō)的，將有必要發(fā)明元語(yǔ)言。

 安全性領(lǐng)域是另一個(gè)快速增長(zhǎng)的領(lǐng)域。在不同團(tuán)體之間建立信任的傳統(tǒng)方法在公共因特網(wǎng)上已不合適，實(shí)際上，在大型 LAN 和 WAN 上也不合適。在這些情況下，基于非對(duì)稱密碼術(shù)的信任機(jī)制可能會(huì)非常有用，但實(shí)際上，部署和密鑰管理的方便性、互操作性的范圍和提供的安全性遠(yuǎn)不如各種的“公鑰基礎(chǔ)設(shè)施”（Public Key Infrastructures (PKI)）的熱情的供應(yīng)商曾讓我們相信的那樣。處理層次數(shù)據(jù)結(jié)構(gòu)，以及帶有機(jī)密、訪問(wèn)權(quán)限或完整性等不同需求的數(shù)據(jù)的子集特別困難。另外，具有不同于 XML 文檔的現(xiàn)今標(biāo)準(zhǔn)安全性控制的應(yīng)用程序一點(diǎn)都不簡(jiǎn)單。

目前，一些團(tuán)體正積極投身于檢查這些問(wèn)題和開(kāi)發(fā)標(biāo)準(zhǔn)的活動(dòng)中。其中主要的相關(guān)開(kāi)發(fā)是 XML 加密和相關(guān)的 XML 簽名、“可擴(kuò)展訪問(wèn)控制語(yǔ)言（XACL）”和相關(guān)的“安全性斷言標(biāo)記語(yǔ)言（SAML — 以前是互為競(jìng)爭(zhēng)對(duì)手的 AuthML 和 S2ML 的結(jié)合）”。所有這些都由 OASIS 和“XML 密鑰管理規(guī)范（XKMS）”驅(qū)動(dòng)。本文將 介紹 XML 加密和 XML 簽名。

“XML 安全性套件”
部分原因是由于這些標(biāo)準(zhǔn)仍處于發(fā)展階段，因此，開(kāi)發(fā)人員可用的工具集和庫(kù)的數(shù)量仍然有限，但十分確信的一點(diǎn)是，這正在開(kāi)始發(fā)生變化。IBM 已經(jīng)向“Java 社區(qū)過(guò)程（JCP）”提交了兩種相關(guān)的“Java 規(guī)范請(qǐng)求（JSR）”。它們是 JSR-105、“XML 數(shù)字簽名 API”和 JSR-106、“數(shù)字加密 API”。
“IBM 東京研究實(shí)驗(yàn)室”在 1999 年開(kāi)發(fā)了“XML 安全性套件”作為 XML 簽名的原型實(shí)現(xiàn)。它包含一些自動(dòng)生成 XML 數(shù)字簽名、實(shí)現(xiàn) W3C 的“規(guī)范”XML 工作草案，以及通過(guò) XML 加密的實(shí)驗(yàn)性實(shí)現(xiàn)來(lái)提供元素級(jí)加密的實(shí)用程序。它還提供一種在應(yīng)用到 XML 文檔時(shí)處理安全性特定要求的方式。還引入了“可擴(kuò)展訪問(wèn)控制語(yǔ)言（XACL）”的 XML 模式定義。

developerWorks 有一篇 Doug Tidwell 著的文章詳細(xì)講述了該套件，可在 alphaWorks 站點(diǎn)獲得該套件的最新版本。（請(qǐng)參閱參考資料。）
XML 加密和 XML 簽名
  象其它任何文檔一樣，可以將 XML 文檔整篇加密，然后安全地發(fā)送給一個(gè)或多個(gè)接收方。例如，這是 SSL 或 TLS 的常見(jiàn)功能，但是更令人感興趣的是如何對(duì)同一文檔的不同部分進(jìn)行不同處理的情況。XML 的一個(gè)有價(jià)值的好處是可以將一整篇 XML作為一個(gè)操作發(fā)送，然后在本地保存，從而減少了網(wǎng)絡(luò)通信量。但是，這就帶來(lái)了一個(gè)問(wèn)題：如何控制對(duì)不同元素組的授權(quán)查看。商家可能需要知道客戶的名稱和地址，但是，無(wú)需知道任何正在使用的信用卡的各種詳細(xì)信息，就像銀行不需要知道購(gòu)買貨物的詳細(xì)信息一樣?？赡苄枰乐寡芯咳藛T看到有關(guān)個(gè)人醫(yī)療記錄的詳細(xì)信息，而管理人員可能正好需要那些詳細(xì)信息，但是應(yīng)該防止他們查看醫(yī)療歷史；而醫(yī)生或護(hù)士可能需要醫(yī)療詳細(xì)信息和一些（但不是全部）個(gè)人資料。

密碼術(shù)現(xiàn)在所做的遠(yuǎn)遠(yuǎn)不止隱藏信息。消息摘要確定文本完整性，數(shù)字簽名支持發(fā)送方認(rèn)證，相關(guān)的機(jī)制用于確保任何一方日后無(wú)法拒絕有效事務(wù)。這些都是遠(yuǎn)程交易必不可少的元素，現(xiàn)在，用于處理整個(gè)文檔的機(jī)制開(kāi)發(fā)得相當(dāng)好。

有了一般的加密，對(duì) XML 文檔整體進(jìn)行數(shù)字化簽名不是問(wèn)題。然而，當(dāng)需要對(duì)文檔的不同部分（可能由不同的人）簽名，以及需要與選擇性的方法一起來(lái)這樣做時(shí)，就會(huì)出現(xiàn)困難。也許不可能或者不值得強(qiáng)制不同部分的加密工作由特定人員按特定順序進(jìn)行，然而成功地處理文檔的不同部分將取決于是否知道這點(diǎn)。此外，由于數(shù)字簽名斷言已經(jīng)使用了特定專用密鑰來(lái)認(rèn)證，所以要小心簽名人是以純文本形式查看文檔項(xiàng)的，這可能意味著對(duì)由于其它原因而加密的部分內(nèi)容進(jìn)行了解密。在另一種情況下，作為更大集合中的一部分，可能對(duì)已經(jīng)加密過(guò)的數(shù)據(jù)進(jìn)行進(jìn)一步加密。在牽涉單一 XML 文檔（可能由一些不同的應(yīng)用程序和不同的用戶處理在工作流序列中使用的 Web 表單或一系列數(shù)據(jù)）的事務(wù)集中考慮的不同可能性越多，就越可能看到巨大的潛在復(fù)雜性。

還有其它問(wèn)題。XML 語(yǔ)言的強(qiáng)項(xiàng)之一是，搜索是明確的，無(wú)二義性的：DTD 或 Schema 提供了相關(guān)語(yǔ)法的信息。如果將包括標(biāo)記在內(nèi)的文檔的一部分作為整體加密，就會(huì)喪失搜索與那些標(biāo)記相關(guān)的數(shù)據(jù)的能力。此外，如果標(biāo)記本身被加密，那么一旦泄漏，它們將被利用對(duì)采用的密碼術(shù)進(jìn)行純文本攻擊。

這些是工作組正在考慮的一些方面。

XML 加密示例
 XML 加密語(yǔ)法的核心元素是 EncryptedData 元素，該元素與 EncryptedKey 元素一起用來(lái)將加密密鑰從發(fā)起方傳送到已知的接收方，EncryptedData 是從 EncryptedType 抽象類型派生的。要加密的數(shù)據(jù)可以是任意數(shù)據(jù)、XML 文檔、XML 元素或 XML 元素內(nèi)容；加密數(shù)據(jù)的結(jié)果是一個(gè)包含或引用密碼數(shù)據(jù)的 XML 加密元素。當(dāng)加密元素或元素內(nèi)容時(shí)，EncryptedData 元素替換 XML 文檔加密版本中的該元素或內(nèi)容。當(dāng)加密的是任意數(shù)據(jù)時(shí)，EncryptedData 元素可能成為新 XML 文檔的根，或者可能成為一個(gè)子代元素。當(dāng)加密整個(gè) XML 文檔時(shí)，EncryptedData 元素可能成為新文檔的根。此外，EncryptedData 不能是另一個(gè) EncryptedData 元素的父代或子代元素，但是實(shí)際加密的數(shù)據(jù)可以是包括現(xiàn)有 EncryptedData 或 EncryptedKey 元素的任何內(nèi)容。

加密工作草案給出了一些示例來(lái)演示：加密的顆粒度如何根據(jù)要求的不同而不同，以及可能出現(xiàn)什么結(jié)果。清單 1 中的代碼片斷顯示了帶有信用卡和其它個(gè)人信息的未加密 XML 文檔。在某些情況下（例如，隱藏支付機(jī)制的信息），可能希望加密除客戶名稱以外的所有信息，清單 2 的代碼片斷演示了如何這樣做。

清單 1. 顯示 John Smith 的銀行帳戶、5000 美元限額、卡號(hào)和有效期的的信息

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

但是，在其它情況下，可能只需要隱藏一些敏感內(nèi)容 — 可能來(lái)自商家或其它第三方 — 清單 3 演示了這點(diǎn)。（請(qǐng)注意，顯示了與加密內(nèi)容相關(guān)的標(biāo)記名。）

清單 3. 只隱藏了信用卡號(hào)的加密文檔

  <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 演示了這點(diǎn)。

清單 4. 隱藏了全部?jī)?nèi)容的加密文檔

 <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 可以封裝，也可以引用原始加密數(shù)據(jù)。在第一種情況下，Ciphervalue 元素的內(nèi)容顯示原始數(shù)據(jù)，而在第二種情況，使用 CipherReference 元素，這包括了一個(gè)指向加密數(shù)據(jù)位置的 URI。

規(guī)范的 XML
   對(duì)應(yīng)用了密碼散列算法的消息進(jìn)行最輕微的更改也會(huì)產(chǎn)生不同的值。這為消息完整性方面提供了信任，并適于通常用法，但是也引入了進(jìn)一步的復(fù)雜性 — 兩個(gè) XML 文檔雖然在邏輯上相等，但可能在確切文本比較中不同。象行定界符、空標(biāo)記、在屬性中使用十六進(jìn)制而不是名稱以及在特定情況下存在注釋或注釋變體這樣的事情都可以成為文檔的邏輯結(jié)構(gòu)不受影響而實(shí)際彼此不同的實(shí)例。規(guī)范的 XML 規(guī)范描述了一種生成文檔的物理表示（也成為范式）的方法，該范式解釋允許的變體，以便如果兩個(gè)文檔具有同一范式，則認(rèn)為兩個(gè)文檔在給定應(yīng)用程序上下文中是邏輯相等的。

對(duì)于加密、特別是數(shù)字簽名來(lái)說(shuō)，這尤為重要，因?yàn)楹苊黠@，邏輯上相同的文本變體不應(yīng)該表示文檔的完整性及其發(fā)送方的認(rèn)證是可疑的。用不同工具（譬如，解析器）生成不同文本（并因而生成不同消息摘要）進(jìn)行處理時(shí)也可能發(fā)生這樣的事。因此，在生成簽名和驗(yàn)證計(jì)算期間，應(yīng)該在范式上進(jìn)行消息摘要。如果摘要匹配，這將確定：即使文本形式可能不同，它們?cè)谄渖嫌?jì)算的范式也匹配。

XML 簽名示例
可以將 XML 簽名應(yīng)用到任意數(shù)據(jù)內(nèi)容。那些應(yīng)用到相同 XML 文檔中數(shù)據(jù)的簽名稱為封裝或被封裝的簽名，而那些數(shù)據(jù)在簽名元素外部的簽名稱為 分離簽名。清單 5 取自簽名候選推薦文檔，它是一個(gè)簡(jiǎn)單分離簽名的實(shí)例。

清單 5. 一個(gè)簡(jiǎn)單分離簽名的示例

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

實(shí)際簽名的信息是位于 s02 行和 s12 行之間，即 SignedInfo 元素。在簽名的部分中包含用于計(jì)算 Signaturevalue 元素的算法的引用，而那個(gè)元素本身位于簽名部分之外（在 s13 行上）。s04 行上的 SignatureMethod 引用的是將規(guī)范的 SignedInfo 轉(zhuǎn)換成 Signaturevalue 所用的算法。它是密鑰相關(guān)的算法和摘要算法（在這里是 DSA 和 SHA-1）的組合，可能還具有象填充這樣的操作。KeyInfo 元素（在這里位于 s14 行和 s16 行之間 — 該元素是可選的）指出用來(lái)驗(yàn)證簽名的密鑰。

轉(zhuǎn)換
    正如前面所提到的，加密、簽名、修改和可能進(jìn)行的更多簽名所發(fā)生的順序有很多種可能性。用戶可能需要向已經(jīng)部分加密或部分簽名的表單字段中輸入更多數(shù)據(jù)，并且需要能夠在不妨礙以后的驗(yàn)證和解密的前提下這樣做。為解決這種情況，W3C 最近發(fā)布了一個(gè)有關(guān) XML 簽名的解密轉(zhuǎn)換工作草案。（請(qǐng)參閱參考資料。）

下面這個(gè)示例摘自那個(gè)文檔，它演示了如何建議文檔接收方采用正確的解密和簽名驗(yàn)證順序。第一個(gè)代碼段顯示了要簽名的文檔部分 — order 元素；其中，第 7 行到第 11 行的 cardinfo 元素是關(guān)于個(gè)人和財(cái)務(wù)方面的詳細(xì)信息，它是純文本，但也存在一些加密數(shù)據(jù)（第 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. 經(jīng)過(guò)簽名和進(jìn)一步加密、且現(xiàn)在顯示轉(zhuǎn)換信息的 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 元素現(xiàn)在包含前面的 order 元素（位于第 16 行到第 24 行），和以前的加密純文本 cardinfo（顯示在第 22 行這一行中）。有兩個(gè)轉(zhuǎn)換引用：解密（第 6 行到第 8 行）和規(guī)范化（第 9 行）。解密轉(zhuǎn)換指示簽名驗(yàn)證器解密除 DataRef 元素中第 7 行指定的數(shù)據(jù)之外的所有加密數(shù)據(jù)。解密了第 22 行中的 EncryptedData 元素之后，規(guī)范化 order 元素并且恰當(dāng)?shù)仳?yàn)證簽名。

其它相關(guān)語(yǔ)言和規(guī)范
   隱藏 XML 文檔中的敏感信息、建立完整性以及認(rèn)證這些文檔的不同部分的來(lái)源主要通過(guò)遵循加密和簽名規(guī)范中列出的步驟來(lái)處理的，在引用的 W3C 草案中描述該規(guī)范（請(qǐng)參閱參考資料）。另外，還有其它緊密相關(guān)的領(lǐng)域，例如認(rèn)證用戶或系統(tǒng)、標(biāo)識(shí)授權(quán)級(jí)別和管理密鑰，所有這些都與 XML 安全性相關(guān)。

SAML 是一個(gè)由 OASIS 驅(qū)動(dòng)的模型，它嘗試融合相互競(jìng)爭(zhēng)的 AuthML 和 S2ML 規(guī)范，使認(rèn)證和授權(quán)信息的互換便于進(jìn)行。“可擴(kuò)展訪問(wèn)控制標(biāo)記語(yǔ)言”是與 SAML 緊密相關(guān)的，但它更著重于特定 XML 文檔的上下文中的面向主題特權(quán)對(duì)象的安全性模型，它也由 OASIS 指導(dǎo)，又是被稱為 XACML 或 XACL（即使在同一些文檔中）。通過(guò)用 XACL 編寫規(guī)則，策略制訂者可以定義，對(duì)于特定 XML 文檔和前面所述的情況中的相關(guān)事情，由誰(shuí)來(lái)實(shí)施哪些訪問(wèn)特權(quán)。

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