In Section2.1.1, a brief introduction to EMV and its architecture was given. The PIN verification process in an online authorisation environment is called the Online-PIN Verification (OPV). An introduction to OPV is given in Section 2.1.2. Investigating the OPV process is the main focus of this chapter. In our investigation, we elaborate on the indelible trust assumptions placed on the intermediaries (subcontractors) between a payment terminal and the scheme operator/card issuing bank. This trust assumption, makes rest of the participants in the payment architecture assume that the intermedi-aries are trusted and secure. When this trust (assumption) is scrutinised, we discuss a potential attack scenario that can be used by a financial fraudster to compromise PIN related information.
We further discuss how this information can be used by the fraudster to carry out an online PIN approved transaction without the involvement of the genuine cardholder but with the correct PIN. We then propose three solutions based on the existing OPV process that defend against these attacks. The proposed improvements are then imple-mented to measure any incurred performance penalties. In our practical implementa-tion as detailed in secimplementa-tion 3.4.2, however, we implement and measure the performance penalties of both symmetric and asymmetric encryption methods proposed in each of our solutions. The results of performance measurements are included in Tables3.7. Fi-nally we subject the proposed protocol to mechanical formal analysis using CasperFDR to evaluate the security guarantees.
In Section3.1.2we explain why securing the PIN is vital for all the stakeholders at different levels of the payment architecture. To secure PIN and associated transaction details, modern payment terminals are designed to be secure and tamper resistant [159,13,133].
In section2.1.1, we explained how EMV supports offline and online PIN verification methods. In the offline PIN verification, the PIN is verified by the payment card and in OPV the PIN is verified by the authorisation entity. The PIN verification carried out by the authorisation entity is considered as having a higher assurance level then the PIN verified by the payment card. This is because the CIB as the entity that issues the payment card also sets the PIN and manages any PIN changes for each particular customer. The main focus of this chapter is the PIN verification carried out by the authorisation entity which is referred to as OPV.
The financial institutions especially the banks suffer significant financial loss due to payment card fraud [93, 150, 37, 174, 140, 181]. The main focus of this Chapter is to improve the security of OPV process which would help to prevent potential
at-tack scenarios that we identify in our work. Preventing such atat-tack scenarios would significantly help improve the security of payment transactions and reduce the risk of potential financial cost associated with such attacks if they are realised.
In the next section, we extend our discussion on EMV OPV and explain two different methods how OPV process can be deployed in the current EMV payment architecture.
3.1.1 Two OPV Deployment Methods
In this section, we discuss the two different OPV methods that may be used in the current EMV payment architecture. In our discussion, the two OPV methods are differentiated based on whether OPV is carried out together with the online transaction authorisation or as a separate authorisation. Then we explain how the OPV process can be carried out at different stages of the overall EMV transaction, depending on the selected deployment method.
Segmented Authorisation Method
In this section, the OPV process discussed in Chapter 3 is revisited. As explained previously, in the Segmented Authorisation method, the OPV is carried out separately to the online transaction authorisation. In order to explain this more clearly, we list the transaction steps in this deployment method as follows:
1. The CTPOS first constructs the encrypted PIN block which contains the user’s entered PIN.
2. The enciphered PIN block is then sent to the authorising entity to be verified.
The authorising entity could be the Scheme Operator (SO) or the Card Issuing Bank (CIB).
3. If the PIN is verified correctly, the authorising entity sends a response message back to the CTPOS confirming that the OPV was successful.
4. It is after this confirmation of the outcome of the OPV, that the CTPOS proceeds to the online transaction authorisation.
5. The online transaction authorisation request contains the card generated Autho-risation Request Cryptogram (ARQC).
6. The card generates a cryptogram and forwards it to the CTPOS.
7. The CTPOS sends the cryptogram in an online transaction authorisation request to the authorising entity.
8. The authorisation entity verifies the cryptogram and sends a response message to the terminal indicating whether the transaction was approved or declined.
As we can see, in the Segmented Authorisation method, the OPV process initi-ated and completed before the transaction authorisation. This separation of the two processes raised a few security concerns that we discuss in subsequent sections. The proposed solutions that addresses the potential attack scenarios related to the Seg-mented Authorisation Method was previously presented in Section3.3.
Unified Authorisation Method
In this section, we introduce the second deployment method which is different to the one we discussed above. The differentiating factor is mainly related to the communication sequence of the OPV and the transaction authorisation. In contrast to the Segmented Authorisation method, in the Unified Authorisation method that we introduce here, the OPV is carried out together with the online transaction authorisation. To explain this more clearly, we list the transaction steps in this deployment method as follows:
1. Similar to the previous method, the CTPOS first constructs the encrypted PIN block which contains the user’s entered PIN.
2. Instead of sending the enciphered PIN block to the authorising entity separately, in this instance the CTPOS requests the ARQC from the card.
3. Once the ARQC is received, the CTPOS constructs a unified message which includes the OPV and the online transaction authorisation requests.
4. The online transaction authorisation request contains the card generated ARQC.
5. The ARQC together with the enciphered PIN block is then sent to the SO/CIB.
6. After receiving the request messages, the SO/CIB conducts OPV and online transaction authorisation. The outcomes of both verifications are then sent back to the CTPOS in a response message.
As we can see, in the Unified Authorisation method, the OPV process and the transaction authorisation is carried out together in the same message sequence. In this section, we explained both the Segmented and Unified Authorisation methods. In the next section, we explain a potential issue that raise concerns regarding the security of OPV process.
3.1.2 Problem Statement
In the current EMV architecture in which OPV process is carried out, there are a number of intermediary entities in the communication path between the CTPOS and the SO/CIB. The EVM Card Specification Book 4 recommends and outlines why this communication should be adequately protected [16].
By examining the OPV process used in the ATM transaction architecture [195] and referring the literature in [49, 131, 65], it is clear that first the CTPOS requests the PIN from the cardholder. Once the PIN is received the CTPOS encrypts it before forwarding the encrypted PIN details to the authorisation entity for verification.
During a transaction, the CTPOS encrypts the PIN using a symmetric key shared between the terminal and the first point of contact (which is not necessarily the SO/CIB) in the communication channel towards the SO/CIB. It must be noted that the symmetric key used to encrypt the PIN between the CTPOS and the first point of contact can also be a session key. We explain this process which is also termed as the key-translation in Section 2.1.2. The same key-translation mechanism is used by the first point of contact to forward the PIN to the next entity in the communication path towards the SO/CIB.
We explained the EMV OPV process in section 2.1.2. There is another process in EMV called the “transaction authorisation” which is used to decide whether a partic-ular transaction can be authorised or declined. As part of this process, during a trans-action the payment card generates a message to request authorisation to a particular transaction by the authorization entity which is called the transaction authorisation message. In the EMV specification, this authorisation request is called the ARQC.
However, the current payment process has no binding between the ARQC and the OPV process [14,13,15,16].
The ARQC is encrypted by a symmetric key shared between the payment card and the authorisation entity. The encrypted fields include a number EMV tags that are standardised parameters in the EMV specification. In EVM Card Specification Book 4, it details that one of these tags is the Cardholder Verification Method (CVM) which indicates the method used to verify a cardholder during the transaction [16]. Normally the cardholder verification is carried out before the transaction authorisation.
The CVM is a tag that is three bytes in length. The bytes indicates: the CVM performed, CVM conditions and CVM results [16, see: p49]. When it comes to infor-mation related to the OPV process in the CVM tag, the only inforinfor-mation related to the OPV is a single binary value that is set to 1 if CVM was performed at the start of a payment transaction [15, see: p162]. As we can see in both the CVM or the ARQC, there are no tags/parameters that binds the OPV process with the associated ARQC.
Another key observation that we understand is that during an OPV, the PIN is handled (creating a PIN block to be sent to the authorising entity for approval) only on the PIN entry device which in this case the CTPOS and the payment card is not informed about the PIN value entered on the CTPOS.
The risk associated with the weaknesses and shortcomings that we briefly outlined above is realised if an adversary compromises one of the intermediaries that engage in the key-translation process between the CTPOS and the authorisation entity. Such compromise would lead to the adversary obtaining details such as PIN and associated payment transaction related information to carry out further financial fraud.
The adversary at the compromised entity will be able to observe OPV messages that include PINs and associated Primary Account Numbers (PAN). By obtaining such information, the attacker is now in a position to carry out an OPV-based transaction at a merchant’s premises with a stolen card for which the adversary has previously obtained the relevant PIN. This way an attacker can perform an EMV transaction that requires online approval at a CTPOS.
As indicated in reports [45, 117, 118], the notion of an attacker being able to compromise an intermediary in the payment architecture is not hypothetical or too far-fetched. It is important not to underestimate such scenarios for the overall improvement of the payment system.
3.1.3 Contributions
In this chapter we propose solutions that enhance the security of EMV OPV process by addressing the aforementioned security concerns that we briefly identified. Our main contributions for this chapter are two fold. The first contribution is the proposed en-hanced OPV process that proposes three separate solutions to protect the PIN details.
The second contribution is how we bind the OPV with the respective ARQC in an online transaction authorisation scenario.
1. To protect the PIN we have proposed an enhanced OPV process using:
(a) Card-based solution with symmetric cryptography.
(b) Card-based solution with asymmetric cryptography.
(c) Payment terminal-based solution with asymmetric cryptography.
2. Binding each OPV with the associated ARQC.
The remainder of the chapter is structured as follows. In section 3.2the payment networks operating environment is outlined and the attacker’s capabilities and potential
attack vectors for compromising the OPV process is discussed. In section 3.3, the three potential countermeasures that address the security concerns are provided. The proposed solutions are then analysed in section 3.4. Finally, concluding remarks are provided in section3.5.