1. Smart card system requirements.
i) Purpose:
Enabling authentication and verification of card and card holder
by a host.
Enabling GUI at host machine to interact with the card
holder/user for the required transactions, for example, financial
transactions with a bank or credit card transactions.
ii) Inputs:
Received header and messages at IO port Port_IO from host
through the antenna.
iii) Internal Signals, Events and Notifications Notifications:
On power up, radiation-powered charge-pump supply of the card
activated and a signal to start the system boot program at
resetTask.
Card start requestHeader message to task_ReadPort from
resetTask.
Host authentication request requestStart message to
task_ReadPort from resetTask to enable requests for Port_IO.
UserPW verification message (notification) through Port_IO from
host.
Card application close request requestApplClose message to
Port_IO.
iv) Outputs:
Transmitted headers and messages at Port_IO through antenna
Control panel:
No control panel is at the card. The control panel and GUIs
activate at the host machine (for example, at ATM or credit card
reader)
v) Functions of the system:
The card inserts at a host machine.
The radiations from the host activate a charge pump at the card.
The charge pump powers the SoC circuit consisting of card
processor, memory, timer, interrupt handler and IO port, Port_IO.
On power up, system reset signals resetTask to start.
The resetTask sends the messages requestHeader and
requestStart for waiting task task_ReadPort.
task_ReadPort sends requests for host identification and reads
through the Port_IO the host-identification message and request
for card identification.
task_PW sends through Port_IO the requested card identification
after system receives the host identity through Port_IO.
task_Appl then runs required API. The requestApplClose message
closes the application.
The card can now be withdrawn All transactions between
cardholder/user now takes place through GUIs using at the host
control panel (screen or touch screen or LCD display panel).
vi) Design metrics:
Power Source and Dissipation: Radiation powered contact less.
Code size: optimum. card system memory needs should not
exceed 64 kB memory.
Limited use of data types; multidimensional arrays, long 64-bit
integer and floating points and very limited use of the error
handlers, exceptions, signals, serialization, debugging and
profiling.
Microcontroller hardware: Generates distinct coded physical
addresses for the program and data logical addresses. Protected
once writable memory space.
Validity: System is embedded with expiry date, after which the
card authorization through the hosts disables.
Extendibility: The system expiry date is extendable by
transactions and authorization of master control unit (for
example, bank server).
Performance: Less than 1s for transferring control from the card
to host machine.
Process Deadlines: None.
User Interfaces: At host machine, graphic at LCD or touch screen
display on LCD and commands for card holder (card user)
transactions.
vii) Test and validation conditions:
Tested on different host machine versions for fail proof card-host
communication.
2. Classes and class diagram
Classes:
Task_CardCommunication is an abstract class from which
extended to class (es) derive to read port and authenticate.
The tasks (objects) are the instances of the classes Task_Appl,
Task_Reset, Task_ReadPort and Task_PW.
ISR1_Port_IO, ISR2_Port_IO and ISR3_Port_IO are interfaces to the
tasks
3. Hardware Architecture
Smart card hardware:
A plastic card in ISO standard dimensions, 85.60 mm x 53.98 x
0.80 mm. It is an embedded SoC (System-OnChip). [ISO standards
- ISO7816 (1 to 4) for host-machine contact based card and
ISO14443 (Part A or B) for the contactless cards.]
Microcontroller MC68HC11D0 or PIC16C84 or a smart card
processor Philips Smart XA or an ASIP Processor. Needs 8 kB+
internal RAM and 32 kB EPROM and 2/3 wire protected memory.
CPU special features, for example, a security lock.
CPU locks certain section of memory - protect 1 kB or more data
from modification and access by any external source or
instruction outside that memory.
Other way of protecting - CPU access through the physical
addresses, which are different from logical address used in the
program.
Standard ROM 8 kB for usual or 64 kB when using advanced
cryptographic features.
Full or part of ROM bus activates take place after a security check
only.
Chip-supply system using charge pump.
I/O system.
4. Software Architecture
Smart Card Software:
Needs cryptographic software, needs special features in its
operating system over and above the MS DOS or UNIX system
features.
Protected environment -OS stored in the protected part of ROM.
A restricted run-time environment.
OS, every method, class and run time library should be scalable.
Optimum Code-size.
Limited use of data types; multidimensional arrays, long 64-bit
integer and floating points and very limited use of the error
handlers, exceptions, signals, serialization, debugging and
profiling.
Three-layered file system for the data.
Master file to store all file headers (file status, access conditions
and the file lock).
A header means file status, access conditions and the file lock.
Dedicated file ─ second file to hold a file grouping and headers of
the immediate successor
Elementary file ─ third file to hold the file header and its file data.
Either a fixed length file management or a variable file length
management with each file with a predefined offset.
