Issue 97, August 1998
Designing for Smart Cards - Part 2: Practical Implementation

---

SMART CARD SESSION

After the identification of the card and reader is completed and the proper transmission protocol established, the session begins. The initial procedures should include authentication of the reader and card, the granting of access privileges to data areas, and the actual transaction.

Authentication is the act of validating the reader (or user) and granting file access. File security can be as simple as assigning file-access authority at card personalization or as complex as the more comprehensive memory-management schemes.

File-access rights can consist of defining the file structure and authorization policies. This can be performed explicitly at the vendor’s factory or at the card issuer’s location.

Data access may be contingent to the reader asking for, and passing, a challenge. A common challenge scenario is for the reader to issue the command get challenge to the card, and the card then sends a random number to the reader for manipulation.

Manipulation may consist of encrypting or decrypting the data with an algorithm that uses a fixed key, set of fixed keys, or changing keys that are coordinated with keys on the card. Once the manipulation is performed, the result is sent to the card for comparison.

The card compares the reader’s result with its own and, if they match, grants further communication to the card. Certain predefined files (whose access rights were defined at personalization) may necessitate further authentication (e.g., user PIN or password) for access. Once identification and authentication are satisfied, a transaction commences.

As an example, consider a debit-card application. The basic transaction information—identity and authorization—are the first steps. A transaction amount is selected, followed by some form of signature (e.g., signature algorithm or other authentication) from the requesting device.

Once the desired transaction type and amount are selected, funds are debited or credited appropriately. This task involves writing to EEPROM to record the transaction in a history file and modifying the correct account.

If the requested transaction is a purchase from a reader, the crediting message should also include a signature. The last step is to confirm the transaction.

In this example, the signature authenticates each critical step of the transaction process. The complete data set is digitally signed, so it cannot be altered during transmission.

You should consider implementing various checks for each step of the transaction. These checks may include control bits or bytes of EEPROM variables that verify each step of the transaction process (because of the critical nature of the EEPROM write sequence mentioned earlier).

Also, think about possible transaction failures or hacking attempts. What happens if the card is withdrawn from the reader during the transaction? What happens if the reader fails to supply the proper power voltage to the card?

What happens if the reader’s encryption of the random number is incorrect? How many times should the card accept authorization attempts, and what action should be taken when the allowed number of attempts is violated?

How does the card or reader know if a transaction completes properly? Also, what action should be taken, and by what part of the system, if there is a transaction failure?

A hacker may try to cheat the system by withdrawing the smart card after a transaction but before it could be recorded onto the card. Put simply, authorizing any transaction should be the last procedure of a smart-card session. Recording procedures onto the smart card should be completed prior to external verification of a transaction.

One possible method of monitoring a transaction’s progress is to define a transaction status byte in EEPROM. Different values indicate transaction in progress, failed transaction, successful transaction, last successful transaction, last unsuccessful transaction, and place of failure of the last transaction. This information may require more than one EEPROM byte.

Monitoring this transaction control byte should be the first and last acts of a smart-card session. Certain states then reflect successful completion of various stages of a transaction.

Most silicon vendors implement a manual or automatic programming of EEPROM. Possible hacker attacks include reducing the power level (Vdd) to the card during critical (EEPROM programming) stages of a transaction.

The manual or automatic programming of EEPROM is acknowledged by some event that the smart card can check. It should be included in every EEPROM programming procedure.

Implementing this check in the EEPROM procedure helps defeats low-voltage attacks. The transaction control byte is the smart card’s check on every transaction and should be included in the software.

Possible reactions to a fraudulent reader—one that fails the authentication procedure—should include a reset of the card. There should be a limit to the number of times a smart card fails authentication. This would likely be a RAM variable since no transaction takes place prior to authentication.

Of course, there should be allowances for one or two failed attempts, possibly due to reader software failure. However, at some point, the smart card should shut down and refuse further communication.

Some smart-card features may not require authentication—for example, the wallet account of an electronic-purse application. Small transactions are normally paid for with pocket change or small-denomination currency can be completed much faster with a smart card.

The wallet account of a smart card can be limited to a small, fixed amount, which is similar to the amount of cash you’re comfortable carrying with you. The risk to this account, just like the risk to your wallet, is that if you lose it, you’ll probably lose all your cash.

However, you can immediately cancel your credit cards and prevent unauthorized use. Similarly, a smart-card wallet could contain an account intended for small purchases or transactions. This account should allow a check of recent transaction (history), as well as the current balance.

More critical and sensitive areas of the smart card (e.g., credit/debit accounts or sensitive personal information) should only allow access after authentication of one or more levels. Such purse accounts are commonly checked by small, key-ring-size readers.

The primary elements of a smart-card transaction are card power-on reset, card/file authentication, transaction type selected and approved, transaction history parameters initialized and checked (for prior incomplete transactions), transaction effected on the card, transaction history parameters modified (to signify a successful transaction), transaction approval sent to the reader, and transaction terminated.

All of these actions may be formulated in pseudocode and then modified to the actual instruction set of the chosen smart-card microcontroller.