This article introduces the basic knowledge that should be kept in mind when implementing Felica reading, which is one of the most popular IC cards in Japan.
You will have a general overview of the system, which will be useful for your future design and implementation.
What is "Felica"?
There are many specifications for IC cards, and Felica is one of them, developed and managed by Sony, and characterized by its high security. In Japan, Felica is used for transportation IC cards such as Suica.
IC Card Standards
The following standards are widely used.
- Type A (Mifare)
- Type B
Since the method of connection differs depending on the standard, it is important to first check which standard the card to be handled corresponds to.
Reading of Cards
Here we'll see how to read cards.
Detecting and Connecting Card Readers
To read a card, it is of course necessary to connect the card reader to the terminal where the application is to be executed. This is actually another area to pay attention to, since different card readers require different SDKs and communication methods.
Check Card Reader Compatibility Standards
- Type A (Mifare)
- Type B
Use a card reader that is compatible with the IC card standard you are using.
By placing the IC card over the card reader, the reader detects the card. However, at this point, the card is not yet connected to the terminal where the application is executed.
Connecting to the Card
Connect the application and the IC card. After connecting the card reader and the application, a connection must also be established with the card.
Once the connection is established, the ATR can be obtained.
What is Card ATR?
ATR stands for (Answer To Reset). It is, for example, a string like the following, which contains information about the card status, protocol (card standard mentioned above), etc.
3B 8F 80 01 80 4F 0C A0 00 00 03 06 11 00 3B 00 00 00 00 42
Why It Says "Reset"?
You may be wondering why Answer To "Reset" includes information about card status, protocols (card standards mentioned earlier), etc.
The term "Reset" here means that the IC card is electrically reset and restored. This response (Answer) is the ATR.
Communication with the Card
Once you have connected with Felica, you can finally communicate. By sending commands as requests, responses can be obtained from the card.
APDU (Application Protocol Data Unit)
APDU (Application Protocol Data Unit) is an international standard for commands used to communicate with IC cards. Communication is performed by creating these APDU commands and sending them to the card. The following is an example of APDU.
Send APDU: <<< FF AB 00 00 0F 06 01 01 02 12 E4 1C 36 0C 01 8F 10 01 80 00 Resp APDU: >>> 1D 07 01 01 02 12 E4 1C 36 0C 00 00 01 A0 00 24 C9 10 01 2C 8D 18 36 00 00 00 00 00 00 90 00
Felica has a value not found in other card standards called "IDm". This is an identification number for the card managed by Sony and plays a role in the security of the card.
The APDU to obtain the IDm of a Felica card is as follows.
Send APDU: <<< FF CA 00 00 00 Resp APDU: >>> 01 01 02 12 E4 1C 36 0C 90 00
Include IDm in subsequent requests
Depending on the request being sent to the card, it may be necessary to include the IDm in that request. Therefore, it is a good idea to start communication by first obtaining the card IDm.
Creating and Sending APDUs
From this point on, you will need to build your own APDUs according to the requests you wish to send to the card. The APDUs accepted vary depending on the type of card, so it is necessary to check the card specifications.
APDUs are generally configured as follows.
|Lc||n byte||data length (size)|
|Data||n byte||data body|
|Le||n byte||response length|
For example, the APDU to obtain the IDm mentioned earlier is configured as follows.
FF CA 00 00 00
- CLA: FF
- INS: CA
- P1: 00
- P2: 00
- Lc: None
- Data: None
- Le: 00 （No Check）
Checking the Response APDU
By sending an APDU to a card, a response is returned from the card. The response must include a status code, as required by international standards.
Resp APDU: >>> 01 01 02 12 E4 1C 36 0C 90 00
The last two bytes (90 00) are the status code.
- 90 00: Normal completion
- 6A 82: File does not exist
There are a variety of status codes, such as For more details, please refer to the following links.
Decoding byte strings
Since the response is a sequence of bytes, it must be converted to a human-readable format.
In some cases, the number of bytes in the response is the number of bits of information required. In the case of bit specifications, the bits must be converted from hexadecimal to binary and then counted.
For example, 2C 8D, which is two bytes, can be converted to bits as follows
If the specification says the upper 4 bits of ↑, then 0010 is the required information, which is further converted to the required format and used.
Disconnect from the Card
After communication is complete, disconnect from the card. For example, when reading multiple cards in succession, it is necessary to disconnect the current card first.
Simply releasing the card from the card reader will, of course, de-energize the card, but depending on the application implementation, the connection may be still alive.
Disconnect from the Card Reader
When exiting the application, the connection to the card reader should be also disconnected.
This article introduced the life cycle of connecting to and reading an IC card.
Although it may seem as if information flows just by touching the card, in reality it is necessary to understand the complex specifications for communication.
In addition, since the response is in the form of a byte string, it is necessary to implement a human-readable conversion of the byte string.
It is not as easy as it sounds to "just read the response" (writing is even more difficult), so it is advisable to be cautious.