EMV file system

Ef files
As noted earlier, it is in the EF files that the data of the card and its applications are stored. In terms of graph theory, EF files are leaves (terminal vertices of a graph) in the tree-like file structure of the IPC.
ISO 7816-4, an EF file may have its own header (FCI). Consider a possible FCI implementation for an EF file.
EF file and takes two bytes. The card EF file operating system reserves the required EEPR0M space. New data can be added to the EF file until there is no free space in the reserved space.
The data element File descriptor (tag ’82’) defines the type of EF file. There are several types of EF-file: secret file (secret file), internal file (internal file) and working file (working file). In accordance with ISO 7816-4, the file type is encoded in one byte.
Secret files are used to store sensitive key information. Internal files contain information that is controlled only by the card application (for example, transaction counter, PIN, etc.). Finally, work files store information that is used externally for application cards.
Secret keys are stored in internal files. Thus, all these elements should be of only two types: internal and working. ISO 7816-4.
The File ID data element (tag ’83’) is encoded in two bytes and has a unique value inside the parent value of the DF file. The File ID element is used for an existing EF file inside the parent DF file.

Data element EF attributes contain 2 parameters that determine the fact that the EF file is used. The number of records in EF is encoded with one byte of information. The number of entries in the linear number is 255.
E1 finally, the “EF file access conditions” data element defines the conditions for access to the EF file for executing commands for changing a record, reading a record, and creating a new record.
EF files come in four forms:
transparent or binary files (transparent file);
linear files with a fixed recording length (linear fixed file);
linear variable file length;
circular files.

Types of EF files:
a) transparent or binary files;
b) linear files with a fixed record length;
C) linear files with variable length records;
d) cyclic files.
A binary file can be viewed as a string of bytes. When a read or write information command is executed on data in such a file, the command must specify the offset in bytes from the beginning of the file to determine the byte from which the read or write will start.
A linear file with fixed or variable length records, as its name implies, contains smaller units of information called records. Entries are numbered sequentially. In a fixed-length file, all records contain the same number of bytes, while in a linear file with variable-length records, the record size is variable. Obviously, a linear file with variable length records requires more access time for read / write operations, as well as more costs for file administration.
A cyclic file contains fixed-length records linked in a ring structure. The latter means that each time such a file is accessed, the command is “applied” to the next file entry. If all the file entries are already used for storing data, the oldest file entry is overwritten.
Cyclic files are used in the EMV standard for storing data about the latest operations performed on the card (Transaction Log File). However, if all records in the Transaction Log File are used, data about the new transaction is recorded in the records that were used to store the oldest transaction.
There are two different ways to link to an EF 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 the terminal selects an EF file, all directories containing it must be selected, including the parent DF file of the selected elementary file. Only after the EF file is selected by its FID value can read and write operations be performed on the file.
Obviously, the need for the terminal to know the card file structure is a disadvantage of the FID reference method. The advantage of the method is the versatility and simplicity of the algorithm used in it, which is used both for selecting DF files and for selecting EF files. This versatility simplifies the implementation of the card application. Therefore, using the FID link may be of interest for local so-called proprietary applications where the terminal knows their file structure in advance.
A link using the Short File Identifier (SFI), which is a number from 1 to 30 and is encoded
5 bits. Each EF file has a unique SFI value inside the parent DF file.
An important advantage of the SFI reference method is that SFI is the input parameter of a number of commands executed on file data. This means that when you use this link method to execute a command, you don’t need to pre-select the file.
Note that the EMV standard uses only the file name reference for both DF files and EF files.

ADF files
The organization of the file structure in the EMV standard is based on the ISO 7816-4 specifications and is described In part 2 of Book 1 and Part 1 of Book 3 of the EMV specifications.
There are two types of DF files in the EMV card file system: DDF (Directory Definition File) and ADF (Application Definition File).
The ADF file corresponds to a separate card application and contains (is an access point) only the AEF (Application Elementary File) files of this application. Inside the ADF, the AEF file is selected by its SFI ID, which ranges from 1 to 30. After selecting the ADF file, the SFI ID is used as the input parameter of the command over the AEF.
Each application on the card must have its own Application ID (AID), which is used as the name or beginning of the DF Name of the ADF file. The app ID can be registered (in ISO) or unregistered (private).
In accordance with the ISO 7816-5 standard, the registered application ID AID is encoded in a size up to 16 bytes. The ID consists of two parts AID=RID| / PIX, where the RID is a Registered Application ID of 5 bytes, and the PIX is a Proprietary Application Extension of up to 11 bytes.
The RID is registered by ISO. E1example, the corresponding RID value for all VISA applications IS ‘AOOOOOOO’, and for MasterCard applications it Is ‘A000000004’h.thus, the RID in the application ID determines the payment system brand.

PIX values define a specific application (card product) for each registered RID. Examples of PIX values set by VISA and MasterCard for some of THEIR applications are listed below:
RID=A000000003 1010 VISA debit/credit
2010 VISA Electron
3010 Interlink 8010 Plus 999910 Proprietary ATM
RID = A000000004 1010 MC credit card Cirrus Maestro 6000 3060.
A DDF file consists of ADF files and DDF files. Each DDF file is also selected in the card file system by its own name. The criteria for grouping ADF files into a DDF file may vary. For example, one of the criteria might be the General nature of applications that match ADF files that belong to a single DDF file. In particular, the DDF file that groups payment applications is called the Payment System Environment (PSE). The name 1PAY is reserved for this DDF file.SYS.DDF01.
Another criterion for grouping ADF files may be whether the corresponding applications belong to a particular payment system operator (for example, VISA or MasterCard).
Each ADF and DDF file corresponds to an FCI Template data element (Tag ‘6F’) containing those FCI header data objects that are returned to the terminal in response to the file selection command. The content of FCI Template for ADF and DDF files is different. FCI Template structure for an ADF file1. As you can see from the figure, the FCI Template for an ADF file consists of two mandatory data objects:
— the DF Name (Tag ’84’) of the ADF file, equal to the application’s AID ID stored in the ADF file. DF Name is encoded as a binary string (the binary format of the data element) with a size from 5 to 16 bytes;
Tag 6F — FCI Template (M)

Tag 84 — DF Name (M)
*- Tag A5 — FCI Proprietary Template (M)
► Tag 50-Application Label (M)
► Tag 87-Application Priority Indicator (0)
► Tag 9F38 — PD0L(0)
► Tag 5F0D — Language Preference (0)
► Tag 9F11 — Issuer Code Table Index (0)
► Tag 9F12 — Application Preferred Name (0)
► Tag BF0C — FCI Issuer Discretionary Data (D)

FCI Template structure for an ADF file
FCI Proprietary Template data object for an ADF file

Tag Contents of data object Mandatory data object
’50’ Application Label (product name) Required
’87 ‘ Application Priority Indicator (application priority) Optional
‘9F38’ PD0L Optional
‘5F2D’ Language Preference (language preference indicator) Optional
‘9F11* issue Code Table Index (encoding for displaying the Application Preferred Name object) Optional
‘9F121 Application Preferred Name (an alternative name of the app) Optional
‘BF0C’ FCI Issuer Discretionary Data Optional

— the FCI Proprietary Template (Tag’a5′), which defines the application parameters that the terminal needs to select the application and the card needs to process the transaction.
Let’s look at the last FCI Proprietary Template data object in more detail. It consists of objects.
The Application Label data object (Tag ’50’) is the only required element of the FCI Proprietary Template. It defines the name of the payment product corresponding to this application (for example, Maestro, Cirrus, Electron), registered by the payment system as a trademark of the card product. The Application Label data element has an alphanumeric format and contains from one to 16 characters (the format is defined in ISO 7816-5). The Application Label object is intended for presenting the card product to the cardholder in the human – machine interface (on the terminal display) when using the card in the payment system terminal.
The Application Preferred Name data object (Tag ‘9F12’) is optional and defines a card product name that is additional to the Application Label. The Application Preferred Name data element is represented by a string of alphanumeric characters ranging from 1 to 16 characters in size and is used as an additional application identifier in the human-machine interface when using the card in the payment system terminal. Application Preferred Name is entered by the card Issuer for the convenience of the cardholder. This data element is usually the product name only in the encoding corresponding to the alphabet of the cardholder’s country.
The data object Issuer Code Table Index (Tag ‘9F11’) is optional and in accordance with ISO 8859 defines the encoding table of the alphabet used to display the Application Preferred Name string. If the Application Preferred Name data object is present in the FCI Proprietary Template, the issue Code Table Index object is required.
The Application Priority Indicator data object (Tag ’87’) is optional and defines the order in which the card applications are displayed on the payment terminal display. The Application Priority Indicator data element has a binary format and is encoded as a 1-byte string.

Bits B4, BZ, B2, and B1 define the priority value. The highest priority is set to 1, and the lowest priority is set to 15. A value of 0 means that the application does not have priority.
Bit B8 determines whether cardholder confirmation is required when selecting an app (B8=1) or not (B8=0). If B8=1, the terminal must ask the cardholder to confirm their consent to use this application to complete the transaction.
The PDOL data object (processing Options Data Object List) (Tag ‘9F38’) is optional and defines the transaction and terminal data required by the card in order to make a decision about the best way to process the transaction from the card Issuer’s point of view (choosing a “profile” for processing the transaction). The PD0L data element contains a list of tags and lengths of data objects that the card needs (at the Issuer’s decision) to select a “profile” for transaction processing.
Let’s explain this with a few examples. The PD0L object can contain the values of tags and lengths of the Amount Authorized (Binary) (Tag’81’) and Terminal Type (Tag’ 9F35′) objects, which represent, respectively, the size of the transaction amount and the type of terminal where the card is served. In this case, the structure of the PD0L data object is shown in Fig. 3.4. PD0L data is reported by the terminal to the card in the data field of the GET PROCESSING OPTIONS command

After receiving the necessary data, depending on their value, the card can tell the terminal in response to the GET PROCESSING OPTIONS command what data it should read on the card and which “application Interchange Profile” is selected by the card to perform the current operation.
In this example, we assume that the terminal is of the “Online Only” type (i.e., we are talking about a terminal where all operations are performed in real time). In this case, the card can return the Application Interchange Profile data object to the terminal, where the’ Terminal Risk Management is to be supported ‘ bit is 0. This means that the terminal in this case should not perform procedures for checking the values of Floor limit and other offline limits for this operation, since the operation will be processed online.
As another example, if the transaction amount is small, the card returns the Application Interchange Profile data object to the terminal, in which the ‘Card Verification Method is supported’ bit is not set, i.e. it is equal to 0. This means that in this case, the terminal will not perform verification of the cardholder. On the one hand, due to the small size of the transaction, the risks associated with the lack of verification of the cardholder are acceptable for the card Issuer. On the other hand, the refusal to verify the cardholder leads to simplification of transaction processing, which in many cases (for example, in fast food outlets, when paying for travel, etc.) is a necessary condition for conducting non — cash payments.
The FCI Issuer Discretionary Data object (Tag ‘BFOC’) is optional and contains information defined by the card application Issuer. This can be reference information, such as the ID of the card manufacturer, the chip type, the operating system version used, and the card mask.
Another possibility is to use FCI Issuer Discretionary Data to implement special non-standard functions. For example, special terminals can be used to implement administrative commands that are intended to change certain data in the card application. In order for the terminal to get the right to execute an operation after the operation, it must be authenticated by the card. A secret key known to the card and terminal can be used for this purpose. The key ID can be stored on the card in FCI Issuer Discretionary Data.