Previous | Table of Contents | Next |
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 cards 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:
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 cant 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, youll find that you dont own them. You do own the Multiflex smart card that comes with this book, but you probably dont or wont 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 Bs responsibility to keep its data secure from A, is it As responsibility not to mess with B, or is it the owners responsibility to keep A and B from fighting? If it is Bs responsibility, then can B hide its data from the card owner while its 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 arent any standards or even any conventions for linking new code into an existing smart card code body.
Previous | Table of Contents | Next |