The file structure, commands, and data protection mechanisms in microprocessor-based cards of the EMV standard

Data objects and their encoding
Any application of a microprocessor card uses a certain set of data elements (Data Element) — minimal units of information that are identified by their name, content, and format (digital, binary, symbolic, and mixed formats are allowed).
Data elements are logical structures, and for their storage in card memory, they are cardped (encoded) into physical data objects (Data Object). There are various forms of displaying data elements in data objects. The BER-TLV encoding defined by the IS0/IEC 8825 standard is widely used in the IPC.
According to IS0/IEC 8825, each data object is defined by three fields: tag, length, and value.
The Tag field consists of one or more bytes. It encodes the class, type, and ID of the data object (the Tag Number that identifies this data object). In EMV specifications, the Tag field is 1 or 2 bytes long. The structure of the Tag field is shown in table. 3.1 and 3.2.
As can be seen from table. 3.1, the bit BB of the highest, i.e. the leftmost byte of the Tag field, defines the type of data object. A data object can be one of two types: a primitive Data Object and a composite object. The Value field of a primitive data object contains the value of the data element.
The value field of a composite data object contains one or more primitive and composite data objects. The Value field of a composite data element is called a template.
Bits B8 and B7 of the highest byte of the Tag field (see table. 3.1) define the class of the data object. Depending on the values of these bits, there are the following classes of data objects:
00-universal class (data objects of this class are not used in EMV). The highest half-byte (4 highest bits) of the first byte of The tag field of a universal class data object changes from ‘ O’h to ‘3’h (as before, here and further on, the h symbol denotes the representation of a number in hexadecimal notation);
01-the application class contains data objects and templates, the formats and values of which are defined for all applications related to a particular industry (for example, the non-cash financial card payments industry). The highest half-byte of the first byte of the Tag field of the application class data object changes from ‘4’h to’ 7’h. data objects of this class in EMV specifications include the card number, card expiration date, the contents of the second track of the card’s magnetic stripe, service code, cardholder name, country code of the Issuer, and so on.;
— a context-specific class contains primitive
data objects defined for a specific application (for example, Debit/Credit EMV applications). The values and formats of such data elements may be determined at the discretion of the payment system operator. The first half-byte of the first byte of the Tag field of a context-specific class data object changes in the range from ‘8’h to’ B’h. Most EMV application data objects belong to this class;
—a private class contains primitive and composite objects
data types defined by the app Issuer at its discretion. Obviously, the first half-byte of the first byte of the Tag field of a private class data object changes from ‘ C’h to T’h.
If all bits are B1, … If the first byte of the Tag field is equal to 1, then the Tag field contains the second byte, the structure of which is shown in table. 3.2. In the second byte, only the highest bit (B8) is not used for encoding the tag ID. This bit determines whether the Tag field contains other bytes. If it is equal to 1, the Tag field contains at least one more byte. Otherwise, the second byte of the Tag field is also the last byte of this field. In the standard, bit B8 of the second byte of the Tag field (if This byte exists) is always 0, since the maximum size of the Tag field is two bytes.
The length field in the ber-TLV encoding of the data object defines the number of bytes of data in the Value field. In its specifications, the Length field is set to one, two, or three bytes. If bit B8 of the highest (leftmost) byte of the field is 0, the Length field consists of a single byte. In this case, bits B7, …, B1 defines the number of bytes in the Value field. Obviously, one byte of the Length field is sufficient to encode data in the Value field of no more than 127 bytes.
If the Value field is larger than 127 bytes, bit B8 of the highest byte of the Length field is set to 1, and the subsequent bits of this byte determine the number of bytes used to represent the Length field. In the case of the EMV standard, this number of bytes can take only two values— 1 or 2. Note that two bytes of the Length field are sufficient for encoding data in the Value field that does not exceed 255 bytes, and three bytes are required for encoding data between 256 and 65,535 bytes.
Note that the BER-TLV data encoding method described above allows you to uniquely determine its ID (Tag field), size (Length field), and value (Value field) for a specific data object.in other words, perform the reverse conversion — get the data ID and value. Thus, the BER-TLV encoding is a universal data representation tool. You just need to agree on the semantic load of tags (IDs) and formats of encoded data.
At the same time, you need to pay for the universality of data representation. In this case, the fee is for an increased size of data objects due to the need to use the Tag and Length fields.
As an example, we give the details of the ber-TLV encoding of the primitive Application Interchange Profile data object:
All data elements used in EMV 4.1 specifications are contained in table. B1 Applications In Book 1 (data elements that can be used in the card application selection procedure) and in table.A1 of Appendix A of Book 3 (other data used for processing the transaction). Both tables share a common structure and define for each data element:
name (name) of the data element defined in the EMV specifications;
description of the data element (brief purpose of the element in EMV applications);
the format of data item: p nbr (digital format item size nbr digits), Pb YYMMDD (numeric date format), an nbr (alphanumeric format data item size nbr of characters) b (binary format);
tags of templates where the data element can be located;
source of the data element (the source can be the card, terminal, and host of the Issuer);

• tag of the data element;
• length of The value field of the data element.

General information about the card file structure
The operating system of the card microprocessor supports a multi-level tree File structure defined by the ISO 7816-4 standard. Most of the card application data is stored in files in this file structure. The files are located in the user part of the EEPROM (User Memory), which is smaller than the size of the entire EEPROM, because part of this memory is reserved for the needs of the operating system.
According to ISO 7816-4, there are two types of files in IPC:
• DF files (Dedicated File), or directories, which are logical structures that define sections of the user part of EEPROM memory and contain other DF files and EF files (Elementary File). The card contains at least one DF file, called an MF file (Master File). The MF file is the root file of the card tree file structure and thus contains all MPC files. This is the only required card file. As directories, DF files do not directly contain data, but are so – called access points (entry points, in the terminology of graph theory, branch points) to other DF and EF files. The card operating system and card applications may need information about the DF file to perform their functions. This information is contained in the file header, which in the case of the IPC file structure is called File Control Information (FCI);
• EF files (Elementary File) containing data from the card and its applications. Each EF file must belong to one of the card’s DF files (possibly an MF file), which is referred to as the parent DF file in relation to this elementary file. As with DF files, each EF file can have an FCI “header”-

The root directory of the MF file contains one elementary EF1 file and two DF1 and DF2 directories.
An EF1 file of the MF file level can contain administrative information that is common to the entire card and information that is necessary for security. E1example, such General information can include the serial number of the chip (ICC Serial Number), the PIN code of the card holder, access control keys, etc.
The DF1 directory contains four elementary files containing data for the debit payment application, while the DF2 directory contains two elementary files and the DF21 subdirectory containing data for the e-wallet application.
In General, the structure of the FCI (file header) is defined in section 5.1.5 of ISO 7816-4. According to this standard FCI can be represented as three data objects
The FCP (File Control Parameters) Template object contains file management parameters, such as the file name, ID, size, descriptor, maximum record size, file access conditions, and so on.This object is mainly used by the card operating system.
The FMD (File Management Data) Template object is used to represent the application’s control data, such as the application name (Application Label) and its expiration Date.
The FCI Template object in accordance with ISO 7816-4 can store both file management parameters and application control data. In EMV specifications, the FCI Template contains the file name and information used to identify the application-
card research. The FCI Template data object is returned to the terminal in response to the SELECT command (see clause 3.10).
Next, when describing the DF and EF files, we will use the structure of the FCI object to illustrate an example of one specific implementation of a microprocessor card.

The File Descriptor data element (Tag ’82’) determines for the card operating system that the file in question is a directory.
The File Identifier data element (Tag ’83’) is encoded with two bytes and takes a value unique to the entire card (the uniqueness must be controlled by the card operating system when creating the DF file). The File Identifier element is used to uniquely identify a DF file among other files in the card file system. In accordance with ISO 7816-4, the File Identifier data object for an MF file has a fixed value of ‘ 3F00’h.
The DF Name data element also identifies the file and is up to 16 bytes long.

The DF Attributes data element contains 3 bytes, of which the first byte is used to encode the DF Nature data element, and the last 2 bytes are used to encode the size of the EEPR0M memory available for this file, expressed in bytes. In many implementations, the DF file does not have a fixed size. When creating it, the operating system does not allocate the eepr0m area that will contain files belonging to the DF file. Therefore, in such implementations, the value of the last two bytes of the DF Attributes data element matches the size of the entire eepr0m memory card available for applications.
The DF Nature data element (1 byte) contains the following IDs:
DF Phase Indicator-indicates the current phase of using the DF file. Possible indicator values: personalization Phase, utilization Phase, and block Phase);
Payment System Indicator-indicates whether the DF file corresponds to a payment application;
Autonomous Security Management Indicator-indicates whether the application defined by the DF file uses its own key system, or whether keys shared by all card applications are used;
PIN Management Supported Indicator-indicates whether the application defined by the DF file uses its own PIN value, or applies a single PIN code for the entire card.
The data object “Conditions for creating child DF and EF files” defines the conditions under which child files can be created for this DF file during the card personalization stage.
The MPC defines various conditions for DF and EF files under which a particular command related to creating/deleting a file, creating a file record, or processing file data can be executed. These conditions are called the conditions of access (access conditions). The command access conditions are defined at the IPC file level and are set in the header of the FCI file.
Encoding and denoting all possible conditions under which the command is allowed to run

The semantic load of command access conditions is distributed as follows:
ALWAYS-the command can be applied to a file without any restrictions;
The AUTH command can only be applied to a file if the command Issuer has been successfully authenticated;
The MAC command can be applied to a file if the data integrity of the command is successfully checked;
The ENC command is executed with its data encrypted;
The ENC + MAC command is executed if the integrity of its data is successfully checked and its data is encrypted;
The AUTH + ENC command can be applied to a file if authentication of the command Issuer is successful and the command data is encrypted;
The AUTH + ENC + MAC command can be applied to a file if authentication of the command Issuer is successful, provided that the integrity of the command data is checked and the command data is encrypted;
NEVER-the command cannot be applied to a file under any circumstances.
The data element “Conditions for creating child DF and EF files” defines access conditions for commands for creating child files in the folder under review during the card personalization stage. The specific type and names of these commands depend on the operating system used in the chip card.
The FCI Proprietary Template data element is mandatory for EMV applications because it contains the mandatory Application Label data element (Tag ’50’). The FCI Proprietary Template data element defines the data required for selecting an application, as well as for selecting the Application Interchange Profile. (This will be explained in more detail in the description of the application selection command in clause 3.10.)
According to ISO 7816-4, there are two ways to link to a DF file in order to select the latter:
Link using FID (File Identifier). In this case, the terminal must know the card file structure, and before it selects the DF file, all the directories containing it (parent directories) must be selected first. For example, in the case of the file structure shown in Fig. 3.1. in order to select a DF21 file by FID, the terminal must first select the MF file, then the DFP file, and then the 0P21 file.
The link with the use of the DF Name. In this case, the terminal can select a DF file without first selecting the directories containing it.