Enable XML Security (1)

xml| Safety | safety

XML is the main supporter of the Internet and the recent continued growth and development of WEB services. However, there is a lot of security-related work to do before implementing the full capabilities of the XML language. Currently, it is a simple process to encrypt an entire XML document, test its integrity, and verify the reliability of its sender. However, it is increasingly necessary to use these features in some parts of the document to encrypt and authenticate in any order and to involve different users or initiators. At present, XML encryption, XML signature, Xacl, SAML, and XKMS are the most important parts of developing specifications in the field of XML-related security. This article describes the first two.
Brief introduction
XML has become a valuable mechanism for exchanging data on the Internet. SOAP, the way in which XML messages are sent, encourages processes to communicate with each other in an unprecedented way, and UDDI appears to be rapidly becoming a standard for the vendors and users of consolidated WEB services, which are described in the form of XML in WSDL, the Web service description language. Without XML, this flexibility and ability will not be possible, and, as many people say, it will be necessary to invent the meta language.

The area of security is another fast-growing area. The traditional methods of building trust between different groups are not appropriate on the public Internet, and are not, in fact, appropriate for large LANs and WANs. In these cases, trust mechanisms based on asymmetric cryptography can be useful, but in fact, deployment and key management ease, interoperability, and security are far less secure than the various "public key infrastructures" (PKI) The enthusiasm of the supplier had made us believe that. It is particularly difficult to deal with hierarchical data structures, and subsets with different requirements, such as confidentiality, access rights, or integrity. In addition, applications with today's standard security controls that are different from XML documents are not simple at all.

At present, some groups are actively engaged in examining these problems and developing standard activities. The main related developments are XML encryption and related XML signatures, extensible access Control Language (XACL) and associated Security Assertion markup languages (saml-formerly a combination of rival AUTHML and S2ML). All of this is driven by OASIS and the XML Key Management specification (XKMS). This article describes XML encryption and XML signatures.

XML encryption and XML signatures
As with any other document, you can encrypt the entire XML document and send it securely to one or more recipients. For example, this is a common feature of SSL or TLS, but it is more interesting to see how different parts of the same document are handled differently. A valuable benefit of XML is that you can send an entire XML as an operation and then save it locally, thereby reducing network traffic. However, this poses a problem: how to control authorization views for different groups of elements. The merchant may need to know the name and address of the customer, but there is no need to know the details of any credit card being used, just as the bank does not have to know the details of the purchase of the goods. It may be necessary to prevent researchers from seeing detailed information about personal medical records, and managers may just need the 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.

Cryptography now does much more than hide information. The message digest determines the integrity of the text, the digital signature supports sender authentication, and the relevant mechanism is used to ensure that no valid transaction can be rejected by either party at a later date. These are essential elements of a remote transaction, and now the mechanism for handling the entire document has been developed fairly well.

With general encryption, it is not a problem to digitally sign an XML document as a whole. However, when you need to sign different parts of a document, possibly by different people, and when you want to do this with a selective approach, you will have difficulty. It may not be possible or desirable to force different parts of the encryption work to be done in a specific order by a specific person, however, the successful processing of different parts of the document will depend on knowing this. In addition, because the digital signature assertion has been authenticated with a specific private key, it is important to be careful that the signer is viewing the document item in plain text, which may mean that part of the content that is encrypted for other reasons is decrypted. In another case, as part of a larger collection, it is possible to further encrypt data that has already been encrypted. The more different possibilities that involve a single XML document (which may be handled by different applications and different users in a Web form or a series of data used in a workflow sequence) are more likely to see significant potential complexity.

There are other problems. One of the strengths of the XML language is that the search is unambiguous and ambiguous: a DTD or Schema provides information about the syntax. If you encrypt a part of a document, including markup, 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 exploited for plaintext attacks using the cryptographic technique once they are compromised.

These are some of the areas that the Working Group is considering.

XML Encryption Example
The core element of the XML encryption syntax is the EncryptedData element, which, together with the EncryptedKey element, is used to transfer 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 content; The result of the encrypted data is an XML cryptographic element that contains or references the password 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 any data is encrypted, the EncryptedData element may become the root of the new XML document, or it may become a descendant element. When you encrypt an entire XML document, the EncryptedData element may become the root of the new document. In addition, EncryptedData cannot be a parent or descendant element of another EncryptedData element, but the actual encrypted data can be anything that includes an existing EncryptedData or EncryptedKey element.

The cryptographic work draft provides examples to demonstrate how the granularity of the encryption varies according to the requirements and what results may occur. The snippet in Listing 1 shows an unencrypted XML document with credit cards and other personal information. In some cases (for example, information that hides the payment mechanism), you may want to encrypt all information except the customer name, and the code snippet in Listing 2 shows how to do so.

Listing 1. Information that shows John Smith's bank account, 5000 dollar limit, card number, and expiration date
<?xml version= ' 1.0 '?>
<paymentinfo xmlns= ' HTTP://EXAMPLE.ORG/PAYMENTV2 ' >
<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>




Listing 2. Encrypted documents that are all encrypted except for the name
<?xml version= ' 1.0 '?>
<paymentinfo xmlns= ' HTTP://EXAMPLE.ORG/PAYMENTV2 ' >
<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>




In other cases, however, you may want to hide only sensitive content-perhaps from a merchant or other third party-listing 3 illustrates this. (Note that the tag name associated with the encrypted content is displayed.) ）

Listing 3. Encrypted document that only hides the credit card number
<?xml version= ' 1.0 '?>
<paymentinfo xmlns= ' HTTP://EXAMPLE.ORG/PAYMENTV2 ' >
<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>