Smart card middleware is a software component connecting a smart card with an application such as a web browser. In this article, Markus Hoffmeister and Klaus Schmeh describe the basics of smart card middleware technology and explain its relevance for electronic identity cards (e-ID cards). Finding an appropriate solution for an e-ID system is complex, because different operating systems, access interfaces as well as a number of e-ID-specific requirements have to be taken into account. Case studies will illustrate how some countries have implemented different smart card middleware solutions, for example the German e-ID card, which relies on a dedicated client.
Introduced in November 2010, the German e-ID card is more than just an identity document. Among other interesting applications it can also be used as a replacement for passwords when accessing web-based e-commerce and e-government platforms, to encrypt emails and digitally sign documents and to verify someone’s age. Due to the sensitive nature of the information stored on the card, access to data is restricted and controlled by means of digital certificates. Such all-in-one identity cards are not unusual. In fact, many other e-ID cards, for example the Malaysian Mykad, the Spanish DNIe, the Estonian EstEID, and all Arab e-ID cards1 also feature cryptographic functions such as authentication, data integrity protection and digital signatures. Over the coming years, virtually all electronic identity card systems will offer a similar functionality.
It goes without saying that cryptographic e-ID card applications for personal computing only gain wide-spread acceptance if they are available across all popular platforms. For this reason e-ID users need software connectors that enable communication between the e-ID chip and the respective applications, just like web browsers running on different operating systems (Windows, Mac OS, Linux). To connect the smart card to an application is where smart card middleware comes into play.
Different cryptographic card access interfaces
The technology on which smart card middleware is based is rather complex. Much of the complexity arises from the different operating systems themselves, but also from the fact that there are at least five different cryptographic card access interfaces (see figure 1). The most widely accepted one is PKCS#11, a platform-independent crypto interface supported by Mozilla Firefox, Lotus Notes and many other programs. PKCS#11 accepts high-level commands from applications for encryption, signature and similar tasks and leverages smart card middleware to map these instructions to the low-level interface of the card operating system in use.
PKCS#11’s two main competitors were designed by Microsoft. Both of them are integrated into Microsoft’s Windows architecture and therefore not platform-independent. The older access interface, Microsoft Crypto API (MS-CAPI) is not compatible with PKCS#11. MS-CAPI is available on all current Windows operating systems as well as prevalent in many Microsoft products such as Internet Explorer and Outlook. A crypto module accessible via MS-CAPI (for example a module controlling a smart card) is referred to as a Cryptographic Service Provider (CSP). With the release of Windows Vista, Microsoft introduced the successor to MS-CAPI called Cryptography API: Next Generation (CNG) with an entirely new architecture which includes an important feature enabling the integration of different smart card types using so-called ‘smart card minidrivers’. It is expected that CNG will gradually replace MS-CAPI over the coming years.
In addition to Microsoft, Apple Computers created a smart card interface of their own: ‘TokenD’, which is supported by Safari, Apple Mail and a number of other Mac applications. Furthermore, the International Standardization Organization (ISO) came up with yet another cryptographic card interface named ISO/IEC 24727. This specification has been adopted in the European Citizen Card standard. To complicate matters, there is no one-to-one relationship between PC operating systems and access interfaces, as PKCS#11 is used by applications on all three major platforms and ISO/IEC 24727 is also operating system independent.
Middleware for e-ID cards
Any government issuing e-ID cards with personal computer based applications has to make decisions on what kind of smart card middleware to use. For instance, if the issuing agency plans to provide a web portal with e-ID authentication and digitally signed e-government messages, Firefox users will expect PKCS#11 support, while Internet Explorer users will require access to the Microsoft interfaces, and Mac/Safari users need TokenD functionality. Another challenge for smart card middlewares is the variety of different card types. There are literally dozens of card types available on the market, all with different card operating systems, different file structures and different crypto support. Typically, an e-ID card operator will eliminate this diversity and implement a closed system in which normally only one card type – or possibly a second one to gain vendor independence – will be implemented.
However, smart card middleware is more than just a driver or connector. Additionally, it needs to provide management functions for tasks such as memory modification and PIN management. These functions are commonly made available to a user via a client interface (see figure 2). Due to the varied nature of the tasks to be performed on the smart card, at least two different management tools are necessary: one for users and one for administrators. The user version usually only enables very basic functionality such as PIN changes, while the administrator version provides all the necessary management tasks.
Establishing new functionalities and requirements
The basic functionalities have been around for many years and are implemented on many types of smart cards such as employee badges and bank cards. However, the growing popularity of e-ID cards is driving new functions, for example granting only partial data access to information stored on the card to ensure data integrity and confidentiality: an automated check-in kiosk should not be able to fully read all the data on an e-ID card and should only have access to non-sensitive data. Smart card middleware suitable for e-ID cards must take into account these access definitions by assisting in the certificate validation.
A special e-ID card requirement results from the ICAO-standardised MRTD protocols. The most promising MRTD protocol for personal computers – and therefore for smart card middlewares – is Password Authenticated Connection Establishment or PACE2. PACE securely transfers a PIN over a contactless connection, depriving an attacker any possibility of determining the PIN, even if its entropy is very low. PACE, which was developed by the German information security agency (Bundesamt für Sicherheit in der Informationstechnik or BSI) and adopted by ICAO, was first implemented in the German e-ID card. The protocol is appealing for computer applications because encryption and signature applications can use the secure channel it establishes between a device and the contactless card. Although so far only a few smart card middlewares support PACE because the majority of smart cards are still contact-based, it is, however, expected that PACE will gain popularity in the coming years.
In contrast to PACE, other ICAO protocols – including Basic Access Control, Extended Access Control and Active Authentication – are not relevant for personal computer applications and therefore not important for a smart card middleware to support. In fact, they are only used by control systems (for example at the border), which usually work with specialised hardware or with dedicated machines running applications that access the e-ID card directly.
Other e-ID-specific requirements pose different challenges. Some e-ID documents require several PINs (for example one for accessing personal data and another one for digital signatures), which currently are not commonly supported by standard smart card access interfaces. Additional requirements for digital certificates issued to control stations (authorisation certificates) are established, because many e-ID systems demand that only authorised terminals may access sensitive data on the card.
Case studies
The e-Passport as standardised by ICAO is the most popular electronic identity document in the world. Several hundred million copies have been issued, yet the market lacks any smart card middleware solutions, as the e-Passport is not meant for signing, encrypting or authenticating on a personal computer. Other e-ID cards without middleware access are the Chinese ID, used only for symmetric authentication which is impractical for online scenarios, and the (old) German and French health cards, which were merely used for storing information. In many other cases, such as the Serbian e-ID card, there is still too little public documentation on the exact usage scenarios.
Austria, Belgium and Finland
The Austrian eCard, which is actually a health card but can also be used as a citizen card, can be accessed via the usual interfaces. The eCard uses elliptic curve crypto algorithms, which are supported by very few smart card middlewares. The Belgian e-ID card, Belpic, can also be used via the popular access interfaces. As Belpic uses the more common RSA crypto system, finding eligible smart card middleware is easier than in the case of the Austrian eCard. The Finish electronic identity document Fineid started a decade ago with PKCS#11 and MS-CAPI support. According to the Fineid website the card has been expanded to support the TokenD interface on Macs.
Germany
The German e-ID card is a different case (see figure 3). The German government chose not to support open access interfaces (ISO/IEC 24272 is used, but not accessible by conventional applications). Instead, the card is only accessible with a special client named AusweisApp, formerly known as ‘Bürgerclient’. If a user wishes to sign on, a server-side application is necessary. This application sends a command to a dedicated e-ID-server, which in turn establishes a secure remote connection to the e-ID card via the AusweisApp. Applications supporting the German e-ID card not only need to be interoperable with the e-ID server, but also have to provide an authorisation certificate issued by an official certification authority. Due to the difficulty of faking these certification authorities, criminals will have very little chance of setting up dubious services. These policies ensure that the e-ID card is only used by authorised applications.
However, the German approach has some disadvantages. As the AusweisApp is proprietary, no standard components can be used. Every user needs to install the software on his PC. Due to the diversity of different platforms, it might take years until the AusweisApp will be available for all relevant operating systems, including mobile platforms. Furthermore, the proprietary software precludes it from being used elsewhere, as there is no international interoperability. The AusweisApp is comparatively complex and therefore not suitable for platforms with restricted resources (for example embedded systems and mobile phones).
Conclusion
The German approach poses an interesting question: will relying on a dedicated client prove more effective than the traditional approach based on standard smart card middleware? Will this prevent users from widely adopting the card for use? Historically, almost all electronic identity card projects have suffered problems due to low user acceptance. Therefore, one thing is clear: user acceptance will play an important role in the competition between the two different middleware philosophies.
References
1 K. Schmeh, Elektronische Ausweisdokumente: Grundlagen und Praxisbeispiele, Hanser Verlag, 2009.
2 J. Bender, D. Kügler, “Introducing the PACE solution”, Keesing Journal of Documents & Identity, issue 30, 2009.
Markus Hoffmeister is CEO of cryptovision (www.cryptovision.com), a German company specialising in smart card and e-ID technology. The company’s product portfolio contains smart card middleware suitable for e-IDs as well as a Java Card Applet suite for implementing e-IDs.
