Smart card, is it really smart?

Yes, it is. Sort of.

Muhammad Aditya Hilmy
HMIF ITB Tech
9 min readMay 2, 2019

--

Do you know that you have tiny computers inside your pocket? No, I’m not talking about your smartphone. I’m talking about your credit card, student card, train tickets, or any other card which has a tiny chip inside.

What is a smart card?

According to Wikipedia,

A smart card, chip card, or integrated circuit card (ICC) is a physical electronic authorization device, used to control access to a resource. It is typically a plastic credit card sized card with an embedded integrated circuit.

A card’s primary job is to store data. Credit card stores credit card information, student card contains student information, train ticket keeps the current balance and which station you entered, and so on. The information kept inside the card is then retrieved by other systems that need it.

To do this, a smart card contains an integrated circuit (IC) inside. Your electronic train ticket (or student card) isn’t just a piece of plastic, it has electronics sandwiched in between. Try putting it on top of a flashlight to see the insides.

My student card when I put on top of my phone’s flashlight

Above image is an example of a contactless smart card. It communicates to a computer without the need for a physical contact. You can see wires near the edges of the card and a rectangular blob on the upper left of the card. The wires are acting as an antenna and the rectangular blob is actually a microchip. It can be laid out roughly like this:

(Rough) anatomy of a combo smart card

What’s the difference with magnetic stripe card?

Both types of card are capable of storing information, but they have quite a lot of differences. The most obvious answer is how the card is used. A magnetic stripe card is swiped in a reader, while smart card are inserted into a reader or put in proximity to a reader.

In magnetic stripe card, the information is encoded in the magnetic strip in the form of magnetism. When the card is swiped, the reader reads the magnetism and decodes it into an alphanumeric string. Anyone who has the card can practically extract the information contained in the card, it has no protection whatsoever.

In smart card, the information is saved in an electrically erasable programmable read-only memory (EEPROM) and only accessible by the IC — the reader doesn’t have the ability to read the memory contents. This is the biggest difference between the two. While magnetic stripe card is read by a reader, smart card talks to the reader. When a computer wants to retrieve the information stored in a smart card, the computer basically requests the smart card to give it to the computer. The smart card can refuse the request, if needed. This is what makes smart card secure, since a smart card can ask for an authentication to ensure that the computer trying to access the information is legitimate.

Smart card vs ‘dumb’ card

With the ability to secure information, smart card is used in multiple applications. You can use it as a door key in physical access control, or as a key to secure your work computer digitally. Some companies even use smart card as a method to securely sign documents.

How to talk to a smart card?

First of all, we know that communication involves two or more parties. In the case of smart card, the parties are the smart card (a.k.a. integrated circuit cards, or ICC) and the host. The host initiates the communication and powers the card. The card will then respond accordingly.

There are two types of smart card interface, contact and contactless. Cards with contact interface have a pretty notable silver or golden metal on the front. On the contrary, cards with contactless interface don’t usually have a visible metal interface and you put them near a reader to use them. Contact interface is standardized by ISO/IEC 7816–1 to -3, while contactless interface is standardized by ISO/IEC 14443. These interfaces are analogous to the methods of human communication — could be verbal, visual, or written.

ISO/IEC 7816–4 defines the language on which the cards should speak: the Application Protocol Data Unit (APDU). APDU is just a series of bytes — usually represented in hexadecimals — exchanged between the host and the card structured in a standardized way.

There are two kinds of APDU: Command APDU and Response APDU. They both have different structures, as laid out below:

Command APDU structure (source: oracle.com)
Response APDU structure (source: oracle.com)

Command APDU

  • CLA (1 byte) is the instruction class of the APDU. Think of it as the folder name of instructions, it organizes instructions into classes. Examples include classes for file- and security-related commands, or application-specific commands.
  • INS (1 byte) is the instruction of the APDU. It tells the card what to do. For example, write data or read data.
  • P1 and P2 (2 bytes total, 1 byte each) is the parameters of the APDU. This field is used to give additional information for the execution of the instruction.
  • Lc (1 byte, optional) is the length of the data field.
  • Data (arbitrary length) is, well, the data which should be processed by the card. If the instruction is to write data, the data field is the actual data to store.
  • Le (1 byte, optional) is the maximum expected response length. It specifies the maximum number of bytes in the data field of the expected Response APDU.

Response APDU

  • Data field (arbitrary length) is the data returned by the card as a response to the instruction. For example, if the instruction is read card number, the data field in the response APDU would be the card number.
  • SW1 and SW2 (2 bytes total, 1 byte each) is the status word of the execution of the instruction. It basically tells the host whether the instruction is executed successfully or not, and if not, the error message. For example, the status words 90 00 could mean that the instruction is executed successfully, and status words 91 AE could mean authentication error.

But how can I exchange these APDUs to the cards from the software I created? First of all, you’ll need the hardware: a card reader. For proximity cards, it’s called a proximity coupling device (PCD). For contact cards, let’s just say card reader. Different card readers can have different APIs for interacting with your software, but the popular ones are PC/SC and CT-API. You can explore those two APIs by yourself, or just use an open-source library like pyscard. Some libraries even abstract the low-level details of the APDU and provide you with methods like read data, write data, etc. for popular chip brands.

Here’s the thing: different chip card brands can have different sets of APDU. Some brands fully comply to ISO/IEC 7816 standard, some are not. Some even have additional proprietary instructions. You should refer to the respective brands’ datasheets if you want to know how to speak their APDU language — which usually need a non-disclosure agreement (NDA).

Let’s say you wanted to be cool and decided that you’d make your own sets of APDU for a smart card project that you did. You could design your own chip — the transistors and everything, but this requires an enormous effort and extensive knowledge about hardware and IC design. It’s not worth doing if you just want to have a custom APDU set.

Another option is to use something called Java Card™.

Java Card™

Java Card™ allows you to create a program and run it in a smart card — yes, you can run Java in a chip smaller than a coin. It works just like any other Java program: you write the code, compile it, and install it to the card. NetBeans IDE even has a support for Java Card (read this guide if you want to know more).

It sounds awesome that you can code smart card in Java. However, smart card chip is very, very constrained. It has a slow processor speed (think 8- or 16-bit with 3.7 MHz clock speed) and a small storage size (around 64KB in EEPROM and 1KB in RAM). Running a program in such a constrained runtime like a smart card has some major inconvenience.

As you probably know, Java is a programming language that takes away the hassle of memory management from the coder — you can’t even explicitly delete an object. Object deletion is handled by the garbage collector running in the background. With Java Card, however, you don’t have garbage collector running in the background. You also don’t have a mechanism to delete an object. You can manually invoke the garbage collector, but in most cases it’s not recommended. Creating and deleting object is just slow and resource-intensive. You need to create all the objects necessary for the entire lifetime of the card at installation time, and reuse the objects whenever possible.

Java Card doesn’t have the convenience of having dynamic arrays. You need to specify all the arrays you need and their sizes at installation time. You should find a delicate balance between your limited memory and array usability. If you want to concatenate two array, you’ll need a third array to be the buffer. You’ll need to reuse those arrays as well, whenever possible. Consequently, having no dynamic array and the fact that creating and deleting object is expensive, means Java Card has no support for string— byte array is all you have.

Having 8- or 16-bit processor running the program means that you don’t have the luxury of having int data type also. The best that you can get is a short data type, which is two bytes long, so the maximum number you can keep in a single variable is 65535. You also don’t have float, by the way.

Finally, debugging Java Card program is quite hard. On normal Java, you have something called a stack trace that tells you which part of the program has the error. Java Card doesn’t have it. You must be able to diagnose the error using a lovely, two-byte status word (SW1 and SW2) in the Response APDU. You can respond using your own custom status word by using try-catch block in parts prone to error, but any unhandled exception will just output a really beautiful status word: 6F 00 —very informative, right?

Despite all those inconvenience, Java Card is still a rather convenient way to make your own proprietary smart card program. It uses a high-level programming language, i.e. Java. You can also run your program in multiple chip brands that support Java Card, instead of being vendor-locked.

Conclusion

To answer the title, yes, smart card is pretty smart since it’s able to do some computation using its embedded chip to secure the data. On the other hand, smart card is pretty dumb because it has such a small computing and storage resource that you can’t even have int or String. Nevertheless, smart card keeps both our physical and digital world secure.

References:

--

--