EMV access condition values
AEF files
As already noted, the ADF file is an access point to the AEF files containing the data of the application corresponding to the ADF file. After the terminal selects the ADF file, all the AEF files of this application can be selected by the SFI name of these files. The SFI value of any application AEF file varies from 1 to 30.
According to Book 3 of the EMV specifications, AEF files identified by SFI in the range from 1 to 10 store data defined in the EMV standard. Files identified by SFI in the range from 11 to 20 and from 21 to 30 store data used by the payment system and the Issuer, respectively.
Each AEF file defined by SFI in the range from 1 to 10 is a linear file with variable or fixed length records. All entries in the file are numbered and identified by their own number. The maximum number of entries in the AEF file, as explained in section 3.4, is 255.
Each entry in the AEF file is a composite data object called an AEF Data Template (Tag 70′), followed by a parity check byte controlled by the card operating system. The structure of the record is shown in Fig.3.5.
The AEF Data Template object is defined only in the EMV standard (there is no description of it in ISO 7816). The Length field of this object is equal to two bytes. Since the card operating system always uses a single byte to encode the record size, the size of the entire AEF Data Template object, along with the Tag and Length fields and minus the parity check control byte, does not exceed 254 bytes. This means that the length of the Value field of the AEF Data Template object does not exceed 251 bytes.
In conclusion, the AEF Data Template can only contain data objects that are used for transaction processing. These data objects are listed in the table.
The remaining EMV data objects used for selecting an application are not stored in AEF files and become available to the terminal during the application selection procedure.
DDF files
Let’s now look at the structure of the FCI Template data object for a DDF file
Tag 6F— FCI Template (M)
► Tag 84 — DF Name (M)
► Tag AS the FCI Proprietary Template (M)
► Tag 88 — SFI of the directory (elementary) file (M)
► Tag BFOC — FCI Issuer Discretionary Data (0)
Structure of the FCI Template object for the DDF file
As you can see from the figure, the FCI Template object for a DDF file consists of the same two mandatory data objects, DF Name (Tag ’84’) and FCI Proprietary Template (TagA5′), as in the case of the FCI Template for an ADF file.
The DF Name data object (Tag ’84’) is mandatory and is encoded as a binary string between 5 and 16 bytes in size.
Let us now consider the object of the FCI Proprietary Template. Its structure differs from that of the FCI Proprietary Template for an ADF file. It consists of only two objects, shown in table. 3.8. The exception is a PSE file that contains additional optional data elements.
Tag Contents of data object Mandatory data object
’88’ SFI of the Directory Elementary File (short filename file name of the directory) is Mandatory
‘BF0C’ FCI Issuer Discretionary Data Optional
The SFI data object of Directory Elementary file (Tag ’88’) is required because it defines a reference (short name) to the Directory file (Directory Elementary File) that displays the structure of the DDF file (more on this later).
The FCI Issuer Discretionary Data object (Tag ‘BFOC’) is optional and contains information defined by the Issuer of card applications grouped in a DDF file.
An important attribute of any DDF file is an EF file called the Directory Elementary File (DEF file). The DEF file is a required file in the DDF directory. It defines the structure of the DDF file. Each DEF file entry contains, in General, several Application Template data objects (Tag ’61’). The Application Template object contains the details of a single ADF or DDF file for which the DDF file we are considering is the parent. However, the content of the Application Template data object for ADF and DDF files is different.
For an ADF file, the Application Template contains two required data objects: Application Identifier (AID, Tag ‘4F’) and Application Label (Tag ’50’). Optionally, Application Template can also contain Application Preferred Name, issue Code Table Index, and Application Priority Indicator data objects. Sometimes in EMV specifications, the Application Identifier object is called ADF Name because the name of the ADF file (the data field of the DF Name object) matches the data field of the AID object.
In the case of a DDF file, the Application Template contains a single DDF Name data object (Tag ‘9D’) and does not contain any optional data objects.
Note that Application Template objects for ADF or DDF files can contain Directory Discretionary Template objects (Tag 73′) that define data that is useful from the point of view of the Issuer of applications hosted on the IPC.
PSE file
The PSE (Payment System Environment) file is a DDF file that defines the card’s payment applications. The PSE file is optional for the card and follows the rules set out in section 12.2.2 of Book 1 of the EMV 4.1 standard. The PSE file is defined by its reserved DDF Name, which takes the value 1PAY.SYS.DDF01. Quite often in practice, the PSE file is also an MF file (FID=’3F00’h), i.e. the root file of the card file system.
The FCI Template data object for PSE has the same structure as for any other DDF file.
Tag 6F — FCI Template (M)
Tag84-DFName = ” 1PAYSYS.DDF01″ (M)
AS Tag — of FCI Proprietary Template (M)
Tag 88 — SFI of the directory elementary file (M)
Tag 5F2D — Language Preference (0)
> Tag 9F11 — Issuer Code Table Index (0)
> Tag BFOC — FCI Issuer Discretionary Data (0)
A possible difference is in the elements of the FCI Proprietary Template object. This difference is that the FCI Proprietary Template of the PSE file contains two additional optional elements: Language Preference (Tag ‘5F2D’) and issue Code Table Index (Tag ‘9F11’). The list of all objects in the FCI Proprietary Template PSE file is shown in table.3.9.
Values of all data elements in the table. 3.9 were explained in the PP. 3.5 and 3.7.
FCI Proprietary Template data object for the PSE file
Tag Contents of data object Mandatory data object
’88’ SFI of the Directory Elementary file Mandatory
‘5F2D’ Language Preference Optional
‘9F11’ Issuer Code Table Index Optional
‘BF0C’ FCI Issuer Discretionary Data Optional
Teams
The card and the terminal are key participants in any operation using a plastic card. In the case of a card with a magnetic stripe, information exchange between the card and the terminal is usually reduced to the terminal reading information stored on the magnetic stripe of the card. In some cases, the terminal can write data to the third track of the magnetic stripe. In any case, a card with a magnetic stripe plays a passive role as a Keeper of information.
In the case of IPC, the terminal interacts with the card in accordance with the “client-server” architecture, when the card plays the role of the server and the terminal — the client. In this case, the terminal sends commands to the card (data with instructions for processing them) and receives back the data (in the form of a response to the command) that the terminal needs to process the operation.
To explain the nature of information exchange between the card and the terminal, the applications of the card and the terminal (obviously, it is between them that information exchange occurs) can be considered as deterministic finite automata. In finite state machines, the next state of an automaton is determined by its present state and an external event. In the case of IPC, the state of the card application is a set of all data elements and cryptographic parameters of the card at a given time. An external event for the IPC is a command coming from the terminal. Depending on the data contained in the command, as well as the current state of the card, the MPC application changes its state (in the terminology of finite state machines, it moves to a new state). In addition, the IPC application calculates the output signal that represents the response to the terminal based on the current state and parameters of the terminal command.
Note that the initial state of the card application is the state it enters after receiving the Reset signal from the terminal.
Information exchange between the card and terminal applications from a communication point of view is carried out in accordance with the seven-level reference model of open systems interaction (EMVOS, or Open System Interconnection (OSI) Model)
In the IPC-terminal dialog, only three levels of interaction between open systems are used: physical, channel, and application
The physical layer defines the characteristics of the electrical signals exchanged between the card and the terminal. The channel level is represented by asynchronous protocols T=0 and T=1
The application level of interaction between the card and the terminal is represented by the C-APDU (Command Application Protocol Data Unit) and R-APDU (Response Application Protocol Data Unit) data blocks. Using C-APDU blocks, the terminal sends data and instructions to the card that determine what the card should do with the information received in the block. The instruction along with the data is a command. The card sends its response to the command in the R-APDU block.
The description of the purpose of individual elements of the C-APDU block is given in table. EVIL.
Code Description Length
CLA command Class 1
INS command Code 1
PI command Parameter 1 1
P2 command Parameter 2 1
Lc Number of bytes in the Data field 0 or 1
Data data String (=Lc) Variable
Le the Maximum number of bytes expected in the card response data field is 0 or 1
The block consists of a mandatory 4-6 byte header and an optional command body. The header includes the command class (CLA), instruction code (INS), and two parameters P1 and P2. All the listed data elements are 1 byte each.
The highest (left) half-byte of the CLA command class determines whether the command is common to all microprocessor cards or belongs to the specifications of a specific standard in the field of microprocessor cards (for example, the EMV standard). The corresponding values of the left half-byte are shown in table.3.11.
Table ZL1
The left nibble of the CLA
The Value Of Interpretation
‘O’h Inter-industry team
‘8’h EMV command Only
The ISO 7816-4 standard defines the basic commands used by any IPC. These commands include commands for selecting a file, reading and changing data, authenticating the card, and so on.additional commands appear in the EMV standard (for example, GET PROCESSING OPTIONS or GENERATE AC).
The right half-byte of the CLA value represents Access Condition Nibble and defines the command’s access condition to the file. The EMV standard uses three access condition values: ‘O’h,’ 4’h, or ‘ C’h. As shown in table. 3.5, the value ‘O’h means that no security mechanisms are used when processing the command, the value’ h ‘ means that the integrity of the data in the command data field is ensured. Finally, the value ‘ C’h means that in addition to the integrity of the command data, its confidentiality is ensured
The second byte of the C-APDU block header is used to encode the command type. The various types of commands used in EMV will be described below.
The assignment of parameters P1 and P2 depends on the type of command (for an explanation of the commands used in the EMV standard, see clause 3.10).
If the size of the C-APDU block is five bytes, then the fifth byte encodes the Le parameter, which is the expected number of bytes in the data field of the R-APDU block (the block containing the command response).
If the chunk size C-APDU is more than five bytes, then the fifth byte encodes the Lc parameter representing the number of bytes in the Data block of the C-APDU, and following the fifth byte Lc bytes comprise the Data block C-APDU. This means that the maximum number of bytes in the command data field is 255 bytes.
If the Data field is followed by another byte of information, it defines the value Le. A null Le value means that the maximum number of bytes (256 bytes) is expected in the data field of the R-APDU block.
Data (Data)
SW1 SW2
Block body
The tail block
The R-APDU block consists of an optional block body of Lr bytes, < 4^ and a mandatory block tail (Trailer) of 2 bytes. The block’s tail specifies the status words SW1 and SW2, each 1 byte in size, that define the result of executing the command.
Two template formats are used to represent data in the R-APDU block. The Response Message Format 1 (Tag ’80’) is used to return data to the terminal without using the BER-TLV encoding. In contrast, the Response Message Format 2 (Tag 77′) is used to return ber-TLV encoded data objects to the terminal.
Status bytes SW1 and SW2 in accordance with EMV 4.1 are encoded as follows:
Normal processing of the command)
’90’ ’00’ – the process is completed normally.
Processing a command with a warning (Warning processing).
The status bytes listed below are used when the command is processed, but special conditions have occurred (for example, the selected file is invalid, the entered PIN-code value was incorrect, etc.), which the card informs the terminal about.
’62″83′ – the non-volatile memory state has changed; the selected file is invalid.
’63″00′ —the non-volatile memory state has changed; authentication failed.
’63 ” CX’ – the non-volatile memory state has not changed.
The value ” x ” is a counter value that changes in the range from 0 to 15. The status bytes SWl= ’63’h, SW2=’ CX’h are used in the response to the VERIFY command in cases where:
the PIN value is incorrect;
the control field of the PIN block (see the description of the VERIFY command in clause 3.10) is not equal to ‘ 02’h;
PIN length is strictly less than 4 or strictly more than 12;
when the value of the fill character in the RC block is not equal to ‘ F’h.
If, when responding to the VERIFY command, SWl= ’63’h and SW2=’ CX’h, the value ” x ” represents the remaining number of attempts to enter the correct PIN value.
An error was detected when processing the command (Checking errors).
The status bytes listed below are used when processing a command is not possible, for example, due to the fact that-
the team’s work on the card is not resolved for various reasons, or the team specified incorrect parameters.
’69’ ’83’ – the command is not resolved; the authentication method is blocked (used, for example, in the response to the VERIFY command, when PIN verification is blocked due to the reset of the PIN Try Counter);
’69″84′ – the command is not resolved; the data used is incorrect (for example, the current PBX value is FFFF (hex); in this case, the response to the GET PROCESSING OPTIONS command is SWlSW2= ‘ 6984’h);
’69″85′ – the command is not resolved; the conditions for applying the command are not met;
‘6A ” 81’ – invalid values for parameters P1 and (or) P2; the function is not supported;
‘6A ” 82’ – invalid values for parameters P1 and (or) P2; file not found;
‘6A ” 83’ – invalid values for parameters P1 and (or) P2; entry not found;
‘6A ” 88’ – the required data (data object) was not found.