6.6 Cardholder verification

The cardholder verification stage allows the terminal to verify the link between the person at the point of service and the eligible cardholder to whom the application in the card was issued. This stage can be performed any time after the completion of the read application data stage and before finalizing the terminal action analysis stage.

6.6.1 Cardholder verification methods in EMV ¢

The EMV ¢ standard accepts several CVMs, which are discussed below. A method number on 6 bits, which is indicated in parentheses, is associated with each CVM, according to Annex C.3, in Book 3 [1].

No CVM required (011111b): This method consists of accepting without proof that the person at the point of service is that to whom the card was issued. For example, at a point of service for paying a highway toll, an operator will capture the card data without requiring the cardholder verification. This is mainly for providing the convenience of the service and the fluency of the traffic in the conditions when the transaction amount is low.
Fail CVM processing (000000b): The card uses this method to force a CVM failure in the terminal. This can lead the terminal to force an on-line connection to the issuer, which could further analyze the card status and apply exceptional risk management policies.
Signature (paper) (011110b): This CVM, explained in Appendix D, Section D.5.1, can be applied for credit card products at a point of service that is attended by an operator. The method consists of comparing the signature produced by the card user on the sales slip against the witness signature of the cardholder written on the back side of the card. The EMV ¢ preserved this method, since in some countries the legislation requires a handwritten signature as a proof of the cardholder's participation in a transaction.
Enciphered PIN verified on-line (000010b): This method is common for debit and credit card products used in unattended environments, when they are implemented with the magnetic stripe technology. The EMV ¢ also accepts this method for chip-based card products. The cardholder types his or her PIN in the terminal's PIN pad. The terminal encrypts it using a symmetric encryption mechanism. The IH receives this cryptogram, decrypts it in a secure module, which computes a PIN image control value that is compared against a witness value kept in the cardholder database, referred to as the PIN image stored value. Details of this CVM are presented in Appendix D, Section D.5.2. One reason for keeping this CVM for EMV ¢ chip products could be that there are issuers that do not trust the transmission in clear of the cardholder's PIN on the interface between the terminal and the chip card. The terminal implementing this CVM has to be equipped with an on-line PIN pad, which is a tamper resistant device that ensures that the PIN of the cardholder never leaves the PIN pad in clear, but just in an encrypted form.
Plaintext PIN verification performed by ICC (000001b): This is a costeffective cardholder verification method, which is specific for chip card products. The terminal captures the PIN from the user and sends it in clear to the chip card. The chip compares the value received with a witness value stored in its permanent memory since the personalization stage. The method is described in Appendix D, Section D.5.3. Issuers that do not consider the threat of eavesdropping on the interface terminal-card prefer this method to on-line enciphered PIN since implementing it is cheaper and it allows the off-line completion of an EMV ¢ transaction at an unattended terminal. The terminal implementing this CVM has to be equipped with an off-line PIN pad, which is a tamper resistant device such that capturing the PIN of the cardholder on the interface card-terminal is difficult.

Note that EMV ¢ supports a combined cardholder verification method, which is referred to as the plaintext PIN verification performed by ICC and signature (paper) (000011b).
Enciphered PIN verification performed by ICC (000100b): This is an expensive cardholder verification method, which is applicable for chip card products able to perform RSA operations. The terminal captures the PIN from the user and sends it encrypted in an RSA envelope to the chip card. The chip decrypts the envelope, retrieves the PIN in clear, and compares the retrieved value with a witness value stored in its permanent memory since the personalization stage. The method is described in Appendix D, Section D.5.5. Issuers that would like to complete transactions off-line and that consider the threat of eavesdropping on the interface terminal-card implement this method. The terminal implementing this CVM has to be equipped with an off-line PIN pad.

Note that EMV ¢ supports a combined cardholder verification method, which is referred to as enciphered PIN verification performed by ICC and signature (paper) (000101b).
There are some method numbers that are reserved for further use:
- 000110 “011101: method numbers to be assigned by EMV ¢ , for example, for biometrics (see Appendix D, Section D.5.6);
- 100000 “101111: method numbers to be assigned by the individual payment systems ”a possible candidate is a one-time password scheme (see Appendix D, Section D.7.3);
- 110000 “111110: method numbers to be assigned by individual issuers.

6.6.2 Data objects involved in cardholder verification

The Cardholder Verification Method List (CVM List) is a data object with tag 8E, which is stored in the card application since its personalization. It contains two amount fields, which are referred to as X and Y , and a list of all the cardholder verification rules accepted by the card. The meaning of these components is described below.

Both the first ( X ) and second ( Y ) amount fields are encoded with an implicit decimal point on 4 bytes in a binary format. They are expressed in the same currency, whose type is encoded in the Application Currency Code data object with tag 9F42 stored in the card. X and Y represent two threshold values established by the issuer, which determine whether the terminal should apply a certain CVM or not. This decision depends on the relationship between the amount involved in the current transaction, which is stored in the terminal in the Amount, Authorized data object (tag 81), and X, Y (see also the CVM condition codes below).

A Cardholder Verification Rule (CVR) consists of 2 bytes: the first indicates the type of CVM to be used, while the second specifies in which condition this CVM will be applied.

The first byte, referred to as the Cardholder Verification Method Code (CVM Code), is encoded as follows :

Bit 8: This is RFU.
Bit 7: This instructs the terminal whether to continue the cardholder verification stage if the CVM fails.
- 0: The terminal finishes the cardholder verification stage when the current method fails.
- 1: The terminal is instructed to consider the next method in the list of CVR when the current method fails.
Bit 6, , bit 1 (the rightmost 6 bits of the CV Code): These bits represent the method number, as defined in Section 6.6.1, indicating which is the CVM that must be applied.

The second byte, referred to as the Cardholder Verification Method Condition Code (CVM Condition Code), indicates the condition to be respected for applying the CVM whose code is specified in the first byte:

00h: The CVM can be always applied.
01h: The CVM is applied for all the transactions where cash or cashback is involved (e.g., ATM cash withdrawal, cashback from an attended POS).
02h: The CVM is applied for all the transactions that do not involve cash or cashback (e.g., POS payment).
03h: The CVM is applied only in case the terminal is adequately equipped. For example, the plaintext PIN verification performed by ICC is a CVM that can be executed only on a terminal equipped with an offline PIN pad.
04h “05h: These values are RFU.
06h “09h: The CVM is applied when the Transaction Currency Code (tag 5F2A in the terminal) of the Amount, Authorized is the same as the Application Currency Code (tag 9F42 in the ICC) and the value of this amount is:
- Under the X value (06h);
- Over the X value (07h);
- Under the Y value (08h);
- Over the Y value (09h).

The issuer specifies the values of the threshold amounts X and Y in the first tow fields of 4 bytes of the CVM List.

0Ah · 7Fh: This range of values is RFU.
80h “FFh: This range of values is reserved for encoding condition codes required by individual payment systems.

Thus, one can see that the CVM List stored in the card application indicates to the terminal the types of CVM supported by the card, the conditions in which each CVM should be applied, and their preferred order.

In its turn the terminal supports all the CVMs indicated in the second byte of the Terminal Capabilities (tag 9F33) (see Annex A2 in Book 4 [3]):

Bit 8 = 1: " Plaintext PIN for ICC verification " is supported.
Bit 7 = 1: " Enciphered PIN for on-line verification " is supported.
Bit 6 = 1: " Signature (paper) " is supported. For this method the terminal shall be an attended terminal, with Terminal Type (tag 9F35) = x1h, x2h, or x3h with x = 1or x = 2. The terminal shall support a printer, which is indicated in Additional Terminal Capabilities (tag 9F40), byte 4 "Terminal Data Output Capability", bit 8 = 1: "Print, attendant" (see Annex A3 in Book 4 [3]).
Bit 5 = 1: " Enciphered PIN for off-line verification " is supported.
Bit 4 ˆ’ Bit 1: RFU.

In addition, the terminal shall recognize the CVM codes for "No CVM required" and "Fail CVM processing", which may be present in the card's CVM List.

The terminal will register the result of the last CVM that was performed in the cardholder verification method results (CVM Results, tag 9F34), whose encoding is given below (according to Annex A4 in Book 4 [3]):

Byte 1 and 2: These indicate the CVR of the last CVM performed as indicated in the CVM List.
Byte 3: This indicates the result of the last CVM performed as known to the terminal:
- 00h = Unknown (e.g., for signature);
- 01h = Failed (e.g., for off-line PIN);
- 02h = Successful (e.g., for off-line PIN).

6.6.3 Common processing performed by the terminal

Whenever bit 5, "Cardholder verification is supported", in byte 1 of the AIP is set, the terminal performs the cardholder verification stage. This section presents the actions performed by the terminal regardless of the type of CVM.

The terminal checks whether the CVM List (tag 8E) is present in the EMV ¢ heap of the terminal.

If the CVM List is not present terminate cardholder verification without setting bit 7, "Cardholder verification was performed", in byte 1 of the TSI. The terminal shall set byte 1 of the CVM Results to "No CVM performed" (3Fh).
Else process each CVR in the order it appears in the CVM List. Finish the stage either when a CVM is successful or when there are no more CVR rules in the CVM List.

For each CVR, the processing is described below:

Verify the CVM Condition Code (the second byte of the CVR):
- Check that the terminal understands the CVM Condition Code. It could be that the EMV ¢ application in the card is a more recent version than the counterpart application in the terminal. Therefore, it could be that the terminal does not yet know how to interpret a condition whose code is known to the card.
- Check that all the data elements involved for the verification of that condition are present in the terminal. For example, the evaluation of a condition that involves the thresholds X and Y needs the presence of the Application Currency Code (tag 9F42).
- Verify that the business environment at the point of service for the current transaction respects the condition expressed in this CVR.
  
  If any of the verifications mentioned above fails, then do:
  
  If the current CVR is the last in the CVM List:
  - Set bit 8, "Cardholder verification was not successful", in byte 3 of the TVR.
  - The terminal shall set byte 1 of the CVM Results to "No CVM performed" (3Fh).
  - Terminate the cardholder verification stage.
  - Else consider the next CVR, and restart from step 1.
  Else continue with verifying the CVM code in the first byte of the CVR, as detailed below in step 2.
Verify that the method number (the rightmost 6 bits) in the CVM code is one of those accepted by EMV ¢ (see Section 6.6.2) or is otherwise understood by the terminal, as specified by a particular payment system or issuer.

The terminal shall set bytes 1 and 2 of the CVM Results with the method code and condition code of the current CVM rule interpreted from the CVM List.

If the method number in the CVM code is "No CVM required" (011111b) and if the terminal supports "No CVM required", it shall set byte 3 of the CVM Results to "successful". Terminate the cardholder verification stage.

If the method number in the CVM Code is "Fail CVM processing", the terminal shall set byte 3 of the CVM Results to "failed". Terminate the cardholder verification stage.

If the method number in the CVM code is not known and, correspondingly, the terminal does not understand the CVM, then do:

The terminal shall set the third byte of the CVM Results to "failed".

If the CVM condition code is known and correctly satisfied:
- Set bit 7, "Unrecognized CVM", in byte 3 of the TVR.
- If the current CVR is the last in the CVM List:
  - Set bit 8, "Cardholder verification was not successful", in byte 3 of the TVR.
  - Terminate the cardholder verification stage.
    
    Else consider the next CVR, and restart from step 1.
  Else perform the CVM whose code is indicated. Refer to Section 6.6.4 for off-line PIN processing and to Section 6.6.6 for on-line PIN processing.
  
  If the terminal successfully completes the CVM:
  - Set bit 7, "Cardholder verification was performed", in byte 1 of the TSI.
  - Terminate the cardholder verification stage.
    
    Else (the CVM processing failed)
  - If bit 7 of the CVM Code is 0:
    - Set bit 8, "Cardholder verification was not successful", in byte 3 of the TVR.
    - Terminate the cardholder verification stage.
      
      Else (bit 7 of the CVM Code is 1):
      - If CVR is the last entry in the CVM List
        
        Set bit 8, "Cardholder verification was not successful", in byte 3 of the TVR.
        
        Terminate the cardholder verification stage.
    - Else consider the next CVR entry in the CVM List, and continue with step 1.

6.6.4 Off-line PIN processing

The processing described in this section applies for the following CVM(s):

"Plaintext PIN verification performed by ICC" (000001b);
"Enciphered PIN verification performed by ICC" (000100b).

First, we discuss two concepts used in the processing performed by the terminal.

Off-line PIN support: A terminal that does not support off-line PIN is a terminal that supports neither off-line plaintext PIN verification nor off-line enciphered PIN verification (see bit 8 and bit 5 in the second byte of the Terminal Capabilities). If either of these two types of verification is supported then the terminal supports off-line PIN.
Bypassing PIN entry: There are situations when a new cardholder or a cardholder that is not used with PIN verification is unable to insert the PIN. Then, three situations can be envisaged:
1. Terminate the transaction.
2. Submit PIN-like numbers until the PIN Try Counter kept in the card is exhausted.
3. Bypass the PIN entry processing either at the initiative of the merchant or of the cardholder. Force the transaction to go on-line and inform the issuer of the circumstances. The issuer could decide based on some risk management procedure whether to authorize the transaction without a PIN.

From the point of view of service availability for the cardholder, the third approach is probably better.

The processing performed by the terminal is described below. If the terminal does not support off-line PIN:

Set bit 5, "PIN entry required and PIN pad not present or not working", in byte 3 of the TVR.

Else

If PIN pad is malfunctioning

Set bit 5, "PIN entry required and PIN pad not present or not working", in byte 3 of the TVR.

Else

If either the merchant or the cardholder bypass the PIN processing

Set bit 4, "PIN entry required, PIN pad present, but PIN was not entered", in byte 3 of the TVR.

The CVM is considered unsuccessful , the CVM Results is not set, and the next CVR in the CVM List is treated.

In case the terminal supports off-line PIN, the PIN pad works correctly, and the cardholder does not bypass the PIN, the processing performed by the terminal is the following. Issue the GET DATA command to the card, with the C-APDU presented in Table 6.4 (according to Table I-16 in Book 3 [1]). This command is used to retrieve the PIN Try Counter primitive data object from the card. This object is not encapsulated in any record within the current application.

Table 6.4: The C-APDU Corresponding to `GET DATA` Command
Code	Value
CLA	80 (EMV ¢ specific command)
INS	CA
P1 P2	9F17 (value corresponding to the PIN Try Counter primitive data object)
Lc	Not present
Data	Not present
Le	00

The data field of the corresponding R-APDU contains the PIN Try Counter, including its tag 9F17 and its length. When the value of this counter is zero, there are no more PIN trials left.

If SW1 SW2 = 9000 and PIN Try Counter is zero then the following processing is performed:

The terminal should not allow off-line PIN entry.
The terminal shall set bit 6, "PIN try limit exceeded" in the third byte of the TVR.
The terminal shall not display any specific message regarding the status of the PIN.
The terminal shall not set the CVM Results.
The terminal shall continue cardholder verification processing in accordance with the card's CVM List.

If either SW1SW2 ‰ 9000 or SW1SW2 = 9000 and PIN Try Counter is different than zero, then the following processing is performed:

The terminal prompts for PIN entry, displaying "Enter PIN". The PIN can contain between 4 to 12 BCD digits.
The PIN is formatted as a 16 nibbles (8 bytes) PIN block as follows:

C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F

where:
- C = Control field (0010b);
- N = PIN length expressed as a 4-bit binary number (0100b “1100b);
- P = PIN digit (0000b “1001b);
- P/F = PIN/filler, which is determined by the PIN length N;
- F = Filler (1111b).
If the method number (the rightmost bits of the CVM Code) indicates "Enciphered PIN verification performed by ICC" (000100b) then issue a GET CHALLENGE command. The C-APDU of this command is presented in Table 6.5 (it conforms to the Table I-15 in Book 3 [1]).

Table 6.5: C-APDU of the `GET CHALLENGE` Command
Code	Value
CLA	00 (interindustry command)
INS	84
P1 P2	00 00
Lc	Not present
Data	Not present
Le	00

In case of successful execution the card returns the R-APDU containing a random sequence of 8 bytes and SW1SW2 = 9000. The terminal stores this sequence in the value field of the Unpredictable Number data object (tag 9F37). The terminal uses this Unpredictable Number to insure the uniqueness of each RSA digital envelope containing a PIN. This security mechanism impedes an attacker from successfully impersonating the legitimate cardholder by simply replying a previously sent RSA digital envelope or determining the PIN from an RSA digital envelope through a dictionary attack.

Issue a VERIFY command, which allows the chip card to compare the PIN typed in by the cardholder with a witness value stored in the chip card. Prepare the C-APDU of the VERIFY command as indicated in Table 6.6 (from Table I-24 in Book 3 [1]).

Table 6.6: C-APDU of the `VERIFY` Command
Code	Value
CLA	00 (interindustry command)
INS	20
P1	00
P2	Qualifier of the reference PIN data: 00: as defined in ISO/IEC 7816-4 80: plaintext PIN, formatted as defined above 88: enciphered PIN, formatted as defined in Section 6.6.5 81 “87 and 89 “8B: RFU for the EMV ¢ 8C “8F: RFU for the individual payment systems 90 “9F: RFU for the issuer
Lc	Variable, depending on P2
Data	Transaction PIN data
Le	00

In case the CVM is "Plaintext PIN verification performed by ICC" (000001b), the data field of the C-APDU is represented by the PIN block of 8 bytes as described above.
In case the CVM is "Enciphered PIN verification performed by ICC" (000100b), the data field of the C-APDU is the RSA digital envelope carrying the cardholder's PIN. This field has N _PE bytes, corresponding to the byte length of the modulus in the ICC PIN encipherment public key. Details of producing the RSA digital envelope and the computations carried out by the card to retrieve the PIN from this envelope are detailed in Section 6.6.5.

After retrieving the PIN received in the command either directly or in the RSA digital envelope, the card compares this value with a witness PIN stored in its permanent memory since the personalization. Every time this comparison fails, the number of possible PIN trials stored in the PIN Try Counter is decreased. The status words SW1SW2 are positioned to 6983 or 6984, in case the PIN Try Counter was zero at the moment the VERIFY command was issued. Otherwise, the card answers the code SW1SW2 = 63Cx, where x indicates the remaining number of possible PIN trials, which could also be zero in case PIN Try Counter is zero.

The terminal receives the R-APDU from the card corresponding to the VERIFY command. This R-APDU consists of the status words SW1SW2, which allows the terminal to assess the completion of the required off-line PIN verification in the card:

If SW1SW2 = 6983, 6984, or 63C0, the off-line PIN verification failed. The terminal sets bit 6, "PIN try limit exceeded", in byte 3 of the TVR.
If SW1SW2 = 63C1 or 63C2, the off-line PIN verification failed but there is still one or, respectively, two possible attempts of off-line PIN verification. The terminal points the cardholder for typing in a PIN and the processing restarts.
If SW1 SW2 = 9000, the off-line PIN verification is considered successful.

6.6.5 RSA digital envelope carrying the PIN

Figure 6.7 outlines the CVM "Enciphered PIN verification performed by ICC" (000100b) (see Appendix D, Section D.5.5, for more details). The main advantage of this CVM is that an attacker loses any opportunity to eavesdrop the cardholder's PIN on the interface between the ICC and the terminal, since the PIN is wrapped in an RSA digital envelope.

Figure 6.7: Overview of the enciphered PIN verification performed by ICC.

During the personalization stage, the issuer generates the pair ICC PIN encipherment private key/ICC PIN encipherment public key and produces the ICC PIN Encipherment Public Key Certificate with the issuer private key. The issuing of this certificate is described in Section 5.6. The issuer loads both the ICC PIN encipherment private key (using a confidential channel) and the ICC PIN Encipherment Public Key Certificate in the card. Note, in order to save EEPROM space in the card, the ICC private/public key pair could be used instead of the ICC PIN encipherment private/public key pair to perform the unwrapping/wrapping of the RSA envelopes. It is important to mention, however, that whenever the card has enough EEPROM space, the best security practice is to keep separate key pairs for signature generation/verification and for unwrapping /wrapping RSA digital envelopes.

During a transaction that selected the "Enciphered PIN verification performed by ICC" as CVM the terminal verifies the existence in the EMV ¢ data objects heap of the following objects:

All the data objects needed by the terminal for performing the off-line static data authentication, except for the Signed Static Application Data (tag 93);
ICC PIN Encipherment Public Key Certificate (tag 9F2D);
ICC PIN Encipherment Public Key Remainder (tag 9F2F), which is present only when N _PE > N _I ˆ’ 42;
ICC PIN Encipherment Public Key Exponent (tag 9F2E).

If the terminal cannot retrieve the last three data objects, it searches for the following three data objects:

ICC Public Key Certificate (tag 9F46);
ICC Public Key Remainder (tag 9F48), which is present only when N _IC > N _I ˆ’ 42;
ICC Public Key Exponent (tag 9F47).

If both sets of data objects mentioned above are missing, the enciphered PIN verification performed by ICC fails.

If the first set of data objects is present, the terminal obtains an authentic copy of the ICC PIN encipherment public key ( n _PE , e _PE ) applying the same algorithm as that described for obtaining the ICC public key (see Section 5.7.2).

The terminal creates a message M of N _PE (or N _IC ) bytes from the following items:

Data header: 1 byte with value 7Fh;
PIN block: 8 bytes;
ICC unpredictable number: the value field of 8 bytes of the data object with tag 9F37, obtained from the ICC with a GET CHALLENGE command (see Table 6.5);
Random pad pattern: a string of N _PE ˆ’ 17 (or N _IC ˆ’ 17) bytes generated at random by the terminal.

The RSA digital envelope is obtained through a public RSA operation (see Appendix F, Section F.2) on M with the modulus n _PE and the public exponent e _PE .

After receiving the C-APDU of the VERIFY command with P2 = 88, the card retrieves the RSA digital envelope E from the data field. The card applies a secret RSA operation (see Appendix F, Section F.2) on this digital envelope with the modulus n _PE and the secret exponent d _PE , where ( n _PE , d _PE ) represents the ICC PIN encipherment private key. The result of this operation is denoted M ² .

The card performs the following verifications:

The first byte of M ² must be equal to the data header with value 7Fh.
Recover the 8 bytes of the ICC unpredictable number, starting with the 10th byte of M ² . Check that these 8 bytes correspond to the sequence of random bytes generated by the card and returned in the R-APDU of the GET CHALLENGE command.
Recover the PIN block of 8 bytes starting from the second position of M ² and retrieve the PIN. Check this value against the witness value stored in the card.

If all the verifications mentioned above are passed, the enciphered PIN verification is considered successful.

6.6.6 On-line PIN processing

The processing described in this section applies to the CVM "Enciphered PIN verified on-line" (000010b). The processing performed by the terminal is described below.

If the terminal does not support on-line PIN (see bit 7 in the second byte of the Terminal Capabilities):
- Set bit 5, "PIN entry required and PIN pad not present or not working", in byte 3 of the TVR.
Else
- If PIN pad is malfunctioning:
  - Set bit 5, "PIN entry required and PIN pad not present or not working", in byte 3 of the TVR.
- Else
  - If either the merchant or the cardholder bypass the PIN processing:
    - Set bit 4, "PIN entry required, PIN pad present, but PIN was not entered", in byte 3 of the TVR.
    - The CVM is considered unsuccessful, the CVM Results is not set, and the next CVR in the CVM List is treated.
- Else (on-line PIN is successfully entered):
- Set bit 3, "On-line PIN entered", in byte 3 of the TVR.
- The cardholder verification is complete and successful.