- 360 page book
- CD with source code
- 3K Multiflex smart card
Smart Card Developer’s Kit
$49.99 – $69.99
Only 1 left in stock
Description
Smart Card Developer’s Kit is designed to provide the practical information you need to design and build applications that incorporate smart cards. Using a combination of detailed exposition, technical reference summaries, and extended examples, this book familiarizes you with the unique strengths and capabilities of this emerging computer technology. Increase your security from a one-factor security-a password-to a two-factor security-a smart card and its PIN. Use the smart card as a portable place to carry your personal preference information and your identity-establishing private signing key. In marketing applications, a smart card offers a much wider and more flexible set of customer benefits than a magnetic-strip card (magstripe) or a paper record card. A smart card can also carry secured information-such as medical records, licenses, subscriptions, and accreditations-that must be guarded against tampering.
The book includes a 3K Multiflex smart card, which you can use to begin programming smart cards. The book’s CD-ROM includes all the source code for the book, EZ Formatter, the Cyberflex and Multiflex smart card specifications, and a browser-ready collection of HTML pages that can be used as a starting point for finding smart card information and freeware development tools on the Web.
Book Preview
Since the advent of the Internet, the need for security has grown exponentially. Smart cards provide a secure medium for storing and transporting data. Smart cards have been produced since the 1970s, but until recently have been confined to a small number of government applications such as pay telephones, national health cards, and financial services cards. Smart cards are now used in Europe for many applications, and are becoming more common in the United States as well. Smart cards offer a much wider and more flexible set of customer benefits than magnetic-strip cards or paper records. They also carry secure information—such as medical records, licenses, subscriptions, and accreditations—that must be guarded against tampering. Smart Card Developer’s Kit is designed to provide the practical information you need to design and build applications that incorporate smart cards. Using a combination of detailed exposition, technical reference summaries, and extended examples, this book familiarizes you with the unique strengths and capabilities of this emerging computer technology.
Scott B. Guthery recently joined CertCo to lead the development of a line of cryptographic signing devices. He had previously worked for Schlumberger, where he headed the team that created the first smart card to run a commercial programming language, the Java Card. While at Schlumberger, Dr. Guthery received two patents for his contributions to the design of Schlumberger’s MAXIS well logging system and also contributed to the development of some novel communication systems for urban terminals such as utility and parking meters. Dr. Guthery received a Ph.D. in probability and statistics from Michigan State University and has published articles in the fields of mathematics, programming languages, and electronic commerce.
Timothy M. Jurgensen is a senior member of the technical staff at Schlumberger’s Austin Products Center. He holds a Ph.D. in nuclear physics from Rice University and has been with Schlumberger for more than 25 years. He has been particularly active in the development of small aperture (VSAT) satellite-based communication systems and in the provision of high-security computer networks. These networks are now used by Schlumberger’s worldwide operating companies in Oilfield Services to move time-critical exploration and evaluation information from remote well site environments to evaluation offices around the world. He has published articles regarding wide area computer networks, satellite-based communication systems, data management, and network security infrastructures.
A smart card is a portable, tamper-resistant computer with a programmable data store. It is the exact shape and size of a credit card, holds 16 KB or more of sensitive information, and does a modest amount of data processing as well. The central processing unit in a smart card is typically an 8-bit microcontroller that has the computing power of the original IBM PC. To make a computer and a smart card communicate, you place the card in or near a smart card reader, which is connected to the computer. After a period of some 20 years of arrested development, smart cards are beginning to evolve. Memory sizes are increasing and processor architectures are moving to 16-bit and 32-bit configurations. This book is about software development for today’s widely available 8-bit microcontroller smart cards.
PART I Smart Card Background and Basics
A Brief History The smart card— a term coined by French publicist Roy Bright in 1980—was invented in 1967 and 1968 by two German engineers, Jurgen Dethloff and Helmut Grottrupp. Dethloff and Grottrupp filed for a German patent on their invention in February 1969 and were finally granted patent DE 19 45 777 (3, titled “Identifikanden/Identifikationsschalter,” in 1982. Independently, Kunitaka Arimura of the Arimura Technology Institute in Japan filed for a smart card patent in Japan in March 1970. The next year, in May 1971, Paul Castrucci of IBM filed an American patent titled simply “Information Card” and on November 7, 1972, was issued U.S. Patent 3,702,464. Between 1974 and 1979 Roland Moreno, a French journalist, filed 47 smart card—related patent applications in 11 countries and founded the French company Innovatron to license this legal tour de force. Two brief but excellent histories of the early days of the smart card by Klaus H. Knapp of the Eduard Rhein Foundation and Robin Townend of MasterCard International can be found at http://www.eduard-rhein-foundation.de/html/t96.html and http://www.smartcard.co.uk/financel.html.
Smart cards cost between $1 and $20, depending primarily on the size of the memory in the card and the software functionality included. Smart card software usually includes a rudimentary on-board operating system with file system, communication, authorization, encryption, and access control primitives. Smart cards are particularly useful components of computer systems that need to address data security, personal privacy, and user mobility requirements. Smart card programming is characterized by a constant and overarching concern for two system requirements: data security and data integrity. Data security means that a data value or a computational capability contained on the card can be accessed by those entities that are authorized to access it and not accessed by those entities that are not authorized to access it. Data integrity means that at all times the value of information stored on a card is defined; the value is not corrupted, even if power to the smart card is cut during a computation involving some piece of information stored on the card.
Unlike many software applications commercial programmers deal with daily, smart card applications are typically public systems. This means first that smart cards are used in settings and situations in which using a computer is not the first thing on the user’s mind. Furthermore, the smart card computer must fit seamlessly and, to the greatest extent possible, unnoticed into existing behaviors and relationships. Paying for a newspaper with electronic money on a smart card should, for example, be very much like paying for the newspaper with cash.
CHAPTER 1 Smart Card Programming
Furthermore, unlike applications that are run on corporate computers in physically guarded environments and on private networks, smart card computers are “on the street” and subject to attack by a range of interests and agendas that are not fully known, let alone understood, by the smart card programmer and system designer. The amount of data processed by a smart card program is usually quite small and the computations performed are typically quite modest. Subtracting 50 cents from a smart card’s electronic purse, for example, entails neither many numbers nor much arithmetic. However, making sure that the expectations of all the parties to this transaction—the cardholder, the card issuer, and the merchant—are met during and after the transaction places an unfamiliar and relatively unique set of demands on software system designers and computer programmers. The merchant expects to be exactly 50 cents richer, the cardholder expects to be exactly 50 cents poorer, and the card issuer expects that the smart card will be left in a consistent state and not have leaked information about its inner workings.
Smart Versus Memory Versus Logic Cards +1 Two other credit card—sized devices contain integrated circuits; because of their identical size and similar uses, they are sometimes confused with smart cards. These are memory cards and logic cards. Memory cards contain only memory and logic cards are memory cards with some added circuitry to provide some data security functions. European telephone cards, transportation fare cards, and some medical record cards are examples of the uses of these cards. Since neither memory nor logic cards contain a general-purpose programmable processor for which software can be written, they are not explicitly considered in this book. Nevertheless, many of the discussions about systems that use smart cards apply equally well to memory and logic cards. Memory cards and logic cards should certainly be considered by system designers in building systems that include a portable personal data store.
Smart Card Software
There are fundamentally two types of smart card software, some examples of which are listed in Table 1.1:
• Host software, which is software that runs on a computer connected to a smart card. Host software is also referred to as reader-side software. • Card software, which is software that runs on the smart card itself. As a counterpart of reader-side software, card software is also referred to as card-side software.
Book Information
Publisher : Macmillan Technical Pub (February 13, 1998)
Authors: Scott B. Guthery, Timothy M. Jurgensen
Language : English
Textbook Binding : 360 pages
ISBN-10 : 1578700272
ISBN-13 : 978-1578700271
Smart Card Details
The Multiflex smart card contains a 5Mhz Motorola SC21 single-chip 8-bit microcontroller with 6,114 bytes of ROM, 3,008 bytes of EEPROM and 128 bytes of RAM. The chip writes 4 bytes at a time to the EEPROM. The time taken for each write operation is 7 milliseconds. The card uses the T=0 communication protocol with a data transfer rate of 9,600bps.
The Multiflex card conforms to the ISO 7816-4 standard and also implements a few additional commands (for example, create file – which is missing from the ISO 7816-4 standard).
2. Activating Smart Cards: Reset and Answer to Reset
In order to reset the microcontroller on the Multiflex card, the voltage on the RST contact must be held high for more than 50 microseconds and then cleared. The Multiflex operating system then conducts some internal consistency checks, selects the master file and transmits a 4 byte answer to reset (ATR) to the terminal on the communication line.
The ATR for the Multiflex is: 3B16 0216 1416 5016. The meaning of each byte is explained in Table 6.1.
| Byte Name | Description | Value | Interpretation |
| TS | Bit synchronization | 3B16 | 1 is voltage high |
| T0 – high order | Other fields present | 016 | No other T fields present |
| T0 – low order | Number of historical bytes | 216 | 2 historical bytes present |
| T1 | First historical byte | 1416 | Component code |
| T2 | Second historical byte | 5016 | Mask code |
Table 6.1: The ATR for the Multiflex smart card.
As mentioned in Chapter 3 the first part of the ATR (up to the historical bytes) is governed by ISO 7816-3. Schlumberger uses the historical bytes to identify the microcontroller and the operating system in the ROM. The component code (1416) means that the chip is a Motorola SC21 and the mask code (5016) indicates that the ROM contains the Multiflex operating system.
After the card has transmitted the ATR to the reader, it enters a polling loop, listening for a command from the application program on the reader side.
3. Directories and Files
The most common operations performed on a smart card are reading and writing data to and from the card as well as establishing the correct authorization to do so. This section describes the organization of data on the Multiflex card.
The Multiflex supports the following five types of files:
| File Type | Value | Max Record Size | Max Number of Records |
| Directory file | 3816 | – | – |
| Transparent file | 0116 | – | – |
| Record file (fixed-length records) | 0216 | 255 bytes | 255 |
| Record file (variable-length records) | 0416 | 255 bytes | 255 |
| Cyclic file | 0616 | 255 bytes | 255 |
Table 6.2: File types supported by the Multiflex.
3.1 Selecting a Directory
The Select File command can be used to select a file (i.e. make the file the current file) by providing the filename of the particular file as its argument. For example to select the master file (the master file on all ISO 7816-4 compliant smart cards has the filename 3F0016), the following command would be used:
C016 A416 0016 0016 0216 3F16 0016. The meaning of each byte is explained in Table 6.3.
| Name | Description | Value | Interpretation |
| CLA | Class | C016 | – |
| INS | Instruction | A416 | – |
| P1 | First parameter | 0016 | – |
| P2 | Second parameter | 0016 | – |
| P3 | Third parameter | 0216 | Two data bytes to follow |
| Data | Data | 3F16 | Field of file to be selected |
Table 6.3: The Multiflex Select File command.
A smart card responds to a command by sending either one to two status bytes known as status word 1 (SW1) and status word 2 (SW2). These bytes inform the reader application of the result of the command. The Multiflex card returns the following response to the above command:
6116 1416
This response indicates that the command was completed successfully, but the card has some additional information. The second byte indicates how much information is available i.e. 1416 (20 bytes). A Get Response command must be sent to the card with the number of bytes as its argument in order to retrieve this information, as shown below.
C016 C016 0016 0016 1416
The 20 bytes of file description information returned from the Get Response command indicates how many bytes are available for new files and subdirectories in the current directory. It also reveals how many subdirectories, elementary files, secret codes and PIN files are in the current directory. The information also indicates which file was selected and its file type as well as the operations that are allowed on that file type. In addition the information shows the access conditions for the various operations on the selected file. The Multiflex supports seven possibilities for access conditions. These are shown in Table 6.4.
| Key Knowledge Needed | Value of Access Condition |
| None – operation always possible |
016
|
| PIN (4 digits) |
116
|
| Protected (8 byte cryptographic key) |
316
|
| Authenticated (8 byte cryptographic key) |
416
|
| PIN and protected |
616
|
| PIN and authenticated |
816
|
| None – operation never possible |
F16
|
Table 6.4: Access conditions supported by the Multiflex smart card.
3.2 Selecting an Elementary File
An unused Multiflex card contains two elementary files. The first if the serial number file with filename 000216 and the second is the transport key file with filename 001116. The serial number file contains a sequence of eight bytes that uniquely identifies the particular smart card. It includes a series number, customer identification code, Schlumberger manufacturing site and usage.
The transport key file contains the transport key that locks the card. The purpose of this key is to protect the card from unauthorized access while being transported from the manufacturer to the customer. The key is usually sent to the customer “out of band” i.e. by post, telephone, fax etc. A simple transport key is sufficient for low-value cards while higher value cards may use more complex transport key protocols. For example, each card may have a different transport key that is a function of the serial number of the card. This is known as a diversified key.
Once the card has been unlocked using the transport key, an application can then be written onto the card. The process of creating a specific application on a generic smart card is known as personalization. This process may also include writing specific data into the files created on the card, for example storing a fingerprint of the card owner. The personalization process should either delete or overwrite the transport key.
When an elementary file is selected using the Select File command, the card should return the following status code:
6116 0F16
This means that there are 0F16 (15 bytes) of descriptive information about the file available. This information includes the number of bytes in the selected file, its file ID and type. It also includes access conditions for the various operations on the selected file.
3.3 Keys and Key Files
The Multiflex smart card uses two types of keys:
- PIN codes
- Cryptographic keys
PIN codes are usually four digits in length, however they may be up to eight digits in length. They are used by the card to ensure that the person attempting to use the card is authorized to do so. Typically, the user is prompted to enter a PIN on a keypad or keyboard attached to the reader containing the card. The value entered is sent to the card via the Verify PIN command. If this matches with the value stored in the current PIN file then the access level on the card is set to CHV (cardholder verified). All operations authorized by the CHV access condition can then be performed.
Cryptographic keys are used for mutual authentication between the card and the reader or computer. There are four ways of using cryptographic keys:
- Verify key – the reader can demonstrate knowledge of a key by simply sending the key to the card.
- External authentication – the reader can demonstrate knowledge of a key by using the key to encrypt a challenge provided by the card.
- Internal authentication – the card can demonstrate knowledge of a key by using it to encrypt a challenge provided by the reader.
- Protected-mode commands – the reader can use a command protected by a key by sending a challenge encrypted with the key along with the command.
Both internal and external authentication are more secure than verifying the key since the key itself is not transferred over the communication channel.
Each directory on the Multiflex card may contain up to three key files that control access to the files in that directory. The key files are transparent elementary files with special reserved names. These files are shown in the table below.
| Key File Identifier | Key File Name | Key File Contents | Max Keys |
| 000016 | PIN file | PIN code | 1 |
| 000116 | Internal authentication file | Cryptographic keys | 16 |
| 001116 | External authentication file | Cryptographic keys | 16 |
Table 6.5: Key files supported by the Multiflex.
The PIN file contains 23 bytes of data. This data contains the PIN code, the number of attempts allowed, the number of attempts remaining until the card is blocked, the unblocking code, the number of unblocking attempts allowed and the number of attempts to unblock the card remaining until the card is blocked indefinitely.
Both the internal and external authentication files have the same format and contain 38 bytes of information. This information includes the length of the key, the algorithm used with the key, the key itself, the number of attempts allowed, the number of attempts remaining until the card is blocked. This information is specified for each key that is stored in the file.
3.4 Record Files
As the name suggests, a record or cyclic file comprises of a series of records. Each record can be up to 255 bytes in length and there may be 255 records in a record or cyclic file.
One of the functions most frequently used on record files is the search function. The Multiflex card supports a Seek command that enables the records in a selected file to be searched for a particular pattern. The search may start at a given offset in each record and either start from the beginning of the file or from the current position in the file. The card returns success if the pattern is found in a record and the record found becomes the current record. If the pattern is not found in any of the records on the file then an error will be returned.
4. Multiflex Commands
The previous section described a few commands supported by the Multiflex smart card. The Multiflex card supports a total of 21 commands which can be used to build an application. Table 6.6 below lists these commands.
| Command Name | Description |
| Change PIN | Change PIN in selected file |
| Create File | Create new file or subdirectory in current directory |
| Create Record | Create new record in selected record file |
| Decrease | Make next record in selected cyclic file the current record minus the given value |
| Delete File | Delete file from selected directory |
| External Authentication | Retrieve encrypted challenge from reader and check |
| Get Challenge | Retrieve challenge from card |
| Get Response | Retrieve information about a selected file or directory |
| Increase | Make next record in selected cyclic file the current record plus the given value |
| Internal Authentication | Retrieve encrypted challenge from card |
| Invalidate | Block access to the selected file |
| Read Binary | Read data from selected transparent file |
| Read Record | Read record from selected linear file |
| Rehabilitate | Remove the block on selected file |
| Seek | Search selected record file for records containing given byte string |
| Select | Make file with given file ID the current file |
| Unblock PIN | Unblock a blocked PIN |
| Update Binary | Overwrite data in selected transparent file |
| Update Record | Overwrite record in selected linear file |
| Verify PIN | Present a PIN to card |
| Verify Key | Present cryptographic key to card |
List of Multiflex commands
Table 6.6:
The purpose of protected mode commands is to add security to certain commands to ensure that the command is performed by an authorized party. Prior to executing a command that is protected mode the reader must first issue a Get Challenge command to the card. The reader must then encrypt the data returned by the card with a specific shared key and return it together with the protected mode command. The card will decrypt the data and if it matches the challenge that it sent previously, then it will execute the command. However if the decrypted data does not match the challenge, the card will abort and return an error status.
5. Authentication States and Authentication State Transitions
The purpose of this section is to explore what happens when a party is successfully authenticated in one directory and then moves to another directory with a different PIN or key file. The ISO standards do not cover this area and so smart cards vary in their authentication state maintenance policies.
Authentication states in the Multiflex card are characterized by three 2-byte variables:
- PIN authentication directory – the file ID of the directory that contains the PIN file of the last PIN to be authenticated
- External authentication directory – the file ID of the directory that contains the external authentication file containing the last key to be authenticated
- External authentication key – 16 bits which, depending on which bit is set, determines which key in the current external authentication file has been authenticated
The operating system simply checks these variables when an access-controlled operation is about to be performed. If PIN authentication is required and the PIN authentication directory variable is non-null, then the operation may proceed. Otherwise it fails. If key authentication is required and the external authentication directory variable is non-null and the bit corresponding to the required key is set in the external authentication key variable, then the operation may proceed. Otherwise it fails.
The Multiflex card implements hierarchical access control, that is, if a key file is present in a directory of a particular application, then that key file defines the keys required to access the files in that directory and all its subdirectories. If there is no key file in an application’s directory, then the key file in the directory containing the application define the keys required to access the application’s files. Consequently, moving from one elementary file to another in the same directory does not alter the setting of the authentication state variables. However, selecting a new directory does change the authentication state. In other words, the authorizations do not follow as you navigate from one directory to another, unless the files in the new directory use the same authorization files as the files in the old directory.
As expected, when moving into a subdirectory of the current directory, the authorizations remain the same, unless a new authorization file is present. If this is the case, then the authorizations are cleared and authentication with the new PIN or key must be performed.
