1 - Introduction
My first tutorial, will be in fact just a little writing about smart card development and the required knowledge to start in this world.
The smart card industry is full of standards and it can be hard to understand the purpose of each technology when searching the web. This post doesn't means to be a full specification of the smart card industry, but is meant to help some people who is in an hurry to understand which are the main concepts and technologies used.
2 - What is a Smart Card?
A smart card is a card which contains a micro-controller embedded, containing the processor, volatile memory (RAM) and non-volatile memory (EPPROM and ROM).
Usually, smart cards are used on security applications (authentication, secure data storage) and can be found on many applications on the current world.
For instance, the Portuguese ID card is a smart card which contains the owner's personal information, and contains public/private key pairs that can be used to authenticate the owner. Probably one of the most used smart card types are the SIM cards used to authenticate with the mobile operator.
The smart cards are physically protected to avoid internal sensitive data being exposed.
The smart cards applications work in a client-server approach where the terminal, the computer connected to the card, is the client.
The main standards for communication and physical properties are defined on the ISO/IEC 7816 parts 1 to 15 (yes, it sounds like a light reading).
3 - Smart Card Technologies
The smart cards market is full of standards and proprietary technologies. This means that, to start developing smart card applications, a lot of technologies must be studied.
The main concerns on smart card development are:
- Programming the smart card - Java Card
- Communicating with the smart card - APDUs (Messages)
- Programming the host application - PCSC
- Installing your applet - Global Platform
3.1 - Programming the smart card
Although the resources are scarce inside a smart card, most of them contain an operating system or at least a runtime environment, abstracting the hardware for the programmer.
One broadly used runtime environment is the Java Card Platform. This platform allow applications to be written in a subset of Java. An Java Card application is called Applet. This platform provides an high portability for the developed applet, being it deployable on different cards from different manufacturers without having to re-write most of the application (you will have to adapt your application in case a card doesn't support some of the card-dependent libraries).
The Java Card platform supports multiple applets being installed on the same card protected by an internal firewall. This is a really good property since we can expect that in the future we will all our applications (pass, id, internet sites authentication) only on one card.
3.2 - Communicating with the smart card
To communicate with the smart card, the terminal must send APDUs (Application Programming Data Unit). These APDUs are byte-based commands sent to the smart card. Understanding the format of the APDUs is important since almost all the libraries to connect to smart cards don't do much more than forwarding the commands created by the application.
The format of these commands is composed by 6 fields:
CLA : 1 byte - The type of the command that you are sending. The byte 0x80 means proprietary command, so if you want to forward commands to your application, this is the byte value you will mostly use on CLA.
INS: 1 byte. This represents the instruction/operation to be performed by the smart card. For instance, you could define in your application to return the public key from a random key pair anytime you receive INS= 0x00
P1 and P2: 1 byte, each. These are parameters that are instruction dependent. for instance, in the previous case of the random key pair, we could tell the card that P1 was the size of the key pair.
Lc: 1 byte. This is the length of data to be sent. Besides the P1 and P2 the card can receive more data on the apdus with an arbitrary size (up to 255 bytes). This byte represents the size of that data.
Data: Lc bytes. This is the data.. Following the example, you could set a password to generate new key pairs, that password could be in this data field.
Le: 1 byte. This is the maximum expected length of the smart card response to your command (in the example, the length of the public key).
As a response, the smart card returns 3 fields:
Data: The data returned by the command.
SW1 and SW2: 1 byte, each. This is the response status from the command. 0x9000 means everything went well, any other response is an error code, meaning you will spend lots of time on google trying to find what the code means.
3.3 - Programming the host application
All this effort programming an applet would be worthless if there was no off-card application connecting to the card.
Programming such an application is very simple.
The industry has made an effort to connect to different smart cards with different card readers, to be homogeneous as possible. The solution is the PC/SC standard(Personal Computer/Smart Card), and implementations, with the same interface, can be found for the major operating systems (Linux, Windows, MAC OS).
Using PC/SC is as simple as: Listing the available readers, connecting to a reader, sending APDUs.
The PC/SC abstracts how to handle different readers/or cards meaning that you can have different readers, different communication channels (contact or contactless cards), even remote cards, without having to concern with their physical level protocols.
3.4 - Installing your applet
This subject is very smart card dependent, but an effort has been made to create standards.
The main standard on applet installation is the Global Platform.
Global Platform defines the apdus used to install applications, creating secure channels to the smart card (only authenticated people can program the smart card), selecting the applet on multi-applet cards, etc.
I really advise downloading the Global Platform card specification to understand most of the errors your applet will return on development phase.
Notice that to debug applets on-card you will probably need card-specific tools.
4 - Warning about smart card development
I consider smart card development being very hard. Most of the technologies i referred (Global Platform, PCSC) are documented on hard to read formal documents and understanding how to do stuff can be painful if you do not have the time to read all these standards and just want to create applets in a short time.
A major warning I have to give about Java Card development is that most of its "How-To" was lost with the Sun forums being removed after the company being bought by Oracle. Most of the answers found on the internet provide links to these forums.
5 - Links
For those who want to start developing with the smart cards, I leave links for more deep information, what they talk about, and what is important to get from these:
PCSC - http://www.pcscworkgroup.com/ - Understanding the PC/SC architecture
Muscle Card /PCSC-lite - http://www.linuxnet.com/ - PCSC implementation for linux
GPShell - http://sourceforge.net/p/globalplatform/wiki/Home/ - Global Platform Compliant shell to comunicate with smart cards
Java Card Book - http://www.amazon.com/Java-Card-Technology-Smart-Cards/dp/0201703297 - I really advise reading this book to learn how to program for java cards
Java Card API - http://www.win.tue.nl/pinpasjc/docs/apis/jc222/ - Really useful when developing to java cards
General - http://0x9000.blogspot.pt/ - This blog can be a nice resource for smart card developers
Nenhum comentário:
Postar um comentário