1
13kviews
Case study of an embedded system for smart card.
1 Answer
4
660views

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

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:

Hardware diagram

  • 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.
Please log in to add an answer.