Since the article is introductory and overview, the simplest variety of smart cards - SIM cards will be considered, I suppose that such cards are the most on the planet right now.
By today's standards, the SIM standard looks archaic, but it is ideal for a first acquaintance with the world of smart cards, mastering the principles that are the basis of this standard, will facilitate further immersion in the subject.
If you are a “card”, you are unlikely to learn something new for yourself, unless some not very clear moments will decompose on the shelves, or maybe you will decompose what the author misunderstood (but, I remind, we keep within SIM!).



A smart card is a software and hardware 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 role of the API performs data exchange with the card through so-called. APDU .
Many different APDUs are a set of commands, each of which has the following structure (according to ISO7816-4 ):

Element	Size (bytes)	Description
CLA	one	team class
INS	one	instruction code
P1	one	parameter number 1
P2	one	parameter number 2
L	one	the length of the data transmitted to the card.
Data	L	data

APDUs are usually written as a set of hexadecimal digits, like this:

A0 A4 00 00 02 3F00

For GSM SIM cards, CLA = A0 .
I will give several instruction codes:

Instruction	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 an APDU, the card always returns at least 2 bytes, i.e. Status Word (SW),
with the first and second bytes, respectively, called SW1 and SW2. SW can determine the execution status of a command, with SW1 usually providing basic information, and SW2 providing additional information. In the case of SIM cards, the status of execution will be 90 00 and 9F xx (here xx is a hexadecimal digit, the length of the additional information, which is described below).
In addition to the SW card can return data. There are also commands, after which it is possible to obtain additional information.
To do this, use the command:

GET RESPONSE

In order to use the “services” of this instruction, you need to keep in mind that it must be called immediately after the command whose result you want to request. If you call any instruction 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 will return.
One of the bright applications of GET RESPONSE is its use after the SELECT command - it gives you the opportunity to get useful information about the selected file system object.

Storage subsystem

By the way, it's time to recall the file system of the card. 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 it with a name. For example, the MF is always identifier 3F00 . Within each card standard, there is a 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 pronounced names (solely for the convenience of the person, the API does not use them), for the above files they are:
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. Unable to create 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 manipulations with three types of files:

1. Transparent
   
   analogue of the usual binary file of any file system.
   Tools for working with such files are a pair of READ BINARY/UPDATE BINARY .
   
   
2. Linear fixed
   
   A file consisting of a fixed number of records, with all the records of the same length, the length of the record is set when the file is created.
   There can be no more than 255 records, each record cannot be longer than 255 bytes.
   The work tool is the READ RECORD / UPDATE RECORD pair.
   You can use both absolute (by record number) and relative addressing (next / previous, but without cyclicity).
   Example of use - a notebook on the SIM-card.
   
   
3. Cyclic
   
   In general - 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 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 with reference only to the previous record. There is even a special command, only for cyclic files, which updates the oldest record of the file (after that it becomes the newest) - INCREASE.
   The first entry always stores the most recent data, and the last one keeps the oldest.
   Example of use - a list of previously dialed numbers. In general, files of this type are used much less frequently than files of other types.
   
   

In the API, it is not possible to request a list of all files / folders for MF or DF , respectively, in order to check the presence of a file in 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

Briefly explain the last two teams:

1. INVALIDATE - reversibly changes the state of the file so that:
   
   • a special flag is set for it, i.e. we can learn that the file is invalid.
   • depending on the settings of the invalid file, read and write operations may become impossible.
   
   
2. REHABILITATE — Returns a previously REHABILITATE file to its normal state, with possible restrictions imposed by invalidation being removed.

An example of use is the mechanism for activating the fixed dialing mode (when only subscribers from a special phone book can call) is built on the invalidation of the file of the main phone book of the SIM card. About other applications of this mechanism is unknown to me.
Having defined the generalized types of file operations, we can proceed to become familiar with the principles of access control.

Access Control

These principles are based on the following concepts:

1. Access Condition (AC) - the state of the card, within the current session, in which a certain type of operation is possible for a specific file.
2. 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	Operation is always allowed.
PIN1 (also known as CHV 1)	To perform the operation, you must present a PIN1 card
PIN2 ( CHV 2)	To perform the operation, you must present a PIN2 card
ADM	To perform the operation, it is required to present the administrative code to the card.

Both PIN codes are presented to the card with the VERIFY CODE command. The ADM is presented by the proprietary team (which team the manufacturer wants, this is what he uses, since it is not regulated by the standard).
The presentation of the code is a scale operation of the session of working with the card, if you presented the PIN or ADM once, you can perform operations with all files that require the corresponding code until the session is completed.
For each file and each operation, the map stores a mapping: a generalized operation is an access condition.
For example, for an EF ICCID file that stores a 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 specific code is disabled, as operators often do with PIN1 now, this code is considered to be presented from the beginning of the card session.

For the 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.

To folders on SIM-cards ( MF and DF ) AC generally not applicable. When an unacceptable operation is performed on a file from an AC point of view (such as an attempt to perform an EF ICCID update), the operation will be refused and an error code will be provided in 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 popular device using 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, working with the map programmatically.

PPS: Thanks to the kind people for inviting!