Issue
97, August 1998
Designing
for Smart Cards
- Part 2: Practical Implementation
MEMORY
MANAGEMENT
Another
way to provide file security is via a memory manager,
which limits access to other memory areas by a running
application or software. Various vendors call these
features by different names (MMU, CCMS, etc.).
These
features enable you to select areas that an application
may reside and operate in, as well as exclude other
areas from accessing that particular application. Essentially,
an application assigned a certain memory space is also
prevented from reading or modifying another application’s
space or data.
With
cryptographic keys, for example, the card issuer can
protect or prohibit access of this particular area of
memory by any software or application other than a unique,
authorized file or program. Enhanced memory-management
features may permit dynamic allocation or updating of
memory areas and their respective applications.
Memory
management units (MMUs) are essential for multiapplication
OSs, where dynamic loading of new tasks in Java or other
interpreted languages is possible. In these environments,
memory and address management ensures that applications
from unrelated tasks (e.g., loyalty and electronic purse)
don’t interfere with each other, even if bugs exist
in the task or OS code. It also limits ways that hackers
can inject uncontrolled behavior into a smart-card device.
Memory
management developed in sophisticated 32-bit environments,
where operating systems such as Unix and Windows demand
a way for hardware to isolate tasks. But in these environments,
issues like silicon area, power, and execution time
are less important than in the smart-card environment.
Smart-card
memory management must combine the best concepts of
existing MMU strategies within a stringent silicon,
performance, and power budget if such solutions are
to be practical in the high volumes and low costs demanded
by distributors.
Another
way to limit access to secure data is by introducing
complex sequences to enable access to certain memory
areas. Control register bit manipulation and other operation-sequence–dependent
methods make a hacker’s job much more difficult
and time consuming. They also prevent rogue code from
accessing data it shouldn’t, even if it’s
trusted code like an operating system.
Currently,
several system providers offer smart cards with Java
operating systems onboard. The security of Java on a
smart card is enforced by virtue of the Java Virtual
Machine (JVM), which prohibits program access to anything
the JVM hasn’t allocated.
These
cards load the JVM in ROM and permit Java applets to
be loaded and run in EEPROM. This type of data security
enables reuse of the card for different applications.
An
added benefit to Java-based smart cards is the ability
to load applications on smart cards from various vendors.
No longer are applets tied to a specific manufacturer
or architecture.
The
I/O channel is a prime target for hackers, so be careful
when selecting what data to transmit across the channel.
It would be simple to solder a wire, record the transmitted
data, and examine it for clues.
Also,
design the data so that an attacker with access to the
I/O channel would not be able to obtain any valuable
or secret information. In an electronic purse, for example,
the balance of an account or the transaction amount
aren’t secret, but account numbers, keys, and passwords
shouldn’t be transmitted (in the clear) across
the I/O channel.
The
card’s software should allow only necessary commands.
Commands that aren’t in the card’s instruction
set should return the appropriate ISO error code and
reset the card after several attempts by a card reader
to issue invalid commands.
Basically,
that’s the default procedure for any illegal action—just
reset the card.
