Atmel applications journal.Summer 2004

available; we will use mutual authentication and data encryption to also protect the History Zones. We can use the same key assigned to debit locations for decrementing the Value Zones to give full access to the History Zones. For the Laundry History Zone, we will use authentication key 1; the Access Register = $D7 and Password Register = $7F. For the Parking History Zone, we will use authentication key 3; the Access Register = $D7 and Password Register = $FF. The keys used for each zone are summarized in Figure 3.

Identifying the Card

Being compliant with ISO 7816-3, CryptoMemory provides an answer to reset (ATR) when inserted into a standard ISO compliant card reader. This 8-byte value automatically sent from the card to the reader is used to identify the card’s communication properties and may also be used to identify the application for which the card was designed. The AT88SC0104C ATR provides for two “historical bytes” that may be used to identify the card as a “laundry/parking” stored value card. This ATR value is defined in the Configuration Zone of the AT88SC0104C where a total of 61 bytes are available to identify the card, the manufacturer, the issuer or the assigned holder of the card. Figure 4 shows the contents of the Configuration Zone with areas available for these identification fields highlighted.

Of the 61 bytes available, it is advised that the ATR comply with ISO 7816-3 for use in standard card readers and that the identification number be a unique number assigned to each individual card. Aside from this, the remaining 46 bytes may be used to store issuer data, the name of the

Using the Card

Two basic operations are performed on the storedvalue card once it is issued to the end user: credit and debit. Immediately following (or possibly combined with) the issuing of the card, the initial value will be loaded onto the card. This operation will be the same as reloading more value to the card at a later time; both are credit operations. Loading value to the card will take place at a trusted station and will typically be manned to avoid equipment tampering and to ensure proper payment from the user. The sequence for loading value to the card follows.

•Read the ATR from the card to determine if it is a valid card for the application.

•Read issuer and user data from the card. This data may be used to track use at a specific station or further validate the card at the station where it is being used.

•Read the identification number from the card. This will be required for the reader to calculate the specific keys to use for authenticating with this specific card.

•Authenticate with key 1 or 3 to gain read access to the Value Zone and full access to the History Zone. The key used depends on whether the card is being loaded for a laundry or parking application.

•After a successful authentication, initialize data encryption with the card. Through the Access Registers, we required data encryption, so even if authentication is successful, the data will not be readable until encryption is initialized.

•Read the value zone and decrypt to determine the current value of the card.

•Read the History Zone and decrypt.

-Compare the latest record to value zone data; the two should match.

-Identify the oldest record in History Zone as the location to write the historical record for this transaction.

•At this point, the application software needs to determine the value that will be credited to the card based on the value supplied by the user for this transaction and the $64 maximum value that the card may hold. For every $0.25 that is to be added, one bit in the Value Zone will be written from a 0 to a 1 state.

•Encrypt data and write the History Zone, overwriting the oldest record.

•Authenticate with key 0 or 2 to gain full access to the Value Zone, initialize data encryption.

•Encrypt data and update the Value Zone by writing the appropriate bits to 1.

•Power down the card to complete the

transaction and close all security access to the card.

Once the card has been loaded with value, it may be used to purchase goods or services (laundry or parking, in this example) at an authorized POS station. In our example, it is likely that these stations will be unattended to provide convenience to the user and efficiency to the system provider. An unattended station may be more prone to attack by someone attempting to illegally load value to a card. For this reason, separate keys are used for credit and debit operations, and the POS stations will only hold the keys to remove value from a card.

A sequence of a debit operation is as follows:

•Read the ATR from the card to determine if it is a valid card for the application.

•Read issuer and user data from the card. This data may be used to track use at a specific station or further validate the card at the station where it is being used.

•Read the identification number from the card. This will be required for the reader to calculate the specific keys to use for authenticating with this specific card.

•Authenticate with key 1 or 3 to gain read access to the value zone and full access to the History Zone. This key will also give access to decrease the Value Zone by writing bits from a 1 to 0. The key used depends on whether the card is being used for a laundry or parking application.

•After a successful authentication, initialize data encryption with the card.

•Read the Value Zone and decrypt to determine the current value of the card.

•Read the History Zone and decrypt.

-Compare the latest record to Value Zone data; the two should match.

-Identify the oldest record in History Zone as the location to write the historical record for this transaction.

• The cost of the services requested by the user is compared to the current value of the card. If sufficient, the card may be debited for the services requested. For every $0.25 that is to be debited, one bit in the Value Zone will be written from a 1 to a 0 state.

•Encrypt data and write the History Zone, overwriting the oldest record.

•Encrypt data and update the Value Zone by writing the appropriate bits to 0.

•Power down the card to complete the transaction and close all security access to the card.

•Provide the services to the user.

Antitearing Provides Further Protection

For critical writes to the card, such as updating the Value Zone, additional protection is provided to ensure what was intended to be written will be written. The technique of “tearing” the card from the reader during the transaction is not uncommon for those who try to obtain goods or services before value is deducted from their card. This is especially true at unattended POS stations. CryptoMemory offers a write with antitearing feature built into the device logic that will prevent the tearing attack. Internal buffers and registers are used to ensure the data is written properly to the EEPROM either before a tear occurs or upon the next card power-up if the card is torn.

Extending the Electronic Purse Example

In this article, we used the smallest CryptoMemory device to design a stored-value card to include two separate applications. If more memory is needed to store larger values or record more information, larger CryptoMemory devices are available up to 256 Kbits of EEPROM. We used two authentication keys for each application in this example; four keys are available that could support four unique applications on one card. Read and write encrypted passwords (a total of eight unique sets) are also available that could be used to further distinguish credit and debit operations if one authentication key is used for each of four applications. CryptoMemory offers the built-in security features for stored-value applications and flexibility in size and use of these features to create the ideal card for many electronic purse programs. Similar to the electronic purse is the loyalty program, also using a stored-value card, but instead of storing monetary value, loyalty points are accumulated for redemption at a later time. The same techniques used in this example can easily be applied to a loyalty program.

One of the key applications of smart cards is electronic payment via electronic purses residing on the smart cards. With an e-purse, a cardholder may purchase items from vendors who participate in the payment network, as he would with cash.

Smart cards have been widely used in several parts of the world, especially in Europe and Asia. One of the key applications of smart cards is electronic payment via electronic purses residing on the smart cards. With an e-purse, cardholders may purchase items from vendors who participate in the payment network, just as they would with cash.

Smart card applications, including those that involve electronic transactions with e-purses, have not been widely deployed in the U.S. for various reasons. However, one of the sectors where smart cards have attracted some interest is on the over 6,000 college campuses in the U.S., where smart cards are used with electronic purses for purchases and other transactions carried out at campus facilities.

accessed only after the chip authenticates a user via a password or a limited challenge-response scheme.

Recently, there has been considerable interest in deploying secure memory smart cards for use in copier payment systems, multi-housing laundry systems, parking, etc. One key reason is that the secure memory card costs significantly less than the processor-based card. When the number of deployed cards is large, the cost savings could be significant. In this article, we will discuss our implementation of e-purses on a new type of smart card chip: the Atmel CryptoMemory® chip. The smart cards that contain these chips must coexist with the existing processor-based smart cards and must operate with the existing transaction system.

Figure 1: Typical uses of CryptoMemory smart cards in a campus environment

Currently, in many smart card campus projects, the smart cards are based on chips with a central processing unit (CPU). These cards are often referred to as processor-based smart cards or processor cards for short. On the opposite end of the capability spectrum of smart cards are those based on chips that do not have a processor. These smart cards are commonly referred to as secure memory cards, as their main function is to store data in the nonvolatile memory on the chip. This data can be

The CryptoMemory Card

The CryptoMemory card can be considered a hybrid between the secure memory card and the processor card. It embodies the properties of the secure memory card in the following ways:

•The card contains logic for managing nonvolatile memory, for controlling access to the memory, and for communicating with an external interface device (IFD).

•Since the card provides a basic set of functions, applications developers need not be concerned with developing their own card-operating system or on-chip application; they only need to use the provided functions in a secure and effective manner.

The CryptoMemory card embodies the properties of the processor card in the following ways:

•The card is capable of performing mutual authentication with an IFD, such as the reader, albeit the mutual authentication is implicit. This is based on an Atmel-specific challengeresponse protocol.

•The card is capable of communicating with the IFD via the smart card T=0 protocol.

•The card contains encryption capability to protect the privacy of data exchanged between the card and a terminal.

Security Requirements for

E-purse Applications

EFM Company has developed a transaction system, named Potentia, for conducting payment transactions in campus settings. CryptoMemory cards will be integrated into Potentia. Therefore, the CryptoMemory cards are subject to a set of security requirements similar to those used in the processorbased cards. These security requirements, as well as some key functional requirements of the transaction system, can be iterated as follows:

•Each CryptoMemory card must contain a unique set of keys and cryptographic variables to safeguard the system in the event of a security breach of a single card. Should the security of one card be compromised and lead to exposures of key values, other cards would not be affected.

•The user experience with the CryptoMemory cards must be the same as that of a processor card. In other words, a cardholder need not be aware of what type of card is being used. The terminals and other interface devices must be able to recognize different card types and issue the appropriate commands to the cards to carry out a requested transaction, transparent to the user.

•The CryptoMemory card must be able to verify the authenticity of terminals and other interface devices that participate in the payment system, and proceed to conduct transactions with a terminal only after it has successfully authenticated the terminal.

•The CryptoMemory card must be able to detect the replay of old data and transaction messages by hostile terminals and reject them.

•The CryptoMemory card, in conjunction with the terminals, must be able to store and maintain the balance of the purses as well as other userspecific data with a high level of integrity.

•The CryptoMemory card and other components of the transaction system must provide audit trails, via records or a log of the transactions. The transaction records must be attached with a cryptographically strong electronic signature to insure a high level of integrity.

The transaction records help detect fraudulent attempts by ill-intentioned cardholders or vendors who sell services on the campus and participate in the payment network. For example, when all the transaction records for a period have been collected

Anthony Kim, CEO, EFM Company

Anthony Kim founded EFM Company in 2000, to provide electronic student portfolios in campus cards. Mr. Kim co-founded DA Management, a management/consulting company, in 1997, working with several Silicon Valley corporations. He has 10 years experience in management and finance and has served on the advisory board of Raining Data Corporation. He graduated from Cornell University and received the distinguished Charles Goodwin Sands Medal.

An Van Le, CTO, EFM Company

An Van Le led the development of EFM’s Transaction system in 2002. Prior to EFM, Mr. Le held senior management and technical positions at leading technology companies. He holds over 25 patents, has published over 20 technical documents, and received seven IBM Invention awards.

Mr. Le holds a MS in electrical engineering/ computer science from the University of Utah.

Acknowledgements

The authors wish to express their appreciation to Bryce Hilton, who led the firmware implementation at EFM for the SAM used in our transaction system and provided useful comments for this article. We also wish to acknowledge another colleague, Richard Luong, for his contributions to the development of the transaction server.

card, it also reads the encrypted PIN if the debit amount is above the predetermined limit. The terminal then provides the SAM with the retrieved (encrypted) PIN as well as the PIN supplied by the cardholder. The main processing steps carried out by the SAM are as follows:

–The SAM derives an AES key unique to the chip and uses it to decrypt the encrypted PIN retrieved from the e-purse of the CryptoMemory card. The result is the reference maximum debit PIN is available for comparison.

–The SAM compares the PIN entered by the user with the reference maximum debit PIN. If they are equal, the SAM continues with the transaction and prepares a new balance to be written back to the card, encrypted under the stream cipher.

–If the two PIN values do not match, the SAM convey the error to the terminal, which in turn aborts the transaction and displays an appropriate message to the cardholder on the incorrect PIN.

Before the cards are deployed, an important step is to inject the cryptographic variables — the secret seeds, initial Cryptograms, and passwords — onto the configuration zone of the cards in a secure manner during the card issuance process. The CryptoMemory card will use these cryptographic variables subsequently as it carries out mutual authentication processes with the terminals and as it exchanges encrypted data with the terminals.

When the CryptoMemory cards are shipped from the card manufacturer’s facility, the security of the cards is protected by a secret transport code. The card issuer is provided with the transport code via a protected communication channel or secure courier. To personalize the cards as part of the process, the card issuer must submit the correct transport code to the CryptoMemory card before the cryptographic variables can be stored on the card. Currently, the data to be written to the configuration zone can only be transmitted to the card in clear form. This means that the card issuance process to inject these secret values onto the card should be performed at a highly secure facility to ensure the values transmitted to the card during this process are not intercepted. Our solution to this issue involved three steps:

–Split the issuance process into two processes: an initialization process and a personalization process. The initialization process is where the

secret values of the cryptographic variables are injected onto the card, this process is only performed at a physically secure facility. The personalization process is where personalized data specific to a student, including the maximum debit PIN discussed earlier, is written to the card. Since the values written to the card during the personalization process can be encrypted under the keys derived from the values injected during the initialization process, the personalization process can be performed in a public setting of the campus, without any security concerns, at the time a student applies for the card.

–Use key diversification based on a set of master keys and the ID of the card to derive unique values of the cryptographic variables before injecting them onto each card. This is also to be in step with the earlier described requirement of unique key values for each card. Thus, in the worst case, if there were a weakness in the physical security of the initialization facility that enabled an adversary to intrude and intercept secret values transmitted to a number of cards, the security exposures would be confined to those cards. Needless to say, the derivation of unique values for the cryptographic variables are performed inside the secure boundary of a specialized cryptographic adapter or SAM to maintain the secret values for the set of master keys.

–Utilize specialized readers and initialization equipment that prevent wire-tapping and interception of secret values written to the card during the initialization process.

The security of the whole transaction system is dependent on the security of each component, how well the components are integrated into the system, and whether interactions between components are well designed. The built-in features of the CryptoMemory card have helped enable us to meet the security and functional requirements stated earlier for e-purses. The cards coexist well with the processor cards in our transaction system.

We have found the CryptoMemory card offers a balanced trade-off between security, cost, and features. Its security features and the reasonable sizes of storage are unmatched by the secure memory cards from various vendors, while its functional features and low cost make it an attractive candidate to replace some of the low-end processor cards.

WHETHER THE NEED IS FOR A SUBWAY SYSTEM, BUS OR RAIL SYSTEM, A CONTACTLESS CARD OR TOKEN CAN BE UTILIZED QUICKLY AND AFFORDABLY.

Figure 3: Transponder Memory Capacity for Passive RFID Systems