[转载]Exploring XML Encryption (第一部分)(页 1) - 脚本程序设计{ All Kinds of Scripts } - 邪恶八进制信息安全团队技术讨论组努力为祖国的信息安全撑起一片蓝天

EvilOctal 2006-6-12 18:55

[转载]Exploring XML Encryption (第一部分)

文章作者：<a href="#author">Bilal Siddiqui</a> (<a href="mailto:wap_monster@yahoo.com?subject=Exploring XML Encryption, Part 1">wap_monster@yahoo.com</a>), CEO, WAP Monster 01 Mar 2002<blockquote>XML Encryption provides end-to-end security for applications that require secure exchange of structured data. XML itself is the most popular technology for structuring data, and therefore XML-based encryption is the natural way to handle complex requirements for security in data interchange applications. Here in part 1 of this two-part series, Bilal explains how XML and security are proposed to be integrated into the W3C's Working Draft for XML Encryption.</blockquote><script language="java script" type="text/java script"></script>Currently, Transport Layer Security (TLS) is the de facto standard for secure communication over the Internet. TLS is an end-to-end security protocol that follows the famous Secure Socket Layer (SSL). SSL was originally designed by Netscape, and its version 3.0 was later adapted by the Internet Engineering Task Force (IETF) while they were designing TLS. This is a very secure and reliable protocol that provides end-to-end security sessions between two parties. XML Encryption is not intended to replace or supersede SSL/TLS. Rather, it provides a mechanism for security requirements that are not covered by SSL. The following are a two important areas not addressed by SSL:<ul><li>Encrypting part of the data being exchanged </li><li>Secure sessions between more than two parties </li></ul>With XML Encryption, each party can maintain secure or insecure states with any of the communicating parties. Both secure and non-secure data can be exchanged in the same document. For example, think of a secure chat application containing a number of chat rooms with several people in each room. XML-encrypted files can be exchanged between chatting partners so that data intended for one room will not be visible to other rooms.XML Encryption can handle both XML and non-XML (e.g. binary) data. We'll now demonstrate a simple exchange of data, making it secure through XML Encryption. We'll then slowly increase the complexity of the security requirements and explain the XML Encryption schema and the use of its different elements.<a name="simple">A simple example of secure exchange of XML data </a>Suppose you want to send the XML file in <a href="#code1">Listing 1</a> to a publishing company. This file contains details of a book that you want to purchase. In addition, it also contains your credit card information for payment. Naturally, you would like to use secure communication for this sensitive data. One option is to use SSL, which secures the whole communication. The alternative is to use XML Encryption. As already mentioned, XML Encryption is not an alternative to SSL/TLS. If the application requires that the whole communication be secure, you'll use SSL. On the other hand, XML Encryption is the best choice if the application requires a combination of secure and insecure communication (which means that some of the data will be securely exchanged and the rest will be exchanged as is). <a name="code1">Listing 1. The sample XML file to be encrypted</a> <table cellspacing="0" cellpadding="5" width="100%" bgcolor="#eeeeee" border="1"><tbody><tr><td><code><pre class="section"><purchaseorder />
<order />
<item />book</item />
<id />123-958-74598</id />
<quantity />12</quantity />
</order />
<payment />
<cardid />123654-8988889-9996874</cardid />
<cardname />visa</cardname />
<validdate />12-10-2004</validdate />
</payment />
</purchaseorder />
</pre></code></td></tr></tbody></table> <blockquote>Note: We have intentionally kept the XML file in <a href="#code1">Listing 1</a> very simple. This helps in keeping our focus on encryption-related issues. Real-world XML files in collaborative commerce or Web services will be similar in structure but more verbose. WSDL (Web Services Definition Language) and SOAP (Simple Object Access Protocol) are XML-based grammars that are frequently used in B2B integration. Both WSDL and SOAP can use XML Encryption to provide secure communication across the enterprise. Visit the W3C for details about them (see <a href="#resources">Resources</a>).</blockquote><a name="N10074">Encrypting complete documents with XML Encryption</a>XML Encryption offers various options. <a href="listing2.html">Listing 2</a>, <a href="listing3.html">Listing 3</a>, and <a href="listing4.html">Listing 4</a> show the different encrypted results. Let's look at them in detail, one by one.<a href="listing2.html">Listing 2</a> shows the resulting XML-encrypted file, in case you decide to encrypt the entire XML document in <a href="#code1">Listing 1</a>. Notice the <code><cipherdata /></code>and <code><ciphervalue /></code>tags. The actual encrypted data appears as contents of the <code><ciphervalue /></code>tag. The complete <code>CipherData</code> element appears within an <code>EncryptedData</code> element. The <code>EncryptedData</code> element contains the XML namespace used for encryption. For example, your original data before encryption was XML and the official type definition by the Internet Assigned Numbers Authority (IANA) for XML is [url]http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml.[/url] This appears as the value of the <code>Type</code> attribute. XML Encryption uses the type definitions by IANA for various popular data formats such as RTF, PDF, and JPG. Refer to their Web site for complete details (see <a href="#resources">Resources</a>). If you have special application data types (perhaps your own DTDs or XSDs that belong to your company's content management system), you can specify them in the <code>Type</code> attribute of <code>EncryptedData</code> element. The other attribute, xmlns, specifies the XML Encryption namespace that we used to encrypt the XML data.<a name="N100B9">Encrypting a single element with XML Encryption</a>You may want to encrypt only one element in <a href="#code1">Listing 1</a> -- for example, the <code>Payment</code> element. In this case, the result is illustrated in <a href="listing3.html">Listing 3</a>. Compare <a href="listing2.html">Listing 2</a> and <a href="listing3.html">Listing 3</a> and you'll find the following differences:<ol><li><a href="listing2.html">Listing 2</a> contains only XML Encryption's schema, while <a href="listing3.html">Listing 3</a> contains both XML Encryption as well as elements from the original data in <a href="#code1">Listing 1</a>. In <a href="listing3.html">Listing 3</a>, the XML Encryption is embedded inside the user's XML. </li><li><a href="listing3.html">Listing 3</a> also has a <code>Type</code> attribute in <code><encrypteddata /></code>, but its value is [url]http://www.w3.org/2001/04/xmlenc#Element.[/url] We are no longer using the IANA type; instead, we are using the type that XML Encryption has specified. </li><li>Note particularly the fragment #Element at the end that means EncryptedData -- this represents one element. </li></ol><a name="N100FB">Encrypting the content of an element</a><a href="listing4.html">Listing 4</a> will be the result if you want to encrypt only the content in <code>CardId</code>, an element in <a href="#code1">Listing 1</a>. This time, we have used [url]http://www.w3.org/2001/04/xmlenc#Content[/url] as the <code>Type</code> attribute value. We use this value whenever we have to encrypt only the content.<a name="N10112">Encrypting non-XML data </a>What if you want to send, say, a JPEG file through XML Encryption? <a href="listing5.html">Listing 5</a> is a typical file that will result. The complete JPEG file in an encrypted sequence of bytes will appear as the content of the <code>CipherValue</code> element. Notice that there is only one difference between <a href="listing2.html">Listing 2</a> and <a href="listing5.html">Listing 5</a>: the <code>Type</code> attribute of the <code>EncryptedData</code> element. <a href="listing5.html">Listing 5</a> includes the IANA type for the JPEG format. Similarly, you can encrypt any format by providing IANA values (refer to the IANA Web site, see <a href="#resources">Resources</a>). <table cellspacing="0" cellpadding="0" width="100%" border="0"><tbody><tr><td><img height="1" src="http://www.ibm.com/i/v14/rules/blue_rule.gif" width="539" /></td></tr></tbody></table><table class="no-print" cellspacing="0" cellpadding="0" align="right"><tbody><tr align="right"><td><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="middle"><img height="16" src="http://www.ibm.com/i/v14/icons/u_bold.gif" width="16" border="0" /> </td><td valign="top" align="right"><a class="fbox" href="#main">Back to top</a></td></tr></tbody></table></td></tr></tbody></table> <a name="keys">Keys for XML Encryption</a>In Listings 1 through 5, we have demonstrated encryption, which is not possible without keys (see the sidebar <a href="#sidebar">Public, private, and secret keys</a>). With XML Encryption, all key-related issues are divided into two parts:<ul><li>Exchange of keys (asymmetric encryption) </li><li>Using keys that were previously exchanged (symmetric encryption) </li></ul>This way, users can exchange keys and use them later.<a name="N1014E">Asymmetric keys for exchange of secret keys</a>In this scenario, one party sends its public key to a second party. The second party uses this public key to encrypt its secret key. This exchange of data is shown in <a href="listing6.html">Listing 6</a> (request) and <a href="listing7.html">Listing 7</a> (response). We will imagine Imran and Ali as the first party and second party, respectively, communicating with each other. Imran initializes the public key exchange request and sends his public key in the element named KeyValue . The attribute <code>CarriedKeyName</code> represents the name of the key that is being transported. Note that the root element of this structure is <code>EncryptedKey</code>, which contains the <code>ds:KeyInfo</code> and <code>ds:KeyValue</code> elements. The <code>ds: KeyInfo</code> and <code>ds:KeyValue</code> elements belong to the XML Digital Signature (ds:) namespace. XML Encryption relies entirely on the XML Digital Signature specification for key exchange. Therefore, both <code><encryptedkey></encryptedkey></code>and <code><keyvalue></keyvalue></code>belong to the XML Digital Signature specification namespace. <a href="listing7.html">Listing 7</a> is what Ali sends in response. The <code>CipherValue</code> element in <a href="listing7.html">Listing 7</a> contains a newly generated secret key, which is encrypted with the public key of the first party. Looking closely at Listing 6 and Listing 7, you'll notice that both request and response contain an <code>EncryptedKey</code> element. The <code>ds:KeyInfo</code> and <code>ds:KeyValue</code> elements within the <code>EncryptedKey</code> element carry the public key (<a href="listing6.html">Listing 6</a>). On the other hand, the <code>CipherData</code> and <code>CipherValue</code> elements inside the <code>EncryptedKey</code> element (<a href="listing7.html">Listing 7</a>) will transport the secret (encrypted) keys. Also notice that the <code>EncryptedKey</code> element always contains a <code>CarriedKeyName</code> attribute to specify the name of the key it is carrying.<a name="N101B5">Using keys we have already exchanged in the past</a>In the previous section, we exchanged a secret key. We'll now use that key to encrypt data. We will assume that Imran sends an XML message (<a href="listing8.html">Listing 8</a>) in response to <a href="listing7.html">Listing 7</a> (recall that <a href="listing7.html">Listing 7</a> contains an encrypted secret key whose name is "Imran Ali"). Imran will decrypt this secret key with his (Imran's own) private key (as Ali encrypted this secret key with Imran's public key). Imran can encrypt the data he wants to send to Ali using this secret key and placing it inside the <code>CipherValue</code> element in <a href="listing8.html">Listing 8</a>.The <code>ds:KeyInfo</code> element in <a href="listing8.html">Listing 8</a> contains a <code>KeyName</code> element. This combination refers to the name of the key that Imran uses for data encryption.Figure 1 is a visual diagram showing this exchange of XML files for secure data exchange. <a name="figure1">Figure 1. Sequence of key and data exchange with XML Encryption</a> [attach]4479[/attach] <a name="N101EB">Referring external encrypted data from our XML Encryption file</a>In <a href="listing5.html">Listings 5</a> and <a href="listing7.html">7</a>, the <code>CipherData</code> element can appear within an <code>EncryptedData</code> element or an <code>EncryptedKey</code> element. We use a <code>CipherData</code> element to refer to either the encrypted data (when it appears inside an <code>EncryptedData</code> element) or the encrypted key (when it appears inside an <code>EncryptedKey</code> element). In both Listings <a href="listing5.html">5</a> and <a href="listing7.html">7</a>, there is a <code>CipherValue</code> child element inside the <code>CipherData</code> element that contains the actual encrypted data.We can also refer to external encrypted data or encrypted keys. This means that actual encrypted data or keys will be present somewhere else (perhaps somewhere on the Internet) and not inside our XML Encryption file. In this case we will use <code>CipherReference</code> instead of the <code>CipherValue</code> child element inside <code>CipherData</code>. We'll refer to the actual encrypted data through a URI. This is shown in <a href="listing9.html">Listing 9</a>.<a name="N10234">Referencing a particular element of an external XML file</a><a href="listing10.html">Listing 10</a> illustrates a variation of referring external XML files. Here we have referenced only a portion of the external file that the URI is pointing to. There is a <code>Transforms</code> child element inside the <code>CipherReference</code> element. This <code>Transforms</code> element may contain a number of <code>Transform</code> elements, each of which will contain a single XPath element. This XPath element specifies an XPath expression that refers to a particular node of the external XML document. <table cellspacing="0" cellpadding="0" width="100%" border="0"><tbody><tr><td><img height="1" src="http://www.ibm.com/i/v14/rules/blue_rule.gif" width="539" /></td></tr></tbody></table><table class="no-print" cellspacing="0" cellpadding="0" align="right"><tbody><tr align="right"><td><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="middle"><img height="16" src="http://www.ibm.com/i/v14/icons/u_bold.gif" width="16" border="0" /> </td><td valign="top" align="right"><a class="fbox" href="#main">Back to top</a></td></tr></tbody></table></td></tr></tbody></table> <a name="DOM">The DOM structure of our API</a>We have already demonstrated how to author XML Encryption files and exchange encrypted data. We will now propose a Java API for XML Encryption and provide a sample implementation. We will use DOM for this purpose.Our DOM implementation consists of a set of classes (Listings 11 to 16). The <code>XmlEncryption </code>class (<a href="listing11.html">Listing 11</a>) is a wrapper for the rest of the classes, which means users of our API will only need to interact with this class. It uses the functionality of other classes internally.<a href="listing11.html">Listing 11</a> is a wrapper class that can generate a complete XML encrypted file.<a href="listing12.html">Listing 12</a> authors the <code>EncryptedData</code> element.<a href="listing13.html">Listing 13</a> authors the <code>EncryptionMethod</code> element.<a href="listing14.html">Listing 14</a> authors the <code>KeyInfo</code> element.<a href="listing15.html">Listing 15</a> authors the <code>CipherData </code>element.<a href="listing16.html">Listing 16</a> contains names of Algorithms as static integers and their corresponding namespaces as strings.The <code>XmlEncryption</code> class (<a href="listing11.html">Listing 11</a>) contains various public Get/Set methods. The user will call Set methods to specify encryption parameters, which include the following:<ol><li>Name of the file to be encrypted </li><li>Name of the resulting XML Encryption file </li><li>Name of the algorithm for encryption </li><li>Name of the key that we will use for encryption </li><li>An ID for identification of <code><encrypteddata /></code>structure </li></ol>We have demonstrated the use of the <code>XmlEncryption</code> class (<a href="listing11.html">Listing 11</a>) through a <code>main ()</code> method. In the <code>main ()</code> method, we have created an instance of this class. The constructor instantiates DOM so that all underlying classes will use the same object.<table cellspacing="0" cellpadding="0" width="40%" align="right" border="0"><tbody><tr><td width="10"><img height="1" src="http://www.ibm.com/i/c.gif" width="10" /></td><td><table cellspacing="0" cellpadding="5" width="100%" border="1"><tbody><tr><td bgcolor="#eeeeee"><a name="sidebar">Public, private, and secret keys</a> We have used three technical terms related to keys (public, private, and secret keys). Although these terms are well known to developers working with end-to-end security, XML developers might not be familiar with them. Let's clarify these terms:Public and private keys: We use them as a pair. Some algorithms generate a pair of public and private keys. We send the public key to anyone who wants to exchange encrypted data with us. With a public key, we can only encrypt data of limited size. Our communicating partner encrypts the data with our public key and sends the encrypted data to us. We then decrypt the data with our private key. This is asymmetric encryption.Secret key: We use public and private keys to exchange a secret key. We normally generate secret keys randomly. Once we have exchanged a secret key with our communicating partner through asymmetric encryption, we then use this key for encrypting data at both ends. This is symmetric encryption.</td></tr></tbody></table></td></tr></tbody></table>This implementation only supports encryption of complete files, as illustrated in <a href="listing2.html">Listing 2</a>. The <code>EncryptCompleteXmlFile ()</code> method will do this job by calling the following methods in a sequence:<ol><li><code>GetEncryptedDataDoc()</code> returns the object of the <code>EncryptedData</code> class (<a href="listing12.html">Listing 12</a>). It contains the structure of the <code>EncryptedData</code> element. </li><li><code>GetEncryptionMethodDoc()</code> returns the Document object, which contains the XML structure corresponding to the <code>EncryptionMethod</code> element. <code>GetEncryptionMethodDoc()</code> uses <code>EncryptionMethod</code> class (<a href="listing13.html">Listing 13</a>) to author XML. </li><li><code>GetKeyInfoDoc()</code> returns the <code>Document</code> object, which contains the XML structure corresponding to KeyInfo element. <code>GetKeyInfoDoc()</code> uses the object of <code>GenericKeyInfo</code> class (<a href="listing14.html">Listing 14</a>) to author the XML. This class only provides the minimum necessary functionality (support for <code>KeyName</code> and <code>KeyValue</code> elements) you will inherit from <code>GenericKeyInfo</code> class to provide the complete functionality, which includes support for X509 Certificates, PGP Data, etc. </li><li><code>ReadFile()</code> fetches the data (complete XML file) that we want to encrypt. </li><li><code>GetEncryptedData()</code> for the time being is not doing anything. We'll implement this method in the next part of this article. It is supposed to create the encrypted form of XML data that we fetched in step 4. We have briefly discussed our encryption strategy in the last section (Java Cryptographic Architecture). </li><li><code>GetCipherDataDoc()</code> takes the encrypted data as an argument and returns the Document Object containing the <code>CipherData</code> element. <code>GetCipherDataDoc()</code> uses the Object of <code>CipherData</code> class (<a href="listing12.html">Listing 12</a>) to author XML. </li><li>At the end, <code>addChild()</code> method of Object of <code>EncryptedData</code> (<a href="listing15.html">Listing 15</a>) is called thrice, which will take the Document Objects of steps 2, 3, and 6 and adds them to the <code><encrypteddata /></code>structure, which is the parent of all of them. </li><li><code>SaveEncryptedFile()</code> saves the completed XML Encryption file. </li></ol><code>AlgoNames</code> (<a href="listing16.html">Listing 16</a>) is a helper class that only specifies namespace declarations required by XML Encryption.The <code>XmlEncryption</code> class (<a href="listing11.html">Listing 11</a>) can also be used as a server-side component. In the next part of this series, we'll demonstrate its use inside independent as well as server-side applications.The set of classes that we have developed only performs DOM-based XML authoring. We need to implement cryptographic functionality as well. We will now try to form a strategy for cryptographic support. For this purpose, we need to study the Java Cryptographic Architecture (JCA). <table cellspacing="0" cellpadding="0" width="100%" border="0"><tbody><tr><td><img height="1" src="http://www.ibm.com/i/v14/rules/blue_rule.gif" width="539" /></td></tr></tbody></table><table class="no-print" cellspacing="0" cellpadding="0" align="right"><tbody><tr align="right"><td><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="middle"><img height="16" src="http://www.ibm.com/i/v14/icons/u_bold.gif" width="16" border="0" /> </td><td valign="top" align="right"><a class="fbox" href="#main">Back to top</a></td></tr></tbody></table></td></tr></tbody></table> <a name="JCA">The Java Cryptographic Architecture (JCA)</a>Java offers complete support for cryptography. For this purpose, there are several packages inside J2SE, covering all the main features of security architecture such as access controls, signatures, certificates, key pairs, key stores, and message digests.The primary principle of JCA design is to separate cryptographic concepts from algorithmic implementations, so that different vendors can offer their tools within the JCA framework.<a name="N10393">JCA Engine classes</a>JCA defines a series of Engine classes, where each Engine provides a cryptographic function. For example, there are several different standards of MD (Message Digest) algorithm. All these standards differ in the implementation, but at the Engine API level they are all the same. Different vendors are free to provide implementations of specific algorithms.<a name="N1039A">Java Cryptographic Extension (JCE)</a>All independent (third party) vendor implementations of cryptographic algorithms are called Java Cryptographic Extensions (JCEs). Sun Microsystems has also provided an implementation of JCE. Whenever we use JCE, we need to configure it with JCA. For this, we need to do the following:1. Add the address of the jar file to configure the provider (all JCE implementations are called providers) in the <code>CLASSPATH</code> environment variables.2. Configure the provider in the list of your approved providers by editing the java.security file. This file is located in JavaHome/jre/lib/security folder. The following is the syntax to specify the priority: <code>security.provider.<n />=<masterclassname /></code>. Here, n is the priority number (1, 2, 3, etc.). <code>MasterClassName</code> is the name of master class to which the engine classes will call for a specific algorithm implementation. The provider's documentation will specify its master class name. For example, consider the following entries in a java.security file:<ul><li><code>security.provider.1=sun.security.provider.Sun</code> </li><li><code>security.provider.2=com.sun.rsajca.Provider</code> </li><li><code>security.provider.3=com.sun.net.ssl.internal.ssl.Provider</code> </li></ul>These entries mean that the engine class will search for any algorithm implementation in the above mentioned order. It will execute the implementation found first. After these simple steps, we are all set to use JCA/JCE in our XML Encryption application.<a name="N103CA">Using JCA and JCE in our implementation of XML Encryption</a>The <code>GetEncryptedData()</code> function in our wrapper class, <code>XmlEncryption</code> (<a href="listing11.html">Listing 11</a>), is the place to handle all JCA/JCE-related issues. Currently this method only returns the string "This is Cipher Data". We have not yet written JCA/JCE-related classes. This method takes the unencrypted data and returns it as an encrypted string. We will handle all the algorithm- and key-related issues in this method after writing the wrapper classes for JCA/JCE.Next time: In our next installment of this series of articles, we will discuss and implement the details of cryptography. We'll demonstrate the working of encryption and decryption classes and their interaction with parsing logic, and present applications of XML Encryption in Web services. <table cellspacing="0" cellpadding="0" width="100%" border="0"><tbody><tr><td><img height="1" src="http://www.ibm.com/i/v14/rules/blue_rule.gif" width="539" /></td></tr></tbody></table><table class="no-print" cellspacing="0" cellpadding="0" align="right"><tbody><tr align="right"><td><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="middle"><img height="16" src="http://www.ibm.com/i/v14/icons/u_bold.gif" width="16" border="0" /> </td><td valign="top" align="right"><a class="fbox" href="#main">Back to top</a></td></tr></tbody></table></td></tr></tbody></table> <a name="resources">Resources</a><ul><li>Read "<a href="http://www.ibm.com/developerworks/library/x-encrypt2/">Exploring XML Encryption, Part 2</a>" of this two-part series of articles on XML Encryption by Bilal Siddiqui (developerworks, August 2002). </li><li>Visit W3C to see official details of <a href="http://www.w3.org/TR/xml-encryption-req">XML Encryption Requirements</a> and <a href="http://www.w3.org/TR/xmlenc-core/">XML Encryption Processing and Syntax</a>. </li><li>Check out news about XML Encryption at <a href="http://www.oasis-open.org/cover/xmlAndEncryption.html">OASIS/Robin Cover's XML Cover Pages</a>. </li><li><a href="http://www.alphaworks.ibm.com/tech/xmlsecuritysuite">IBM's toolkits for XML Encryption</a> is available for download at alphaWorks. </li><li>Check what's happening at <a href="http://jcp.org/jsr/detail/106.jsp">SUN's community process for XML Encryption</a>. </li><li>We mentioned XPath in this article. Here is a <a href="http://www.oreilly.com/catalog/xmlnut/chapter/ch09.html">chapter on XPath</a> from an XML book XML in a Nutshell by O'Reilly. </li><li>We mentioned IANA in this article. Visit <a href="http://www.isi.edu/in-notes/iana/assignments/media-types/media-types">IANA's Web site</a> to check type definitions for popular data formats. </li><li><a href="http://www-3.ibm.com/security/services/index.shtml">IBM Security Services</a> can help you determine what your risks are, and then design a security program to address them. </li><li>IBM <a href="http://www-4.ibm.com/software/ad/studioappdev/">WebSphere Studio Application Developer</a> is an easy-to-use, integrated development environment for building, testing, and deploying J2EE (TM) applications, including generating XML documents from DTDs and schemas. </li></ul> <table cellspacing="0" cellpadding="0" width="100%" border="0"><tbody><tr><td><img height="1" src="http://www.ibm.com/i/v14/rules/blue_rule.gif" width="539" /></td></tr></tbody></table><table class="no-print" cellspacing="0" cellpadding="0" align="right"><tbody><tr align="right"><td><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="middle"><img height="16" src="http://www.ibm.com/i/v14/icons/u_bold.gif" width="16" border="0" /> </td><td valign="top" align="right"><a class="fbox" href="#main">Back to top</a></td></tr></tbody></table></td></tr></tbody></table> <a name="author">About the author</a><table cellspacing="0" cellpadding="0" width="100%" border="0"><tbody><tr><td colspan="3"><img height="5" src="http://www.ibm.com/i/c.gif" width="539" /></td></tr><tr valign="top" align="left"><td></td><td><img height="5" src="http://www.ibm.com/i/c.gif" width="4" /></td><td width="100%">XML consultant Bilal Siddiqui received a degree in Electronics Engineering from the University of Engineering and Technology, Lahore, in 1995. He then began designing software solutions for industrial control systems. Later he turned to XML and used his experience programming in C++ to build Web- and WAP-based XML processing tools, server-side parsing solutions, and service applications. You can e-mail Bilal for working copies of the code files contained in this article at <a href="mailto:wap_monster@yahoo.com?cc=">wap_monster@yahoo.com</a>.</td></tr></tbody></table>

页: [1]

邪恶八进制信息安全团队技术讨论组's Archiver

[转载]Exploring XML Encryption (第一部分)