Shulou(Shulou.com)06/03 Report--

This article mainly shows you the "XML encryption and XML signature example analysis", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "XML encryption and XML signature example analysis" this article.

Brief introduction

XML has become a valuable mechanism for exchanging data on the Internet. SOAP, this way of sending XML messages, drives processes to communicate with each other in an unprecedented way, and UDDI seems to be rapidly becoming the standard for integrating Web services providers and users; the service itself is described by XML in the form of WSDL ("Web Services description language"). Without XML, it would be impossible to have this flexibility and capability, and, as many people have said, it would be necessary to invent metalanguage.

The area of security is another fast-growing area. The traditional method of building trust between different groups is no longer appropriate on the public Internet, nor, in fact, on large LAN and WAN. In these cases, trust mechanisms based on asymmetric cryptography can be very useful, but in fact, the convenience of deployment and key management, the scope of interoperability, and the security provided are far less than the enthusiastic vendors of various "Public Key Infrastructures (PKI)" have made us believe. It is particularly difficult to deal with hierarchical data structures and subsets of data with different requirements such as confidentiality, access, or integrity. In addition, applications with today's standard security controls that are different from XML documents are by no means simple.

At present, some groups are actively involved in examining these issues and developing standards. The main related developments are XML encryption and related XML signatures, Extensible access Control language (XACL), and related Security assertion markup language (SAML-a combination of AuthML and S2ML that used to be competitors). All of this is driven by OASIS and the XML key Management Specification (XKMS). This article introduces XML encryption and XML signing.

XML Security Suite

Part of the reason is that because these standards are still in the development stage, the number of toolsets and libraries available to developers is still limited, but it is certain that 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".

The IBM Tokyo Research Lab developed the XML Security Suite as a prototype implementation of XML signatures in 1999. It includes utilities that automatically generate XML digital signatures, implement the W3C "specification" XML working draft, and provide 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. The XML schema definition of Extensible access Control language (XACL) is also introduced.

DeveloperWorks has an article by Doug Tidwell detailing the suite, and the latest version of the suite is available on the alphaWorks site. (see Resources. )

XML encryption and XML signature

Like any other document, you can encrypt the entire XML document and then securely send it to one or more recipients. For example, this is a common feature of SSL or TLS, but what is more interesting is how different parts of the same document are treated differently. One of the valuable benefits of XML is that an entire XML can be sent as an operation and saved locally, thereby reducing network traffic. However, this raises the question of how to control authorization viewing for different groups of elements. The merchant may need to know the name and address of the customer, but you do not need to know the details of the credit card you are using, just as the bank does not need to know the details of the goods purchased. It may be necessary to prevent researchers from seeing detailed information about personal medical records, and managers may just need those details, but they should be prevented from viewing medical history; doctors or nurses may need medical details and some, but not all, personal data.

Cryptography is now doing much more than hiding information. Message digest determines text integrity, digital signature supports sender authentication, and related mechanisms are used to ensure that neither party can refuse a valid transaction in the future. These are essential elements of remote transactions, and the mechanism for processing the entire document is now quite well developed.

With general encryption, it is not a problem to digitally sign XML documents as a whole. However, difficulties arise when you need to sign different parts of the document (which may be by different people) and when you need to do so in conjunction with an optional method. It may not be possible or worthwhile to force different parts of encryption to be done by specific people in a particular order, but success in dealing with different parts of a document will depend on whether you know it or not. In addition, because the digital signature assertion has used a specific private key for authentication, be careful that the signer looks at the document item in plain text, which may mean decrypting some of the content that has been encrypted for other reasons. In another case, it is possible to further encrypt already encrypted data as part of a larger collection. The more different possibilities you consider in a transaction set involving a single XML document, which may be handled by some different applications and different users with Web forms or a series of data used in the workflow sequence, the more likely you are to see great potential complexity.

There are other questions. One of the strengths of the XML language is that searches are explicit and unambiguous: DTD or Schema provide information about the syntax. If you encrypt part of a document, including tags, as a whole, you lose the ability to search for data related to those tags. In addition, if the tags themselves are encrypted, they will be used for plain text attacks on the cryptography used if they are compromised.

These are some of the aspects that are being considered by the working Group.

XML encryption example

The core element of the XML encryption syntax is the EncryptedData element, which, together with the EncryptedKey element, is used to pass the encryption key from the initiator to the known receiver, and the EncryptedData is derived from the EncryptedType abstract type. The data to be encrypted can be any data, XML document, XML element, or XML element content; the result of encrypted data is an XML encrypted element that contains or references password data. When an element or its content is encrypted, the EncryptedData element replaces the element or content in the encrypted version of the XML document. When arbitrary data is encrypted, 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. In addition, EncryptedData cannot be a parent or child 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 according to the requirements, and what results may occur. The code snippet in listing 1 shows an unencrypted XML document with credit cards and other personal information. In some cases (for example, hiding the information about the payment mechanism), you may want to encrypt all the information except the customer name, and the code snippet in listing 2 shows how to do so.

Listing 1. Displays information about John Smith's bank account, $5000 limit, card number and expiration date

John Smith A23B45C56

In other cases, however, you may only need to hide some sensitive content-perhaps from a merchant or other third party-as demonstrated in listing 3. (notice that the tag name associated with the encrypted content is displayed. )

Listing 3. Only encrypted documents with credit card numbers hidden

A23B45C56

CipherData can encapsulate or reference raw encrypted data. In the first case, the contents of the Ciphervalue element display the original data, while in the second case, the CipherReference element is used, which includes a URI pointing to the location of the encrypted data.

Standard XML

The slightest changes to messages with the password hashing algorithm applied can also result in different values. This provides trust in message integrity and is suitable for general usage, but it also introduces further complexity-two XML documents, although logically equal, may differ in exact text comparisons. Things like line delimiters, empty tags, the use of hexadecimal instead of names in attributes, and the existence of comments or annotation variants in certain cases can be instances where the logical structure of the document is not affected but actually different from each other. The canonical XML specification describes a way to generate a physical representation of a document (also known as a normal form) that interprets allowed variants so that if two documents have the same paradigm, two documents are considered logically equal in a given application context.

This is particularly important for encryption, especially digital signatures, because it is clear that logically identical text variants should not indicate that the integrity of the document and the authentication of the sender is questionable. This can also happen when different tools (for example, parsers) generate different text (and therefore different message digests) for processing. Therefore, message digest should be performed on the paradigm during signature generation and verification calculations. If the summary matches, this determines that the normal form on which the text is calculated matches, even though the text may have different forms.

Example of XML signature

You can apply XML signatures to any data content. Signatures that are applied to data in the same XML document are called encapsulated or encapsulated signatures, while signatures that are outside the signature element are called separate signatures. Listing 5 is taken from the signature candidate recommendation document, which is an example of a simple separate signature.

Listing 5. An example of a simple separation signature

[S01] [S02] [S03] [S04] [S05] [S06] [S07] [S08] [S09] [S10] j6lwx3rvEPO0vKtMup4NbeVu8nk = [S11] [s12] [s13] MC0CFFrVLtRlk= [s14] [s15a] [s15b] [s15c]

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

The information of the actual signature is between lines S02 and S12, that is, the SignedInfo element. The signature section contains a reference to the algorithm used to calculate the Signaturevalue element, which itself is outside the signature section (on line s13). The SignatureMethod on line S04 refers to the algorithm used to convert the canonical SignedInfo to Signaturevalue. It is a combination of key-related algorithms and digest algorithms (in this case DSA and SHA-1) and may also have operations such as padding. The KeyInfo element (in this case, between lines S14 and S16-this element is optional) indicates the key used to verify the signature.

Conversion

As mentioned earlier, there are many possibilities for the order in which encryption, signatures, modifications, and possible more signatures occur. Users may need to enter more data into form fields that are partially encrypted or partially signed and need to be able to do so without prejudice to future verification and decryption. To solve this situation, the W3C recently released a working draft of decryption and conversion of XML signatures. (see Resources. )

The following example, excerpted from that document, demonstrates how to recommend that the recipient of the document adopt the correct order of decryption and signature verification. The first code snippet shows the part of the document to be signed-the order element; where the cardinfo element on lines 7 through 11 is personal and financial details, which is plain text, but there is also some encrypted data (line 12).

Listing 6. Order element in an 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 documents that have been signed and further encrypted and now display 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 on lines 1 through 26 now contains the previous order element (on lines 16 through 24) and the previous encrypted plain text cardinfo (shown on line 22). There are two transformation references: decryption (lines 6 through 8) and normalization (line 9). The decryption transformation instructs the signature verifier to decrypt all encrypted data except the data specified in line 7 of the DataRef element. After decrypting the EncryptedData element in line 22, normalize the order element and verify the signature appropriately.

Other related languages and specifications

The sources of hiding sensitive information in XML documents, establishing integrity, and authenticating different parts of these documents are handled primarily by following the steps listed in the encryption and signature specification, which is described in the referenced W3C draft (see Resources). In addition, there are other closely related areas, such as authenticating users or systems, identifying authorization levels, and managing keys, all of which are related to XML security.

SAML is an OASIS-driven model that attempts to integrate competing AuthML and S2ML specifications to facilitate the exchange of authentication and authorization information. "Extensible access Control markup language" is closely related to SAML, but it focuses more on the topic privileged object-oriented security model in the context of specific XML documents, which is also guided by OASIS and is also known as XACML or XACL (even in the same documents). By writing rules in XACL, policy makers can define who enforces which access privileges for specific XML documents and related matters in the case described earlier.

The above is all the contents of the article "sample Analysis of XML encryption and XML signature". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.