Element Wise Encryption of XML using XSLT                                      J. Ahmed Muzammil*, A. Manikandan+         ...
If we regard encryption/decryption as just another XML            was first proposed by Maruyama and Imamura [4], in andoc...
1.   A function to act as an encryption interface between     within an XSLT processor may still be exploited to connect, ...
In preliminary experiments, DOM segments were extractedfrom an XML document, by a stylesheet and encrypted. The           ...
the specifications classified as a “Working Draft” after fouryears of development. XML Encryption has progressed to the   ...
Upcoming SlideShare
Loading in...5

Element wise encryption of XML using XSLT


Published on

XML is expected to facilitate Internet B2B messaging because of its simplicity and flexibility. One big concern that customer may have in doing Internet B2B messaging is security. Therefore considering some security features in XML such as element-wise encryption, access control and digital signature that are beyond the capability of the transport-level security protocol such as SSL is of interest. We describe element-wise encryption of XML documents by performing some cryptographic transformations on it. For this reason, XSLT (Extensible Stylesheet Language Transformations) may well have sufficient functionality to perform all reasonable cryptographic transformations.

In this paper we implement element wise encryption operation in the document using XSLT. Extension functions of XSLT are made use to enhance the abilities of XSLT to include the encryption and decryption functions.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Element wise encryption of XML using XSLT

  1. 1. Element Wise Encryption of XML using XSLT J. Ahmed Muzammil*, A. Manikandan+ *+ UG Students, Dept. Of Information Technology, Noorul Islam College of Engineering (Anna University), Kumaracoil, Tamilnadu, India * ahmedmuzammil@outlook.com +mani_mm4@yahoo.co.inKeywords: XML, XSLT, Security, WWW Through adherence to a system independent character set (Unicode), XML documents are human legible. While thisAbstract makes an XML document more palatable for viewing purposes (compared to a binary file), it raises privacy of The eXtensible Markup Language (XML) is regarded information issues. At the very least, information required togenerally as having promise of becoming established as the be secure should not appear human legible. A simple, yetgeneral purpose framework for enabling transfer of data effective way to achieve this is to encrypt XML dataamongst heterogeneous environments. elements. For reasons to be explained below, encryption of elements should be carried out on an isolated / individualClosely associated with XML is the eXtensible Stylesheet basis. Within an XML document there are two different places data elements can reside:Language (XSL), whose document transformation component(XSLT) may well have sufficient functionality to perform all • Attributes of tags, orreasonable cryptographic transformations to deliver a desired • Text children of container elements.level of document security. We will require a secure XML document to retain the sameXML is expected to facilitate Internet B2B messaging structure as the original XML document. By doing this, anbecause of its simplicity and flexibility. One big concern that application can be decoupled from any security measures.customer may have in doing Internet B2B messaging is This principle is grounded in practical experience with XMLsecurity. Therefore considering some security features in applications such as the Data Sockets project [7], whereXML such as element-wise encryption, access control and documents are composed with elements from different sources, by an intermediary who ought not to be privy to thedigital signature that are beyond the capability of the data content of those elements, as well as providing for atransport-level security protocol such as SSL is of interest. finely-grained access control mechanism in respect of theWe describe element-wise encryption of XML documents by visibility of individual elements of a document. This rules outperforming some cryptographic transformations on it. For this a simplistic approach, i.e. to encrypt the entire contents of anreason, XSLT (Extensible Stylesheet Language XML document (tags included) at source, producingTransformations) may well have sufficient functionality to unstructured text. Such text can be encapsulated in an XMLperform all reasonable cryptographic transformations. content element, hence making the document an “XML document” (providing encoding types and character sets are supported). Miyazawa and Kushidia [3] present a similarIn this paper we implement element wise encryption approach to XML document security. In their schemeoperation in the document using XSLT. Extension functions security information, including the name of the algorithm andof XSLT are made use to enhance the abilities of XSLT to size of the key used for encryption is included inside of ainclude the encryption and decryption functions. “secure XML document”. Whilst this is not an explicit vulnerability, keeping this information separate from the XML document, makes a secure XML document more1 Introduction difficult (but not impossible) to decrypt; as information pertaining to encryption specifics is commonly used as theOver the past three years the eXtensible Markup Language foundation for an unauthorized party to decrypt documents.(XML) has appeared, offering a framework which promotesthe movement of business information across networks. XML XSLT (eXtensible Stylesheet Language Transformations) is ais a standard from the World Wide Web Consortium (W3C), W3C specification for a document manipulation languageallowing users to structure (and label) information separately capable of restructuring documents and performing computations on their elements. It is of interest to discoverfrom the presentation of that information. A single instance of whether XSLT could express transformations of an XMLthis structured information is known as an XML Document. document to and from an encrypted form, thereby unifyingAn XML document must adhere to particular syntax and this aspect of document handling within the XSLT ramework.semantics as outlined in Extensible Markup Language (XML) This leads to the questions addressed in this paper: What are1.0(Second Edition), W3C Recommendation 6th October 2000 the issues involved with using XSLT to transform an XML[1]. The use of XML, as a container for business information document into a secured format and back again; and howis desirable because it is platform independent; it utilizes suitable is this use of XSLT?existing communication protocols (i.e. HTTP and SSL); and itis able to pass through firewalls as a result.
  2. 2. If we regard encryption/decryption as just another XML was first proposed by Maruyama and Imamura [4], in andocument transformation operation, then it is apparent that article published on a W3C mailing list. Unlike the definitionthe advantages XSLT provides in respect of other operations, contained in this research Maruyama and Imamura requiredsuch as presentation formatting, carry over to this aspect of stricter validation of information and allowed resultingdocument transfer as well. In particular it might avoid the documents to possess different structures (to the originalneed to deploy and maintain special purpose software: Once a document). Applying element-wise encryption can be likenedstandard XSLT processor is available, the specifics of to carrying out semantic operations on sections of an XMLsecurity operations may be confined to stylesheets. As we document. In Maruyama and Imamura’s proposal ofshall see however, it turns out that XSLT cant provide a elementwise encryption, validation of information (throughcomplete solution. As mentioned above, in this paper we the use of a Document Type Definition [DTD]) wasconsider an ebusiness scenario where an intermediary or suggested, as means of assuring information contained withinbroker parses input XML documents and produces a an XML document existed within an appropriate form. Thiscollection of (smaller) XML documents (comprising a article does not consider issues derived or relating to thetransaction), or correspondingly, where this intermediary validation of XML documents.combines a collection of XML documents. Data contained inthe XML documents should be hidden from the intermediary(to respect the privacy of information), but the structure of a 3 Encryption Transformationsdocument, including identification of individual elements is to In this section we examine how readily “pure” XSLT may beremain visible to enable the broker to function. It ought to be applied to encryption transformations, and conclude that thepossible to apply encryption/decryption stylesheets in this only reasonable strategy is to employ extension functions,scenario, so that information can be hidden as desired from which allow XSLT code to request computations expressed inthe intermediary, and at the same time leave control of another language. The proposed model for this problem isinformation to its source: A result of applying depicted in Figure 1: A source XML document undergoes aencryption/decryption stylesheets is that provision for an transformation (contained in a stylesheet), to produce anaccess control mechanism becomes possible; by varying encrypted XML document (that is, a secure XML document);either encryption key, or even encryption procedure, element a second stylesheet transforms an encrypted XML documentby element. into its original form.In what follows we examine the capability of XSLT toperform security transformations meeting the aboverequirements and identify its limitations in this regard.Although we reason directly from the W3C XSLTspecification to reach our conclusions, we also provide a briefdescription of the test environment used during the course ofthe project to verify those conclusions in the case of aparticular XSLT processor implementation.2 Related WorkAlthough this research set out to ascertain the suitability andapplicability of using XSLT to achieve XML documentsecurity, it is not the only way in which XML documentsecurity can be achieved. A simple yet effective way,adhering to the basis of element-wise encryption and utilizingan XML processor, can be constructed in almost anyprogramming language. The obvious benefit of such an Figure 1. XML Encryption and Decryptionapproach is a reduction in the amount of complexity requiredto construct and implement. Problems with this approach are Constructing encryption and decryption stylesheets withthat such a package is required at each point in the system complete adherence to XSLT syntax is plausible, but not(where the security of the XML document is dealt with) and a fruitful owing to the inherent complexity of programmingnew mechanism for determining selection for encryption encryption algorithms without an assignment statement. Even simple programming within a stylesheet significantlywithin a source XML document is required. An example of an increases complexity - one need only consider the effortimplementation of this type is that of W3C’s, XML needed to compute N! (the factorial function) using an XSLEncryption, which incorporates security concerns into an stylesheet to be convinced of this.XML processor, controlled by attributes in an XMLdocument (for the purposes of initialization and invocation) 3.1 Extension Functions[5]. A realization of this processor is the XML Security Suitefrom IBM [6]. In order to provide conventional programming language functionality without adversely affecting stylesheet2.1 Element-Wise Encryption complexity, extension function provisions (Section 14, in [2]) are utilized. Requirements for two different extensionElement-Wise Encryption is the name given to the process of functions are immediately obvious:applying encryption algorithms to sections of an XMLdocument to produce a secure XML document. This concept
  3. 3. 1. A function to act as an encryption interface between within an XSLT processor may still be exploited to connect, cryptographic libraries and a stylesheet. in a reasonably transparent way, the encryption functions with 2. A function to act as a decryption interface between an XML parser interface such as SAX [11]. We may thereby continue to expect to save some degree of development and cryptographic libraries and a stylesheet. deployment effort as pointed out in Section 2.These extension functions are to be applied in accordancewith element-wise encryption. A stylesheet carrying out the 4 Extension Functionsencryption or decryption of XML documents is In this section we discuss how the requirement for structureconceptualized as consisting of several components: preserving encryption may be met, and examine what constraints are placed upon such transformations by the way • Template declarations matching all tags in a in which XSLT processors operate. If we require an encrypted corresponding XML document. This must be done to XML document to have the same XML structure as its preserve the structure contained within the original decrypted form, it can thereby be manipulated, irrespective of XML document. A demonstration of this is an XML whether it is encrypted or not, transparently by document document: handling applications. Values contained in such a document are decoupled from the document structure. For instance, in a <?xml version=“1.0” ?> scenario where an XML document is received and forwarded, <tag1> based upon the value of a specific document element, all values (except for the identifying element) are irrelevant <tag2/> (to the task of forwarding). The difference between encrypted </tag1> and unencrypted documents is that in an encrypted document, the desired textual pieces of data are indecipherable. These containing two different tags; tag1 and tag2, pieces of data can either be tag attributes or text-node children must have each tag “matched” by a template, in of a content element. For example: order to be reproduced in an output document. An XSLT processor discards tags not explicitly <tag attribute=“data”> data </tag> “matched”. This is most undesirable. where data represents data able to be encrypted. data • Extension functions, which carry out both encryption resides in two different locations, as a child of the tag and decryption of text strings. Attribute element and the value of the attribute attribute. Small identification and reproduction. This point is similar amounts of encrypted data are commonly regarded as easier to the first, in that attributes contained in a source for an eavesdropper to decrypt, than a large encrypted block XML document must also be reproduced in an of data. Within this study this issue was disregarded, since output document, else be discarded (and their many security suites compensate for the risk of encrypting information lost). small amounts of data (i.e. by padding data to a certain length before encrypting). • Inclusion of extension functions within the stylesheet The type of encryption applied to any piece of data can be framework is depicted in Figure 2, where an XSLT independent from the encryption applied to any other piece of Processor accepts an XSLT document (a stylesheet) data. For example, each attribute in an XML document may and an XML document, utilizes functionality from have a different encryption algorithm and key applied to it. extension functions in order to produce either an Furthermore, pieces of data that can be encrypted do not encrypted or decrypted XML document. necessarily have to be; depending on the requirements at the source of the information. During the course of this project the concept of element-wise encryption needed refinement. Initially, element-wise encryption was envisaged to encrypt a segment of XML (a node and all of its children). This uncovered a problem: Before a styelsheet can be applied to an XML document, an XML processor must parse that XML document, producing a DOM (Document Object Model) Object representation. The DOM is an API specification for operations on a document in parsed (deserialized) form [8]. During the application of a stylesheet, an XSLT processor steps through a DOM Object applying corresponding templates as tags are matched (tags in the XML document are “matched” with templates in the stylesheet). This means that before a stylesheet is applied, an XML document no longer exists (as an XML document). Whilst it was possible to pass a section of a DOM Object to Figure 2. Extension Functions within the Stylesheet the encryption function, this presented several new problems: Framework a segment (sub-tree) of a DOM Object is not a text element; and when trying to restore a fragment, additional processingClearly the underlying logic of this XSLT solution would be could not be carried out (in order to return a sub-tree into itssimilar to that of a custom-built encryption suite as describedin Section 2; i.e. parse then encrypt/decrypt. While this original XML format).diminishes the advantages which might have been gainedfrom a “pure” XSLT solution, the pre-implemented logic
  4. 4. In preliminary experiments, DOM segments were extractedfrom an XML document, by a stylesheet and encrypted. The <?xml version="1.0"?>encrypted DOM segments were immediately decryptable. <document>However, when trying to serialize encrypted DOM objects (to <customer id="1">be stored in an encrypted XML document) information about <surName>Jamal</surName>the objects is lost and attempts to restore DOM segments will <firstName>Ahmed</firstName>be unsuccessful. </customer> <customer id="2">Without using additional extension functions no means were <surName>A</surName>discovered to perform additional evaluation (i.e. value <firstName>Manikandan</firstName>extraction) upon such DOM segments. Owing to the implied </customer>additional level of complexity, it was concluded that element- </document>wise encryption should not apply to “structured” elements,i.e. non-trivial subtrees of the document, and would beconfined to text nodes. Figure 3. Source XML Document The encryption and decryption stylesheets used in testing are similar. Differences between the two reside in the different5 Project Environment extension functions used (i.e. the encryption stylesheet uses the encrypt function, whilst the decryption stylesheet uses theAspects of XSLT discussed in this paper were investigated decrypt function). Figure 3 depicts a portion of an XMLand/or verified by means of specifying and implementing a document which we’ll use to illustrate a typical test case; thenumber of demonstration stylesheets. The XSLT processor element surName is to be encrypted. The requiredutilized in these tests was xalan-j version 2.7.1. xalan-j claims transformation appears in the corresponding stylesheetconformance to the XSLT 1.0 and is constructed in the Java segment depicted in Figure 4. The encryption functionProgramming Language. encrypt() is identified as an extension function by means of the namespace prefix security which is itself defined andAs described in Section 3.1, extension functions are code linked to the relevant compiled class by the xsl:scriptwritten in a (programming) language other than XSLT that element.are “hooked” into a stylesheet to provide additionalfunctionality. XSLT extension functions are processorimplementation specific. <xsl:script implements-prefix="security" language="java" src="java:test"/>Extension functions used in the test scenario are written in ...Java. The reason for this is that xalan-j, (the XSLT Processor) <xsl:template match="surName"> <xsl:text disable-output-escaping="yes">is constructed in Java and provides a binding for this &lt;surName&gt;</xsl:text>language. In this scenario, the Java extension functions use <xsl:value-of select=the same Java Runtime Environment (JRE) as xalan-j since "security:encrypt(text())"/>xalan-j requires a JRE in order to operate. <xsl:text disable-output- escaping="yes">&lt;/surName&gt; </xsl:text>6 Test Procedures </xsl:template>This section gives an overview the series of steps used tocarry out testing. Figure 4. Stylesheet Encryption ExtractThe file containing the Java extension function code mustfirst be compiled using the “javac” compiler included with a 7 ConclusionsJava Software Development Kit (SDK). While XSLT possesses the ability to manipulate the structureThe source XML document and encryption stylesheet are and contents of XML documents, trying to extract additionalpassed as input to xalan-j. The class file, created from the functionality, such as the application of an encryptionextension function source code once compiled, must be algorithm leads to unacceptable complexity and constrains theincluded on the classpath of the processor. By applying the ways in which documents can be encrypted.encryption stylesheet to the source XML document, a secureXML document is produced, along with the temporary“keystore” file, containing a queue of the keys used for It has been shown that through the use of extension functionsencryption. the former problem can be overcome, by providing small modules that extend XSLT capabilities. This solution led toThe secure XML document and the decryption stylesheet are some technical difficulties, since, at the time of this project,passed as input to xalan-j. Again, the class file containing the extension functions had yet to be clearly (and cleanly) definedextension functions must be included on the XSLTprocessor’s classpath. From this transformation, the source within an XSLT specification. Subsequent specificationXML document is reproduced. updates [10], where, incidentally, the <xsl:script> element has been removed, indicate that this is still the case. It may be considered that, as a technology, XSLT is still immature, with
  5. 5. the specifications classified as a “Working Draft” after fouryears of development. XML Encryption has progressed to the [11] Brownell D., ‘‘SAX’’, http://www.saxproject.org/status of “Candidate Recommendation” after two years, andfurther development may see this established as the pathway [12] XML security using XSLT Bartlett, R.G.; Cook,of choice to XML document security. M.W. System Sciences, 2003. Proceedings of the 36th Annual Hawaii International Conference onReferences Volume , Issue , 6-9 Jan. 2003 Page(s): 6 pp. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber= [1] W3C, “Extensible Markup Language (XML) 1.0 1174279 (Fifth Edition) W3C Recommendation 26 November 2008”, http://www.w3.org/TR/2008/REC-xml- [13] Kayvan Farzaneh; Mahmood Doroodchi, "XML 20081126/ Security beyond XSLT," Innovations in Information Technology, 2006 , vol., no., pp.1-5, Nov. 2006 [2] W3C, “XSL Transformations (XSLT) Version 1.0 http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber W3C Recommendation 16 November 1999”, =4085468&isnumber=4043134 http://www.w3.org/TR/1999/REC-xslt-19991116 [3] Miyazawa, T.; Kushida, T., "An advanced Internet XML/EDI model based on secure XML documents ," Parallel and Distributed Systems: Workshops, Seventh International Conference on, 2000 , vol., no., pp.295-300, Oct 2000 http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber =884601&isnumber=19134 [4] Maruyama H. and Imamura T., “Element-Wise XML Encryption”, http://lists.w3.org /Archives/Public/xml-encryption/2000Apr/att- 0005/01-xmlenc.html, April 2000. [5] W3C, “XML Encryption Syntax and Processing; WG Working Draft 26 June 2001”, http://www.w3.org/TR/2001/WD-xmlenc-core- 20010626/, June 2001. [6] Tidwell D., “The XML Security Suite: Increasing the security of e-business”, http://www- 4.ibm.com/software/developer/library/xmlsecuritysui te/index.html, April 2000. [7] Bryan G., Curry J., McGregor C., Holdsworth D. and, Sharply R., “Using XML to facilitate information management across multiple local government agencies”, Hawaii International Conference on System Sciences, Hawaii, United States, January 2002, pp. 1544-1553. [8] Tidwell D., ‘‘The XML Security Suite: Increasing the security of e-business’’, 02 May 2000. [9] W3C, “Document Object Model (DOM) Level 3 Core Specification Version 1.0 W3C Recommendation 07 April 2004” http://www.w3.org/TR/2004/REC-DOM-Level-3- Core-20040407 [10] W3C, “XSL Transformations (XSLT) Version 2.0; W3C Working Draft 30 April 2002”, http://www.w3.org/TR/2002/WD-xslt20-20020430/, April 2002.