STORK Work Item 3.2.5 eID OSS Middleware
Status Final Author(s): M. Preliteiro (PT-MULTICERT), T. Zefferer (AT_TUG) Partner(s) contributing: AT-TUG, PT-MULTICERT
Abstract: Within this work item, a minimal-footprint open source and open specification middleware approach has been developed, implemented, and analysed. Therefore, several relevant technologies have been investigated first in order to find a solution that satisfies the requirements of a minimal-footprint middleware approach. Based on the results of these investigations an appropriate middleware architecture has been developed that mainly relies on the Java Applet technology. In order to proof the functionality of the proposed architecture, a demonstrator has been implemented that follows the developed design. Finally, a security analysis of the implemented demonstrator has been carried out in order to evaluate the level of security that can be provided by the proposed middleware architecture. It turned out that the Java Applet based approach is capable to provide a comparable level of security as installation-based middleware solutions.
Project funded by the European Community under the ICT Policy Support Programme Copyright by the STORK-eID Consortium
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Table of Contents
ABBREVIATIONS ...... 4 1 INTRODUCTION ...... 5 1.1 OBJECTIVES ...... 5 1.2 DESCRIPTION OF WORK...... 5 2 INVESTIGATION OF POSSIBLE MIDDLEWARE ARCHITECTURES ...... 6 2.1 INTRODUCTION ...... 6 2.2 INVESTIGATION OF RELEVANT TECHNOLOGIES ...... 6 2.2.1 TECHNOLOGIES OVERVIEW...... 6 2.2.1.1 CRYPTOGRAPHIC SERVICE PROVIDERS (CSP) ...... 6 2.2.1.2 CRYPTOGRAPHY API: NEXT GENERATION (CNG) ...... 7 2.2.1.3 PKCS#11 ...... 7 2.2.1.4 PC/SC ...... 8 2.2.1.5 ACTIVEX ...... 9 2.2.1.6 JAVA APPLETS...... 10 2.2.1.7 JAVASCRIPT ...... 10 2.2.1.8 ADOBE FLASH ...... 11 2.2.1.9 MICROSOFT SILVERLIGHT...... 12 2.2.1.10 .NET...... 13 2.2.1.11 OPENSC ...... 14 2.2.2 COMPARISON OF COMPETING TECHNOLOGIES ...... 14 2.2.2.1 SMART-CARD ABSTRACTION TECHNOLOGIES...... 15 2.2.2.2 BROWSER-BASED TECHNOLOGIES ...... 15 2.2.3 TECHNOLOGICAL SYNERGIES AND ARCHITECTURAL SOLUTIONS ...... 16 2.2.3.1 ACTIVEX AND CSP/CNG ...... 16 2.2.3.2 ACTIVEX / JAVASCRIPT AND PKCS#11 ...... 17 2.2.3.3 ACTIVEX/JAVASCRIPT AND OPENSC ...... 18 2.2.3.4 ACTIVEX ...... 18 2.2.3.5 JAVA APPLET AND CSP/CNG ...... 18 2.2.3.6 JAVA APPLET AND PKCS#11 ...... 19 2.2.3.7 JAVA APPLET AND OPENSC ...... 20 2.2.3.8 JAVA APPLET ...... 20 2.3 INVESTIGATION OF POSSIBLE MINIMAL-FOOTPRINT MW-ARCHITECTURES ...... 21 2.3.1 REQUIREMENTS OF A MINIMAL-FOOTPRINT MIDDLEWARE ARCHITECTURE ...... 21 2.3.1.1 PLATFORM INDEPENDENCY ...... 21 2.3.1.2 BROWSER INDEPENDENCY ...... 21 2.3.1.3 NUMBER OF COMPONENTS TO BE INSTALLED ...... 21 2.3.2 EXAMINATION OF POSSIBLE SOLUTIONS ...... 21 2.3.3 DESIGN OF A MINIMAL-FOOTPRINT MIDDLEWARE ARCHITECTURE ...... 22 2.4 SUMMARY ...... 23
STORK-eID Consortium Page 2 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
3 PROOF OF CONCEPT OF A MINIMAL-FOOTPRINT MIDDLEWARE ...... 25 3.1 INTRODUCTION ...... 25 3.2 GENERAL ARCHITECTURE OF THE MIDDLEWARE DEMONSTRATOR ...... 25 3.3 PROVIDED FEATURES OF THE MIDDLEWARE DEMONSTRATOR ...... 25 4 SECURITY ANALYSIS OF A MINIMAL-FOOTPRINT MIDDLEWARE ...... 29 4.1 INTRODUCTION ...... 29 4.2 ARCHITECTURE OF THE MINIMAL-FOOTPRINT MIDDLEWARE ...... 29 4.2.1 GENERAL MIDDLEWARE ARCHITECTURE ...... 29 4.2.2 PARTICIPATING ENTITIES ...... 30 4.2.2.1 USER ...... 31 4.2.2.2 ONLINE APPLICATION OPERATOR ...... 31 4.2.2.3 MIDDLEWARE SERVER OPERATOR ...... 31 4.2.2.4 APPLET PROVIDER ...... 31 4.3 SECURITY ANALYSIS OF THE MINIMAL-FOOTPRINT ARCHITECTURE ...... 32 4.3.1 POSSIBLE ATTACKS ...... 32 4.3.2 OPERATION MODE “VISUALISATION BY APPLET” ...... 32 4.3.3 OPERATION MODE “VISUALISATION BY SERVER”...... 33 4.3.4 IMPLICATIONS ON THE CURRENT IMPLEMENTATION ...... 34 4.4 COMPARISON TO INSTALLATION-BASED APPROACHES ...... 34 4.5 SUMMARY ...... 35 5 CONCLUSIONS ...... 37 REFERENCES ...... 38
STORK-eID Consortium Page 3 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Abbreviations
APDU Application Protocol Data Unit API Application Programming Interface CAPI Cryptographic Application Programming Interface CIL Common Intermediate Language CLR Common Language Runtime CNG Cryptography API: Next Generation COM Component Object Model CSP Cryptographic Service Providers DES Data Encryption Standard DF Directory File DLL Dynamic Link Library DOM Document Object Model EF Elementary File eID Electronic Identity HTML HyperText Markup Language IDE Integrated Development Environment IE Internet Explorer IT Information Technology JRE Java Runtime Environment JVM Java Virtual Machine MS Microsoft NSA National Security Agency OLE Object Linking and Embedding OS Operating System OSS Open Source and Open Specification PC/SC Personal Computer / Smart Card PDF Portable Document Format PHP PHP: Hypertext Preprocessor PKCS Public Key Cryptography Standards RSA Rivest Shamir Adleman RTMP Real Time Messaging Protocol S/MIME Secure / Multipurpose Internet Mail Extensions SSL Secure Socket Layer SVG Scalable Vector Graphics TLS Transport Layer Security VM Virtual Machine WPF Windows Presentation Foundation XAML Extensible Application Mark-up Language XML Extensible Markup Language YUI Yahoo! User Interface Library
STORK-eID Consortium Page 4 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
1 Introduction
Within this work item, a new approach for a minimal-footprint eID OSS middleware solution has been developed, implemented, and analysed.
1.1 Objectives
The objective of this work assignment was to investigate existing and upcoming eID open source and open specifications middleware approaches in order to provide a profound decision basis for WP5. A comparison of installation-free or minimal-footprint architectures with middleware requiring client-installation was to be made. In addition, a security analysis of minimal-footprint architectures was to be developed in order to identify or eliminate possible risks arising. The objectives thus were: • An in-depth analysis of middleware architectures including a security analysis • Prototypes of open source minimal-footprint card-communication modules
1.2 Description of Work
This work assignment has been divided into the following 2 sub-tasks. Task 1: Investigation of possible middleware architectures The task was to work out possible middleware architectures for STORK and to balance their pros and cons. In particular, minimal-footprint architectures, using Java, Java Applets, .NET, or OpenSC, have been investigated upon their serviceability and usability. Task 2: Proof of concept and security analysis of a minimal-footprint middleware The task was to develop and provide a demonstrator as proof of concept for a minimal-footprint middleware using one of the above mentioned technologies. Furthermore, a security analysis of the particular middleware architecture which is used by the demonstrator has been made.
STORK-eID Consortium Page 5 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
2 Investigation of Possible Middleware Architectures
2.1 Introduction
The approach to access the functionality of smart cards inserted in a locally connected smart card reader device using some kind of middleware is commonly used. The middleware is normally used to hide the troublesome smart card communication behind some kind of interface, which can be used by applications in order to access smart cards in a more comfortable way. Nowadays, most of the commonly used middleware solutions are implemented in the form of ordinary software that has to be installed on the user’s local computer. Although this approach is basically working fine, this kind of middleware implementation is far from being ideal. The fact that additional software needs to be installed and maintained in order to be able to use smart card enabled applications is a handicap that reduces the usability of these applications significantly. The goal of this study is to investigate different approaches that could be able to remove this barrier and to make future middleware approaches more usable. Ideally, the resulting middleware approach should fulfil the minimal-footprint criterion, i.e. it should be applicable without requiring the user to install any additional components. Furthermore, in order to provide a solution for as many users as possible, the final middleware approach should also be platform and browser independent. This study is subdivided in the following sections. Section 2.2 deals with the investigation of different technologies, which may be interesting in the context of minimal-footprint middleware architectures. In Section 2.2.1, several technologies that may be relevant in this context are described and analysed. Subsequently, Section 2.2.2 compares some of these technologies in order to extract their pros and cons related to competing technologies. In Section 2.2.3, possible synergies of different technologies are examined and used to design several architectures that could be used as a basis for future minimal-footprint middleware approaches. Finally, in Section 2.3 a minimal-footprint middleware approach is designed based on the findings that have been obtained in Section 2.2. First, requirements that have to be fulfilled by minimal- footprint middleware approaches are defined in Section 2.3.1. Subsequently, the different architectures being proposed in Section 2.2.3 are tested for their capability to meet these requirements. The most promising approach is finally described in more detail in Section 2.3.3 of this document by providing more architectural details.
2.2 Investigation of Relevant Technologies
In order to be able to develop suitable approaches for minimal-footprint middleware architectures, technologies that are able to contribute to the final solution need to be identified first. Therefore, in this section diverse technologies are analysed, weighted against each other, and finally combined to architectural approaches that may be useful for the development of the final middleware architecture. 2.2.1 Technologies Overview
2.2.1.1 Cryptographic Service Providers (CSP)
2.2.1.1.1 Description The Cryptographic Service Providers (CSP) technology [1] is used in Microsoft Windows based systems. It provides cryptographic methods within the scope of Microsoft’s Cryptographic Application Programming Interface (CAPI) [2]. CAPI is a Windows API, offering libraries for the integration of cryptographic methods for software developers. The CAPI supports diverse cryptographic operations and is usually implemented by Cryptographic Service Providers. The
STORK-eID Consortium Page 6 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009 libraries being provided by CSPs are special variants of Dynamic-Link Libraries, which are linked to the particular software during runtime and not during compile time. Generally, CSPs can be developed by third parties. However, the resulting CSP-DLL needs to be signed by Microsoft. This signature is validated when the respective library is loaded. In order to get a library signed, developers of CSPs have to meet several obligations. However, the source of the library to be signed is not inspected by Microsoft as only a hash value of the respective DLL is signed. In order to ensure its integrity and to detect a possible tampering of the loaded library, the Windows operating system scans the DLL periodically while it is residing in the memory of the system. A special occurrence of a Cryptographic Service Provider is a smart card CSP, which is customised to a particular smart card operating system. This way, a smart card CSP acts as a Windows based pendant to PKCS#11. However, PKCS#11 does usually provide more functionality than CSPs. Thus, many CSPs are basing upon the open standard PKCS#11.
2.2.1.1.2 Analysis Similar to PKCS#11, CSP provides a technology to access smart cards in a more abstract way than this is possible with the plain PC/SC interface for instance. Especially the smart card CSP technology could be useful in this context. Anyway, due to the restriction of this technology to Microsoft Windows based platforms, this technology does not seem to be able to meet all defined requirements of OSS minimal-footprint middleware architectures.
2.2.1.2 Cryptography API: Next Generation (CNG)
2.2.1.2.1 Description The Cryptographic Application Programming Interface (CAPI) that has already been mentioned in Section 2.2.1.1 has been replaced with the launch of Microsoft Windows Vista by a new technology called Cryptography API: Next Generation (CNG) [3]. Compared to its predecessor, the new interface shows a better API factoring and the inclusion of several new algorithms being part of the NSA Suite B [4]. This is a collection of secure cryptographic algorithms proposed by the National Security Agency (NSA). Beside several improvements e.g. support for elliptic curve cryptography, all of the algorithms that have already been defined in the CAPI are supported by CNG as well. Similar to its predecessor, CNG provides facilities for the integration of smart cards. The CNG includes a Base Smart Card Cryptographic Service Provider module encapsulating the respective application programming interface for smart cards.
2.2.1.2.2 Analysis Being the successor of Microsoft’s Cryptographic Application Programming Interface, similar considerations regarding a possible integration of this technology in OSS minimal-footprint middleware architectures can be made for the CNG technology too. Like CAPI and its implementing Cryptographic Service Providers, CNG can be used as an additional abstraction layer between applications and the PC/SC interface simplifying the communication with the smart card from the applications’ point of view. The main drawback of this technology is its restriction to Microsoft Windows Vista based systems, which reduces this technology’s potential to be integrated in a platform independent solution.
2.2.1.3 PKCS#11
2.2.1.3.1 Description
STORK-eID Consortium Page 7 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
The Public-Key Cryptography Standards (PKCS) are a set of specifications produced by the RSA labs in cooperation with developers of secure systems of the entire world. The purpose was to speed up the implementation of public key cryptography [26]. These documents are so important that many of the specifications defined in them became in fact real standards like for example S/MIME and SSL. One of these specifications, being the most relevant one for the purpose of this deliverable, is PKCS#11 – the Cryptographic Token Interface Standard. It specifies a platform independent API denominated Cryptoki for devices capable of processing and storing cryptographic information (e.g. cryptographic smart cards) [27]. This API follows a simple object based approach (i.e. the information stored inside the device is treated for example like a normal Java object). Always having in mind the technology independency, resource sharing and presenting to applications a logic and common perception of smart cards. PKCS#11 defines the most commonly used cryptographic objects to be stored in a smart card (RSA keys, X509 certificates, DES/Triple DES Keys) as well as all necessary functions to create, alter, and delete those objects. With PKCS#11 any developer can create and manage his cryptographic objects in any arbitrary way. This creates portability problems for applications. To avoid this problem, the PKCS#15 standard [28], basically representing a standard for file structures, was developed by RSA. Due to this standard, applications that are PKCS#15 aware can communicate with any card that is implemented following PKCS#11 and PKCS#15 standards.
2.2.1.3.2 Analysis At the moment, PKCS#11 is the de facto standard in use for any cryptographic token. It was thought to be platform independent and although Cryptoki is a C implementation, PKCS#11 is so well disseminated and accepted that wrappers exist in most currently used languages (e.g. Java, Python, etc.). This acceptance and almost total platform (and programming language) independency are huge advantages of PKCS#11. The need to implement PKCS#15 in order to achieve application independency is one of the disadvantages of this standard. Another disadvantage is the fact that for several card vendors the developer will need the dynamic link libraries implementations of PKCS#11 for each particular vendor. In case the developer has access to those libraries and can correctly identify the card in question, this is no longer a problem.
2.2.1.4 PC/SC
2.2.1.4.1 Description PC/SC [25] is another well disseminated standard. It was created by the PC/SC Workgroup in order to provide the necessary interoperability that enables the effective use of smart card technology in computer-based applications. This motivation arose because the use of smart cards on computers was hampered due to the lack of interoperability at various levels/layers, like for instance [29]: • The solution to fix the interoperability problems of interfacing different cards from different vendors at the application level led to increased costs for both the level of development and maintenance of the software. • The lack of a high-level API that enables the encapsulation of the basic features of the cards.
STORK-eID Consortium Page 8 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
• Lack of implemented mechanisms that allow resource sharing of a smart card by several applications. These mechanisms are impossible to develop without the existence of an accepted standard. Due to these requirements, the PC/SC standard for smart cards was developed by several cooperating companies in order to create a standard for communication/manipulation of smart cards. Later, several others IT and smart card leading companies joined the PC/SC Workgroup.
2.2.1.4.2 Analysis Due to the significant global presence of the companies (Microsoft, current Gemalto, Toshiba, etc.) involved in the development of this standard, it has rapidly become the most used standard for communication with smart cards. Its most important layer, the Resource Manager [30] is native to most modern OS (Windows, Mac OS, and UNIX/Linux) so it is also platform independent. It’s the second most bottom layer of smart card application architectures and at this level the most widely spread and mature solution.
2.2.1.5 ActiveX
2.2.1.5.1 Description ActiveX [35] [36] (formerly known as OLE controls) from Microsoft is a technology developed for resource sharing between applications. It can be used for example to share a MS Excel graphs with MS Word. ActiveX or better ActiveX Control uses several programmatic elements to interact efficiently with a control OLE container and with the user [37]. The technologies are Microsoft’s answer to Java Applets in a way that it can be automatically downloaded and executed by the Internet Explorer Web browser [36]. Unlike Java Applets, however, ActiveX controls have full access to Windows. This gives them much more power than Java Applets, but with this power comes a certain risk that the ActiveX control may damage software or data on the machine. To control this risk, Microsoft developed a registration system so that the IE Web browser can identify and authenticate an ActiveX control before downloading it [40]. Another concern in the scope of this deliverable with ActiveX is the fact that it’s only compatible to Microsoft systems/solutions by default (Windows, IE), and for Mac OS with IE for Macintosh. Microsoft is planning on support UNIX based systems also [38] [39].
2.2.1.5.2 Analysis ActiveX is a very powerful technology. The unlimited access to the computer resources makes it extremely flexible but also dangerous. It is not browser independent (supported by IE and a few others through plug-ins only), which causes severe limitations when it comes to a multiplatform solution. There is support for Mac OS but that support is intrusive as users might not be willing to install IE or other browsers in their systems. For UNIX/Linux the support is in a planning stage at the moment and not readily available yet. However, due to the long period of time, in which ActiveX has been available for Windows-based systems only, many of the available ActiveX components depend on particular Windows components. In order to ensure compatibility with alternative platforms, these components of the Windows operating system would have to be emulated. This would result in major implications for the achievable performance and robustness of solutions that are based on this technology.
STORK-eID Consortium Page 9 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
2.2.1.6 Java Applets
2.2.1.6.1 Description A Java Applet [31] is a program written in the programming language Java that can be included in an HTML page in the very same way as for instance an image can be included. If the used Internet browser has the necessary plug-in to execute the Applet embedded in some Web page, the Applet code (i.e. a .jar file) is downloaded and executed by the Java Virtual Machine (JVM) integrated in the browser. They are used to provide interactive possibilities/characteristics to Web applications that couldn’t be accomplished by the HTML alone. Since Java Applets are available in byte code [32] (in the .jar file), they are also platform independent. But since the required plug-in [33] to run the Applets needs to be installed in the browser, they become instead browser dependent. Although the plug-in can be installed in most of the actual browsers (IE, Firefox, Opera, Safari, etc.) it isn’t a default characteristic of them. Like other technologies that run in a browser (Microsoft Silverlight, Adobe Flash), Java Applets are executed in a sandbox [34]. With the user permission it can run outside that sandbox and access system resources, like for example, in this deliverable’s scope, smart cards.
2.2.1.6.2 Analysis Due to the possible integration in most of the commonly used browsers (after the installation of the plug-in), a Java Applet is platform independent. It can also be executed (with the user permission) outside the context of the sandbox. Being embedded in HTML, Java Applets are very easy to be manipulated and configured, as passing parameters and options through the HTML is very simple. The main disadvantages of a Java Applet come from the performance side. The first time an Applet is accessed it has to be downloaded and the VM has to be started. In subsequent accesses to the Applet this is no longer the case because the Applet stays cached in the system and the VM already started. Further, the required download and installation of a plug-in in the browsers is a disadvantage regarding the minimal-footprint constrained defined in the scope of this document. Last but not least, Java Applets might have special requirements regarding the version of the needed Java Virtual Machine. Thus, a solution that is based upon the Java Applet technology should provide facilities to check the available configuration on the user’s local system, in order to avoid malfunctioning due to an installed Java VM that is incompatible to the provided Applet.
2.2.1.7 JavaScript
2.2.1.7.1 Description JavaScript is a powerful script language that has been originally developed by Brendan Eich for the Netscape Navigator Web browser in 1995. One of the initial ideas was to provide an interface to Java Applets called LiveConnect [5]. Amongst others, the script language supports dynamic typing as well as object-oriented, procedural, and functional programming. Being available for Netscape Web browsers only in the beginning, JavaScript is nowadays standardised in the ECMA-262 standard [6] and can be interpreted by nearly all common Web browsers. Although JavaScript has been originally designed to be used in the context of Web browsers, there exist also several other fields of application nowadays. For instance, the script language is also used for the dynamic modification of PDF documents, for the automation of several applications like Adobe Photoshop [7] or InDesign [8], or as script language within computer games. However, the main field of application is still the World Wide Web, where JavaScript is
STORK-eID Consortium Page 10 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009 used for so called DOM scripting. Although JavaScript is mainly used on clients that interpret JavaScript code included in HTML files, also server based JavaScript applications are possible. JavaScript can be used in Web browsers for the validation of form inputs, frame handling, roll- over effects, banners, and tickers. Additionally, it supports the manipulation of Web sites using DOM, or the sending and receiving of data without the need to reload the entire Web site. Unfortunately, the diverse powerful capabilities of this language have also led to an abuse of this technology. For example, it is possible to hide link addresses, to deactivate context menus or to create pop-up windows using JavaScript. These annoying features have significantly decreased the acceptance of JavaScript in several user groups, resulting in the fact that these users do not allow JavaScript code to be interpreted by their Web browsers any more. The security of JavaScript is based on the sandbox principle, which means that the scripts are interpreted within a closed environment. For instance, no opportunity to access the local file system is provided by this language. Furthermore, several actions like closing browser windows or reading the Web browser history require a decided confirmation of the user. There are several libraries available to increase the basic functionality of JavaScript. For instance, Adobe Spry [9] and the Dojo Toolkit [10] provide Ajax functionality in order to build Web 2.0 sites using JavaScript. Other examples of available JavaScript libraries are the Yahoo! User Interface Library (YUI) [11], or Ext-JS [12]. Mozilla based Web browsers provide a special JavaScript object, which may be interesting in the context of this document. The “crypto” object [13] allows access to several cryptography related services. Using this object, it is even possible to listen for and to react to a certain set of smart card events.
2.2.1.7.2 Analysis JavaScript is a powerful script language being commonly used nowadays. Beside its advantage to be based on an open standard, there are several unsolved problems that aggravate a contribution of this technology in the development of an appropriate OSS minimal-footprint architecture. Due to the suspiciousness of several users regarding JavaScript, it cannot be assumed that a software solution based on this technology is applicable on all target systems. Due to the inherent sandbox principle, on which the security of JavaScript is based on, full smart card access cannot be provided by this technology. As limited capabilities are available for Mozilla based browsers only, an OSS middleware solution based on JavaScript would not be able to ensure browser independency. Finally, there exists also a set of known security attacks that are based on JavaScript based browser error exploits. Thus, this technology does not seem to be capable to provide a sufficient degree of security in order to ensure reliable and secure middleware solutions.
2.2.1.8 Adobe Flash
2.2.1.8.1 Description Adobe Flash [14] has been originally invented by Macromedia and represents a proprietary integrated development environment (IDE) for the design and creation of multimedia content. In 2005, Macromedia has been taken over by Adobe, which has maintained the product Flash since then. Using the Adobe Flash IDE, users are able to create Flash movies, which can be embedded in ordinary HTML sites and viewed using an appropriate Flash player plug-in. According to the vendor, more than 95% of all users in the world have this plug-in installed [15]. Beside the mentioned Flash IDE, there exist several other tools that can be used to create Flash movies. For instance there is a PHP module called Ming [16] available that allows the creation of
STORK-eID Consortium Page 11 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Flash files. Flash Movies can also be generated using third party software like Impress or the graphics tool Draw from the Open-Office suite [17]. All graphics in the created animations are completely vector-based, which results in a better scalability of high quality and reduced memory requirements. Furthermore, Adobe Flash is a streaming format, i.e. the playback of movies can already been started before the entire file has been loaded. Flash uses the Real Time Messaging Protocol (RTMP) to stream movies over the Internet. The main field of application for Flash is the visualisation and presentation of multimedia content like interactive tutorials etc. With the release of Version 4 in 1999, Flash was extended by ActionScript, enabling developers to create complex interactive Web sites and even the programming of browser based applications. ActionScript is an event-oriented script language and based upon the ECMA-262 standard. It is part of the available integrated development environment and is interpreted by the installed Adobe Flash player plug-in. There are several alternatives to Flash, providing similar functionality. One competing product from Microsoft called Silverlight will be described in Section 2.2.1.9 in more detail. Another coexisting technology is the open standard Scalable Vector Graphics (SVG), which in contrast to Flash allows modifications on already published files too. However, this standard is hardly supported by any browser and there are hardly any common development tools available. Another powerful alternative of Adobe Flash is the Java Applet technology being described in more detail in Section 2.2.1.6. Basically, all of the features offered by Adobe Flash are provided by Java Applets as well. Anyway, due to the high-grade specialisation of Flash on presentation and visualisation, this technology is more efficient in these fields of application than the less specialised Java Applet technology. Furthermore, the Adobe Flash browser plug-in is usually loaded faster than the Java plug-in that is required by the Java Applet technology. On the other hand, there are several drawbacks the Flash technology is suffering from. First, Flash is a proprietary product that is not based on any open standard. Further, it requires a browser plug- in on each client in order to work properly. This plug-in is available for the most common, but not for all platforms. Finally, the main problem of the flash technology in the context of this document is the fact that neither Flash nor the included ActionScript seem to provide any possibility to access smart cards directly or through an abstraction layer.
2.2.1.8.2 Analysis The main intention of the Flash technology is to provide a tool for the efficient creation of Web based presentations and visualisations. Although Flash has been extended by ActionScript in order to provide means for data processing as well, the focus of this technology still lies more on the presentation of data than on its processing. Thus, several required features that would be needed for an integration of this technology in OSS middleware architectures cannot be provided. Finally, the fact that Flash is a proprietary technology and its need for an appropriate plug-in on each client are further drawbacks of this technology.
2.2.1.9 Microsoft Silverlight
2.2.1.9.1 Description Microsoft Silverlight [18] is a Web presentation technology invented by Microsoft in 2006 and aims to become one of the most competitive alternatives to the Adobe Flash technology that has been described in Section 2.2.1.8. Like Adobe Flash, Microsoft Silverlight has been designed to support developers in creating graphically demanding Web presences. Similar to Adobe Flash, a browser plug-in is required to display Silverlight content properly. While Flash uses its own ActionScript in order to implement the program’s business logic, JavaScript can be used for Silverlight 1.0.
STORK-eID Consortium Page 12 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Like Microsoft’s Windows Presentation Foundation (WPF) technology [19], the Microsoft Silverlight technology is based upon the Extensible Application Mark-up Language (XAML) [20], which may be used to describe graphics in XML style. Thus textual content being prepared with Microsoft Silverlight is easier to be indexed by search engines than that being created with Adobe Flash. With the release of Microsoft Silverlight 2.0 this technology has been equipped with several new features. The most important difference to its predecessor version is the support of the .NET technology, which enables developers to write code for Microsoft Silverlight in any .NET language. More information regarding the .NET technology is provided in Section 2.2.1.10 of this document. However, for security reasons Microsoft Silverlight code runs in a sandbox making the invocation of platform APIs impossible. Compared to Microsoft Silverlight 1.0, the newly released version provides much more functionality including restricted access to the file system, i.e. read access to files being selected by the user, but similar to the Adobe Flash technology, Microsoft Silverlight does not seem to provide any opportunities to access smart cards on the local system.
2.2.1.9.2 Analysis Compared to Adobe Flash – its main competitor – Microsoft Silverlight is a rather new technology. Thus, its current degree of distribution is much lower compared to Adobe Flash. Together with the fact that Microsoft Silverlight requires a browser plug-in in order to work correctly, this is one of the main drawbacks of this technology. Another problem is that Microsoft Silverlight is not compatible with all platforms and browsers. So far, only the most common Web browsers on Microsoft Windows based systems are able to display Microsoft Silverlight content correctly. For Linux distributions, a compatible third party runtime called Moonlight [21] is under development. The lack of possibilities to access smart cards with the Microsoft Silverlight technology is another reason that makes it difficult for this technology to be able to contribute to possible minimal- footprint middleware architectures. Last but not least, like Adobe Flash Microsoft Silverlight is a proprietary technology, which is another drawback in the context of an OSS middleware solution.
2.2.1.10 .NET
2.2.1.10.1 Description The software platform .NET [22] has been developed by Microsoft and comprises a runtime environment called Common Language Runtime (CLR), an application programming interface (API), and several associated services. The entire framework is available for Microsoft Windows based systems only. However, there are several projects in progress, which have the goal to port the framework to UNIX based systems as well. The .NET technology aims to replace older technologies like the Windows Component Object Model (COM) and provides easier facilities to access the functionality of the underlying operating system. The .NET framework makes use of the so called Interop-technology that guarantees that older COM based programs and components can be used by the .NET framework and vice versa. By implementing the Common-Language-Infrastructure Standard, the .NET framework provides the opportunity to run byte code resulting from the compilation of source code being written in different programming languages. As all these languages compile to the same byte code, this intermediate interpretable language is called Common Intermediate Language (CIL). This CIL is finally interpreted by the .NET framework’s Common Language Runtime. Regarding security, the .NET technology uses several mechanisms to ensure for instance the authenticity of software manufactures, and the integrity of programs. Other security mechanisms target the point of origin as well as the point of program execution.
STORK-eID Consortium Page 13 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Since the .NET technology supports software development using different programming languages, this framework is rather powerful and enables developers to create a variety of applications including Web services and Web applications.
2.2.1.10.2 Analysis While other investigated technologies like Adobe Flash or Microsoft Silverlight suffer from limited capabilities to access certain relevant resources like smart cards, Microsoft’s .NET framework is a powerful technology with few limitations. However, the main drawback of .NET is its restriction to Microsoft Windows based systems. Although there are several attempts to make this technology available for other technologies as well, the results of these aims cannot yet satisfy the high requirements imposed by the goals of this document.
2.2.1.11 OpenSC
2.2.1.11.1 Description OpenSC [23] [24] offers a set of libraries and utilities for smart card access. Its main focus is on cards that support cryptographic operations and ease their use in security applications like e-mail ciphering, digital authentication, and digital signature. It implements the PKCS#11 API so it’s available to any application that supports this standard and has the particularity of also implementing the PKCS#15 standard (refer to Section 2.1.3). Thus, it aims to be compatible to any application that is PKCS#15 aware. Since OpenSC follows the PKCS#11 standard, all considerations about PKCS#11 apply to OpenSC as well. Additionally, also the characteristics of PKCS#15 apply to OpenSC. This technology is available as a C++ implementation on all main platforms (Windows, Mac OS, and UNIX/Linux) and already supports a high number of different cards from different manufacturers. One extra that comes with OpenSC is the fact that its API allows low level communication with PC/SC in a simplified manner. It supports APDU communication in a higher level of abstraction than the PC/SC technology, especially if we think in C++ programming language.
2.2.1.11.2 Analysis OpenSC is already used in smart card middleware architectures of several countries, like Belgium (eID), Germany (German ID Cards), etc. This is because it counters the disadvantages of PKCS#11 by implementing PKCS#15 and has native support for several cards (no need to load different DLL files during runtime for the supported cards). It encapsulates simple APDU communication, which increases the development level if we think in C++. The main disadvantage comes from the fact that it isn’t programming language independent, it’s implemented in C (version 0.11.6) and there aren’t any good wrappers for it. OpenSC is also available for Java but its underdeveloped comparing to the C version (actual OpenSC for Java version is 0.2.2). 2.2.2 Comparison of Competing Technologies Most of the technologies that have been investigated in Section 2.2 can be assigned to two main categories. Several examined technologies aim to provide capabilities to access smart cards in a more abstract way in order to ease the integration of smart card operations in higher level applications. These smart card abstraction technologies are compared to each other in Section 2.2.2.1 in order to reveal their pros and cons.
STORK-eID Consortium Page 14 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
The second set of technologies being examined in Section 2.2.2.2 covers all technologies that may be used in the context of a Web browser in order to enhance the capabilities of Web sites and Web applications. All relevant browser-based technologies are weighted against each other in Section 2.2.3 of this document in order to ease the selection of appropriate approaches.
2.2.2.1 Smart-Card Abstraction Technologies We start by looking to PC/SC before all the other technologies. This is because PC/SC is not in any way a competing technology of the remaining smart card abstraction technologies studied in this deliverable. It is in fact a lower layer of the complete architecture (and practically the unique option on that level). The other studied technologies all depend on PC/SC to access the smart cards placed on the readers. They can be seen as an encapsulation and automation of PC/SC API calls and they make the use of PC/SC transparent to the developer when it comes to cryptographic object manipulation. Moving to the other technologies, which are in fact competing with each other, they can be classified in three kinds: the Proprietary solution, the Standard and the Open Source Implementation of the Standard. The proprietary solution (CSP/CNG from Microsoft) is the less capable technology in terms of fitting the requirements of an OSS middleware. Not because it’s not a good technology but because it does neither meet the requirements of platform independency described in neither Section 3.1, nor the OSS goals. Thus, the solution has to be based on a standard that is widely accepted and freely implemented in all platforms. According to the analysis of the Section 2.1, it turns out that PKCS#11 seems to be the most appropriate solution. Together with OpenSC, PKCS#11 may be combined in order to benefit from diverse synergies. OpenSC is a PKCS#11 open source implementation with additional low level controls that allow the direct transmission of APDU commands to the cards. Since not all objects contained in smart cards are necessarily cryptographic objects defined in PKCS#11, the simplified C++ API of OpenSC allows a direct communication with the PC/SC layer allowing the direct manipulation of DFs (directory files) and EFs (Elementary Files, used to store for example public data in a smart card). It also has the big advantage of supporting PKCS#15, automatically storing the cryptographic objects in the cards according to that standard. The limitation of OpenSC comes from the fact that it is programming language dependent, since there are no known wrappers for it in other programming languages. Contrary, for the PKCS#11 C API named Cryptoki there are a lot of good tools to interact with it in a lot of programming languages.
2.2.2.2 Browser-based Technologies There exist several technologies being compatible to most common browsers and that enhance the set of features and capabilities of plain HTML. However, due to security reasons and due to the specialization of several technologies on certain fields of application, the capabilities of these investigated technologies are also limited as it has been shown in Section 2.2.1. The two most similar browser technologies that have been investigated are Adobe Flash and Microsoft Silverlight. Both technologies are specialized on the presentation and visualisation of especially prepared Web content that may be viewed in the browser using a certain plug-in. Both technologies do also provide means to implement some kind of program logic using different script and programming languages. In this context, the current version of Microsoft Silverlight shows a higher flexibility as it allows the usage of any .NET based programming language while Adobe Flash supports its own ActionScript standard only. While Adobe Flash is already widely spread and well known, Microsoft Silverlight still suffers from being a relatively new technology. For instance, the required plug-in to view Microsoft Silverlight based animations is not available for all browsers and platforms yet.
STORK-eID Consortium Page 15 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
The main drawback of both technologies is the fact that they provide no opportunity to access smart cards on the local system. Thus, both of these technologies cannot meet the requirements of minimal-footprint middleware solutions. In contrast to the technologies Adobe Flash and Microsoft Silverlight, JavaScript focuses less on visual effects but more on the general extension of the set of features being provided by Web sites. Although JavaScript code is executed within a so called sandbox in order to meet security requirements, some browsers support methods for limited smart card interaction. However, due to the restriction on a special class of browsers and due to the very limited set of smart card communication capabilities, JavaScript is not much more usable in the context of possible smart card middleware solutions than Adobe Flash or Microsoft Silverlight. Compared to JavaScript, ActiveX is much more powerful as it is not subject to the sandbox principle that restricts the capabilities of the JavaScript technology regarding access to the local system. In general, the ActiveX technology is a defined interface that can be used to provide functionality to other software components on the system independent from the used programming language. The technology being relevant for browsers is called ActiveX Controls and can be used to develop distributed applications using the local browser. Due to its nearly unlimited access to the local system, this technology is much more flexible, powerful, and also dangerous than all other browser technologies that have been investigated so far. That’s why for security reasons this technology is often deactivated in client systems, which complicates a possible use of this technology. While JavaScript is compatible to nearly all commonly used browsers nowadays, ActiveX is originally only available for Microsoft based products. Other browsers have to be enhanced by ActiveX manually through the installation of appropriate plug- ins. Like JavaScript, Java Applets are executed in a sandbox in order to protect the local system. However, in contrast to JavaScript and comparable technologies, signed Java Applets may use additional features allowing them to gain advanced access to the system they are being executed on. This way it is for instance possible for Java Applets to use the Smart-Card-IO API that enables communication with locally connected smart cards. While Adobe Flash, Microsoft Silverlight, and JavaScript do not seem to be powerful enough to meet the requirements of minimal-footprint middleware architectures, the ActiveX technology appears to be even too mighty and therefore not trustworthy to many users. The Java Applet technology seems to represent a reasonable compromise by providing more functionality than JavaScript or Adobe Flash while concurrently offering enhanced security mechanisms. 2.2.3 Technological Synergies and Architectural Solutions The different technologies that have been analyzed in Section 2.2.1 and compared to each other in Section 2.2.2 can be combined in order to obtain synergies that may be used for the development of minimal-footprint middleware architectures. The most promising synergies are described and analysed in the following sections in order to reveal their pros and cons.
2.2.3.1 ActiveX and CSP/CNG One technological synergy is given by combining the technologies ActiveX and CSP/CNG as being shown in Figure 2.2.1. The browser-based technology ActiveX controls could be used to access smart cards being connected to the local system through an appropriate CSP/CNG smart card abstraction layer.
STORK-eID Consortium Page 16 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Figure 2.2.1: Visualisation ActiveX and CSP/CNG
Although this approach is rather powerful due to the versatile functionality being provided by the ActiveX technology, this architecture suffers from several drawbacks. First, usage of the CSP/CNG smart card abstraction layer would require the installation of additional components, which counteracts the desired minimal-footprint approach. The more severe disadvantage of this solution is its platform dependency that restricts a possible application of this approach to Microsoft Windows based systems only.
2.2.3.2 ActiveX / JavaScript and PKCS#11 Contrary to the approach described in Section 2.2.3.1, the architecture being illustrated in Figure 2.2.2 uses the PKCS#11 smart card abstraction layer instead of the CSP/CNG technology. Beside the Microsoft Internet Explorer in combination with the ActiveX technology, also Mozilla based browsers could be included in this approach using JavaScript. However, other browser would still be incompatible to this solution. Even Mozilla based browsers would suffer from very limited capabilities to communicate with smart cards. The usage of the PKCS#11 technology would also require additional components to be installed on local systems in order to provide a correct functionality of this architecture, which is another drawback of this solution.
Figure 2.2.2: Visualisation ActiveX / JavaScript and PKCS#11
STORK-eID Consortium Page 17 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
2.2.3.3 ActiveX/JavaScript and OpenSC Comparing to Section 2.3.2, the introduction of OpenSC instead of PKCS#11 allows benefitting from advantages provided by PKCS#15 as well as low level control of APDU commands. However, this architecture cannot solve the main problems of the previous approach which are located in the two top layers.
Figure 2.2.3: Visualisation ActiveX / JavaScript and OpenSC
2.2.3.4 ActiveX In order to omit the required installation of additional components, the architecture shown in Figure 2.2.4 avoids the usage of a smart card abstraction layer. Instead, smart cards are accessed directly using the PC/SC interface. As this approach relies on ActiveX technology as well, this solution is applicable on Microsoft Windows based systems and browsers only. Other browsers could be extended by the required functionality through appropriate plug-ins.
Figure 2.2.4: Visualisation ActiveX
2.2.3.5 Java Applet and CSP/CNG In order to avoid platform dependency being the main drawback of the architecture described in Section 2.2.3.4, the approach being illustrated in Figure 2.2.5 uses Java Applet technology instead
STORK-eID Consortium Page 18 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009 of ActiveX. This makes this solution compatible to any browser that is supporting the Java Applet technology. However, this approach requires an additional component, i.e. the Java Runtime Environment, to be available on the particular system. Since CSP/CNG technology is used in order to access smart cards, this architecture is restricted to Microsoft Windows platforms too. Hence, this approach is not ideal either.
Figure 2.2.5: Visualisation Java Applet and CSP/CNG
2.2.3.6 Java Applet and PKCS#11 In order to remove the platform dependency being the main drawback of the architecture that has been described in Section 2.2.3.5, the CSP/CNG technology has been replaced by PKCS#11 in the approach shown in Figure 2.2.6. Again, the installation of a Java Runtime Environment is required for this architecture. Furthermore, appropriate PKCS#11 drivers need to be installed in order to be able to access smart cards. The main advantage of this approach is its de facto platform independency. This architecture is compatible to all platforms that are able to provide support for Java and PKCS#11.
Figure 2.2.6: Visualisation Java Applet and PKCS#11
STORK-eID Consortium Page 19 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
2.2.3.7 Java Applet and OpenSC The objective of this architecture is to further improve the technological independency of the approach shown in Section 2.3.6, this time at the application level (e.g. the Java Applet) by replacing PKCS#11 with OpenSC, which would provide PKCS#15. Besides the required installation of the Java Runtime Environment, there is no wrapper for OpenSC in Java, which would lead to extra effort in its implementation.
Figure 2.2.7: Visualisation Java Applet and OpenSC
2.2.3.8 Java Applet Similar to the architecture being introduced in Section 2.2.3.7, this approach relies on the usage of the Java Applet technology in order to guarantee platform and browser independency. Additionally, the architecture illustrated in Figure 2.2.8 does not use any smart card abstraction layer but communicates with the smart cards directly using the PC/SC interface. This requires a rather recent version of the Java Runtime Environment to work, but requires no further components to be installed.
Figure 2.2.8: Visualisation Java Applet
STORK-eID Consortium Page 20 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
2.3 Investigation of Possible Minimal-footprint MW-Architectures
2.3.1 Requirements of a Minimal-footprint Middleware Architecture The success of an eID middleware depends on several criteria. One of the most important criteria is the degree of acceptance that is shown to the provided solution by end users. The acceptance itself depends mainly on the usability that is provided by the offered product. Thus, the following points have to be taken into account in order to ensure that the chosen middleware approach satisfies all demands regarding usability.
2.3.1.1 Platform Independency Although Microsoft Windows based operating systems are widely spread throughout the entire world, there are a number of alternative platforms that have to be supported too in order not to discriminate a certain group of citizens. Besides for current Microsoft based systems like Windows XP or Windows Vista, at least support for the most common operation systems like Mac OS and diverse UNIX based systems should be provided by the final middleware solution. Unfortunately, some of the technologies being investigated in Section 2.2 are only compatible to a subset of all available platforms. Thus, the set of platform independent technologies that can be used in an OSS middleware approach is limited.
2.3.1.2 Browser Independency All considerations that have been made in Section 2.3.1.1 regarding different platforms have to be made for Web browsers as well. The Web browser is a crucial component of most e-government services as it usually acts as an interface to the user. For all platforms, there is a variety of browsers, which usually differ in the features they are actually supporting. Thus, offering a browser based solution of an eID middleware that is compliant to all browsers is even more difficult than providing platform independency. Nevertheless, in order to reach a high degree of usability, as many browsers as possible should be supported by the final implementation of the eID middleware.
2.3.1.3 Number of Components to be installed The middleware solution to be developed in this task should be easy to use for all user groups in order to ensure a high acceptance of the elaborated product. Like other software products, the developed solution has to be intuitive and easy to use. However, usability already starts at the installation of the particular piece of software. Thus, the solution being elaborated in this task should be a minimal-footprint middleware, i.e. as less components as possible should need to be installed on the target system. On the one hand, this requirement ensures that users with less or no technical skills are able to use the software. On the other hand, the minimal-footprint architecture guarantees that the developed product may also be used on systems, where the user does not have the particular right to install new software, which for instance allows the use of the software in Internet cafés. 2.3.2 Examination of Possible Solutions In Section 2.2.3 of this document, several architectural approaches using different technologies have been elaborated. Furthermore, in Section 2.3.1 a number requirements have been defined, which have to be fulfilled by minimal-footprint middleware architectures. The first requirement defined in Section 2.3.1.1 and to be fulfilled by an appropriate middleware solution is platform independency, which is crucial in order to provide an applicable solution for as many people as possible. Unfortunately, some of the technologies being investigated in Section 2.2.1 and used in some of the architectures being proposed in Section 2.2.3 are available on a limited set of platforms only. Most of the times, this applies to technologies that have been invented from Microsoft and which are restricted to their own Microsoft Windows based
STORK-eID Consortium Page 21 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009 platforms. In detail, the smart card abstraction technologies CSP and CNG are affected as well as the browser technology ActiveX. Thus, middleware architectures using these technologies would be applicable on Microsoft Windows based systems only and hence not satisfy the requirement of platform independency. Another requirement that has been defined in Section 2.3.1 targets the browser independency of possible minimal-footprint middleware architectures. Similar to platform independency, this requirement is relevant in order to ensure that the final middleware solution can be used by as many users as possible. Regarding the technologies contributing to the proposed solutions in Section 2.2.3, there are some, which are not able to meet this requirement. Again, the ActiveX technology is basically restricted to the Microsoft Internet Explorer Web browser only. Other browser may only get ActiveX enabled through the installation of some appropriate browser plug- ins. Similar considerations have to be made for the JavaScript technology too as limited access to smart cards using this technology is only available for Mozilla browsers. Therefore, architectures using these technologies are not able to meet the requirement for browser independency. Finally, the last requirement defined in Section 2.3.1 deals with the number of components that need to be installed on the target system by the user in order ensure a properly working of the proposed minimal-footprint middleware architecture. A high number of required components to be installed reduce the usability of the proposed approach and also the number of users that are able and willing to use the offered solution. However, any middleware solution being proposed in Section 2.2.3 requires one or more components to be installed prior to its successful use. At least a smart card reader and an appropriate PC/SC driver need to be installed on the target system in each scenario. Architectural solutions using an additional smart card abstraction layer require a CSP, an appropriate mini-driver, or a PKCS#11 driver to be installed. Java based solutions additionally need a Java Runtime Environment (JRE) to be installed on the system. Taking into account all these considerations, there is obviously no solution that is able to completely satisfy all requirements. All proposed architectures show some benefits but also several drawbacks when being compared with each other. However, the architecture being proposed in Section 2.2.3.8 seems to be one of the most suitable approaches. Due to the omitting of the additional smart card abstraction layer, no PKCS#11 or CSP/CNG components need to be installed on the target system. Furthermore, the use of the Java Applet technology provides a quite good platform and browser independency. The only drawback of this approach is the need for an installed Java Runtime Environment, which is basically the one and only precondition, the target system has to fulfil. A more detailed description of this minimal-footprint middleware approach is given in Section 2.3.3 of this document. 2.3.3 Design of a Minimal-footprint Middleware Architecture Based on the observations and conclusions that have been obtained from the previous sections, minimal-footprint architectures using Java Applet technology seem to be the most promising approaches. In the following, a possible middleware architecture using this technology is described. The proposed minimal-footprint middleware solution is based upon a distributed architecture. In general, it consists of a central server component that may be used by several clients and a local component being implemented via Java Applet technology. The two components implement different functionality. While the server component is mainly used for the communication with the requesting application and hence responsible for an appropriate transport binding and request processing, the local Applet component basically handles the communication with the smart card using the PC/SC interface. Figure 2.3.1 shows an overview of the entire architecture and illustrates the required steps to create a signature using this middleware approach.
STORK-eID Consortium Page 22 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Figure 2.3.1: Architecture of a minimum-footprint MW
In order to create a signature, the requesting online application sends an appropriate CreateXMLSignatureRequest to the client’s browser (1), which forwards the request to the OSS Middleware Server (2). The server processes the request and sends a Web site containing a Java Applet back to the browser (3). The loaded and started Applet immediately connects itself to the middleware server in order to receive the prepared CreateSignatureRequest containing all information that is required to perform the sign process (4). After the reception of the CreateSignatureRequest, the Applet connects to the smart card and sends the required APDU commands in order to sign the provided data (5). The result of the signing process is returned to the middleware server via a CreateSignatureResponse (6), where the middleware server generates an appropriate CreateXMLSignatureResponse based on the obtained results. This response is transmitted to the client (7), which further forwards it to the calling online application (8).
2.4 Summary
The goal of this study was to investigate new approaches for minimal-footprint middleware architectures, i.e. solutions that do not require additional components to be installed on the client. In this study, several technologies have been investigated and compared to each other. It has turned out that most of them suffer from certain drawbacks, which complicates a possible use of these technologies in future minimal-footprint architectures. Especially the defined requirements regarding platform and browser independency have shown the limits of many of the investigated technologies. Thus, it was difficult to find an architecture that can completely satisfy all requirements of an ideal minimal-footprint solution. However, application of the Java Applet technology in concert with the PC/SC interface without any intermediate abstraction layers like PKCS#11 has led to an adequate solution. The proposed architecture requires only a Java Runtime Environment to be installed on the local system but no additional software modules or further components. The developed architecture follows a distributive approach. While smart card access capabilities are implemented in a Java Applet running on the client’s browser, most of the remaining functionality is realised on a server component. Server and Applet communicate with each other using a specified interface.
STORK-eID Consortium Page 23 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
As all used technologies are de facto platform independent, this approach is basically able to fulfil all defined requirements.
STORK-eID Consortium Page 24 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
3 Proof of Concept of a Minimal-footprint Middleware
3.1 Introduction
In Section 2 several technologies have been investigated in order to determine their capabilities to contribute to a future minimal-footprint middleware solution. Based on the observations that have been made during these investigations, possible middleware architectures have been derived. The capability to meet the requirement of a minimal-footprint OSS middleware solution has been resolved of each developed approach. The most promising architecture has finally been extended to a solution that is able to act as de-facto browser and system independent minimal-footprint middleware. Based on the derived architecture, a demonstrator has been developed, which is compatible to eID cards of several European countries. In this section, the implemented demonstrator is described in more detail. Therefore, Section 3.2 focuses on the general architecture of the developed solution, while Section 3.3 illustrates the main features of the provided implementation.
3.2 General Architecture of the Middleware Demonstrator
Generally, the implemented demonstrator is based on the architecture being shown in Figure 2.3.1. This architecture follows a distributed approach by incorporating a server component as well as a Java Applet component. The implemented demonstrator is based upon a publicly available open source implementation. The server component of the demonstrator is realised as a web service, which runs on a state-of- the-art web container (i.e. Apache Tomcat) and provides a certain set of functionality to higher level applications. More precisely, the provided web service accepts several XML-based requests to access eID cards on the user’s local system. Thus, the server component of the realised middleware demonstrator is responsible for the proper communication with the requesting entity, which includes binding and XML processing facilities. The second part of the developed demonstrator, i.e. the Java Applet component, implements the access to the user’s smart card. Upon reception of an appropriate XML request, the Java Applet is loaded in the user’s browser and sets up a connection to the server component. The server component provides the necessary commands to the Applet, which finally accesses the connected eID card using Java’s SmartCard-IO library and the PC/SC interface. This way, the smart card can be accessed in order to perform signature operations on the card or to obtain data being stored on the token. The resulting data is finally returned to the server component, which prepares the obtained results and returns it to the calling application in a XML based format. The main advantage of this demonstrator is the fact that in principle it does not require the installation of any additional software on the user’s system. The only requirement is an installed Java 1.6 runtime environment in order to ensure that the smart card can be accessed correctly on the user’s local system. This makes this solution suitable for environments, where users have only limited access rights on the used system.
3.3 Provided Features of the Middleware Demonstrator
The implemented demonstrator of the developed middleware approach provides a frontend that can be used to send arbitrary text to be signed to the middleware. Figure 3.3.1 illustrates the provided web-based frontend.
STORK-eID Consortium Page 25 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Figure 3.3.1: Input frontend
This input form can be used to send a signature creation request to the middleware. Upon reception of this request, the user is redirected to another web site that contains the Java Applet, which is responsible for the smart card communication. Figure 3.3.2 shows the corresponding web site.
Figure 3.3.2: Java Applet
When the Applet is completely loaded and initialized, it requests the user to insert the smart card into the connected reader device. The Applet identifies the inserted token and displays the identification result by showing an appropriate flag. For example, inserting an Austrian citizen card causes the Applet to display the Austrian flag. Figure 3.3.3 shows the card identification process.
STORK-eID Consortium Page 26 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Figure 3.3.3: Card identification Since the private key that is required to perform the signature creation is protected, the Applet requests the user to enter the correct PIN. In case the PIN is provided correctly, the signature is created on card. The result is sent back to the middleware’s server component, which returns the result to the calling application. In this demonstrator, the success of the signature creation process is indicated by an appropriate web site the user is redirected to when the signature creation process has been finished successfully. This web site shows some of the most important results of the signature creation process. Figure 3.3.4 shows the web site that is displayed in case of a successful signature creation.
Figure 3.3.4: Result
STORK-eID Consortium Page 27 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
STORK-eID Consortium Page 28 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
4 Security Analysis of a Minimal-footprint Middleware
4.1 Introduction
In current smart card based systems, the approach to access these cards using some kind of middleware is commonly used. The middleware is usually a software component that handles the communication with smart cards being connected to the system and provides a defined interface for other applications to access the functionalities of the smart card. Within this work item, a demonstrator of an open source and open specification minimal-footprint middleware has been developed. The basic architecture of this demonstrator has been designed according to the outcomes of a study, which has been carried out beforehand. In this study, different technologies have been evaluated and compared to each other in order to determine their capabilities to contribute to minimal-footprint architectures. The term “minimal-footprint” refers to solutions for middleware approaches that do require no or only few additional components to be installed on the client system. As the proposed architecture, which has been implemented by the demonstrator, is mainly intended to be used in eID based applications, the security of the solution is of high relevance. The goal of this document is to evaluate the provided security in order to reveal possible risks. Following this introduction, Section 4.2 of this document introduces the architecture of the evaluated middleware approach. For this purpose, Section 4.2.1 focuses on the general architecture of the implemented demonstrator and sketches its fundamental functionality. In Section 4.2.2, all contributing entities and their capabilities to interact with each other are described. Subsequently, Section 4.3 focuses on the security analysis of the proposed architecture being implemented by the demonstrator. In this section, possible attacks on the architecture are outlined and different modes of operation supported by the demonstrator are described in order to determine their impact on the global security of the entire system. Finally, Section 4.4 compares the security provided by the newly developed minimal-footprint approach with solutions relying on a classical installation-based approach. The basic findings being obtained from this document are finally summarized in a conclusion.
4.2 Architecture of the Minimal-footprint Middleware
4.2.1 General Middleware Architecture The demonstrator being evaluated in this document is based on an architecture that has been designed according to the results of a precedent study. In this study, different relevant technologies have been investigated in order to evaluate their capabilities to contribute to possible minimal-footprint middleware architectures. It has turned out that most of the technologies suffer from diverse drawbacks that make an integration of these technologies practically difficult. Many of the investigated technologies are either platform or browser dependent or require the installation of additional software components, which decreases the capabilities of these technologies to be included in an open source and open specification minimal-footprint middleware approach. Due to the results of to the study, the demonstrator has been finally developed according to an architecture, which basically uses PC/SC and Java Applet technology to provide access to smart cards. The use of a smart card abstraction layer like PKCS#11 or CSP/CNG has been omitted due to the fact that these technologies are either platform or browser dependent or require additional software components to be installed on the client system, which infringes the requirements of
STORK-eID Consortium Page 29 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009 minimal-footprint architectures. Thus, the implemented middleware approach accesses underlying smart cards directly by using the PC/SC interface. Although the Java Applet technology also requires a Java Runtime Environment as an additional component to be installed on the local client, this technology has been chosen to be the best choice available. Figure 4.2.1 shows an overview of the general architecture that has been developed using the selected technologies and which has finally been implemented by the middleware demonstrator.
Figure 4.2.1: General Middleware Architecture
As illustrated in Figure 4.2.1, the architecture is based on a distributed approach. Requests to access smart card functionality are based on the Austrian Security Layer specification [41] and sent to the middleware’s server component via the particular client (1) (2). The server component processes the received XML based requests and redirects the client to a web site containing the Java Applet (3). The Applet is loaded and started by the client in order to enable it to connect itself back to the server component. After establishing a connection between server and Applet, the pre-processed request is transmitted to the client (4). In the following, the Java Applet performs the required communication with the locally installed smart card using the PC/SC interface. Depending on the received request, the required APDU commands are sent to the card in order to retrieve the desired data or to perform the required operations (5). The obtained results are then transmitted to the server component (6), which uses these data to create an appropriate XML based response according to the original XML request. This response is finally sent to the requesting application via the client (7) (8). 4.2.2 Participating Entities As it has been described in Section 4.2.1, the architecture of the implemented demonstrator is based on a distributed approach. This implies that several different entities participate in the general scenario described in Section 4.2.1. As the role of these entities is crucial for the security of the architecture that is to be investigated in this document, they are described in the following in more detail. Figure 4.2.2 illustrates the basic interaction of all participating entities.
STORK-eID Consortium Page 30 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Figure 4.2.2: Participating entities
4.2.2.1 User The user is the central entity using some kind of smart card enabled online application. The user represents the client system, which usually includes the browser that is used to access and communicate with the particular online application and the smart card reader being connected to the local machine. According to the distributed architecture being described in this document, the client also includes the Java Applet that is obtained from the middleware server and that is responsible for the smart card communication as well as for the user interaction.
4.2.2.2 Online Application Operator The online application is usually operated by a third party, e.g. a government institution, and is the entity that initiates smart card based operations. For example, the user of an online application can be requested to perform an authentication process using the local smart card. Thus, the online application is the entity that originally creates an appropriate request that has to be handed over to the used middleware.
4.2.2.3 Middleware Server Operator The middleware server being a key part of the entire minimal-footprint middleware architecture is a central component that can be principally used by an arbitrary number of clients. The server component basically provides a certain web service and accepts incoming XML based requests for smart card based operations. These requests are based upon the Austrian specification of the Security Layer [41] defining an interface between the middleware and applications. Upon reception of such a request, the middleware server performs an appropriate pre-processing of the request and is further responsible for the communication with the Applet running on the client and performing the desired smart card operations. The middleware server is usually operated by a third party, who is usually but not essentially distinct from the operator of the already mentioned online application.
4.2.2.4 Applet Provider As mentioned in Section 4.2.1, the Java Applet technology is used in order to perform smart card related operations on the local system. For security reasons, the capabilities of Java Applets are usually more restricted compared to normal Java applications in order to minimize security risks that can arise when Applets are loaded to and started on local systems. Hence, in order to allow Applets to access the PC/SC interface via Java’s Smart-Card-IO library, the respective Applet being part of the middleware architecture needs to be signed by an Applet provider. Additionally, the Applet provider’s signature ensures the integrity of the Java Applet that is loaded onto the client’s system. While the signer of the Applet is practically transparent to the client regarding the middleware demonstrator’s functionality, this role is very important in terms of security. Again
STORK-eID Consortium Page 31 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009 the Applet provider and the operator of the middleware server may be distinct from each other but can also be represented by the same party.
4.3 Security Analysis of the Minimal-footprint architecture
In Section 4.2.1 of this document, the basic architecture of the minimal-footprint architecture being developed and implemented by a demonstrator has been described. Based on the results of this analysis, different entities being part of the entire architecture and playing different roles in order to guarantee a correct functionality of the whole system have been identified. As the security of the entire architectures relies heavily on the relationships between these different entities, the links between these roles have to be investigated in more detail in order to identify possible security risks. 4.3.1 Possible Attacks This section sketches a possible scenario for an attacker in order to compromise the investigated middleware architecture. For that purpose, the main focus lies on the creation of signatures on the smart card using the mentioned middleware approach being a key operation, most security relevant applications are based on. Other features being optionally supported by the described middleware architecture like the reading of identity credentials being stored on accessed smart cards are less subject to possible attacks, as these credentials are usually protected by means that are out of the scope of this middleware solution. For example, the identity credentials being stored on the Austrian citizen card are protected by an electronic signature. In the course of signature creation, the visualisation of the content to be signed is one of the most crucial components of the entire architecture, as this data must be necessarily equal to the data that is finally signed by the connected smart card. For a hypothetical attacker, it would be a desirable scenario to be able to display content to the user that differs from the data that is actually signed. This would enable an attacker to get data, which has never been reviewed by the user, signed. Thus, the correct displaying of the data to be signed is one of the most sensitive features of a middleware in terms of security and has to be guaranteed on any account by a reliable middleware solution. The developed middleware architecture allows two different ways to implement this feature. Depending on the implementation, the relationships between the different entities participating in the entire middleware system have to be set to different levels of security. In the following, the two possible approaches are described and analysed in more detail. 4.3.2 Operation Mode “Visualisation by Applet” In this approach, the visualisation of the respective data to be signed is performed by the Java Applet. Thus, in order to trust the entire middleware to be able to produce correct signatures using the particular smart card, the user has to trust at least the loaded Applet. Figure 4.3.1 illustrates the relationships between the participating entities.
STORK-eID Consortium Page 32 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Figure 4.3.1: Trusted entities in operation mode “Visualisation by Applet”
As being shown in Figure 4.3.1, in this mode of operation, the only entity that has to be trusted by the user is the Java Applet Provider, since its signed component is responsible for the visualisation of the content to be signed. The user can evaluate the trustworthiness of the provided Applet by inspecting the signature of the applet. Thus, the Applet provider’s signature is the key element, on which security between user and applet provider is based on. It should be noted, that the signature of the Java applet is required even if the visualisation of the data to be signed is hypothetically done by another component of the architecture, as only signed Applets are able to use the Java Smart-Card-IO API in order to access locally connected smart cards. Therefore, the displaying of the content to be signed by the Java Applet does not cause any additional effort. Neither the middleware server operator, nor the online application needs to be trusted using the approach being described in this sub section. However, additional security enhancements like secured SSL/TLS connections to the remaining entities are of course possible. It is also conceivable that two or more of the entities being shown in Figure 4.3.1 are represented by one party. For instance, the operator of the online application could provide the Applet or operate the particular middleware server as well. Anyway, this would have a positive effect on the entire level of trust, but would not change the fact that in this mode of operation only the Applet provider needs to be trusted in order to ensure a reliable architecture. 4.3.3 Operation Mode “Visualisation by Server” In contrast to the mode of operation that has been introduced in Section 4.3.2, in this mode the visualisation of the content to be signed by the user is done by the middleware server component, which extends the set of entities that have to be trusted. Figure 4.3.2 illustrates the relationships between the single components of the entire architecture.
STORK-eID Consortium Page 33 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Figure 4.3.2: Trusted entities in operation mode “Visualisation by Server”
As being visualised in Figure 4.3.2, the set of entities that have to be trusted by the user is expanded by the middleware server operator as this entity is responsible for displaying the relevant content to be signed by the user. The authenticity of the middleware server can be verified using the SSL/TLS technology. Similar to the approach being introduced in Section 4.3.2, the Applet provider has to be trustworthy as well. The Applet needs to be signed anyways in order to ensure the required access to the Smart-Card-IO API that enables communication with the particular smart cards. Of course, two or more entities being sketched in Figure 4.3.2 can be optionally represented by one party too. For instance it is conceivable that the operator of the online application, which is originally initiating the smart card based operation, is also operating the appropriate middleware server component. However, in order to satisfy all security requirements, only the Applet provider and the middleware server operator need to be trustworthy. Of course, links to further entities, e.g. the operator of the online application, should be secured as well in order to enhance the level of trust to these participants. In case the operator of the middleware server and the Applet provider are represented by one and the same party, only this party needs to be trusted in order to ensure a reliable security of the entire architecture. 4.3.4 Implications on the Current Implementation The minimal-footprint middleware architecture that has been introduced in Section 4.2 allows two possible implementations being presented in Sections 4.3.2 and 4.3.3, respectively. Depending on the kind of implementation, different entities being part of the entire architectures have to be assumed to be trustworthy by the user. The current implementation of the previously developed middleware architecture – i.e. the demonstrator – uses the approach described in Section 4.3.3 of this document. The middleware server is used to display the relevant contents to be signed by the user. According to the considerations that have already been made in the previous sections of this document, this approach requires both the Applet provider and the operator of the middleware server to be trusted by the user. As described in Section 4.3.3, this trust is guaranteed by the Applet provider’s signature and the secured SSL/TLS connection to the middleware server, respectively.
4.4 Comparison to Installation-based Approaches
The intention of the developed minimal-footprint middleware approach is to provide an attractive alternative to pure installation-based local solutions. The benefits of the new approach include the provided platform and browser independency as well as the increased usability that is achieved STORK-eID Consortium Page 34 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009 due to the fact that basically no additional software components need to be installed on the client system in order to enable the proposed solution to work properly. However, an increased platform independency and usability must not decrease the degree of security that is provided by the particular solution. Therefore, it is necessary to compare the security being provided by the new developed approach with that coming with already known installation-based solutions. The security analyses of both the minimal-footprint middleware and the installation-based approach are based on the constrained that the used client system is not compromised by any malware. Installation-based middleware solutions are typically software components being installed and executed on the user’s local system. These programs are basically implementing two interfaces. One interface can be used by other applications that require access to smart cards being connected to the system via some kind of smart card reader device in order to communicate with the cards. The middleware uses the second interface to send commands to the particular smart card using a standardized protocol. This way the locally installed middleware acts as an additional abstraction layer between smart cards and higher level applications. As the entire functionality of the middleware is implemented in one single software component being installed on the user’s local system, all security basically relies on the user’s decision to trust this component. In contrast to the installation-based approach, the new developed and implemented approach uses a distributed architecture. Since some parts of the functionality are outsourced to a central server component, only a subset of the entire functionality is actually performed on the local machine. The exact set of functionality being outsourced to the server component depends on the chosen mode of operation. If the visualisation of the data to be signed is implemented by the Applet component as described in Section 4.3.2, the provided security is similar to that of an installation-based solution. Instead of trusting the application to be installed on the local system, the client needs to trust the Java Applet (i.e. the particular Applet provider) that is to be downloaded and started. In total, exactly one component needs to be trusted in each approach. Comparable considerations apply to the mode of operation being described in Section 4.3.3, which uses the server component in order to display the relevant data to be signed. In case the Applet provider and the operator of the middleware server are represented by one party, again only one party needs to be trusted by the client. Only if these two entities are represented by distinct parties, the client needs to trust both of them. In this case, the number of entities to be trusted is doubled compared to installation-based approaches. In any case, the required security can be achieved by application of appropriate protocols and technologies making the middleware based on the minimal-footprint architecture at least as secure as commonly used installation-based approaches.
4.5 Summary
In this document, the security provided by the demonstrator that has been developed within this work item has been analysed. The architecture of the middleware approach, on which the demonstrator is built on, has been investigated first in order to identify all participating entities. Based on this identification process, different possible modes of operation have been investigated in order to determine corresponding security issues. Finally, the security of the middleware approach that has been investigated in this document has been compared to the level of security being provided by an installation-based middleware solution. It has turned out independent of the mode of operation, basically the same security can be provided by the investigate minimal-footprint middleware architecture compared to commonly used installation-based approaches. The required security is ensured by the signing of the used
STORK-eID Consortium Page 35 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
Java Applet and – if required – by an appropriate SSL/TLS secured connection to the participating middleware server.
STORK-eID Consortium Page 36 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
5 Conclusions
Within this work item, possible solutions for future eID OSS middleware architectures have been investigated. Therefore, several relevant technologies have been examined first, in order to determine their benefits and drawbacks concerning their possible integration in eID middleware solutions. It turned out that most of the investigated technologies suffer either from platform and browser dependencies, or from the fact that these technologies require additional components to be installed on the target system in order to work properly. As these requirements are not acceptable for a minimal-footprint middleware approach, it turned out that the most appropriate architecture is basically based on the Java Applet technology. Being de-facto browser and platform independent, this technology meets the requirements of a minimal-footprint eID OSS middleware appropriately. By avoiding the use of an additional smart card abstraction layer like CSP/CNG or PKCS#11, the chosen approach requires only a minimum of additional components to be installed on the target system. Based on the chosen technologies, a middleware architecture has been developed that follows a distributed approach consisting of a Java-Applet component and a server component. While the latter on is responsible for the communication with the calling applications, the Java-Applet component is basically used to access the smart card on the user’s local system. In order to show the capabilities of the developed approach, a demonstrator has been built, which is able to communicate with several different eID cards including the Austrian, Belgian, or Portuguese eID cards. Although the functionality of the demonstrator is currently limited to signature creation operations, the demonstrator visualises the capabilities of the developed approach rather well. An integration of further cards is also possible. As eID cards are usually used in security-sensitive applications, the developed demonstrator has been finally subject to a security analysis. This analysis has focussed on the different entities, which participate in the proposed middleware approach. By sketching possible attacking scenarios and identifying entities that need to be trusted by the user, the provided security of the proposed solution has been examined. It turned out that depending on the implementation, the new developed approach can basically provide the same level of security than comparable installation- based middleware solutions. Thus, the minimal-footprint eID OSS middleware approach that has been elaborated within this work item has the potential to play an important role in future middleware solutions.
STORK-eID Consortium Page 37 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
References
[1] Cryptographic Service Providers (Windows), [http://msdn.microsoft.com/en- us/library/aa380245.aspx], (14.11.2008) [2] Cryptography Reference (Windows), [http://msdn.microsoft.com/en- us/library/aa380256.aspx], (14.11.2008) [3] CNG Features (Windows), [http://msdn.microsoft.com/en- us/library/bb204775(VS.85).aspx], (14.11.2008) [4] Fact Sheet NSA Suite B Cryptography, [http://www.nsa.gov/ia/industry/crypto_suite_b.cfm], (14.11.2008) [5] LiveConnect – MDC, [https://developer.mozilla.org/en/LiveConnect], (14.11.2008) [6] Proposed ECMAScript 4th Edition – Language Overview, [http://www.ecmascript.org/es4/spec/overview.pdf], (14.11.2008) [7] Adobe – Adobe Photoshop Family, [http://www.adobe.com/products/photoshop/family/?promoid=BPDEK], (14.11.2008) [8] Publishing software | Adobe InDesign CS4, [http://www.adobe.com/products/indesign/?promoid=BPDEI], (14.11.2008) [9] Adobe Labs – Spry framework for Ajax, [http://labs.adobe.com/technologies/spry/], (14.11.2008) [10] Home | The Dojo Toolkit, [http://dojotoolkit.org/], (14.11.2008) [11] The Yahoo! User Interface Library (YUI), [http://developer.yahoo.com/yui/], (14.11.2008) [12] Ext-JS – Client-side JavaScript Framework, [http://extjs.com/products/extjs/], (14.11.2008) [13] JavaScript crypto – MDC, [https://developer.mozilla.org/en/JavaScript_crypto], (14.11.2008) [14] Adobe – Flash CS3 resources, [http://www.adobe.com/support/documentation/en/flash/], (14.11.2008) [15] Adobe Flash Player Version Penetration, [http://www.adobe.com/products/player_census/flashplayer/version_penetration.html], (14.11.2008) [16] PHP:Ming – Manual, [http://at.php.net/ming], 14.11.2008) [17] www: OpenOffice.org – The Free and Open Productivity Suite, [http://www.openoffice.org/index.html], (14.11.2008) [18] The Official Microsoft Silverlight Site, [http://silverlight.net/], (14.11.2008) [19] Architectural Overview of the Windows Presentation Foundation Beta 1 Release, [http://msdn.microsoft.com/de-de/library/aa480177(en-us).aspx], (14.11.2008) [20] XAML Overview, [http://msdn.microsoft.com/en-gb/library/ms752059.aspx], (14.11.2008) [21] Moonlight – Mono, [http://www.mono-project.com/Moonlight], (14.11.2008) [22] .NET Framework Development Center, [http://msdn.microsoft.com/en- gb/netframework/default.aspx], (14.11.2008) [23] OpenSC Project, [http://www.opensc-project.org/opensc/], (14.11.2008) [24] OpenSC FAQ, [http://www.opensc-project.org/faq.html], (14.11.2008) [25] PC/SC Workgroup, [http://www.pcscworkgroup.com/specifications/overview.php],
STORK-eID Consortium Page 38 of 39
Work Item 3.2.5: eID OSS Middleware 09 November 2009
(14.11.2008) [26] Private Key Cryptography Standards, [http://www.rsa.com/rsalabs/node.asp?id=2124], (14.11.2008) [27] PKCS#11, [http://www.rsa.com/rsalabs/node.asp?id=2133], (14.11.2008) [28] PKCS#15, [http://www.rsa.com/rsalabs/node.asp?id=2141], (14.11.2008) [29] PC/SC Workgroup. Interoperability specifications for iccs and personal computer systems – Part 1: Introduction and architectural overview. Technical report, PC/SC Workgroup 2005 [30] PC/SC Workgroup. Interoperability specifications for iccs and personal computer systems – Part 5: Icc resource manager definition. Technical report, PC/SC Workgroup 2005 [31] Java Apllets, [http://java.sun.com/applets/], (14.11.2008) [32] The Java Virtual Machine, [http://java.sun.com/docs/books/jvms/second_edition/html/Introduction.doc.html#3057], (14.11.2008) [33] Java plug-in downloads, [http://www.java.com/en/download/manual.jsp], (14.11.2008) [34] Java Security Specification, [http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html], (14.11.2008) [35] ActiveX overview 1, [http://msdn.microsoft.com/en-us/library/aa280221(VS.60).aspx], (14.11.2008) [36] ActiveX overview 2, [http://msdn.microsoft.com/en-us/library/aa268948(VS.60).aspx], (14.11.2008) [37] ActiveX overview 3, [http://msdn.microsoft.com/en-us/library/aa268985(VS.60).aspx], (14.11.2008) [38] ActiveX browser compatibility, [http://support.mozilla.com/en-US/kb/ActiveX], (14.11.2008) [39] ActiveX in Mac OS, [http://www.mactech.com/articles/mactech/Vol.13/13.06/ActiveXControlsforMac/index.ht ml], (14.11.2008) [40] ActiveX security, [http://msdn.microsoft.com/en-us/library/bb250471.aspx], (14.11.2008) [41] Die Österreichische Bürgerkarte, [http://www.buergerkarte.at/konzept/securitylayer/spezifikation/aktuell/], (14.11.2008)
STORK-eID Consortium Page 39 of 39