啟用 XML 安全性(2)

xml|安全|安全性

 

<Expiration>04/02</Expiration>
        </CreditCard>
      </PaymentInfo>

可能還有必要加密文檔中的所有資訊，清單 4 示範了這點。

清單 4. 隱藏了全部內容的加密文檔
<?xml version='1.0'?>
      <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>




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"