Detailed introduction to XML encryption and XML signature introduction

Introduction

XML has become a valuable mechanism for exchanging data on the Internet. SOAP, this method of sending XML messages enables processes to communicate with each other in an unprecedented way, and UDDI looks to be quickly becoming the standard for providers and users of integrated Web services; the services themselves are XML based Described in the form of WSDL (i.e. "Web Services Description Language"). Without XML, this flexibility and power would not be possible, and, as many have said, it would be necessary to invent a metalanguage.

Safety The sexual field is another rapidly growing area. Traditional methods of establishing trust between different groups are no longer appropriate on the public Internet, and indeed, on large LANs and WANs. In these cases, trust mechanisms based on asymmetric cryptography can be very useful, but in practice, the ease of deployment and key management, the scope of interoperability, and the security provided are far inferior to the various "public key foundations". Public Key Infrastructures (PKI) had us led to believe by its enthusiastic vendors. It is particularly difficult to deal with hierarchical data structures, and subsets of data with different requirements such as confidentiality, access rights, or integrity. Additionally, applications with different security controls than today's standard for XML documents are anything but simple.

Currently, several groups are actively engaged in examining these issues and developing standards. The main related developments are XML encryption and related XML signatures, "Extensible Access Control Language (XACL)" and the related "Security Assertion Markup Language (SAML - a combination of the former competitors AuthML and S2ML)" . All of this is driven by OASIS and the XML Key Management Specification (XKMS). This article will introduce XML encryption and XML signature.

"XML Security Suite"
Part of this is because these standards are still in the development stage, so the number of toolsets and libraries available to developers is still limited, but very confident. The point is, this is starting to change. IBM has submitted two related "Java Specification Requests (JSR)" to the "Java Community Process (JCP)". They are JSR-105, "XML Digital Signature API" and JSR-106, "Digital Encryption API".
"IBM Tokyo Research Laboratory" developed the "XML Security Suite" in 1999 as a prototype implementation of XML signatures. It contains utilities for automatically generating XML digital signatures, implementing the W3C's "canonical" XML working draft, and providing element-level encryption through an experimental implementation of XML encryption. It also provides a way to handle security-specific requirements when applied to XML documents. An XML schema definition for the Extensible Access Control Language (XACL) is also introduced.

developerWorks There is an article by Doug Tidwell describing the suite in detail, and the latest version of the suite is available at the alphaWorks site. (See Resources.)

XML Encryption and XML Signing
Like any other document, an XML document can be encrypted in its entirety and then sent securely to one or more receiver. This is a common feature of SSL or TLS, for example, but what is more interesting is how different parts of the same document are treated differently. A valuable benefit of XML is that an entire XML can be sent as one operation and then saved locally, thus reducing network traffic. However, this raises a question: how to control authorized viewing of different groups of elements. The merchant may need to know the customer's name and address, but does not need to know the details of any credit card being used, just as a bank does not need to know the details of the purchase of goods. Researchers may need to be prevented from seeing details about an individual's medical records, while administrators may need exactly those details, but they should be prevented from viewing medical history; whereas a doctor or nurse may need medical details and some (but not all) personal material.

Cryptography now does much more than hide information. Message Summary determines textual integrity, digital signatures support sender authentication, and related mechanisms are used to ensure that no party can later reject a valid transaction. These are all essential elements of remote transactions, and the mechanisms for handling entire documents are now quite well developed.

With general encryption, digitally signing the entire XML document is not a problem. However, difficulties arise when different parts of a document need to be signed (perhaps by different people), and when doing so needs to be done in conjunction with a selective approach. It may not be possible or worthwhile to force encryption of different parts to be done by specific people in a specific order, however successfully handling different parts of a document will depend on knowing this. Additionally, because digital signatures assert that they have been authenticated using a specific private key, be careful that the signer is viewing the document item in plain text, which may mean decrypting portions of the content that were encrypted for other reasons. In another case, already encrypted data may be further encrypted as part of a larger collection. The more different possibilities you consider in a transaction set involving a single XML document (a web form or a series of data used in a workflow sequence that may be processed by a few different applications and different users), the more likely you are to see huge potential complexity.

There are other questions. One of the strengths of the XML language is that searches are unambiguous: a DTD or Schema provides information about the syntax. If a portion of a document, including tags, is encrypted as a whole, you lose the ability to search for data related to those tags. Furthermore, if the tokens themselves are encrypted, then if leaked they can be exploited to perform plain text attacks on the employed cryptography.

These are some of the areas the working group is considering.

XML Encryption Example
The core element of XML encryption syntax is the EncryptedData element, which is used together with the EncryptedKey element to transmit the encryption key from the initiator to the known recipient. , EncryptedData is derived from the EncryptedType abstract type. The data to be encrypted can be arbitrary data, XML documents, XML elements, or XML element content; the result of encrypted data is an XML encryption element that contains or references cryptographic data. When an element or element content is encrypted, the EncryptedData element replaces the element or content in the encrypted version of the XML document. When encrypting arbitrary data, the EncryptedData element may become the root of a new XML document, or it may become a descendant element. When encrypting an entire XML document, the EncryptedData element may become the root of the new document. Additionally, EncryptedData cannot be a parent or child element of another EncryptedData element, but the actual encrypted data can be anything that includes an existing EncryptedData or EncryptedKey element.

The encryption working draft gives some examples to demonstrate how the granularity of encryption varies depending on the requirements and what the results might be. The code snippet in Listing 1 shows an unencrypted XML document with credit card and other personal information. In some cases (for example, hiding payment mechanism information), you may want to encrypt all information except the customer name, and the code snippet in Listing 2 demonstrates how to do this.

##List 1. Display information about John Smith’s bank account, $5,000 limit, card number and expiration date

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

List 2. Encrypted documents where everything is encrypted except the name

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

However, in other cases, there may only be some sensitive content that needs to be hidden — perhaps from a merchant or other third party — Listing 3 demonstrates this. (Note that the tagname associated with the encrypted content is shown.)

Listing 3. Encrypted document with only credit card number hidden

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

#It may also be necessary to encrypt all information in the document, as Listing 4 demonstrates.

List 4. Encrypted document that hides all contents

 <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 can be encapsulated or reference the original encryption data. In the first case, the content of the Cipher

value element displays the raw data, while in the second case, a CipherReference element is used, which includes a URI pointing to the location of the encrypted data.

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

The above is the detailed content of Detailed introduction to XML encryption and XML signature introduction. For more information, please follow other related articles on the PHP Chinese website!