Since the article is introductory and overview, we will consider the simplest type of smart cards-SIM cards, I believe that there are most such cards on the planet right now.
By today's standards, the SIM standard looks archaic, but it is ideal for the first acquaintance with the world of smart cards, mastering the principles that are the basis of this standard will facilitate further immersion in the topic.
If you are a "card reader", you are unlikely to learn anything new for yourself, except that some not very clear points will be sorted out, or maybe you will sort out what the author did not understand (but, I remind you, we keep within the framework of SIM!).
A smart card is a software and hardware complex, in fact-a miniature computer, which includes at least:
Often, but not always, the card also includes a Java VM. The OS itself is not visible to the end user.
The API role is used to exchange data with the card via the so-called APDU.
The set of different APDUs consists of a set of commands, each of which has the following structure (according to ISO7816-4):
APDU is usually written as a set of hexadecimal digits, like this:
A0 A4 00 00 02 3F00
For GSM SIM cards, use CLA = A0.
Here are some instruction codes:
In response to APDU, the card always returns at least 2 bytes, the so-called Status Word (SW),
and the first and second bytes are called SW1 and SW2, respectively. SW can be used to determine the execution status of a command, with SW1 usually providing basic information and SW2 providing additional information. In the case of SIM cards, success will be indicated by the statuses 90 00 and 9F xx (here xx is a hexadecimal digit, the length of additional information, which is described below).
In addition to SW, the card can also return data. There are also commands that allow you to get additional information after completing them.
The following command is used for this purpose:
GET RESPONSE
In order to use the "services" of this instruction, keep in mind that it must be called immediately after the command whose result you want to request. If you call any statement other than GET RESPONSE, the context of the previous command will be lost.
If any instruction allows you to use GET RESPONSE after its call, then in SW2 it returns the amount of data in bytes that the GET RESPONSE command returns.
One of the most striking applications of GET RESPONSE is its use after the SELECT command — it allows you to get useful information about the selected file system object.
By the way, it's time to think about the card's file system. This system is hierarchical, there is a root folder (Master File, MF), regular folders (Dedicated File, DF) and, in fact, files (Elementary File, EF). Each file system object has an identifier (File ID, FID), which, in the simplest case, consists of four hexadecimal digits and which replaces its name. For example, MF always has an ID 3F00. Each card standard has its own list of reserved file identifiers. For example, the address book file on the SIM has the identifier 6F3A, and the file for storing SMS has the identifier 6F3C. Standard files also have pronounceable names (just for human convenience, the API doesn't use them). For the files listed above, they are as follows:
EF ADN for 6F3A;
EF SMS for 6F3С.
In the case of SIM cards, standard usage scenarios do not provide for modification of the file structure, i.e. it is not possible to create an EF or DF.
You can only modify the contents of files. Of course, life also dictates non-standard scenarios, but we will not consider them now.
The smart card API provides manipulation of three types of files:
The API does not have the ability to request a list of all files/folders for MF or DF, respectively. In order to check the presence of a file at the specified path, you must try to select this file with the SELECT command and analyze SW.
The types of generalized file operations are shown in this table:
I will briefly explain the last two commands:
Usage example-the mechanism for activating fixed-dial mode (when you can only call subscribers from a special phone book) is based on disabling the main phone book file of the SIM card. I don't know about other applications of this mechanism.
Having decided on the generalized types of operations on files, we can proceed to get acquainted with the principles of access control.
These principles are based on the following concepts::
Possible access conditions:
Both PIN codes are presented to the card by the VERIFY CODE command. ADM is presented by a proprietary team (whichever team the manufacturer wants, it uses, since this is not regulated by the standard).
Presenting a code is an operation that extends the card session. If you have presented a PIN or ADM once, you can perform operations with all files that require the corresponding code until the session ends.
For each file and operation, the card stores a mapping: generalized operation-access condition.
For example, for the EF ICCID file, which stores the unique serial number of the card (not to be confused with the mobile subscriber number), the AC values will look like this:
For the main phone book:
If the presentation of a certain code is disabled, as operators often do with PIN1 now, then this code is considered presented from the beginning of the card session.
For the SELECT operation, all AC values are Always equal. To find out the AC for a specific file, select it ,and then run the GET RESPONSE command.
For folders on SIM cards (MF and DF), AC does not apply at all. When an operation is performed on a file that is considered invalid from the AC's point of view (such as an attempt to update the EF ICCID), the operation will be denied, and an error code will be provided in SW.
Of course, what I have described here is not a real file system — as a rule, behind this abstraction, at the OS level, is hidden the familiar FAT.
In conclusion, I simply have to give an example of using this API in real life.
I think many people have already guessed (or knew?) that the most famous and popular device that uses this API constantly and intensively is an ordinary mobile terminal.
PS:
In the next article, I plan to talk about how you can apply the knowledge you have gained now, working with the card programmatically.
PPS: Thanks to the kind people for the invite!
By today's standards, the SIM standard looks archaic, but it is ideal for the first acquaintance with the world of smart cards, mastering the principles that are the basis of this standard will facilitate further immersion in the topic.
If you are a "card reader", you are unlikely to learn anything new for yourself, except that some not very clear points will be sorted out, or maybe you will sort out what the author did not understand (but, I remind you, we keep within the framework of SIM!).
A smart card is a software and hardware complex, in fact-a miniature computer, which includes at least:
- processor;
- random access memory;
- data storage subsystem;
- operating system.
Often, but not always, the card also includes a Java VM. The OS itself is not visible to the end user.
APDU
The API role is used to exchange data with the card via the so-called APDU.
The set of different APDUs consists of a set of commands, each of which has the following structure (according to ISO7816-4):
| Element | Size (bytes) | Description |
|---|---|---|
| CLA | 1 | team class |
| INS | 1 | instruction code |
| P1 | 1 | parameter #1 |
| P2 | 1 | parameter #2 |
| L | 1 | length of data transmitted to the card. |
| Data | L | data |
APDU is usually written as a set of hexadecimal digits, like this:
A0 A4 00 00 02 3F00
For GSM SIM cards, use CLA = A0.
Here are some instruction codes:
| Instruction manual | Description |
|---|---|
| A4 | SELECT FILE |
| B0 | READ BINARY |
| B2 | READ RECORD |
| C0 | GET RESPONSE |
| 20 | VERIFY CODE |
| D6 | UPDATE BINARY |
| DC | UPDATE RECORD |
In response to APDU, the card always returns at least 2 bytes, the so-called Status Word (SW),
and the first and second bytes are called SW1 and SW2, respectively. SW can be used to determine the execution status of a command, with SW1 usually providing basic information and SW2 providing additional information. In the case of SIM cards, success will be indicated by the statuses 90 00 and 9F xx (here xx is a hexadecimal digit, the length of additional information, which is described below).
In addition to SW, the card can also return data. There are also commands that allow you to get additional information after completing them.
The following command is used for this purpose:
GET RESPONSE
In order to use the "services" of this instruction, keep in mind that it must be called immediately after the command whose result you want to request. If you call any statement other than GET RESPONSE, the context of the previous command will be lost.
If any instruction allows you to use GET RESPONSE after its call, then in SW2 it returns the amount of data in bytes that the GET RESPONSE command returns.
One of the most striking applications of GET RESPONSE is its use after the SELECT command — it allows you to get useful information about the selected file system object.
Data storage subsystem
EF ADN for 6F3A;
EF SMS for 6F3С.
In the case of SIM cards, standard usage scenarios do not provide for modification of the file structure, i.e. it is not possible to create an EF or DF.
You can only modify the contents of files. Of course, life also dictates non-standard scenarios, but we will not consider them now.
File Types
The smart card API provides manipulation of three types of files:
- Transparent
analogous to a regular binary file of any file system.
Tools for working with such files are a couple of commands READ BINARY/UPDATE BINARY.
- Linear Fixed
A file consisting of a fixed number of records, and all records are of the same length. The record length is set when creating the file.
There can't be more than 255 records, and each record can't be longer than 255 bytes.
The work tool is a READ RECORD/UPDATE RECORD pair.
Can be used as an absolute value (by record number) and relative addressing (next/previous, but without cycling).
An example of usage is a notebook on a SIM card.
- Cyclic
In general, it is the same as Linear Fixed, but with the following additional functionality:
When reading: closure — when using relative addressing, moving from the last to the next record gets to the first, moving from the first to the previous record gets to the last.
When writing: only relative addressing is allowed, with access only to the previous record. There is even a special command, only for cyclic files, that updates the oldest record of the file (after that it becomes the newest) - INCREASE.
The first record always stores the newest data, and the last record stores the oldest.
Usage example — a list of previously dialed numbers. In general, files of this type are used much less frequently than files of other types.
The API does not have the ability to request a list of all files/folders for MF or DF, respectively. In order to check the presence of a file at the specified path, you must try to select this file with the SELECT command and analyze SW.
The types of generalized file operations are shown in this table:
| Generalized operation type | Command examples |
|---|---|
| Read | READ BINARY, READ RECORD |
| Update | UPDATE RECORD, UPDATE RECORD, INCREASE |
| Invalidate | INVALIDATE |
| Rehabilitate | REHABILITATE |
I will briefly explain the last two commands:
- INVALIDATE- reversibly changes the state of the file so that:
- a special flag is set for it, i.e. we can find out that the file is disabled.
- depending on the disabled file settings, read and write operations may not be possible.
- REHABILITATE - returns a previously disabled file to its normal state, and any restrictions imposed by the disability are removed.
Usage example-the mechanism for activating fixed-dial mode (when you can only call subscribers from a special phone book) is based on disabling the main phone book file of the SIM card. I don't know about other applications of this mechanism.
Having decided on the generalized types of operations on files, we can proceed to get acquainted with the principles of access control.
Access control system
These principles are based on the following concepts::
- Access Condition (AC) — the card state, within the current session, at which a certain type of operation is possible for a certain file.
- Access conditions, the most famous of which is the presentation of a PIN code.
Possible access conditions:
| Access Condition | Explanation |
|---|---|
| Never | Operation is prohibited |
| Always | This operation is always allowed |
| PIN1 (also known as CHV 1) | To perform the operation, you need to show the card PIN1 |
| PIN2 (CHV2) | To perform the operation, you need to show the card PIN2 |
| ADM | To perform the operation, you must present the administrative code to the card. |
Both PIN codes are presented to the card by the VERIFY CODE command. ADM is presented by a proprietary team (whichever team the manufacturer wants, it uses, since this is not regulated by the standard).
Presenting a code is an operation that extends the card session. If you have presented a PIN or ADM once, you can perform operations with all files that require the corresponding code until the session ends.
For each file and operation, the card stores a mapping: generalized operation-access condition.
For example, for the EF ICCID file, which stores the unique serial number of the card (not to be confused with the mobile subscriber number), the AC values will look like this:
| Read | Update | Invalidate/Rehabilitate |
|---|---|---|
| Always | Never | Never |
For the main phone book:
| Read | Update | Invalidate/Rehabilitate |
|---|---|---|
| PIN1 | PIN1 | PIN2 |
If the presentation of a certain code is disabled, as operators often do with PIN1 now, then this code is considered presented from the beginning of the card session.
For the SELECT operation, all AC values are Always equal. To find out the AC for a specific file, select it ,and then run the GET RESPONSE command.
For folders on SIM cards (MF and DF), AC does not apply at all. When an operation is performed on a file that is considered invalid from the AC's point of view (such as an attempt to update the EF ICCID), the operation will be denied, and an error code will be provided in SW.
Of course, what I have described here is not a real file system — as a rule, behind this abstraction, at the OS level, is hidden the familiar FAT.
In conclusion, I simply have to give an example of using this API in real life.
I think many people have already guessed (or knew?) that the most famous and popular device that uses this API constantly and intensively is an ordinary mobile terminal.
PS:
In the next article, I plan to talk about how you can apply the knowledge you have gained now, working with the card programmatically.
PPS: Thanks to the kind people for the invite!
