Introduction to XML Encryption and XML Signature

XML has become a valuable mechanism for exchanging data on the Internet. SOAP: This method of sending XML messages prompts the process to communicate with each other in an unprecedented manner, while UDDI seems to be quickly becoming a standard for integrating Web service providers and users; the service itself is described in XML in the form of WSDL (Web service description language. Without XML, it would be impossible to have this flexibility and capability, and, as many have said, it would be necessary to invent a metalanguage. Introduction

XML has become a valuable mechanism for exchanging data on the Internet. SOAP: This method of sending XML messages prompts the process to communicate with each other in an unprecedented manner, while UDDI seems to be quickly becoming a standard for integrating Web service providers and users; the service itself is described in XML in the form of WSDL (Web service description language. Without XML, it would be impossible to have this flexibility and capability, and, as many have said, it would be necessary to invent a metalanguage.

Security is another rapidly growing field. Traditional methods of building trust between different groups are no longer appropriate on the public Internet, but not on large LAN and WAN. In these cases, the trust mechanism based on asymmetric cryptography may be very useful, but in fact, the ease of deployment and Key management, the scope of interoperability, and the security provided are far inferior to the various Public Key infrastructure (PKI )) enthusiastic suppliers once let us believe that. It is particularly difficult to process hierarchies and subsets of data with different requirements, such as confidentiality, access permissions, or integrity. In addition, applications with standard security control different from XML documents are not simple at all.

At present, some groups are actively engaged in activities to check these issues and development standards. The main development is XML Encryption and related XML signatures, and "eXtensible Access Control Language (XACL) "and related" security asserted Markup Language (SAML-used to be a combination of AuthML and S2ML for competitors )". All of these are driven by OASIS and the XML Key Management Specification (XKMS. This document describes XML Encryption and XML signature.

"XML Security Suite"
This is partly because these standards are still in the development phase, so the number of toolsets and libraries available to developers is still limited, but it is quite certain that this is starting to change. IBM has submitted two related "Java Standard request (JSR)" to "Java Community Process (JCP )". They are JSR-105, XML digital signature API, and JSR-106, digital encryption API ".
In 1999, the IBM Tokyo Research Laboratory developed the XML Security Suite as a prototype implementation of XML signatures. It includes some practical programs that automatically generate XML digital signatures, implement W3C "standard" XML work drafts, and provide element-level encryption through the experimental implementation of XML encryption. It also provides a way to handle specific security requirements when applying to XML documents. The XML Schema Definition of "eXtensible Access Control Language (XACL)" is also introduced.

DeveloperWorks has an article by Doug Tidwell describing the suite in detail. you can get the latest version of the suite at the alphaWorks site. (See references .)

XML Encryption and XML Signature
Like any other document, you can encrypt the entire XML document and send it to one or more recipients securely. For example, this is a common feature of SSL or TLS, but it is more interesting to know how to process different parts of the same document. A valuable advantage of XML is that it can send an entire XML file as an operation and save it locally, thus reducing network traffic. However, this raises the question: how to control the authorization view for different element groups. Sellers may need to know the customer's name and address, but do not need to know the details of any credit card in use, just as banks do not need to know the details of the purchased goods. It may be necessary to prevent researchers from seeing detailed information about individual medical records, while managers may need such details, but they should be prevented from viewing medical history; while doctors or nurses may need medical details and some (but not all) personal data.

What password technology does now is far more than hiding information. The message digest determines the text integrity. the digital signature supports sender authentication. the relevant mechanism is used to ensure that any party cannot reject valid transactions in the future. These are essential elements of remote transactions. Currently, the mechanism for processing the entire document is well developed.

With General encryption, it is not a problem to digitally sign the XML document as a whole. However, it is difficult to sign different parts of the document (possibly by different persons) and to do so with selective methods. It may not be possible or worthwhile to force encryption of different parts to be performed by specific personnel in a specific order, but the successful processing of different parts of the document will depend on whether you know this. In addition, since the digital signature assertions have used a specific private key for authentication, be careful that the signatory can view document items in plain text, this may mean that part of the content encrypted for other reasons has been decrypted. In another case, as part of a larger set, encrypted data may be further encrypted. There are more possibilities to consider in a transaction involving a single XML document (Web forms or a series of data that may be used by different applications and different users to process in the workflow sequence, the more likely you will see the huge potential complexity.

There are other problems. One of the strengths of the XML language is that search is clear and unambiguous: DTD or Schema provides information about related syntax. If you encrypt a part of the document, including the tag, the data associated with the tag will be lost. In addition, if the flag itself is encrypted, once leaked, they will be attacked in plain text using cryptographic techniques.

These are some aspects that the working group is considering.

XML encryption example
The core element of the XML Encryption syntax is the EncryptedData element, which is used together with the EncryptedKey element to transmit the encryption key from the initiator to a known receiver. EncryptedData is derived from the EncryptedType abstract type. The data to be encrypted can be any data, XML document, XML element, or XML element. the encrypted data is an XML Encryption element that contains or references password data. When the encryption element or element content is used, the EncryptedData element replaces the element or content in the XML document's encrypted version. When any data is encrypted, the EncryptedData element may become the root of the new XML document or a child element. When the entire XML file is encrypted, the EncryptedData element may become the root of the new file. In addition, EncryptedData cannot be the parent or child element of another EncryptedData element, but the actually encrypted data can contain any content of the existing EncryptedData or EncryptedKey element.

The draft encryption work provides examples to demonstrate how the granularity of encryption varies according to requirements and what results may occur. The code snippets in listing 1 show unencrypted XML documents with credit cards and other personal information. In some cases (for example, hiding the payment mechanism information), you may want to encrypt all information except the customer name. the code snippet in listing 2 demonstrates how to do this.

Listing 1. display information about John Smith's bank account, $5000 limit, card number, and validity period

  
           
  
   John Smith
             
               
    
     4019 2445 0277 5567
                
    
     Bank of the Internet
                
    
     04/02
              
           
  
 

List 2. all encrypted documents except their names

           
  
   John Smith
             
                 
    
     
      A23B45C56
     
              
           
  
 

However, in other cases, you may only need to hide some sensitive content-probably from a merchant or another third-party-listing 3 demonstrates this. (Note that the tag name related to the encrypted content is displayed .)

Listing 3. only encrypted documents with credit card numbers are hidden

  
           
  
   John Smith
             
               
                  
                       
      
       
        A23B45C56
        
                    
                 
                
    
     Bank of the Internet
                
    
     04/02
              
           
  
 

It may be necessary to encrypt all the information in the document, as shown in listing 4.

Listing 4. encryption document with all contents hidden

 
                  
  
   
    A23B45C56
   
          
 

CipherData can be encapsulated or referenced by the original encrypted data. In the first case, CipherValueThe content of the element displays the original data. in the second case, the CipherReference element is used, which includes a URI pointing to the location of the encrypted data.

Standard XML
Slight changes to messages that use the password hashing algorithm also generate different values. This provides Trust for message integrity and is suitable for common usage, but introduces further complexity-although the two XML documents are logically equal, they may be different in exact text comparisons. Things such as line delimiters, empty tags, using hexadecimal notation in attributes instead of names, and the existence of annotations or annotation variants in specific circumstances can all be the logical structure of the document without being affected and actually different instances. The canonicalized XML specification describes a method for generating the physical representation of a document (also known as a paradigm). This paradigm explains the allowed variants so that if two documents have the same paradigm, the two documents are logically equivalent in the context of the given application.

This is especially important for encryption, especially for digital signatures, because it is obvious that logically the same text variant should not indicate the integrity of the document and the sender's authentication is suspicious. This can also happen when different tools (such as the parser) are used to generate different texts (and thus generate different message digests) for processing. Therefore, message summarization should be performed in the paradigm during signature generation and verification calculation. If the abstract matches, this determines that even if the text form may be different, their calculated paradigms also match.

XML signature example
You can apply an XML Signature to any data. The signatures applied to data in the same XML document are called encapsulated or encapsulated signatures, while those outside the signature element are called separated signatures. Listing 5 is taken from the signature Candidate Recommendation document, which is an example of simple signature separation.

Listing 5. An example of simple signature separation

 [s01] 
 
              [s02]   
  
               [s03]   
               [s04]   
               [s05]   
   
                [s06]     
    
                 [s07]       
                 [s08]     
                [s09]     
                [s10]     
    
     j6lwx3rvEPO0vKtMup4NbeVu8nk=
                [s11]   
               [s12] 
              [s13]   
  
   MC0CFFrVLtRlk=
              [s14]   
  
               [s15a]    
   
               [s15b]      
    
                 [s15c]        
     

     
     
                 [s15d]      
                [s15e]    
               [s16]   
              [s17] 
 

The actual signature information is located between line s02 and line s12, that is, the SignedInfo element. The Signature contains the Signature used to calculate Signature.ValueElement algorithm reference, and the element itself is located outside the signature section (on line s13 ). The SignatureMethod on line s04 references converting the standard SignedInfo into Signature.ValueThe algorithm used. It is a combination of key-related algorithms and digest algorithms (DSA and SHA-1), and may also have operations such as filling. The KeyInfo element (which is located between lines s14 and s16-this element is optional) indicates the key used to verify the signature.

Conversion
As mentioned above, there are many possibilities for encryption, signature, modification, and the order in which more signatures may occur. You may need to input more data to a form field that has been partially encrypted or partially signed, and do so without interfering with future verification and decryption. To solve this problem, W3C recently released a draft work on decryption and conversion of XML signatures. (See references .)

The following example is taken from the document and demonstrates how to recommend that the document receiver adopt correct decryption and signature verification sequence. The first code segment shows the order element of the document to be signed. among them, the cardinfo element of rows 7th to 11th is about personal and financial details. it is plain text, however, there are also some encrypted data (12th rows ).

Listing 6. order element in XML document

[01] 
 
             [02]   
  
              [03]     
   XML and Java           [04]     
   
    100.0
              [05]     
   
    1
              [06]   
             [07]   
  
              [08]     
   
    Your Name
              [09]     
   
    04/2002
              [10]     
   
    5283 8304 6232 0010
              [11]   
             [12]   
             [13] 
 

Listing 7. order document with signature and further encryption and now displaying conversion information

[01] 
 
             [02]   
  
              [03]                [04]     
   
               [05]       
    
                [06]         
     
                 [07]           
                 [08]         
                [09]         
                [10]       
               [11]                  [12]     
              [13]   
             [14]   
             [15]   
             [16]     
   
               [17]       
    
                [18]         
     XML and Java           [19]         
     
      100.0
                [20]         
     
      1
                [21]       
               [22]       
               [23]       
               [24]     
              [25]              [26] 
 

The Signature element of rows 1st to 26th now contains the previous order element (in rows 16th to 24th) and the previously encrypted plain text cardinfo (displayed in rows 22nd ). There are two conversion references: decryption (6th rows to 8th rows) and normalization (9th rows ). Decryption conversion indicates that the signature validator decrypts all the encrypted data except the data specified by row 7th in the DataRef element. After the EncryptedData element in row 3 is decrypted, the order element is normalized and the signature is properly verified.

Other related languages and specifications
Hiding sensitive information in XML documents, establishing integrity, and authenticating the sources of different parts of these documents is mainly handled by following the steps listed in encryption and signature specifications, this specification is described in the referenced W3C draft (see references ). In addition, there are other closely related fields, such as user or system authentication, identity authorization level, and management key, all of which are related to XML security.

SAML is a model driven by OASIS. it tries to integrate competing AuthML and S2ML specifications to facilitate interchange of authentication and authorization information. The eXtensible Access Control Markup language is closely related to SAML, but it focuses more on the security model of topic-oriented privileged objects in the context of a specific XML document. it is also guided by OASIS, it is also called XACML or XACL (even in the same document ). By using XACL to write rules, policy makers can define who will implement access privileges for specific XML documents and related events described above.
For details about SAML, I will describe it in the next Blog.

The above are detailed descriptions of XML Encryption and XML Signature. For more information, see other related articles in the first PHP community!