Previous Table of Contents Next


Testing and Debugging

A smart card is explicitly constructed to keep hackers at bay. It includes many hardware and software features that make looking inside a smart card difficult. Unfortunately for the card-side programmer, debugging looks surprisingly like hacking from a smart card’s point of view. Thus, many of the features of a smart card that make it such an attractive, secure, personal computing platform make it at the same time very difficult to deal with as a software development platform.

In the best situations, debugging and testing of card-side software proceeds in four phases:

1.  Simulation. During the simulation phase, you run your smart card program in its software development environment typically on a workstation or Windows PC. Calls to the smart card API are simulated, including the effects of these calls on a file system or to a communication channel. Returned values faithfully reflect the result of the call. Simulation environments allow you to single-step through your program at the source code level.
2.  Emulation. During the emulation phase, you download your code into the actual chip that will be in the target smart card, but rather than being mounted in a card, the chip is mounted on a personality board of an in-circuit emulator. This phase is more problematic than the simulation phase. Because emulators are such excellent hacking tools, not just anybody can buy an emulator for smart card chips. A viable alternative is to use an emulator for a non-smart card version of the chip you are developing (that is, an off-the-shelf version of a chip with the same instruction set). Emulation environments let you single-step through your program at the assembly language level. The theory is that your program behaves exactly as it would in an actual smart card. The theory has not always been borne out by practice, but emulation is close to actual execution.
3.  Scripting. You can do scripting against a simulation of your program, an emulation of your program, or an actual smart card containing your program. A script is simply an executable description of some task that the card is expected to perform. It is a simulation of the terminal side of a smart card application. Scripts send commands to the card and monitor the card’s response, reporting an error condition if the response is not as expected. By building scripts for all the demands that will be placed on your card and running them against the card, you can make sure that your program does what it is supposed to do. Systems such as the Aspects SmarTest system (http://www.aspects-sw.com) are explicitly built for the purpose of testing smart card software.
4.  Integration. The final step in card software testing and debugging is to connect all the parts and components together and run the whole system just as it would be run in live use. This is typically done in the laboratory first, then with users from your own organization (alpha test). Closed population alpha tests—all the employees in a particular building or organization, for example—are a popular way to shake out smart card systems with real users. Next, the system is released to one or two friendly customers (beta test) and finally placed in a limited field test. Even though they are full-fledged computers, the smart card form factor invites everyone handling the card to expect it to work as easily and flawlessly as a credit card.

Linking and Loading

Writing, testing, and debugging code for a smart card is only half the problem. The other half is actually getting the code in use. Unlike writing code for a desktop PC, you can’t just put it on a public Web site and let everybody help themselves. Not yet, at least.

When it comes to loading code onto a smart card, we come right up against the question of whose card it is. The owners of some cards may not want your incredibly creative Hunt the Wumpus game on their card. The owners of other cards may allow your game on-board, but only after you and your code have been thoroughly checked out.


Note:  
Keep in mind that the owner of the card is not necessarily the person holding or using the card. You are the cardholder of the credit cards in your wallet or purse, but if you check the fine print, you’ll find that you don’t own them. You do own the Multiflex smart card that comes with this book, but you probably don’t or won’t own the smart card provided to you by your bank. The owner of the card, not the holder of the card, will by and large have the final say as to what applications can and cannot be loaded onto the card and what conditions they must satisfy before they are loaded.

One way of controlling the code that gets onto a particular smart card is to program the loader to check for a digital signature of some sort associated with the code, and only load code that is signed by an authenticated and authorized entity. You can easily imagine, for example, that One Bank will only allow code on its cards that has been approved and signed by One Bank.

On the other hand, just as there are people who will download code from anywhere onto their personal computers, there will be individual smart card cardholders who will be willing to load code onto their smart cards with no check whatsoever. But this brings up another consideration. What if Application A decides to mess with the data for Application B? Is it B’s responsibility to keep its data secure from A, is it A’s responsibility not to mess with B, or is it the owner’s responsibility to keep A and B from fighting? If it is B’s responsibility, then can B hide its data from the card owner while it’s hiding it from A?

Last but certainly not least, how does your program work with the loader to find the entry points to the API that it was written against on this particular smart card? Currently there aren’t any standards or even any conventions for linking new code into an existing smart card code body.


Previous Table of Contents Next