A New Secure Communication Framework for
Smart Cards
H. Karen Lu1, Senior IEEE Member, Asad M. Ali1, Stephane Durand2, and Laurent Castillo2
Gemalto, Inc., 1Arboretum Plaza II, 9442 Capital of Texas Highway, North, Austin, TX, USA
2
6 rue de la Verrerie, Meudon Cedex France 92197
email: {karen.lu, asad.ali, stephane.durand, laurent.castillo}@gemalto.com
Abstract— Smart cards have provided security services in
many domains over the past two decades. They should be able to
offer security services to the Internet and prevent online identity
theft as well. Having developed a smart-card-based solution for
preventing identity theft, we have found that it is very difficult to
push it to the consumer market. A common critical requirement
from both users and service providers is that smart card tokens
must be plug-and-play without any software installation.
However, conventional smart cards require installations of device
drivers and middleware on host computers. The key to solving
this problem is to develop a new communication framework for
smart cards. This paper presents such a framework that enables
USB smart cards to be plug-and-play. We leverage pre-installed
device drivers present in all modern computer operating systems.
A USB smart card emulates such devices to communicate with its
client software, which resides on the smart card and runs on the
host computer. The client software enables the smart card to use
a web browser for its human interface and to support web
applications. All communications among smart card services, the
web browser, and remote web servers are secured using TLS.
Keywords—Communication, Consumer-friendly security tool,
Portable device, Smart card.
I. INTRODUCTION
Internet security problems and online identity theft have
raised a lot of concerns for not only governments and
organizations, but also general consumers. One promising
solution is to use smart cards because they have successfully
provided security services in many other domains over the
past two decades. Figure 1 shows a smart card of a credit card
shape and size, and a smart card as a USB token.
Figure 1. A smart card and smart card token.
Smart cards are secure, portable, and tamper-resistant. They
have been used as subscriber identification modules (SIM) in
cell phones, cards for physical access to buildings and public
transportation, and tokens for logical access to computers and
networks. Smart-card-based solutions for preventing online
identity theft have also been developed. However, we have
978-1-4244-2309-5/09/$25.00 ©2009 IEEE
Authorized licensed use limited to: DELHI TECHNICAL UNIV. Downloaded on December 31, 2009 at 05:44 from IEEE Xplore. Restrictions apply.
found that it is very difficult to push smart card solutions to a
general consumer market in which people use computers for
online banking, shopping, social networking, and so on.
Consumers want convenience and usability as well as
security. Service providers want low cost solutions. A key
common requirement from both users and providers is that the
smart card token be plug-and-play without any software
installation, and without change of settings to host computers.
However, conventional smart cards do not satisfy this
requirement. They need installations of device drivers based
on the smart card’s communication standard [1] and
installation of middleware to enable computer applications.
Although SIM cards are in a consumer market, the required
drivers and middleware are pre-installed into cell phones.
Installing software may not be a major problem in controlled
environments, such as government offices and corporations,
but presents problems in uncontrolled environments, such as
homes and Internet cafes. Software installation is neither
convenient for users, nor easy to deploy for service providers.
The key to solving the above problem is the
communication. A smart card works with its client software or
middleware running on the host computer to provide a human
interface (HI) and to interact with other software on the host
computer and remote servers. Without a smart card device
driver, how should smart cards communicate? Without
middleware or client software, how should smart cards interact
with other software? A new communication framework must
be developed to allow smart cards to be plug-and-play. Over
the past ten years, researchers in the smart card industry have
made many efforts to solve this problem. (See Section II.)
However, for most computers in use today, smart cards are
still not plug-and-play.
This paper presents a new smart card communication
framework that enables USB-based smart cards to be plug-
and-play. For communication with the host computer, we
leverage pre-installed device drivers present in all modern
computer operating systems. A USB smart card emulates such
devices. Although these device drivers were not designed for
general purpose data communication, we define protocols over
them to achieve data communication. The smart card still
needs client software. To be portable, the client resides on the
smart card and runs on the host PC. The smart card and its
client secure their communications using encryption with
1
periodically renewed keys. The smart card also checks the
authenticity and integrity of its client periodically. With the
help of the client software, we can use a standard web browser
for smart card’s human interface, and the smart card can
support web applications. All communications among the
smart card services, the web browser, and remote web servers
are secured using TLS. When putting these techniques
together, a USB smart card can be plug-and-play and provide
security services to Internet applications.
II. RELATED WORK
Smart card companies have been working on network smart
cards that communicate with host computers and remote
servers using standard Internet protocols. One primary
objective of the efforts is to turn smart cards into plug-and-
play devices. A review and analysis for network smart cards
can be found in [2]. In the late 1990s, the WebCard [3] was
the first smart card that had a TCP/IP stack inside. The host
computer contained a tunnel device and a daemon to route IP
packets to and from the card through ISO 7816-4 APDUs [1].
Early in this decade, several smart card companies
demonstrated network smart cards with full TCP/IP stacks and
web servers inside the cards [4][5][6]. The USB network
smart cards are especially appealing due to standard Ethernet
over USB protocols, such as ECM and EEM [7]. However
deployment of network smart cards is hindered by the lack of
support from PC operating systems. None of the commercial
PC OSs includes Ethernet over USB drivers by default. Users
need to download these drivers and configure their PCs in
order to use network smart cards.
The CCID is a specification for smart card interface devices
published by USB-IF [7]. With a CCID driver installed on a
host computer, a CCID smart card reader enables a smart card
to communicate with a host computer without requiring
vendor-specific drivers. Recently, USB tokens with an
embedded smart card have been gaining popularity. Such a
token can implement CCID to act as a smart card reader. If the
CCID driver is already installed on the computer, the CCID
smart card token is plug-and-play. Although Windows Vista
has CCID driver installed by default; other operating systems
do not. It may take several years for the majority of PCs to
include smart card support. In the meantime, we need
solutions to provide plug-and-play smart card tokens without
card-specific support from computer operating systems.
III. FRAMEWORK
A smart card contains a secure and tamper-resistant
microprocessor chip. It has secure memories, serves
cryptographic functions, and contains security applications.
We focus on smart cards that have a USB interface. A recent
trend is to make a smart card in a USB token form, which
looks very much like a USB memory stick from the outside
(Figure 1, right). To use it, a user plugs the smart card token
into a USB port of a computer.
We can partition a smart card application into two main
logical components - Host Agent and Card Agent (Figure 2).
Authorized licensed use limited to: DELHI TECHNICAL UNIV. Downloaded on December 31, 2009 at 05:44 from IEEE Xplore. Restrictions apply.
The host agent is the client software, which runs on the host
computer. It enables HI to the smart card as well as
interactions with other programs on the host computer and
remote servers. The card agent resides and runs inside the
smart card. It keeps sensitive user data in its secure memory
and performs cryptographic operations that access the data.
USB MSD
interface
Host Card
Agent Agent
USB
communication Private Files
interface
Host Computer Smart Card
Figure 2. Partition into a host agent and a card agent.
To prevent software installation, we have the USB smart
card emulate a USB Mass Storage Device (MSD) [7] when it
is plugged into a host computer. The host agent resides in the
smart card and appears to be in the MSD (Figure 2). Many
computers support some kind of auto-run. In this case we can
configure the host agent to run automatically when the smart
card token is plugged in. If a host computer does not support
USB disk auto-run or disables it, a user can run the host agent
manually from the MSD of the smart card token. The smart
card may also emulate a CD-ROM to get around the USB
auto-run problem.
To avoid driver installation, the host agent must
communicate with the smart card using pre-installed drivers in
the host computer. For this purpose, we define communication
protocols on top of two pre-installed drivers that are not
designed for general data communication. In this way, the
framework does not require any new device driver installation.
Furthermore, the communication is secured using a symmetric
cipher to prevent eavesdropping. Since the host agent resides
on the smart card, the later can inject secrets to the former
before it runs. The secrets enable the host and card agents to
update encryption keys, and allow the card agent to
authenticate the host agent.
The host agent could provide human interface (HI) for a
user to interact with his smart card. A more attractive
approach is to use a standard web browser as HI. This has
several advantages: (1) easier to integrate smart cards with
web applications; (2) familiar human interface to users, and
(3) seamless user experience for web applications, such as
online banking, since a user does not need to consciously
switch between a smart card application and a web
application. To use a standard web browser as HI for smart
cards, the host agent contains an HTTP server. The web
browser and the host agent communicate using HTTPS.
To provide security services to Internet applications, such as
providing mutual authentication to web servers, and to enable
remote token management, such as software update, the smart
card needs to communicate with remote Internet servers. For
this purpose, the host agent contains one or more HTTP
2
clients, which communicate with remote servers using
HTTPS.
Figure 3 summarizes our new smart card communication
framework. This framework enables USB smart cards to be
plug-and-play without software installation, to provide
security services to Internet applications, and to leave nothing
behind on the host computer after usage. The next few
sections describe different parts of the framework.
Figure 3. The new smart card communication framework.
IV. COMMUNICATION BETWEEN HOST AND CARD AGENTS
Assume that the smart card has a full-speed USB interface
and the host computer has no CCID driver enabled. In order to
communicate and to achieve plug-and-play, the smart card
must use pre-installed USB device drivers that enable sending
data in both directions, require no software installation, and
need no administrator privileges to use.
After examining USB device drivers on typical computers,
we have found that only two USB protocols, Mass Storage
Class Device (MSD) and Human Interface Device (HID) [7],
can satisfy the above requirements. HID provides means for
low latency communication that a device initiates. A USB
keyboard and mouse are both examples of HIDs. However,
HID data throughput is capped at 64 KB per second with a
full-speed USB device. In contrast, MSD can reach the
maximum throughput of the bus (1.2 MB/s) with the same
device, but it has the lowest priority access on the bus and
behaves in a master/slave mode only. If a smart card had a
high speed USB interface, HID would be fast enough.
However, current USB smart cards only support full speed
USB; using HID alone would be inefficient. To take
advantages of MSD’s throughput and HID’s low latency, we
combine MSD with HID in the smart card. The resulting
communication model is both efficient and responsive.
To enable plug-and-play and communication, we have a
USB smart card enumerate two MSDs and one HID. The first
MSD is read-only, which stores computer-readable files. The
host agent resides on this MSD as described in Section III.
The host and card agents communicate via files using the
second MSD (Figure 2).
Authorized licensed use limited to: DELHI TECHNICAL UNIV. Downloaded on December 31, 2009 at 05:44 from IEEE Xplore. Restrictions apply.
Due to the master/slave operation mode of MSD, the host
agent must poll the card agent to see if it has anything to send.
Polling consumes computing resource and is not efficient. To
solve this problem, the smart card also enumerates an HID.
The card agent uses HID to signal the host agent when it has
data to send. The combination of MSD and HID achieves
peer-to-peer communication.
The computer file system is designed for storing, retrieving,
and managing files, but not for general purpose
communication. Therefore, to use files for communication, we
need to define higher-level protocols. On the one hand,
applications should not worry about details of the
communication; hence the communication protocol should be
application-independent. On the other hand, different
applications have different data transport requirements. For
example the transport requirements between a smart card and
an application on a local host are different from those between
the smart card and a remote server over the Internet. Some
applications may require ISO 7816 APDU as transport while
others may prefer standard Internet protocols. Some
applications require card user privileges while others may
require card administrator privileges. Therefore, an
application-dependent communication protocol layer is also
needed.
ALP: Application Layer Protocol
CLP: Communication Layer Protocol
File System HID: Human Interface
MSD: Mass Storage Device Device
USB: Universal Serial Bus
Figure 4. Communication stack
Based on the above requirements, our communication
protocols have two layers: the lower layer is called
Communication Layer Protocol (CLP) that is purely for
communication; the upper layer is called Application Layer
Protocol (ALP) that supports application protocols. The CLP
layer provides a secure communication channel between the
host agent and card agent, including key management and
diversification, host agent authenticity, data encryption, and
data integrity. Figure 4 illustrates the communication stack.
A. Communication Layer Protocol
The Communication Layer Protocol (CLP) combines a
MSD with a HID. It enables the host and card agents to
communicate securely and efficiently. Figure 5 illustrates the
inner workings of the CLP.
The host agent uses a CLP library to communicate with the
smart card. The CLP library accesses an input file and an
output file, which are both stored on an MSD presented by the
smart card, and responds to the HID signals sent by the same
device. The smart card communicates through a dedicated
CLP driver connected to MSD and HID device drivers.
To send data to the smart card, the CLP library writes to the
CLP output file through host computer’s file system calls. The
MSD driver on the smart card intercepts the low level write
request from the host and relays the data written to the CLP
3
layer to upper layer software. the smart card’s host agent related files stored on the first
To receive data from the smart card, the CLP library waits a MSD partition. The card management system uses ALP 3
HID signal from the device. This operation has no CPU cost commands to administrate the smart card, for example, to
since the USB hardware manages it. update a file in card’s internal secure memory. To protect the
integrity of the product, both ALP 2 and ALP 3 operate in
authenticated and encrypted sessions.
HID signal
C. Communication Security
The smart card communicates with its client software
CLP-enabled software

CLP-enabled software
CLP drivers on device
CLP device MSD running on the host computer to accomplish its tasks. The card
CLP library

volume and its on-card software are trustworthy. However, a user

CLP cannot fully trust his computer, which might have malicious
output file software running in it. The host agent on the computer is
initially trustworthy, but may be tampered by attackers later
CLP on. In this environment, the communication between the card
input file and its host side software must be secured; the card must
monitor the host side software that it communicates with.
Host Hence, the security tasks include (1) key management and
Transport over USB Device
software software diversification, (2) message authenticity, confidentiality and
integrity, and (3) client software authenticity and integrity.
Figure 5. CLP uses MSD and HID for communication. The CLP layer manages these tasks using the methods in [8].

To send data to the host computer, the smart card first V. COMMUNICATION WITH A STANDARD WEB BROWSER
readies the data in the CLP input file’s internal buffer, and
We use a standard web browser on a PC to provide human
then sends a HID signal to the host computer. Upon reception
interface to the smart card. The host agent implements a HTTP
of the HID signal, the CLP library reads the CLP input file
web server that serves the web browser and facilitates smart
through host computer’s file system calls. Once received the
card access. The communication protocol between the browser
low level read request from the computer, the MSD driver on
and the web server is HTTPS.
the smart card gets the data from the internal buffer and sends
To support TLS for HTTPS, the smart card maintains a
it to the computer.
RSA key pair and an x.509 certificate for host agent’s web
The CLP layer makes no assumption about data being
server. It keeps the private key in its secure memory, and
transmitted. A CLP frame consists of a 2-bytes header
stores the certificate and the public key in a MSD partition
followed by a payload. The header contains the payload
visible from the host computer. In this way, the web server can
length. The payload may contain one ALP frame or one
easily get the certificate during TLS handshaking.
command frame. Commands are defined for maintenance and
To achieve performance and maintain security, the host
management of the communication channels.
agent implements the TLS protocol in collaboration with the
B. Application Layer Protocol smart card. During the TLS handshaking, the host agent does
The Application Layer Protocol (ALP) enables applications computationally intensive work, including computing digest
to define or choose appropriate transport. An ALP frame and generating session keys; the smart card does security
begins with a 2 bytes header followed by its payload. The critical parts, including decrypting the pre-master secret
header contains information about the ALP type, payload (PMS) using the private key [9]. Once the handshaking
length, and if the payload is encrypted and/or compressed. completes, the browser and the web server in the host agent
Each ALP type represents a specific transport type, for communicate securely using HTTPS.
example, ISO 7816 APDU, HTTP, or TCP/IP.
The ALP types that we have implemented include: VI. COMMUNICATION WITH A REMOTE WEB SERVER
ALP Type 1 encapsulates ISO 7816 APDUs. It enables The smart card communicates with remote servers over the
reusing existing smart card operating systems and interfaces Internet for two general purposes:
for applications using an USB connection. 1. To provide security services to Internet applications; for
ALP Type 2 is used to administrate the MSD on the smart example, to authenticate a remote server before a user logs
card, for example, adding files to MSD. into the server, and to send the user data stored in the card to
ALP Type 3 transports card administrative commands. The the remote server securely when needed.
security mechanisms of this type use a PKI infrastructure that 2. To enable online token management after smart card
enables a higher degree of trust and security. This also enables tokens are issued to users; for example, to update the token
reusing existing smart card operating systems. software and to unblock the user PIN.
The ALP type 2 and 3 enable a remote card management The host agent implements a web client to initiate
system over the Internet to update the smart card software. connections to remote web servers. The communication
The remote system can generate ALP 2 commands to update protocol between the web client and a remote web server is

4
Authorized licensed use limited to: DELHI TECHNICAL UNIV. Downloaded on December 31, 2009 at 05:44 from IEEE Xplore. Restrictions apply.
HTTPS. For this purpose, the smart card maintains a RSA key
pair and an x.509 certificate for host agent’s web client.
Again, during TLS handshaking the host agent does
computationally heavy work and the smart card does security
critical ones, such as verifying the remote server’s certificate,
to achieve both performance and security [9].
Figure 6. An application example.
VII. EXAMPLE AND DISCUSSIONS
The communication framework presented in this paper has
been used in various projects. The Network Identity Manager
(NIM) is one example [10], which has been demonstrated in
security conferences and trade shows. NIM is a key fob-sized
USB token with an embedded smart card (Figure 1, right). It
enables a user to securely login to websites without entering a
username and a password each time. NIM thwarts many
online identity theft schemes, such as Phising and Pharming.
Figure 6 illustrates an example about how NIM uses our
communication framework to support login to remote websites
with mutual authentications. In the figure, the wide double-
arrow lines show various communication channels. The user
accesses his smart card through a web browser, which
communicates with the card through the http server in the host
agent. The user selects the website he wants to access. The
card authenticates the remote server through the HTTP client
in the host agent. After server authentication, the smart card
sends the user’s login credential at the website through the
HTTP server in the host agent and the web browser. Once the
user is authenticated, he can access the website through the
web browser.
The communication framework presented in this paper
executes well on several Microsoft Windows operating
systems. Although we have not done a formal evaluation, the
performance of our communication method is comparable
with other USB smart card solutions from the users’
perspective and is well enough to support interactive web
applications.
Operating system other than Windows may allow user-
space applications to install device drivers and may have other
USB drivers suitable for general data communications.
However, MSD and HID are common to all PC operating
Authorized licensed use limited to: DELHI TECHNICAL UNIV. Downloaded on December 31, 2009 at 05:44 from IEEE Xplore. Restrictions apply.
systems. Using them will enable a same smart card token be
plug-and-play on any PC regardless of the PC operating
system.
VIII. CONCLUSIONS
One of the key requirements for a security token in the
consumer market is plug-and-play without installation of any
software on the PC. This paper presents a new smart card
communication framework that enables USB smart cards to be
plug-and-play. The method relies only on pre-installed device
drivers that are included in modern computer operating
systems. Since these devices were not designed for general
purpose communication, we define new communication
protocols over the devices. The USB smart card emulates the
devices to communicate with the host computer using these
new protocols. The framework further includes methods for a
smart card to communicate with a standard web browser and
with remote Internet web servers. With this framework, USB
smart cards can achieve true plug-and-play and provide
security services to Internet web applications.
ACKNOWLEDGEMENT
The authors would like to thank Apostol Vassilev and Mike
Montgomery for their contributions to this work.
REFERENCES
[1] “Identification Cards – Integrated Circuit(s) Cards with contacts”, ISO
7816 standards.
[2] H. K. Lu, "Network Smart Card Review and Analysis," Computer
Networks, Volume 51, Issue 9, June, 2007.
[3] J. Rees and P. Honeyman, “Webcard: a Java card Web server,”
Proceeding of Smart Card Research and Advanced Application
Conference CARDIS’ 2000.
[4] M. Montgomery, A.M. Ali and H.K. Lu, "Secure Network Card -
Implementation of a Standard Network Stack in a Smart Card," Sixth
Smart Card Research and Advanced Application IFIP Conference
(Cardis), Toulouse, France, August 23-26, 2004.
[5] “Internet Smart Card”, Giesecke & Devrient, Available at:
http://www.us.gi-de.com/portal/page-
_pageid=42,54860&_dad=portal&_schema=PORTAL.htm
[6] “Oberthur Card Systems Launches SIMphonICTM WebSim at 3GSM
Congress,” Available at:
http://www.oberthurcardsystems.biz/press_page.aspx?id=159&otherid=
112.
[7] USB Device Classes, Available at :
http://www.usb.org/developers/devclass_docs/ .
[8] H. K. Lu and A.M. Ali, “Communication Security between a Computer
and a Hardware Token,” The Third International Conference on Systems
(ICONS), April 13-18, 2008 - Cancun, Mexico.
[9] A. M. Ali and H. K. Lu, “xID: A Flexible Architecture for Plug-n-Play
Smart Cards,” IASTED Int. Conf. on Software Engineering and
Applications, Cambridge, Massachusetts, USA, Nov. 19-21, 2007.
[10] “Online identity theft protection,” Gemalto, Inc.
http://www.gemalto.com/internet/.
5