As stand-alone active entities, smart cards have a life-cycle and
First, some terminology. The ``chip manufacturer'' is responsible for
the chip design, production, and testing. The ``card manufacturer''
embeds the chip into the plastic card. The ``card issuer'' creates,
designs, and prints the end-user organization's logo onto the plastic
card. The ``card holder'' is the user whose name is printed on the
outside of the card at the same time it is written to a file inside the
card file system.
The following life-cycle is typical for single-application smart cards:
The internal architecture development stage is used to develop the
control and data structures that is best suited to the requirements of
applications that will use the card. Some structures might not be
architected, and might be left open to future application developments
and extensions. Once an architected solution is found, it defines a
permanent configuration specifying the file directory structure, and
card behavior: it becomes a solution model. This solution model is a
solution for a given problem (for example, a GSM solution model or a
company solution model) that can be reproduced and manufactured.
Multiple card manufacturers can reproduce the solution model if the
solution specification follows interoperability characteristics.
The next requirement is for the chip for a card to be manufactured and
given a unique serial number that identifies characteristics of
manufacture (IC lot number, wafer number, die number, test equipment
numbers, etc.). The chip then undergoes a self-test process that
results either in an invalid, erased chip, or a valid chip with no
non-user modes enabled. After this stage, there is no access to card
memory addresses except under the control of the card operating system.
Tamper-resistance circuitry has been activated.
Independent of chip manufacture, plastic card manufacture occurs.
During the smart card manufacturing stage, a chip is embedded into the
plastic card. The card can be printed with the issuer's logo at this
point or later.
The smart card preparation stage creates the externally-downloadable
control structure and downloads it to the smart card - changing the
basic behavior of the smart card, specifying the file structure that
will exist on the card, associating rights, keys, and privileges with
directories and files through various primitive card access and control
operations (see Security Architecture), as well as setting basic card
control parameters such as number of allowed invalid access attempts.
If the smart card preparation stage is not integrated with the
application preparation stage, cards need to be transported from the
card manufacturer to the end-user. In this case, the keys written at
the smart card preparation stage are termed ``transport keys'' or
``initialization keys''. These keys are sent to the card issuer by the
manufacturer separately from the cards. They prevent modification of
the cards during transport from the manufacturer to the issuer. Once in
possession of the transport keys, the issuer can access the card to
perform the application preparation stage.
For security purposes, the card manufcaturer can permanently set rights
and privileges before cards can move to the application preparation
The application preparation stage initializes the card password(s), the
data in the card file system, and optionally writes the user's name on
the card. Some cards accept dynamic update, creation and deletion of
files in the file structure after the application preparation stage
(depending on the card preparation stage), but others enforce a fixed
file structure once application preparation has taken place.
Then follows a stage of active card usage, during which the operations
defined in the card preparation stage may be performed using the
passwords defined during the card preparation stage. Usually, passwords
and keys may be changed during the usage stage.
During the final stage of the card lifecycle, the card is invalidated. Cards should not be re-used in order to avoid any problems in organizational policy that might arise from having two users associated over time with the same card serial number. Invalidation of multi-application cards can be complex if internal applications are tied to the exterior appearance of the card: if one application is invalidated, then the issuer logo on the card may be confusing for the user. If the entire card must be invalidated in order to invalidate one expired application, then the user must obtain a new card in order to maintain access to the remaining applications.