Issue
97, August 1998
Designing
for Smart Cards
- Part 2: Practical Implementation
by
Bobbi Crouch
The
difficulty in smart-card design always hinges on
security. After showing us how to implement transactions,
Bobby walks us through the memory authentication
procedures that keep the cards shipshape and secure.
A
typical smart-card session involves some form of transaction,
such as a purchase, information transfer, or perhaps
authorization for entry or access.
In
Part 1, Carol Fancher presented smart-card basics and
the history of the industry. This month, I consider
the software, command structure, and security concerns
of a smart-card developer.
I
first discuss some of the software coding considerations
involved in smart-card transactions. Later sections
detail some common ISO 7816 commands used in smart-card
transactions.
Most
technical information from each smart-card silicon vendor
is proprietary, and the considerations pertinent to
secure technical information focus on hardware security
features. Although the CPU cores are the same as their
nonsecure counterparts (e.g., ’HC05 or 80C51 microcontrollers),
the other silicon implementations that improve security
must remain secret.
The
software development tools are also secretive in nature,
although vendors do give out memory size (RAM, ROM,
and EEPROM), operating voltage, and, of course, pricing
information. As another obstacle, the U.S. government
requires export licenses for smart-card devices using
cryptography (these devices fall under the control of
armament laws).
