22 November 2020
Introduction
In this article, we will tell you what capabilities the trading and banking POS terminals can or should have, and touch upon some aspects of the EMV certifications. This article is the logical follow-up of the first part of the series: «Acquiring: Types of POS-terminals (Classification of EMVCo and Payment Systems)».
Terms and Definitions
Authorization is the process of data exchange between the parties of a transaction through a bank card or other means of payment (e.g. mobile wallet, etc.). A standard exchange chain is as follows: An acquirer (see below) sends an authorization request to the Payment system (hereinafter referred to as PS), and the PS sends it to the issuer. The issuer performs all the necessary checks such as security checks, checks of funds available on the card account, and other checks based on which a response (affirmative or denial) to the authorization request will be sent. The response to the authorization request will be sent on the return route. I.e., to the PS first and then to the acquirer.
POS-terminal (POS - Point Of Service) is a device providing the capability to service the cards and other means of payment.
The issuer is a financial institution (bank or another financial organization) that has issued a card.
The acquirer is a financial institution (bank or another financial organization) that ensures the cards servicing by the merchant.
The merchant is a retail and service outlet (hereinafter the RSO) with the capability to take bank cards.
The cardholder is a holder of a card with the right to perform a set of transactions permitted by the issuer.
Terminal
As we have mentioned before, from the perspective of PS and EMVCo, a terminal is a technological sum of the following three basic components: Terminal Type, Terminal Capabilities and Additional Terminal Capabilities. In this article, we will consider one of the components of the data, namely the Terminal Capabilities.
Terminal Capabilities
This component is placed in EMV Tag 9F33 within a device’s configuration. During the transaction, the card analyzes this component based on which the further script of the transaction will be defined.
Terminal Capabilities component has three data units:
Unit 1 (Byte 1, b 8-1) is the Card Data Input Capability.
This unit describes the methods such as the manual input, magnetic stripe and contact chip (since the data is read from the high-order bit to the low-order bit, those are bits 8, 7 and 6, respectively). I.e., if the terminal supports any method, the respective bit will be set (1) and if not, it will not be set (0). The rest of the first byte’s bits are reserved for use by the specifications of the specific Payment systems.
Unit 2 (Byte 2, b 8-1) is the Cardholder Verification Method (CVM) Capability.
CVM (Cardholder Verification Method) - is a way to verify that this particular cardholder has the right to use the card.
The cardholder verification capabilities include the following methods:
- Offline text-based pin code (bit 8): «offline» means that the value of the pin code will be computed by the special algorithms without reference to the issuer.
- The encrypted online PIN code (bit 7). The PIN code encrypted by the 3DES algorithm and sent to the issuer for checking online.
- Signature on the cheque (bit 6). The method verifying the cardholder’s right to use the card by signature on the terminal cheque. It is presumed that the representative of the RSO has to match the signature on the cheque with the specimen signature on the dedicated stripe on the reverse of the card.
- The offline encrypted PIN code (bit 5) is the PIN code encrypted by the RSA algorithm using the issuer’s keys, and its value is encrypted without reference to the issuer.
- The method is not required (No CVM Required) (bit 4) is the method where, under certain conditions, the terminal will not require the PIN codes and the cheque will not include a place for the signature.
The rest of the second byte’s bits are reserved for use by the specifications of the specific Payment systems.
Unit 3 (Byte 3, b 8-1) is the Security Capability.
The capabilities of the card authenticity verification as well as the capability of its retaining (if the case at hand involves an ATM and/or a payment kiosks with the technical capability to “swallow” the card).
The security capabilities include the following methods:
- SDA is the Static Data Authentication (bit 8). It is the oldest method, and the least reliable because nowadays there are sufficiently functional ways to fully copy the data from the chip and write it on a «white plastic» as is. In this case, there is a high probability that a terminal would not be able to identify the fraud. For this reason, the current Regulations of all major Payment systems prohibit both the acquirers and the issuers from using the SDA method.
- DDA is the Dynamic Data Authentication (bit 7). The algorithm of this method includes using of so-called «ICC Private Key» (ICC PK)) which is used to sign the dynamic data listed in the special DDOL (Dynamic Data Authentication Data Object List) object. It is the use of ICC PK that ensures a high cryptographic security level of this method.
- Card Capture: see above (bit 6).
- CDA is the Combined Data Authentication (bit 4). Just like with DDA, it uses ICC PK. The key difference is that CDA is not a separate operation, the cryptographic procedures are carried out in the main flow of the transaction, and the encrypted message formed by the card is one of the components that are to be signed. It clearly results from the description that CDA and DDA methods are considered cryptographically secure and are currently in widespread use. However, CDA is the preferred method.
The bits 5, 3, 2 and 1 of the third byte are reserved for use by the specifications of the specific Payment systems.
It should be noted that SDA, DDA and CDA are under the common abbreviation «ODA», i.e. the Offline Data Authentication. To execute any of these procedures, special RSA keys of one or another Payment system (so-called RSA Public Keys) are to be downloaded into the terminal. Otherwise, although it is claimed that the Security Capability will support DDA, for example, the procedure will fail, which, in some cases, will result in offline or online denial.
Also, note that the devices that do not in any way support the offline authorization are not required to support ODA. ATMs are a case study of it. This is why the RSA keys loading into them is not required. On the other hand, the devices with offline support, for example, the 22-type terminals, are required to support ODA.
Additional Terminal Capabilities
This component is placed in EMV Tag 9F40 within a device’s configuration.
The Additional Terminal Capabilities component has five data units. Since all the components of that unit are clear without additional clarifications, let us limit ourselves to a general description.
Units 1 and 2 (Byte 1-2, b 8-1) describe the financial and administrative capabilities of the terminal (cash disbursement, payment for the merchandise and services, cashback, payments, transfers, etc.).
Units 3 and 4 (Byte 3-4, b 8-1) describe the technical capabilities (features of the printer, display and keyboard).
Unit 5 (Byte 5, b 8-1) describes the terminal’s capabilities to support ISO-8859 code pages.
These are the main components of the payment terminals. The specific “combinations” of these components are configured by the acquirers to meet their own needs and comply with the Regulations of the PS. Their consideration is beyond this article, but they will by all means be highlighted in our future articles.
EMV certificates of the terminals
All of the above-listed features of one or another device are described in the respective EMVCo certificates that are usually divided into three levels:
EMV Level 1 (Reader): it is issued for the hardware, i.e. for the terminal’s readers, both contact and contactless.
EMV Level 2 (Kernel): it is issued for the software core of the terminal. It is the very certificate that describes the Terminal Type and also the Terminal Capabilities and the Additional Terminal Capabilities of each type.
The L1 and L2 certifications are carried out by the immediate developer of the terminal’s software and/or the manufacturer of the hardware.
EMV Level 3 (Acquirer): certification by the bank or another payment services provider. It is carried out using only the equipment with the EMV L1 and L2 certificates. Each PS has its requirements and a certain set of test scripts (so-called cases), that an acquirer has to execute during the certification.
Each Payment system’s set of certification procedures itself usually has its name. E.g.:
- Mastercard — M-TIP (Terminal Integration Process). It implies a certification through both the contact interface and the contactless interface.
- Visa — ADVT (Acquirer Device Validation Toolkit) — contact chip.
- Visa — CDET (Contactless Device Evaluation Toolkit) — contactless.
- NSPK (National Payment Card System) —CITES (Certification Integration Testing of the Acquiring Network): contact or contactless interfaces.
However, if an L2 certificate is not claimed to support one or another method, the encrypted offline PIN code, for example, the acquirer may not claim its certification. The same is true with the rest of the methods.
Hence, it is clear that the L2 certificate is the basic one. Just as the capabilities described in it (and in this article) are, in our opinion, crucial for an understanding of all the logic of interaction between a modern terminal and a card.
