Since the article is introductory and overview, we will consider the simplest type of smart cards - SIM cards, I believe that there are most of such cards on the planet now.
By today's standards, the SIM standard looks archaic, but it is ideal for the first acquaintance with the world of smart cards, the assimilation of the principles underlying this standard will facilitate further immersion in the topic.
If you are a "card player", then you are unlikely to learn something new for yourself, except that some not very clear moments will be decomposed on the shelves, or maybe you will decompose on the shelves what the author misunderstood (but, I remind you, we keep within the framework SIM!).
A smart card is a hardware and software complex, in fact - a miniature computer, which includes at least:
Often, but not always, a Java VM is included in the map. The OS, as such, is not visible to the end user.
The API role performs the exchange of data with the map through the so-called. APDU .
Many different APDUs are a set of commands, each with the following structure (according to ISO7816-4):
APDU is usually written as a set of hexadecimal digits, like this:
For GSM SIM cards, CLA = is used A0.
Here are some instruction codes:
In response to the APDU, the card always returns at least 2 bytes, the so-called. Status Word (SW),
with the first and second bytes respectively referred to as SW1 and SW2. By SW, you can determine the status of the command execution, with SW1 usually providing basic information, and SW2 - additional. In the case of SIM cards, the status 90 00 and 9F xx will indicate the success of the execution (here xx is a hexadecimal digit, the length of additional information, which is described below).
In addition to SW, the card can return data. There are also commands, after the execution of which it is possible to obtain additional information.
The command is intended for this:
In order to use the "services" of this instruction, you need to keep in mind that it must be called immediatelyafter the command whose result you want to request. Calling any instruction other than GET RESPONSE will lose the context of the previous instruction.
If any instruction allows GET RESPONSE to be used after its call, then in SW2 it returns the amount of data in bytes that the GET RESPONSE command will return.
One of the brightest uses 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 remember about the file system of the card. This system is hierarchical, there is a root folder (Master File, MF), ordinary 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 identifier 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 the SMS is 6F3C. Standard files also have pronounceable names (solely for human convenience, the API does not use them), for the above files they are as follows:
EF ADNfor 6F3A;
EF SMS for 6F3С.
In the case of SIM cards, the standard usage scenarios do not provide for modification of the file structure, i.e. it is not possible to create an EF or DF .
It is only possible to modify the contents of the files. Of course, life dictates non-standard scenarios, but now we will not consider them.
The smart card API provides for 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 existence of a file at a given path, you must try to select this file with the SELECT command and analyze the SW.
The types of generalized file operations are presented in this table:
I will briefly explain the last two commands:
An example of use - the mechanism for activating the fixed dialing mode (when you can call only subscribers from a special phone book) is based on invalidating the file of the main phone book of the SIM card. I am not aware of other applications of this mechanism.
Having defined the generalized types of operations on files, we can proceed to acquaintance with the principles of access control.
These principles are based on the concepts:
Possible access conditions:
Both PIN codes are presented to the card by the VERIFY CODE command. ADM is presented by a proprietary command (which command the manufacturer wants, he uses this one, since this is not regulated by the standard).
The presentation of the code is an operation of the scale of the session of working with the card, if you have presented the PIN or ADM once, then you can perform operations with all files that require the corresponding code until the session ends.
For each file and each operation, the map 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 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 a SELECT operation, all ACs are Always. To find out the AC for a specific file, you must select it (SELECT), and then execute the GET RESPONSE command.
For folders on SIM cards ( MF and DF ) ACs are generally inapplicable. When an operation is performed on a file that is not valid from the AC point of view (such as trying to update the EF ICCID ), the operation will be denied and an error code will be provided to the SW.
Of course, what I described here is not a real file system - as a rule, behind this abstraction, at the OS level, the familiar FAT is hidden.
In conclusion, I just have to give an example of using this API in real life.
I think many have already guessed (or knew?) That the most famous and widespread 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 gained now by working with the map programmatically.
PPS: Thank you 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, the assimilation of the principles underlying this standard will facilitate further immersion in the topic.
If you are a "card player", then you are unlikely to learn something new for yourself, except that some not very clear moments will be decomposed on the shelves, or maybe you will decompose on the shelves what the author misunderstood (but, I remind you, we keep within the framework SIM!).
A smart card is a hardware and software complex, in fact - a miniature computer, which includes at least:
- CPU;
- RAM;
- data storage subsystem;
- operating system.
Often, but not always, a Java VM is included in the map. The OS, as such, is not visible to the end user.
APDU
The API role performs the exchange of data with the map through the so-called. APDU .
Many different APDUs are a set of commands, each with the following structure (according to ISO7816-4):
| Element | Size (bytes) | Description |
|---|---|---|
| CLA | 1 | team class |
| INS | 1 | instruction code |
| P1 | 1 | parameter no. 1 |
| P2 | 1 | parameter no. 2 |
| L | 1 | the length of the data transmitted to the card. |
| Data | L | data |
APDU is usually written as a set of hexadecimal digits, like this:
Code:
A0 A4 00 00 02 3F00For GSM SIM cards, CLA = is used A0.
Here are some instruction codes:
| Instructions | 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 the APDU, the card always returns at least 2 bytes, the so-called. Status Word (SW),
with the first and second bytes respectively referred to as SW1 and SW2. By SW, you can determine the status of the command execution, with SW1 usually providing basic information, and SW2 - additional. In the case of SIM cards, the status 90 00 and 9F xx will indicate the success of the execution (here xx is a hexadecimal digit, the length of additional information, which is described below).
In addition to SW, the card can return data. There are also commands, after the execution of which it is possible to obtain additional information.
The command is intended for this:
Code:
GET RESPONSEIn order to use the "services" of this instruction, you need to keep in mind that it must be called immediatelyafter the command whose result you want to request. Calling any instruction other than GET RESPONSE will lose the context of the previous instruction.
If any instruction allows GET RESPONSE to be used after its call, then in SW2 it returns the amount of data in bytes that the GET RESPONSE command will return.
One of the brightest uses of GET RESPONSE is its use after the SELECT command - it allows you to get useful information about the selected file system object.
Storage subsystem
EF ADNfor 6F3A;
EF SMS for 6F3С.
In the case of SIM cards, the standard usage scenarios do not provide for modification of the file structure, i.e. it is not possible to create an EF or DF .
It is only possible to modify the contents of the files. Of course, life dictates non-standard scenarios, but now we will not consider them.
File types
The smart card API provides for manipulation of three types of files:
- Transparent is
analogous to a regular binary file of any file system.
The 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, with all records of the same length, the record length is set when the file is created.
There can be no more than 255 records, each record cannot be longer than 255 bytes.
Means of work - pair READ RECORD / UPDATE RECORD.
You can use both absolute (by record number) and relative addressing (next / previous, but without cyclicity).
An example of use is a notebook on a SIM card. - Cyclic
In general - the same as Linear Fixed, but with the following additional functionality:
When reading: closed - when using relative addressing, moving from the last to the next record we get to the first, moving from the first to the previous record, we get to the last.
When writing: Only relative addressing is allowed, referring only to the previous record. There is even a special command, only for circular files, that updates the oldest record in the file (after that it becomes the newest) - INCREASE.
The first record always stores the newest data, and the last one the oldest.
An example of use is 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 existence of a file at a given path, you must try to select this file with the SELECT command and analyze the SW.
The types of generalized file operations are presented in this table:
| Generalized type of operation | 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 invalid.
- read and write operations may not be possible depending on the settings of the invalid file.
- REHABILITATE - returns the previously invalidated file to its normal state, while the possible restrictions imposed by the invalidation are removed.
An example of use - the mechanism for activating the fixed dialing mode (when you can call only subscribers from a special phone book) is based on invalidating the file of the main phone book of the SIM card. I am not aware of other applications of this mechanism.
Having defined the generalized types of operations on files, we can proceed to acquaintance with the principles of access control.
Access control
These principles are based on the concepts:
- Access Condition (AC) - the state of the card, 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.
Possible access conditions:
| Access condition | Explanation |
|---|---|
| Never | Operation prohibited |
| Always | Operation is always allowed |
| PIN1 (also known as CHV 1) | To complete the operation, you need to present your PIN1 card |
| PIN2 ( CHV 2) | To complete the operation, you need to present your PIN2 card |
| ADM | To complete 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 command (which command the manufacturer wants, he uses this one, since this is not regulated by the standard).
The presentation of the code is an operation of the scale of the session of working with the card, if you have presented the PIN or ADM once, then you can perform operations with all files that require the corresponding code until the session ends.
For each file and each operation, the map 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 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 a SELECT operation, all ACs are Always. To find out the AC for a specific file, you must select it (SELECT), and then execute the GET RESPONSE command.
For folders on SIM cards ( MF and DF ) ACs are generally inapplicable. When an operation is performed on a file that is not valid from the AC point of view (such as trying to update the EF ICCID ), the operation will be denied and an error code will be provided to the SW.
Of course, what I described here is not a real file system - as a rule, behind this abstraction, at the OS level, the familiar FAT is hidden.
In conclusion, I just have to give an example of using this API in real life.
I think many have already guessed (or knew?) That the most famous and widespread 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 gained now by working with the map programmatically.
PPS: Thank you kind people for the invite!
