【Felica】Basic Knowledge Required for Implementing Felica Reading

2022/10/29に公開

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.

By reading this article, 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
  • Felica

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
  • Felica

Use a card reader that is compatible with the IC card standard you are using.

Card Detection

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 

Obtaining IDm

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.

APDU Configuration

APDUs are generally configured as follows.

name size description
CLA 1byte command class
INS 1byte command code
P1 1byte parameter-1
P2 1byte parameter-2
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.

https://www.eftlab.com/knowledge-base/complete-list-of-apdu-responses/

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

0010110010001101

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.

Conclusion

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.

Discussion