March 2004, Issue 164

BasicCard 101(Part 1):
Program Your First Smartcard

---

---

Start • Unpacking the Kit • First Steps • Write Terminal Programs • Pick Your API • Sources and PDF

Although I have as many credit cards in my wallet as the next guy, I haven’t had much exposure to so-called “smartcards,” except for the smartcard that fits into the front of my TV satellite dish receiver. Apart from knowing that this is what prevents my receiver from delivering any programming until I actually subscribe for it, I haven’t paid too much attention to it. I expect that the satellite-programming provider is hoping that no one is getting too familiar with its smartcard!

Conventional credit cards contain a magnetic stripe that can hold data for numerous purposes. This stripe is reasonably robust and easy to read, but it isn’t totally secure. The data contained therein can be read by any card reader and duplicated. On the other hand, the smartcard contains an internal microcontroller that runs a program as soon as it’s inserted in a smartcard socket.

The firmware running in the smartcard is an interpreter with a passive nature, which means that instead of initiating its own actions, it merely responds in a predetermined way to commands sent in from the outside world. Furthermore, like most modern microcontrollers, its program memory can be locked so that it can be neither examined nor modified by any external means. Smartcards generally contain encryption routines built in their firmware. The combination of the three aforementioned characteristics makes these devices particularly well suited for applications requiring high security. In the case of my satellite dish receiver, this high level of security is used to selectively unlock reception of the various channels that I pay for with my monthly subscription.

Because smartcards originated in the high-security arena of the electronics world, their internal workings were kept pretty secret, and programming them hasn’t been something that the average Circuit Cellar reader could expect to do. I recently came across a company that produces smartcards that can be programmed by anyone who uses its inexpensive development kit and knows the Basic computer language. As an added bonus, the necessary development software may be downloaded for free, and the smartcards themselves can be purchased for a few dollars apiece in small quantities. In this article I’ll introduce you to these devices and describe a simple application that you can implement with them.

 ZeitControl SMARTCARD

ZeitControl Cardsystems is a German company that produces smartcards and related products. To make the adoption of these devices as simple as possible, ZeitControl markets the inexpensive development kit ($59) shown in Photo 1. The kit includes a card reader, several BasicCards, and all the necessary software. The software and manuals (PDFs) are available for free on the company’s web site (www.zeitcontrol.de) if you want to check things out before you make a purchase.

(Click here to enlarge)

Photo 1—Check out the development kit. Don’t bother unwrapping the CD-ROM. You should download the up-to-date software directly from ZeitControl’s web site.

The smartcards themselves are available in different models to suit various applications. Table 1 lists selected models recently available through ZeitControl’s on-line store. Although it isn’t listed in Table 1, the least expensive Compact card, with its 1 KB of flash memory EEPROM, is sufficient to store a small user program and a limited amount of nonvolatile data storage. More complex applications can be handled by the Enhanced and Professional models, which sport up to 32 KB of EEPROM as well as more RAM.

Table 1—Visit ZeitControl’s on-line store to learn about these versions of the smartcard.

The card’s operating system is a Basic interpreter. Like Java, it executes P-code, but the Basic P-code is different from Java’s P-code. The Enhanced card’s interpreter is contained in a 17-KB ROM memory. The Professional cards use various amounts of flash memory for the interpreter, so it can be upgraded and customized by Zeit more easily as a result. Because P-code consists of short “tokens” representing commands and functions, a substantial user program can fit within the 8-KB EEPROM available in the larger Enhanced cards, for example. 

Apart from the low-end Compact card model, all the other models contain a fairly comprehensive implementation of the Basic language. For instance, along with byte, integer, and long integer numeric data types, these cards also support IEEE floating-point numbers. A DOS-like file system is available, using the EEPROM as the storage media. String conversion utilities are also available.

Because of their intended use for commerce, all BasicCards come with some encryption capability built in to the operating system. This is an important consideration because encryption routines are complex, and most users (myself included) do not have the knowledge to program these functions from scratch. The Professional cards, in particular, contain public Key encryption algorithms such as RSA and Elliptical Curve, as well as AES and SHA-1.

All BasicCards connect to the outside world via a rectangular array of eight metallic pads on the card. When the card is inserted into the reader, tiny fingers contact the five pads necessary for operation. To allow the cards to work reliably over time, the pads are plated with a precious metal coating that looks like gold. Figure 1 shows the pin out of the device, which follows the ISO standard for smartcards. Photo 2 shows the card itself.

(Click here to enlarge)

Figure 1—Take a look at the connections to the BasicCard pads. Note that the larger ones are the power terminals.

 

(Click here to enlarge)

Photo 2—The BasicCard MCU is under the gold contact area.

In addition to the power and ground pads, which are a bit larger, there are three other signal lines: *Reset, I/O, and Clock. The *Reset line, when pulled low, resets the internal microcontroller. The Clock line provides a clock for the BasicCard’s MCU. I don’t know how they managed to fit so powerful an MCU into such a thin card, but they decided against fitting a quartz crystal in there, so you must provide the clock. Smartcards can operate with up to a 5-MHz clock. If you pick a 3.579-MHz clock, the BasicCard communicates at the standard communications rate of 9600 bps. The NTSC TV color burst frequency is 3.579 MHz. Because such crystals are extremely cheap, I suspect this influenced the BasicCard design.

The last line is the I/O line, which is used for bidirectional communication between the BasicCard and the host. Basically, it’s an asynchronous 8-bit protocol with start and stop bits at TTL levels so you can interface it easily with the asynchronous port on your MCU.

The BasicCard is a slave device: it only transmits data when the host commands it to do so. The only exception to this is after the *Reset line is pulsed low. At that point, the BasicCard performs an answer-to-reset (ATR) procedure, which sends out a string of characters and identifies the device to the host. Therefore, however you choose to hook up the BasicCard to a host MCU, you must ensure that the MCU port connected to the I/O line is set up as an input immediately after a reset. Then, after reading the ATR string that’s sent out by the BasicCard at reset, you can switch its direction to output and begin to issue commands to the card. Here, too, after a command is sent to the card, the port must be switched back to an input in preparation for receiving the response from the card. Although this can be done using the hardware UART found in most MCUs, it’s probably easier to use a software UART routine and switch the data direction line of the MCU port pin from input to output as required.

All data transfers between the card and host are done using data packets, the exact format of which is specified by the ISO/IEC 7816-3 standard. This specification actually contains two standards: T=0 and T=1. The Enhanced cards use only the faster and more versatile T=1 block protocol. The Professional cards also support the T=0 protocol. The T=1 protocol includes longitudinal redundancy check (LRC) error checking. Chapter 7 of ZeitControl’s BasicCard manual gives a detailed description of the ISO 7816-3 standard, containing enough information to allow you to write BasicCard drivers for the MCU of your choice. Next month, I’ll describe the BCCARD library, which allows Atmel AVR MCUs running BASCOM compiler code to interface to BasicCards.