|
Printed
15-Mar-01 1
IP Smart Cards in the
(Not So) Distant Future
Thierry
Lamotte
Gemplus
Research Lab
Gemplus,
Parc d’Activites de Gémenos - B.P.100 – 13881 Gémenos
Cedex (France)
e-mail:
thierry.lamotte@research.gemplus.com
Abstract.
This
paper suggests that future smart cards should be designed to
communicate
using Internet protocols. A related implementation is
described. A
possible
architecture and some protocol standardizations are suggested.
Most
observers
believe that using Internet Protocol will bring substantial
benefits and
business
potential, yet other issues remain to be resolved. As the
Internet grows
at
a phenomenal rate, security concerns are becoming more
pressing. This paper
suggests
that smart cards could in the future offer the security
features that we
will
need in this global network. This new approach will become
possible in a
few
years when wireless communications use higher communication
rates,
smart
card chips are more powerful, the Internet Protocol v4 has
migrated to
Internet
Protocol v6.
1.
Introduction
We
will provide a brief overview of the history of smart cards,
Internet Protocol
(IP)
and interconnections between these technologies. We will
mention pertinent
work
that has been done in these fields.
1.1.
History of Smart Cards
Early
applications used stored-value memory cards, followed by smart
cards with
micro-controllers
to improve tamper resistance. Cryptographic algorithms,
protocols
and
keys were be stored on these microprocessor cards. The smart
card has since
become
the cardholder’s security device for identification in a
large-scale security
scheme.
This
does not mean that the smart card is the magic bullet of
digital security [16],
but
that it offers a combination of valuable features not found on
any other device so
small
size, portable, flexible and cost effective. These features
meet the needs of large
businesses
which usually target individual consumers.
Tdoc
SCP-010080 ETSI
Project Smart Card Platform Meeting #5
Palm
Springs, USA, 20 - 23 March, 2001
Printed
15-Mar-01 2
Years
ago the 7816-3 ISO standard [11]
defined T=0 and T=1 protocols. These
have
become the standard communication protocols for smart cards
with several
significant
limitations:
The
T=0 and T=1 protocols combine OSI layers 1, 2 and 4 in a
single layer,
The
smart card is always the slave in these protocols and the
transfer rate is
relatively
low,
The
smart card execution model is closely related the
communication model,
These
protocols are specific to smart cards.
We
expect to see far more powerful smart card chips in the
future, allowing
previously
impossible implementations. Following this development, recent
model
smart
cards have the resources to support advanced implementations
(e.g., virtual
machines).
1.2.
The IP World
The
phenomenal growth of today’s networks is evident. We use a
variety of digital
networks
(e.g., LANs) in our everyday lives. These networks, coupled
with the
client/server
model, are commonly used to transfer files, send e-mail and
share disk /
CPU
resources.
We
must say a word about the rapid growth of the Internet and its
vast potential.
Ordinary
people now use the Internet as a means of communication
alongside mail,
telephone,
and television.
The
feature shared by all these networks is the interoperability
of the protocol layer
(which
implements network features according the OSI [Open Systems
Interconnection]
model). The combination of Internet Protocol (IP)[10],
[8],
TCP/IP
(or
UDP/IP), and the socket has now become the de facto standard
throughout the
world.
Network layer IP normally ensures interoperability between
higher-level
local/distant
software applications.
Physical
transport can theoretically be implemented independent of the
network
layer.
It
must be noted that the current Internet Protocol IPv4 [10]
is moving to a new
release,
IPv6 [10],
[1]
which offers new properties, namely:
A
much larger addressing range,
Security
features [14]
to counter some of the known attacks under IPv4,
Printed
15-Mar-01 3
Improved
mobility to meet the needs of contemporary users.
Another
technological breakthrough, pervasive or ubiquitous computing,
is also
expected
to have a major impact. This will become increasingly relevant
as the global
network
is deployed and microchips become more powerful. Once again we
find that
security
concerns will be critical.
1.3.
Today’s Smart Cards and the IP world
Smart
cards have evolved on their own, largely untouched by network
technology
although
early standardization (T=1 proposal) included efforts to
introduce network
features[11].
1.4.
Related work
In
recent years, several organizations have been working toward
new technologies
and
implementations. Notable examples can be seen at the
University of Michigan
[13,15],
Mobile-Mind [3],
[4-7]Bull
CP8 [22],
Deutsche Telecom, Schlumberger and
Gemplus.
These
efforts have received little support due to lack of
standardization and current
technological
limitations. If major players set their mind to it, the
situation will
change
rapidly. In short, we believe that these technological
limitations will be
overcome
if there is a clear need for such applications.
2.
A Related Implementation
2.1.
Introduction
Gemplus
Research Labs have explored what implementing OSI-Layer-3
concepts
in
a smart card might actually imply. Here, we would like to give
some technical
details
and also the results of this implementation in a
recent-generation smart card: A
mid-range
smart card, the ATMEL AT90SC3232C.
2.2.
A Touch of TCP/IP in Smart Cards
Printed
15-Mar-01 4
We
chose to leave aside the current execution model of the smart
cards. We have
retained
the data link layer (OSI layer 1 and 2) which is strictly
compatible with ISO
7816-1,
2 and 3 since all of today’s smart card readers are ISO7816
compliant. The
smart
card execution model is similar to that encountered in
ordinary computers.
The
example below shows the internal structure of OSI Layer 1, 2
and 3
implementations
in the smart card:
System
Communication API
Resolution
Reception
Messages
Datalink
Transport
Protocol
I/O
Driver
IO1
& IO2
OSI
Layer 1 OSI Layer 2 OSI Layer 3
Route
Table
Emission
Message
Stack
IO#1
IO#2
Figure
1: Internal Structure of OSI Layers 1, 2 and 3
Such
an implementation is relatively similar to an actual IP
functional diagram [19],
[20],[21].
OSI Layer 1 runs asynchronously from any system module as does
OSI
Layer
2. It should be noted that OSI Layer 2 used only for two ISO
7816-4
commands,
notably Envelop
and
GetResponse
[12].
OSI
Layer 3 was experimental since we chose to create a smart card
sub-network
(a
daisy chain of smart cards) connected to a host platform
which, in turn, was
connected
to a common IP network (See Figure 2).
Printed
15-Mar-01 5
We
chose a much smaller Maximum Transmission Unit (MTU) than that
used in
an
actual IP layer in order to fit into the relatively small
memory and also, to provide
a
fair distribution of the bandwidth between different
communication channels.
The
system communication interface offers four generic entry
points:
Open
a communication channel()
The
application either declares a socket port number attached to
the channel or
negotiates
this socket number with the host platform. The application
also declares
the
type of the communication channel i.e. server or client. If
the communication
channel
is a client, it can connect to any IP address and port number.
Close
a communication channel()
Terminates
a previously-open communication channel.
Send
message over a communication channel()
An
application sends a message at any time to either a local or a
distant application
via
a previously-open communication channel.
Receive
message from a communication channel ()
An
application requests (waits for) reception of a message from
either a local or a
distant
application via a previously-open communication channel.
This
communication interface model is actually similar to the
socket layer
interface.
A
generic daemon running under the host platform obtains and
propagates all
smart
card channel operations to/from the IP network. This daemon
continuously
supports
a service attached to a fixed socket port number which in turn
provides the
list
of smart card services currently available (i.e., list of
service names and associated
socket
port numbers).
2.3.
Conclusion
This
simple implementation demonstrated the benefits of
implementing OSI
layer
3 above the common OSI Layers 1 and 2. Smart Card applications
could
generically
and seamlessly communicate with one another (loop-back
address). These
applications
can offer services to external applications connected to the
IP-enabled
world
(server model). They can initiate communications to external
applications that
are
connected to the IP-enabled world (client model). Smart Card
applications can
independently
open one or more communication channels. The smart card can
support
multiple
communication channels simultaneously. For the smart card
application, it
would
be very useful to distribute operations and resources to
external applications
connected
to the IP-enabled world.
Printed
15-Mar-01 6
In
short, this implementation does not represent a significant
innovation, but it
helped
us simulate the situation of a device connected to an IP
network in the context
of
the smart cards.
Certain
critical issues were identified in this implementation.
Indeed, the support of
multi-threading
seems necessary for a new communication architecture of this
type.
Hardware,
software or both could be used to provide this support. An
efficient
communication
peripheral in smart cards would go a long way toward
implementing
such
a network communication layer.
Fast-access
memory turns out to be an important issue. To support such
layers
efficiently,
we find a direct correlation between the amount of fast-access
memory
and
the completeness of the implementation. If not enough memory
is available,
external
support needs to be made available.
Such
an implementation may challenge the current execution model
for the smart
card
applications. In short, the ADPU[11]
does not seem properly adapted to such
implementations.
More work needs to be done on this point.
3.
Discussion
3.1.
Introduction
Smart
cards certainly stand to benefit from connections to one or
more socket ports
of
the host platform. This would also be a practical way of
establishing quick and
easy
communications over the global network with the smart card
recovering the IP
address
of the host platform. Is this the right way to proceed given
the rapid
technological
advances in this area? What will we do with this
implementation when
we
want to communicate with the smart card as a separate entity?
Smart cards are
often
moved from one host platform to another (people often change
their cell phone
handsets).
In this respect, a borrowed IP address would not be suitable.
It
might seem that the most important step would be to make the
smart card IPaddressable
independent
of the host platform. This would make the smart card
interoperable
with other systems while bringing the world of smart cards
within the
reach
or other network users.
An
initial solution (with only the IP address and/or the
corresponding name) might
be
replaced by an implementation of the entire IP protocol suite
in the smart card. The
initial
solution would have the disadvantage of increasing the load on
the host
platform
since a specialized daemon (i.e., program that runs in the
background on the
host)
would be needed. There are many intermediate solutions that
might be chosen
for
technological, economic and social reasons.
Printed
15-Mar-01 7
How
the IP address is allocated remains to be resolved. The
solution retained will
depend
on both business and technological considerations. The
technical solutions to
achieve
this already exist. A fixed name with a dynamically-allocated
address might
offer
the best solution in terms of security and privacy. This paper
will not explore
that
option.
In
the next sections we present some suggestions to start the
discussion on how the
smart
cards might move to IP, on the current limitations of the
smart cards and some
short-term
alternatives we may propose. We described a sample
implemention
approach
and some new standard suggestions.
3.2.
Suggestions
This
paper focuses not only on current problems. We aimed to answer
the
immediate
difficulties while providing longer-range solutions that would
offer real
potential
for future architectures. It seems unwise to choose a reduced
implementation
given
the pace of technological progress, as mobile telephony has
shown in recent
years.
The proposed architecture is similar to the one found in
ordinary routers. This
means
that the host platform e.g. the mobile phone would need to
have two network
interfaces
beneath OSI Layer 3 (network layer).
The
network interface to the wireless network (e.g., GPRS),
The
network interface to the smart card sub-network.
In
this case, the network layer is able to route IP packets to
various network
interfaces
(as is the case in a regular IP layer).
Smart
Card Subnetwork
Mobile
Phone UICC Additional
Smart Card
OSI
Layer 4
OSI
Layer 3 (IP)
OSI
Layer 1, 2
Smart
Card
OSI
Layer 4
OSI
Layer 3 (IP)
OSI
Layer 1, 2
Smart
Card
OSI
Layer 4
OSI
Layer 3 (IP, router)
OSI
Layer 1
(GPRS)
OSI
Layer 1, 2
(Smart
Card)
GPRS
Figure
2: Proposed IP Architecture with Smart Card Subnetwork
Printed
15-Mar-01 8
We
obtain a standard IP model and interoperability is ensured. We
can then benefit
from
OSI Layer 3 features, simply adding new routes to the smart
card sub-network.
This
implementation assumes the following:
A
dedicated IP address can be either allocated fixed or
dynamically,
In
cell phones, OSI Layer 3 that can route IP packets (if this
layer has not been
entirely
implemented),
In
cell phones, Smart Card Interface,
Smart
cards that implement the IP Layer.
The
way the smart card gets its IP address is an issue that needs
to take into
consideration
the IP version, on the business model, and other factors.
Regardless,
there
are mechanisms answer such concerns.
It
should also be noted that such an implementation may challenge
the execution
model
in the smart card. For example
The
USIM application may keep its current ADPU model for backward
compatibility.
Other
applications in the smart card (e.g., those related to OTA
services) may
change
the execution model. This would help OTA communications
overcome
today’s
limitations.
3.3.
Current Technological Issues for Smart Cards.
Implementing
an actual IP layer requires smart card chips that did not
exist prior to
2001.
These chips have features that will allow us to start enabling
such
implementations.
The main technological issue in implementing IP in smart cards
may
still be the limited size of the MTU. This amount of data is
assumed to be
received
at once in the smart card. This minimum MTU is 576 bytes and
1280 bytes
long
in IPv4 and IPv6 respectively [1].
Unless the smart card has enough fast access
memory
it will not be able to support the MTU efficiently.
If
we look at today’s smart cards, we might choose a reduced
implementation.
Memory
is an issue in today’s smart cards since there is no
fast-access memory.
Gemplus
Research Labs have however prototyped a new kind of smart card
that could
overcome
these obstacles. The industrial process would need to be
improved to
manufacture
these new smart cards in volume. Coming years will see new
generations
of
smart card chips that dispose of more fast-access memory.
Moreover, if there is an
actual
business need, integrated circuit makers could for example
reduce the amount
of
certain types of memory to increase the amount of the
fast-access memory.
The
communication rate may be an issue, but it can be improved by
using a higher
ISO
7816-3 communication rate within GSM Third Generation (3G)
standard. For
years,
Gemplus smart cards have supported communications at 115,000
Baud (even
Printed
15-Mar-01 9
higher
for certain products). At the smart card trade fair Cartes
2000,
Gemplus
demonstrated
a prototype of a USB data link layer in a smart card, offering
much
higher
communication rates (9.5 Mb per second, in theory).
These
observations suggest that it will be possible to implement an
actual IP layer
within
a few years. This paper deliberately focuses on
medium-/long-term prospects,
meaning
that current limitations should not dissuade us from starting
to integrate IP
into
smart cards.
3.4.
Short-Term Alternatives.
Buffering
the IP packets on the host platform would be an option until
smart cards
can
support enough fast-access memory. A reduced IP protocol could
be defined to
help
smart cards deal with communication. This does not mean that
another protocol
will
be defined but rather that certain IP features will not be
implemented and MTU
flexibility
will be implemented. Both the host platform and the smart card
could
benefit
from this option. MTU flexibility would not be acceptable if
we were to use
IPv6
since the MTU relies at all times on knowledge of the IP
packet, whose value
must
be unique and at least 1280 bytes long.
In
a worst case, certain functional IP features could be
implemented on the host
platform
but this alternative would be far from ideal since it would
overload the host
platform.
3.5.
Sample Implementation
Beyond
the discussion of how an IP address might be allocated (not
discussed
here),
we have shown a possible implementation approach. The IP layer
of the host
platform
is able to route packets. The route table takes into account
the second
interface.
The dark box in Figure 3 is what we call “external
support”. It provides a
regular
IETF interface for the host IP layer. It seems advisable to
choose a procotol
similar
to a standardized IETF protocol. For example Point-to-Point
Protocol (PPP),
RFC1661
[17]
would be a logical choice since it is designed to work on an
asynchronous
line and its interface does not require a universal interface
identifier.
What
is more with IPv4 PPP, the Maximum Receive Unit (MRU) can be
set to a
smaller
value which is adapted to the relatively small MTU supported
by ISO 7816-3
T=0.
It should be noted that PPP (RFC2472[9])
is used under IPv6 (IPv6CP) where
the
smaller MRU, must be at least as long as the minimum IPv6 MTU
(i.e., 1280
bytes).
We can then expect the fast-access memories of the smart cards
to support
such
an MTU.
Moreover,
the communication would be converted from full-duplex to
half-duplex
(e.g.,
ISO7816-3 T=0). This means that buffering would be used in
both
Printed
15-Mar-01 10
communication
directions. This is a temporary solution until a new
generation of
smart
cards has emerged. Efficient double I/O hardware interfaces
will soon be
implemented,
allowing smart cards to support full-duplex communications.
The
way distant users address the smart card would not need to be
modified in the
near
future. This is a major consideration in our present approach.
This
scheme proposes two simultaneous execution models for the
smart card
applications:
The
first model is the one that we are familiar with in smart
cards. It ensures
backward
compatibility with existing Application Programming Interfaces
(API)
and
applications. We might use a single communication channel (a
predefined
socket
port) that would be automatically opened after the smart
card’s Answer to
Reset
(ATR).
The
second model opens the way to future developments by providing
an
execution
model that is well known in computer operating systems. We
might not
want
to start from scratch and choose [a subset of] the socket
layer interface. This
would
offer support for multiple concurrent communication channels.
Printed
15-Mar-01 11
UICC
Regular
execution
model
(1
channel)
| 