Revisiting Secure Documents with XML Security: A ...

Revisiting Secure Documents with XML Security: A Component-Based Approach Galoh Rashidah Haron, Dharmadharshni Maniam and Shawn Tan Ser Ngiap Information System Security Lab MIMOS, Kuala Lumpur, Malaysia Abstract— In this paper, we propose a web solution that generates secure documents using XML security technology and tokens through a component-based approach. Tokens consist of user identity certificates and keys associated with the certificates. Tokens can either be in software or hardware. To provide such middleware, we gather a list of applicable components related to XML security, review its trends and analyse its reusable functionalities. Based on the feasibility of the component reuse, we report experiences on component based development, focusing on issues and challenges arising from the practice. Index Terms— XML digital signature, XML encryption, token, Public Key Infrastructure, component-based

I. INTRODUCTION Component-Based Software Development (CBSD) is a terminology associated with developing a software unit as a component with specific functional bindings. The purpose of the component design is to elicit definite requirements and optimise its reusability factor. Our preliminary study on secure documents and XML Security indicates that under normal situations the secure document systems perform digital signing and encryption on a single machine. Meaning, its security processes are based on single sided operation. It is designed as a system either on a user’s machine [6][7][8] or on a server machine [4]. For new development, we aim to secure documents with XML security in client-server communications. The challenge is to identify and segregate the security processes that are proven on single machines to work on client and server machines synchronously. On the client side, it will support client authentication mechanism. The idea is to protect users’ credentials from being transported to other machines while the user performs security operations. On the server, it handles documents with XML security. In previous development, we have managed to develop a Document Management System (DMS) with built-in security. It is a solution to provide secure information exchange in web browsers with Public Key Infrastructure (PKI) technology. The solution provides digital signing, verification, encryption and decryption mechanisms with representation of secure data structures in S/MIME, PKCS#7, and ASN.1 standard formats. In the design, the DMS system was handled in a web environment on C/C++ platform. It was implemented using client-server architecture with a web plug-in (Active-X and Mozilla Plug-in) as its communication mediator. Users can create a document, perform digital signing and ensure its

privacy with encryption in the user’s machine. Finally, users upload the secured documents to a dedicated server and the DMS system sends the document to the intended recipients using a specific document workflow. Feedback from this solution is on the document workflow, which was frequently redesigned, to accommodate the requirements of different users. Users may opt to use another document workflow in handling a company’s documents which are commonly based on approved management processes and policies. Users may already have an up and running DMS system and the security component can be plugged into the DMS. These factors led to the creation of security middleware with an abstract interface to encapsulate the complexity of its integration to any DMS system. The design of the new middleware will apply the open standard technology of Extensible Markup Language (XML) by W3C community with Java being the primary language. II. ARCHITECTURE AND DESIGN XML has experienced more than a decade of use in web technology. Exploring XML through technical papers gave a positive outlook on the project’s feasibility. The new components model is structured under client-server architecture as depicted in Figure 1. A user will access a web browser to secure any digital document residing in the web server by applying XML, PKI and secure token under HTTP(S) protocol. The requirement specification of the solution is to support any digital document format, translated into XML format and secured with digital signature and encryption technology that conforms to W3C XML Digital Signature and Encryption standards. Firefox Web Browser

Document Management System (DMS)

CC

CS

Client Component-Based

Server Component-Based

Certificate Database

HTTP(S)

File Database

PKCS#11 PKCS#12 (Smart Card) Figure 1: Component Based Architecture for DMS

The security mechanism uses user credentials based on hardware or software tokens. These tokens store private keys with accompanying public key certificates. A software token is basically a binary file format used to store public key, private key and certificate. For a software token, the implementation is to support any compatible and secure certificate file format. For the prototype’s purpose, the PKCS#12 standard [2] is chosen as the format for the cryptographic software token. For hardware token, our national smart card known as MyKAD was chosen and it follows the PKCS#11 standard [1]. The Document Management System (DMS) in Figure 1 is regarded as an existing system. Users are able to access the DMS through a web browser e.g Mozilla Firefox. The new development will involve coding on Cc and CS components. Cc is the client component to be plugged into the DMS. It is the main interface to access user credentials and certificates using PKCS#11 and PKCS#12. This client side component will provide user credential management - any operation that accesses user credentials e.g. digital signing and decryption is handled in a user’s machine. Module

Java XML Digital Signature and Encryption APIs Apache XML Security Library XML Security Library

CS is the server component plugged into the DMS. It directly creates and secures the digital document. This server side component provides XML support - creation of documents, translation to XML documents and (re)structuring of XML documents are performed in the server. III. RELATED WORK The "buy, don't build" philosophy is advocated in CBSD approach. What it means is, reuse of ready software components - either Open-source software (OSS), Commercial Off-The-Shelf (COTS) or previously in-house released libraries - are taking precedence over developing a new component. It is obvious for good reasons, to reduce the overall cost and maintenance. In this section, we will review other efforts in XML security. First, we will list library modules that provide a platform for other developers to integrate the XML security functions. Then, we will list end-user applications that run XML security functions.

Language Java

Table 1: XML Modules and Features License Codes c14n GPL Y N

C++, Java

Apache

Y

C++

MIT

Y

XSig Y

XEnc Y

Token N

Y

Y

Y

Y

Y

Y

NSS / MSCrypto (C++) NSS / MSCrypto (C++)

GPL: General Public License; MIT: Massachusetts Institute of Technology; Y: yes; N: no; NSS: Network Security Services; MSCrypto: Microsoft Crypto

A. Libraries We have selected three available XML security libraries and Table 1 provides a summary of their features. We focused on the features that have the potential to be reused in our new solution: XML Security and token management. For XML Security, three features are identified: XML Digital Signature (XSig), XML Encryption (XEnc) and XML Canonicalization (c14n). For token management, a module that supports either Network Security Services (NSS) [16] or Microsoft Crypto (MSCrypto) [17] can be used in token services integration. Below is the detailed description of XML Security libraries. 1) Java XML Digital Signature & Encryption APIs Sun provides a Java development kit for the developer to do extensive applications in Java. In order for a developer to apply W3C recommendations for XML Security technology specification in the new solution, the XML Security needs to be translated to Java Application Programming Interfaces (APIs). This is initiated by the Java community, who will propose Java Specification Requests (JSRs). The JSR is a collection of technical specifications developed in Java and designed to conform to the standard specifications. The result is JSR 105: Java XML Digital Signature APIs and JSR 106: Java XML Encryption APIs. When the proposed JSR is approved for its public release, the JSRs are included in the next Java Development Kit (JDK) release. Thus, for integrating XML Digital Signature and XML Encryption to the new solution, JDK release 1.6 [3] was used. 2) Apache XML Security Library Apache XML security [4] is an open source initiative for XML security released under Apache Software license. It is developed in C++ and Java. It supports the W3C

specifications for XML Signature and XML Encryption. It is considered as a complete series and marks the maturity in XML technology. 3) XML Security Library The XML Security Library or known as XMLSec library [5] is an open source initiative to enable the integration of XML security inside third party solution. It is developed in C++ and released under MIT license. It supports the W3C specifications for XML Signature and XML Encryption in both Windows and Linux operating systems. B. Applications Besides looking at the reusability of the middleware component, the search may extend to application level. These applications are worth mentioning to measure applicability of these libraries to the new solution. 1) XML Digital Signature Tool Application XML Digital Signature Tool [6] is a Firefox extension for processing digital signature in XML documents. The XML interface is built on top of Apache XML Security library. It is developed in C++ and Java Script languages and supports the W3C Specification for XML signature. This application allows users to select a list of user certificates from the browser certificate database and use the selected credential information to sign the XML document. It is released under Mozilla Public License (MPL), on top of the Apache XML Security C Library. The application is ready to be downloaded and packed with java script and XML User Interface Language (XUL) source code. What interest us is the implementation of scriptable XPCOM base API for accessing the service to manipulate X.509 certificates stored in Mozilla Firefox database.

Meaning, the certificate database management is centrally handled by the browser. Users who store credentials in Mozilla Firefox will be able to directly use this application. This application’s design is within the scope of the new requirements. 2) XML Security Tools Application The XML security tool plug-in [7] for Eclipse allows users to exploit XML security features. This application is released under Eclipse Public License and is intended to bridge the lack of user acceptance in XML technology. The XML interface is built on top of Apache XML Security library using Java. It is an excellent tool for beginners to study the internals of XML Security. 3) JVNRSS XML Signature SIG_rdf (RDF with XML signature) [8] is an application to promote the use of XML signature within security information exchange. It utilises Windows certificate management to access the X.509 certificate with addition of time stamping properties. C. Components Recall in Figure 1, we require components for client (Cc) and server (CS) to complete the secure DMS. In the client, we impose the requirement that all security operations involving private keys, for example digital signing and decryption should be executed at the user’s site. So a user’s private key must not be allowed to transfer to or be stored at any other machine besides the user’s machine. For web environment, this client component should have properties to read the certificate and user’s credential information either in PKCS#12 or PKCS#11 standard through a web browser. Based on Table 1, the token management functionalities are provided by NSS in C++ and not in Java. Since all the designs need to fully utilize the Java language for token management, we require NSS in Java. At first, we considered developing a Java wrapper for the NSS. Initial research showed that JSS [9], a Java version of NSS, has been developed by Mozilla. It is available under the MPL and GPL. JSS has dependencies on NSS. Thus, the final design for the Cc is a token management system ready to be plugged into the client site of the DMS as in Figure 2.

Figure 2: Client Component Based Architecture

In the server component, the CS must have properties to perform security operations on digital documents. Thus, features to validate and encrypt documents should be available in the server site. The server should also (re)construct partial XML signature and encryption document structures. Based on Table 1, we identified several combinations of feasible components to be reused in the server side: 1) Java XML Digital Signature and Encryption APIs 2) Apache XML Security Library. Studying these two libraries, we found that Apache XML Security Library is dependent on Java XML Digital Signature and Encryption

APIs for its XML security function. Both of these libraries are packaged inside JDK 1.6. The CS upholds the W3C security recommendation in XML technology as in Figure 3.

Figure 3: Server Component Based Architecture

IV. DEVELOPMENT ISSUES The development of these components by means of CBSD raises several issues. These issues are discussed as follows: A. Token In dealing with PKI technology, one of the main aspects of development involved token management. Token management is about administration of certificates, private and public keys. Java provides several techniques to read user credentials and certificates based on software and hardware tokens. The first technique is through Java KeyStore (JKS) [10] which provides a mechanism for deploying X.509 certificates and private keys through methods called in “java.security.KeyStore” and “java.security.cert” classes. The second technique deals directly with the certificate database in the web browser. Firefox has its own certificate database and provide a NSS module to deal with PKCS#11, PKCS#12 and X.509 certificates. For Internet Explorer, the certificate management is handled by MSCrypto through the certificate storage in the registry. Several other possibilities are explored before reaching the decision to go with JSS. In the trial of using JKS, we found that a myriad of steps in client configuration are required particularly when working with smart cards. An example of JKS calling smart card library is listed in [18]. The specific smart card provider is hardcoded within the code. This design does not allow other providers to be easily integrated into the solution. In our solution, we need to list all the software and hardware token in web environments. Through JSS, the list of modules and tokens that are configured in the NSS database is available for any usage. This makes it easy to write code for JSS API and XML security interfaces. However, in actual development, this module had the most problems. We had problems where the decrypt operation using the hardware token was not successful. Assuming that the errors originated from the external party’s component; we spent much debugging time in JSS component. Later, we realized that the problem was actually with our new PKCS#11 components - digital signing was supported but not decryption. So, extra development time was needed to meet the new decryption requirement. B. Signature Applying Java JSR 105 [11] into the solution was an effortless experience. The library is complete with API documentation and code samples. The java package providing these functions is “javax.xml.crypto.dsig”. The next job is to divorce functions performed in the client and server for signing an XML document.

Based on W3C XML Digital Signature [13], there are three methods of digital signature format: enveloped, enveloping and detached. Enveloped means that only the signature element is wrapped and it must co-exist with other elements in the XML document. Enveloping means that the signature element is a container or wrapper to the other elements in the XML document. Detached means that only the signature element is being wrapped and the signature element is separated from other elements. Next is to figure out the mean and applicability of these formats. The advantage of each format against the others is unknown. It has been reported [25] that the enveloping format is used for a time stamping object in the signature. The example given in W3C recommendation is that the signing object can exist in detached and enveloping in a single XML Document. It has been reported that the detached signature allows a user to sign a file that is located at the other server site by attaching it to the Reference URI element [13]. It is also reported that most applications use the enveloped format [20]. From our research, we came to the conclusion that the different signature formats can be combined with one another in a single XML document [13][21]. Thus, the XML document can be in enveloped signature format and yet some of the reference elements, data to be signed, can adopt a detached signature. For our design we have selected a traditional enveloped format where the data to be signed is located at the first section and the signature is at the last section, reasons to mimic the PKCS#7 structure. C. Encryption As this point, we have successfully integrated XML signature using JSR 105. We have proven that a document can be digitally signed with a token using XML Signature components provided by the JDK. Thus, we thought that the integration of W3C XML Encryption [14] will be a similar cycle of development. However, our assumption was wrong. Developing the XML Encryption is not as straight forward as for the XML Signature. The intended class was not found in the JDK library. In querying the status of the class, we found out that the status of JSR 106 [12] is inactive, meaning that they have not posted a milestone within the last 18 months. The last update was made in 2006, it is not yet finalised compared to JSR 105 whose status was Final Release in 2005. The Java Community Process (JCP) program has yet to release the final draft of a Java API for XML Encryption (JSR 106). Others have encountered the same problem. In 2005, it was reported that the XML Security Plug-in for Eclipse is stable and complete. However, for XML Encryption it is yet to be finalised [7]. It is reported in Apache XML Security [19] that the current version of 1.4, the Java library supports the standard Java API JSR 105 and for JSR 106 is in progress and is not final. As per JSR 106 documentation, the final release will include “javax.xml.crypto.enc” a class for parsing, encrypting and decrypting XML encrypted type structures, and “javax.xml.crypto.enc.dom”, a DOM-specific class. Since this class does not exist in the current JDK, the present workaround solution is to use the non conformant W3C XML Encryption APIs. To create the confidential documents, the “javax.crypto.Cipher” class is applied and to (re)construct the XML structure the “javax.xml.parser” is applied as in XML signing code.

D. Canonicalisation When we first transform a document with XML security, the power of canonicalization is evident. The sample code given by the Java community is sufficient for any document to be structured as an XML document by creating one mandatory element as depicted in Figure 4, called CanonicalizationMethod. Figure 4: Canonicalization Method

Understanding canonicalisation as provided under W3C recommendation [15] is not difficult. Reading the standard, leads to the frequent use of the word “normalisation”. The purpose of data being normalised is to eliminate redundant information and formatting in the structured data. So the canonicalisation method applied in XML is basically to standardise the format of the XML structure; e.g. removing whitespace. As stated in Wikipedia [22], two XML documents must be converted to Canonical XML prior to searching for difference. For canonicalisation, we encountered issues in client server communication where data being sent from server to client or vice versa, was not recognised as XML format but more critically, the digital signature failed to be verified. From prior experience, for client-server communication to be in sync, data needs to be in base64 encoding to ensure that the data remains intact. But implementing the base64 solution did not solve the issue. Further investigation was required. We compared the data sent out by the server and the data received by client using a text differentiator application. It appeared that both of the data was identical and the issue was yet to be resolved. Next, we delved into Java and XML code from JDK and reviewed the XML Security recommendation by W3C XML. Exploring all other possibilities, we decided that canonicalisation was required. Canonicalisation ensures the equivalence on a byte comparison basis. Thus, we reused components that provide methods which perform direct canonicalisation by Apache XML Security Library. They provide canonicalize (byte[] inputBytes) method to perform normalisation in a Canonicalizer class. E. Interoperability Vital time is required to investigate the interoperability of all reusable components with the in-house components. The feasibility study of these components, learning its behaviour and properties must be proven by sample code before the project starts. When OSS component is used together with CBSD approach, it involves research oriented software development. It requires trial and error to glue all the components and ensure it is working as required in one system. Recall that our development challenge is to perform XML security in client-server environment which is normally performed on a single machine. The interoperability issues lays within client and server components and its sequence of communications. In the client, we need to assure the right token module fits to the client component. In the server, the

XML security engine must be able to perform as per requirements. Based on experience, coding and running small prototypes is the best way to inspect interoperability of components. V. LESSONS LEARNED As promising as the reusable component might seem, there are technical hitches and glitches that developers need to be aware of before committing to the CBSD approach. Based on our experience, we have to agree that reusable components simplify the overall development. Applying XML security technology with CBSD approach allows a speedier development time compared to the previous non-XML technology (S/MIME, PKCS#7 and ASN.1). By metrics, the man hour to develop the new solution, which is functionally equivalent to the previous technology, is lessened by half. In terms of the development work, it reduces the code complexity. Table 2 provides product properties for both XML and non-XML technologies. The difference in line of codes by both technologies is 9788, about 62% more code in non-XML. Figure 5 shows the number of non-comment source lines (NCSL) for each of the components in XML and non-XML.

Skills required to develop this solution are not as complex as understanding the previous technology. So the new XML security hides the complexity of security. In fact, the development of the XML secure document can be performed by a new developer. This gives good reason to motivate more developers to engage with security and to grasp the new technology faster. Table 2: Product Properties of XML and Non-XML

Feature Language Token Documents Token Interface Security Component Total NCSL

XML

Non-XML

Java Hardware and software token Resides in server machine PKCS#11

C++ Hardware token only Resides in user’s machine MyKAD Interface

XML

S/MIME, PKCS#7, ASN.1 15848

6060

Figure 5: Relationship between NOC and NSCL Although the speed of development is increased through a component-based approach, before heading to this direction, there are issues that need to be understood. 1) Reusable component interoperability investigation In CBSD approach, it is important to perform research to understand the inside out of the reuse component. Although the development time is shortened, developers need to assure that the component is right for the new solution. Otherwise, more time is required to seek for alternative components. 2) Reusable component progress status Before choosing either COTS or OSS, we need to ensure that the required functions are fully implemented. In case of OSS, some of the required functions are not ready and still in progress. Some of the code can even be categorised as dormant. This factor impacts on the new solution’s delivery time. To avoid this, developers need to thoroughly understand the codes of the components. This is the best method to know what exact functions are offered by OSS. 3) Reusable component needs an increased level of debugging skills This issue is specifically for OSS. Normally, OSS

components allow developers to download its source code and binaries. In order to map features to new requirements, developers must study the code and where the result is not as expected, debugging skills will come in handy. Developers need to understand the style of logging and debugging offered by the reuse component. For example, debugging the PKCS#11 component by Mozilla, e.g using PKCS#11 Module Logger in C++ [23] is different compare to logging and debugging of XML security component [24] by Java community. In fact these skills have its own focus areas; programming language (C++/Java), products (application/middleware/web), development tools (Eclipse/Visual Studio) and operating system specifications (Windows/Unix). 4) Reusable component licensing Before integrating any reusable component, it is vital for a developer to clearly understand the licensing for each reusable component. Each license scheme has different terms and conditions. The licensing of the component is a determining factor in the licensing of the new solution.

5) Huge integration effort When dealing with CBSD, particularly security components, extra effort is required to assemble all components into a final system. It is true that CBSD simplifies development time, but to ensure that the components work as expected in a whole system requires more time. We are looking at any unexpected behaviours in terms of security concerns, when all these components are glued together. 6) Know all the components Learn to understand not only the new components but the in-house components as well. The in-house components are developed by multiple developers who have different focus areas. Some components may move from one hand to another due to human resource issues. Some components may be stripped for a better design for its performance. Thus, developers must have a mindset that the integration errors may come from all of the integrated components.

[9] [10]

[11]

[12]

[13]

[14]

[15] [16]

VI. CONCLUSION We designed a security component that has “plug n play” behaviour to any DMS system with CBSD approach. The objective of the component development is to secure documents with XML security technology based on the Java platform. The security features involved are digital signing, validation, encryption and decryption via XML technology. The reason to shift toward XML security technology is to experience the promise of XML technology in providing a flexible framework for signing and encrypting of documents. Based on experience, the CBSD approach simplifies the code development and lessens half of the development time when compared against the development using previous security technology. In the future, it will be interesting to investigate performance issues in signing and encryption of the XML document and to perform security analysis of these components.

[17] [18]

[19] [20]

[21]

[22] [23]

[24]

ACKNOWLEDGMENT We acknowledge the support provided by the Ministry of Science, Technology and Innovation (MOSTI) in funding the MIMOS Security Platform and Services (MSPS) project through the Ninth Malaysia Plan (9MP). The completion of the project allows optimised use of our national smart card technology. REFERENCES [1]

[2]

[3] [4] [5] [6] [7] [8]

RSA Laboratories, “PKCS#11: Cryptographic Token Interface Standard”, June 2004. Available FTP: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf, November 2007 RSA Laboratories, “PKCS#12: Personal Information Exchange Syntax Standard, June 2004. Available FTP: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf, November March 2010 Java SE Downloads - Sun Developer Network (SDN). Available: http://java.sun.com/javase/downloads/widget/jdk6.jsp, March 2010 Welcome to XML security. Available: http://santuario.apache.org/, November 2009 XML Security Library. Available: http://www.aleksey.com/xmlsec/index.html, March 2010 S. Mazumdar, XML Digital Signature Tool :: Add-ons for Firefox. https://addons.mozilla.org/en-US/firefox/addon/4522 D. Schadow, 2005. Experience XML security. In: Communications and Multimedia security, vol. 3677. Springer, Berlin. pp. 321-329. M. Terada, S. Takada, J. Fukuzawa, and N. Doi, Proposal of RSS Extension for Security Information Exchange, In: 18th Annual FIRST

[25]

Conference on Computer Security Incident Handling, June 25–30, 2006 Network Security Services for Java (JSS). Available: http://www.mozilla.org/projects/security/pki/jss/, December 2009 KeyStore (Java Platform SE 6). Available: http://java.sun.com/javase/6/docs/api/java/security/KeyStore.html, November 2009 JavaTM XML Digital Signature API Specification (JSR 105). Available: http://java.sun.com/javase/6/docs/technotes/guides/security/xmldsig/o verview.html, February 2010 The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 106. Available: http://jcp.org/en/jsr/detail?id=106, February 2010. M. Bartel, J. Boyer, B. Fox, B. LaMacchia, E. Simon, XML-Signature Syntax and Processing (Second Edition) W3C Recommendation 10 June 2008. http://www.w3.org/TR/xmldsig-core/ T. Imamura, B. Dillaway, E. Simon, XML Encryption Syntax and Processing W3C Candidate Recommendation 10 December 2002. http://www.w3.org/TR/xmlenc-core/ J. Boyer, Canonical XML Version 1.0 W3C Recommendation 15 March 2001. http://www.w3.org/TR/xml-c14n Mozilla, Netscape Security Services (NSS) Available : http://www.mozilla.org/projects/security/pki/nss/, November 2007 Using the Microsoft CryptoAPI, Available: http://msdn2.microsoft.com/en-us/library/aa266944.aspx, March 2008 B. Haas, Creating XML Signatures with Smart Cards. Available : http://jce.iaik.tugraz.at/sic/Support/Technical-Articles/Creating-XMLSignatures-with-Smart-Cards, March 2010 The Java section. Available : http://santuario.apache.org/Java/index.html, January 2010 Berin Lautenbach, Introduction to XML Encryption and XML Signature, Information Security Technical Report, Volume 9, Issue 3, July-September 2004, Pages 6-18. Dr. Everett F. Carter Jr., Jeremy Faircloth, Curtis Fraklin Jr., Larry Loeb, XML Digital Signatures, In: Dr. Everett F. Carter, Jr., Jeremy Faircloth, Curtis Fraklin, Jr. and Larry Loeb, Editor(s), Hack Proofing XML, Syngress, Rockland, 2002, Pages 143-182. Canonical XML – Wikipedia. Available: http://en.wikipedia.org/wiki/Canonical_XML, January 2010 Using the PKCs#11 Module Logger. Available: http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn2.html, March 2010 S. Mullan, Programming With the Java XML Digital Signature API, Available: http://java.sun.com/developer/technicalArticles/xml/dig_signature_ap i/, December 2009 A. Apvrille and V. Girier, XML Security Time Stamping Protocol, In: Informations Security Solutions Europe (ISSE 2002), Paris Disneyland, October 2-4, 2002