Developing Applications for Windows for Smart Cards

This paper is part of a series of white papers known as " The Smart Card Deployment Cookbook."

On This Page

Deployment Remarks


This document describes the applications developed for a company called Hay Buv Toys (HBT). HBT, headquartered in Seattle, develops and sells the latest in technological toys. In addition to operating stores worldwide, the company has a Web site that customers can use to buy merchandise. HBT customers who shop online receive a personalized smart card to access the Web site and pay for orders.

In this scenario, the following technologies are used:

  • On card applications

  • Remote procedure call (RPC) or proxy calls of smart card application programming interfaces (APIs)

  • Cryptography

  • Authentication

  • Automated personalization of the cards

Although there are multiple ways to use Microsoft Windows for Smart Cards, such as with mobile phones, this scenario uses it for a smart card that connects to a standard PC reader (ISO 7810 form factor).


The HBT online ordering system is based on a smart card–based application, a client-based application, and a server-side application. The application has a Web-based user interface and server-side request processing.

The HBT control is instantiated by a client-side Microsoft Visual Basic script when a user accesses the Web site. This control can also be used by other client applications.

The following figure illustrates the client application and smart card.



On the HBT Web site, the user can choose between charging with the card or buying a product. When the transaction starts, the client application generates a random transaction ID that is stored on the smart card. The transaction ID is transmitted with all the other information to the server, which then processes that request. The server component analyzes the encrypted information from the client. If the server accepts this request, it encrypts the information together with the transaction ID and the result, and sends it back to the client, as shown in the following figure.


The client application, realized as an ActiveX control, decrypts the message with the Data Encryption Standard (DES) key from the smart card. The decrypted information is then used to manipulate the amount that is stored on the card. Whenever a method is called that changes the amount, the transaction ID on the card is reset. This prevents the user from using the encrypted message more than once.

The user authenticates access to the smart card by using a personal identification number (PIN). The smart card and the server application use the same DES key to encrypt and decrypt the data. In the future, HBT hopes to improve security by using stronger encryption, such as triple DES and by using private or public keys.


The system requirements for the client are:

  • Microsoft Windows 2000 Professional (Service Pack 1 or later)

  • Microsoft Visual Basic 6.0 (Service Pack 5 or later)

  • Windows Smart Card Toolkit 1.1 (Service Pack 1)

  • Hay Buv client control (HayBuvControl.ocx)

  • A smart card reader device

  • A smart card compatible with Windows for Smart Cards (see for vendors)

The system requirements for the server are:

  • Windows 2000 Server (Service Pack 1 or later)

  • Internet Information Services (IIS) 5.0

  • Visual Basic 6.0 (Service Pack 5 or later)

  • Windows Smart Card Toolkit 1.1 (Service Pack 1 or later)

  • Hay Buv server component (HayBuvServer.dll)


To install a new application on the smart card:

  1. Load the application on the smart card.

  2. Modify the SmartCard.xml file for the deployment tool.

  3. Personalize the smart card with the deployment tool.

To test the smart card installation:

  • Run the test tool.


The procedures required to set up the client are summarized as follows:

  1. Register the HayBuvControl.ocx ActiveX control.

  2. Insert the smart card with the payment application on it. The smart card must contain the common DES key as the server and other information.

  3. Modify the security settings of Microsoft Internet Explorer to allow running the ActiveX control.

  4. Test the installation.

The procedures required to set up the server are summarized as follows:

  1. Copy .asp and .dll files to the server.

  2. Create a new Component Services application, such as "Hay Buv Payment System."

  3. Register the HayBuvServer.dll component.

  4. Install this component in the Component Services application.

  5. Create a new virtual directory on IIS.

  6. Test the installation.


The following procedure represents a user's experience of using a smart card to make a purchase on the Hay Buv Toys Web site:

  1. Start Internet Explorer, and go the HBT Web site.


    In the initial window of the pilot, the Get balance option can be processed directly on the client. All other actions require a validation from the server.

  2. Click Connect to connect to the smart card reader.

    For security reasons, user authentication is required. In this pilot, there are two groups defined with different access rights:

    • Admin. Members of this group have full access to the file system and can change key files or update the application.

    • User. Members of this group have restricted access rights.

    In the pilot, there are two different users called Known Principals (KP), each with a six-digit PIN:

    • admin (PIN: 123456). A typical member of the Admin group.

    • user (PIN: 123456). A typical member of the User group.

    These security settings are part of the solution manager of the Windows Smart Card Toolkit and can be found at: \CompiledDiskImage\fsimage.txt

  3. In the Login dialog box, type your user name and PIN, and then click OK.


    After authentication, a transaction can begin. To do this, you need to select a different action to get a balance or to specify the amount.

  4. Click…type…, and then click Execute.


    The Confirm window appears and shows the information that the server received. The cipher text shows the encrypted response from the server. Cipher text covers the transaction ID, amount, action, and decision to accept the transaction or not. When the Confirm button is clicked, the balance on the card is processed and the result is sent to the server that can close the transaction.

  5. Click Confirm. The ActiveX control generates a random transaction number and stores it on the smart card.


    HBT developed a test tool for the pilot to simulate the client/server communication.


Deployment Remarks

Deployment of Windows for Smart Cards Applications

For the development phase, you can use special development cards. These cards have a flashable, electrically erasable programmable read-only memory (EEPROM) to test different operating system configurations and applications. These cards can be used for smaller deployments, but doing so poses a huge security gap. In larger deployments, production cards should be used. After the application is developed and tested, the manufacturer can install it on the development cards.

Deploying the developed applications in the enterprise is a big issue. For the pilot phase, it is appropriate to use development cards that are flashed by the solution manager of the Windows Smart Cart Toolkit. This uploads the Windows for Smart Cards operating system and the file system with the applet. To simplify deployment, you can use some of the following tools in the Windows Smart Cart Toolkit:

  • RFlasher.exe to load the operating system.

  • FSLoader.exe to load the file system image onto the smart card.

  • FSBuilder.exe to build the file system image.

For the HBT project, an additional tool is implemented to roll out the application together with personalized information on the customer cards. This tool obtains its information from an .xml file with the following schema:

<?xml version="1.0" encoding="ISO-8859-1"?>

During full deployment of the application, the manufacturer may provide the cards. These production cards should carry the most parts of the application in a non-flashable chip or in ROM. The developer decides how many parts of the system should be stored in ROM. For security reasons, the user should not be able to manipulate the application and the keys on the card, or even read the keys.

References (You must register at the Gemplus site in order to download this resource).

Microsoft Enterprise Services

Bertil Syamken: MCS Germany

March 2001

For information about Enterprise Services, see

Companies, organizations, products, people, and events depicted in examples in this paper are fictitious. No association with any real company, organization, product, person, or event is intended or should be inferred.