Acquiring

acquiring focuses on the steps carried out between merchants and banks for processing credit and debit transactions, either through traditional card based transactions or mobile payments the following sections cover these acquiring topics pin translation and verification emv validation mobile payment acceptance cvv validation pin translation and verification when users enter their card personal identification number (pin) on a device (such as an atm or payment terminal), the device encrypts the pin and then sends it to an hsm in the bank data center, along with the account or card number and the pvv or offset (depending on the method) the hsm then decrypts the pin that the user entered, takes the account or card number, the bank pin verification (pvk), and the pvv or offset and derives the actual pin then, it compares that pin value to what the user entered and approves or declines the transaction the data structure for an encrypted pin is called a pin block pins are typically four characters, but you cannot encrypt only four characters with the des algorithm because you need at least an 8 byte block of data, the payment industry created the concept of pin blocks embedded in a pin block are the length of the pin, the pin itself, and padding then, all of that data is xored with a portion of the account number the result is the clear value of the pin block the clear pin block value is then encrypted with a pin encryption key (pek) different standards exist for pin blocks, and we currently support iso format 0 and iso format 3 the new iso format 4 standard supports an aes pin encryption key, but aes pin blocks were previously not supported because of issues with aes requiring a 16 byte block of data to encrypt common pin translation and verification commands this section contains pin translation and verification commands for excrypt, standard, and international command sets excrypt command description rpin pin change & optional pin verification (ibm 3624) rpin pin change & optional pin verification (ibm 3624 dukpt) rpin pin change & optional pin verification (visa) rpin pin change & optional pin verification (visa dukpt) tpcp translate encrypted pin coordinates to a pek for generate new map collection tpdd allow an encrypted ansi pin block to be translated tpin translate pin blocks tpin translate pin blocks (dukpt) tpin translate pin blocks (ibm 4736) trpn translate pin from rsa to symmetric pin block tspn translate pin from pin block to rsa encryption vmap verify mac and pin (diebold method) vmap verify mac and pin (ibm 3624 method) vmap verify mac and pin (visa method) vpin verify pin wpin weak pin checking xpin ansi to ansi xpin ansi to pin pad xpin extended pin translation xpin ibm 3624 to ibm 3624 xpin ibm 3624 to pin pad xpin ibm 4736 to ibm 4736 xpin pin pad to pin pad standard command description 31 translate pin block 32 verify pin 32 verify pin ansi 32 verify pin compare two pin blocks 32 verify pin diebold 32 verify pin diebold dukpt 32 verify pin ibm 3624 32 verify pin ibm 3624 dukpt 32 verify pin ibm 4736/ncr 32 verify pin visa 32 verify pin visa dukpt 335 translate pin block 33 extended pin translation 346 dukpt pin translate 35 translate pin block using double encryption 36 verify pin block using double encryption 36 verify pin block using double encryption (ansi) 36 verify pin block using double encryption (compare two pin blocks) 36 verify pin block using double encryption (diebold dukpt) 36 verify pin block using double encryption (diebold) 36 verify pin block using double encryption (ibm 3624 dukpt) 36 verify pin block using double encryption (ibm 3624) 36 verify pin block using double encryption (ibm 4736 ncr) 36 verify pin block using double encryption (visa dukpt) 36 verify pin block using double encryption (visa) international command description bc verify a terminal pin using the comparison method be compare pin to encrypted pin block ca translate pin block from tpk to pek encryption cc translate pin block from one pek to another pek ci translate pin block from bdk to pek encryption ck verify pin using the ibm method (dukpt) cm verify pin using the visa pvv method cu validate pin and generate new pvv da verify terminal pin block ibm 3624 dc verify terminal pin block visa du verify and generate an ibm pin offset (of a customer selected pin) ea ibm 3624 ec visa g0 translate pin from bdk to zpk encryption (3des dukpt) jc translate pin from tpk to mfk encryption je translate pin from zpk to mfk encryption jg translate pin from mfk to zpk encryption sc verify public key encrypted pin emv validation when you insert (or dip) an emv card at a terminal, the terminal performs a few validations, such as the type of product (such as debit or credit) and the cardholder verification method (such as chip and pin or chip and signature) after validations, the terminal requests an authorization request cryptogram (arqc) from the integrated circuit chip (icc) of the card arqc validation and arpc generation the following workflow describes the arq validation and arpc generation process the chip generates an 8 byte application cryptogram (ac) using an application cryptogram master key (mkac) the chip performs the following actions to generate the application cryptogram (ac) it generates an application cryptogram session key (skac) by using the mkac and an application transaction counter (atc) value the session key is unique for each transaction it uses the session key and the data to generate an application cryptogram (ac) by applying 3des or aes in the case of an online transaction, this authorization cryptogram is called an authorization request cryptogram (arqc) the chip sends the arqc to the terminal, which in turn sends the arqc in the authorization message to the issuer host for authorization upon receiving the arqc in the authorization request, the issuer system validates the arqc and generates an application response cryptogram (arpc) by using a hardware security module (hsm) if the arqc verification is successful, an arpc is generated by using arqc as one of the inputs if the arqc verification is unsuccessful, then you shouldn't use the arqc for arpc generation you can use the following methods to generate the arpc method 1 generates an 8 byte arpc by using an 8 byte arqc and a 2 byte authorization response code (arc) as input method 2 generates a 4 byte arpc by using an 8 byte arqc, a 4 byte card status update (csu), and a 0–8 byte proprietary authentication data as input the arpc is sent in an authorization response message from the issuer to the terminal through the acquirer commonly used emv validation commands this section contains emv validation commands for excrypt, standard, and international command sets excrypt command description empt translate pin block for emv personalization emva verify qrqc and optionally generate arpc emvp pin change emvr emv rsa private key or component translation to encryption under a personalization key emvs translate an icc master key to encryption under a personalization key emvt emv translate sensitive data vcac verify emv mastercard cap token vcav verify cardholder authentication verification value vdac verify a data authentication code (dac) vdcv verify cvc3 vddc verify discover dynamic card cvc3 vemi verify an emv issuer certificate vidn verifies an icc dynamic number (idn) vvdc verify a dynamic cvv standard command description 350 emv arqc validation 357 dynamic cvv validation 359 dynamic cvc3 validation 365 verify visa cloud based payments international command description js upi arqc verification and arpc generation kg validate a signed issuer certificate kq arqc (or tc/aac) verification and/or arpc generation mobile payment acceptance mobile payments use a combination of specialty hardware and a mobile wallet (such as google pay, apple pay, samsung pay, and so on) users hold their mobile devices up to the contactless payment terminal this enables the two devices to communicate over a specific radio frequency, passing encrypted payment information back and forth to complete the transaction the funds then leave the user's digital wallet and enter the business point of sale system tokenization is another critical piece in enabling mobile transactions and payments when you set up a mobile wallet, details are sent to your issuing bank the bank replaces these details with a token, a set of randomly generated numbers this keeps your account details completely encrypted and protected from fraud commonly used mobile payment acceptance commands this section contains mobile payment acceptance commands for excrypt command set excrypt command description dapt decrypt apple pay token dgpt decrypt google pay token dspt decrypt samsung pay token vhmc verify hce mobile cryptogram vhmd verify hce magstripe verification value the standard and international command sets do not support mobile payment acceptance card verification value validation card issuers and banks use card verification values (cvv) to determine when someone uses a forged card in a card notpresent transaction using the card expiration date, pan data, and pin, an hsm can cryptographically validate cvv (in its many forms, including cvc, cid, csc, cvc2, and cvv2) and determine if the card data presented is authentic for online or contact free payments cvv, cvc, and cvc2 cvc accelerates the process of verifying card data in card present transactions the magnetic strips contain the cvc, and card reading point of sale terminals process these codes anytime a card is inserted cvv and cvc2 are commonly referenced for card not present transactions and are used interchangeably they are usually in the form of a three or four digit code on the back of the card, and they are often used in place of cvc for card not present transactions reasons for validating cvv in online transactions, cvv validation is one of two ways of verifying if cards are authentic (the other method is xml based authentication) storage of cvvs in any database is expressly prohibited, but businesses need to have access to the card's public key to decrypt and verify transactions to secure the cvv, the process uses hsms to validate and encrypt it there is cvv generation and verification, but not translation because it is not encrypted between the hops commonly used cvv validation commands this section contains cvv validation commands for excrypt, standard, and international command sets excrypt command description vaav verify account holder authentication value vcsc verify american express (amex) csc value vcvc verify cvc and cvc2 vcvv verify cvv vdcv verify discover dynamic card cvv vddc verify dynamic cvc value (cvc3) vemi verify emv issuer certificate vidn verify icc dynamic number (idn) vvdc verify dynamic cvv standard command description 357 dynamic cvv validation 359 dynamic cvc3 validation 35a verify american express (amex) csc value 5e verify card verification value (cvv) international command description cy verify visa card verification value (cvv) ry (mode 4) verify card security codes for csck message authentication code generation and verification message authentication code (mac), also referred to as tags, authenticates messages in other words, mac ensures that the message came from the stated sender (its authenticity) and has not been changed the mac value protects message data integrity by enabling verifiers (who also possess the secret key) to detect any changes to the message content, thus preventing man in the middle attacks and fraudulent hosts or atms currently, macing is not very common in the u s for payment transactions however, in canada, a government owned interbank network, interac, forces participating banks to mac all payment transactions common mac generation and verification commands this section contains mac generation and validation commands for excrypt, standard, and international command sets excrypt command description emvm generate/verify mac ghpb generate hmac and pbkdf2 obfuscated value gmac generate message authentication code (mac) gpmc general purpose symmetric mac hmac generate mac hash rkhm generate/verify hmac vmac verify message authentication code (mac) vmap verify mac and pin diebold method vmap verify mac and pin ibm 3624 method vmap verify mac and pin visa method standard command description 56 generate mac (512 bytes or less) 57 generate mac (512 bytes or more) 5a verify mac (512 bytes or less) 5b verify mac (512 bytes or more) 5c verify and generate mac (dukpt) 98 generate mac value based on mac key and data 99 verify mac value based on mac key and data 11d generate mac and dek keyblocks 304 verify cmac using tdes 305 generate cmac using tdes 324 verify apacs 40 request mac 348 verify mac using dukpt key derived using the bdk and ksn 386 generate mac using dukpt key derived using the bdk and ksn international command description c2 generate a mac (as2805) c4 verify a mac (as2805) eo generate a mac on a public key eq verify a mac on a public key gw generate or verify a mac (3des dukpt) l0 generate an hmac secret key lq generate an hmac on a block of data ls verify an hmac on a block of data m6 generate mac using mak (supports continuation mode) m8 verify mac using mak (supports continuation mode) ma generate mac using mak mc verify mac using mak mk generate a binary mac mm verify a binary mac mq generate a binary mac (extended length) ms generate a binary or hex mac (extended length) my verify and generate mac pq generate an as2805 4 mac ps verify an as2805 4 mac rk verify mac and return mac residue remote key loading (rkl) we all depend on encryption keys in one way or another while few people outside the payments industry are aware of this, anytime you present your payment card at a point of sale (pos) terminal or use an automated teller machines (atm), an encryption key quickly goes to work to encrypt the pin or the primary account number (pan) associated with your card this encryption obscures the data and protects against information theft as the transaction goes back to the card issuer for validation for this process to work, an encryption key must be securely loaded into that endpoint device, such as an atm, a pos terminal, or even a commercial off the shelf device used for payment acceptance you load the encryption key onto those devices manually through a process known as direct key injection for pos terminals and pin entry devices, this involves bringing the devices to a key injection facility where key administrators manually inject each device this can be time consuming and expensive it requires the upfront cost of maintaining a validated payment card industry (pci) level 3 key injection facility (kif), and the operational costs of shipping devices to the kif anytime you need to rekey them for larger devices, like atms and gas station payment terminals, key administrators often have to travel to each device in the field to load the necessary encryption keys for organizations with widespread atm or pos networks, this can be a significant operational expense with a high susceptibility to human error while the direct injection model is sufficient for many organizations, others find a remote key loading (rkl) solution more cost effective and efficient with rkl, a remote key server establishes a secure, pki authenticated connection with each device and remotely distributes encryption keys without needing physical access to the device the ability to remotely rekey the device in the field without extended downtime is a powerful time and money saver for many organizations rkl allows organizations to manage keys for an entire infrastructure by sending cryptographically secure key exchanges from a centralized location better yet, you can rekey devices instantaneously with minimal downtime, eliminating the costs of maintaining an injection facility and manual injection successful remote key loading (rkl) operations require collaboration and standardized communication protocols between the device manufacturer and the rkl provider trust at both ends of the key exchange is the backbone of rkl, with the rkl provider on one side and the field level device on the other a certificate authority establishes this trust, providing the endpoint terminal and the rkl platform with a digital certificate this certificate is a private key in the public key infrastructure (pki) that facilitates secure key exchanges the manufacturer must ensure that their devices have this certificate before deployment furthermore, the endpoint devices and the rkl provider must use the same communication and encryption protocols, which furthers the manufacturer’s role in the process while the most common and accepted encryption standard for rkl is tr 34, which was developed by asc x9, there are many others in use depending on manufacturers, geographic location, and other factors rkl providers need to be accommodating in their platform design to enable integration with multiple manufacturers atms millions of people use atms to withdraw cash every year in 2016, the united states federal reserve noted that 91% of americans have credit, debit, or other bank accounts, and three quarters of them use atms for cash withdrawals with so many people depending on atms functioning properly, security is a major concern atms rely on network protection and pin encryption techniques to keep the customer pins safe compliance and security mandates require you to rotate the encryption keys that encrypt and validate pins regularly before remote key loading became a viable option, keyholders had to visit each atm in person to rotate keys across the network as the number of atms grew, this process became cumbersome and increasingly infeasible furthermore, payment card industry data security standard (pci dss) regulations require all pins to be encrypted upon capture at the terminal rkl provides a secure, efficient, and cost effective method for loading and managing atm encryption keys across entire atm networks pos terminals pos terminals have double the encryption work like atms, they encrypt pins for debit card transactions, but many merchants also require encryption of the primary account numbers, commonly known as pans, which are the account numbers associated with credit card payments while pci dss regulations do not require pan encryption, it's rapidly becoming the norm in the payments landscape recent years have seen high profile data breaches traced back to a lack of pan encryption pan encryption works similarly to pin encryption, but the technology surrounding pan encryption is typically called point to point encryption (p2pe) like pin encryption, p2pe encrypts the pan at the moment of capture in the pos device the encryption mechanisms behind pin and pan encryption differ slightly on the payment processing end, but they are the same for rkl both processes require reliable access to encryption keys most pos terminals have at least two key slots, with separate keys for pin and pan encryption common rkl commands this section contains rkl commands for the excrypt command sets excrypt command description pedk key request (version 3 mode 1 two pass) pedk key request (version 3 mode 2 one pass tr 34) pedk key request (version 3 mode 2 one pass tr 34 with aes) pedk key request (version 3 mode 3 one pass) drki identification request (mode 1) drki identification request (mode 2) drkk key request (mode 1) drkk key request (mode 2) drkv key verification request (mode 1) drkv key verification request (mode 2) standard and international command sets do not support rkl atm network an atm network, or interbank network, is a computer network that enables you to use atm cards issued by a financial institution that is a member of the network to perform atm transactions through atms that belong to another member of the network network key exchange every active atm has a pin encryption key (pek), master key, and key encryption key (kek) loaded on it through remote key loading (rkl) to do this, the payment application on the backend sends a request to an hsm to generate a random kek, encrypt it under the atm public key or certificate, and send it to the atm the atm then decrypts the kek by using the private key associated with the public key or certificate that encrypts it this key management scheme is called master/session on the atm, the kek (or master key) encrypts a randomly generated working key (or session key) in this case, the session key is the pin encryption key (pek) the pek is changed out regularly in some cases, once a day or once every 1,000 transactions the kek is changed out less frequently (such as annually or once in the life of the atm) foreign transaction example suppose an ibc bank customer goes to a chase bank atm and inserts their ibc debit card in the card reader they enter their pin, which the atm encrypts under its pek and sends to first data corporation first data hosts their star network, which provides debit acceptance at more than two million retail pos, atm, and online outlets for nearly a third of all u s debit cards this example uses first data, but many other networks exist to provide debit acceptance services because first data also has a relationship with ibc, they know that the ibc processor is visa debit processing services (dps) and therefore initiate the following process first data forwards the request to visa dps to process visa dps sends the response back to first data first data delivers the response to the chase atm so, why can't chase send the request directly to ibc or visa dps? because it's not feasible for chase to have relationships with every processor thus, they go to a network, first data, in this case first data has relationships with all banks and processors and with other networks that do have a relationship with the issuing bank pin translation pin translation plays a crucial role in all atm foreign transactions between each of the hops in the preceding example, a pin translation takes place by using the tpin excrypt command each involved entity has its own pin encryption key (pek) in addition, between each link in the network chain, a shared pek is established between the two entities for example, the process looks like this chase and first data have a shared pek, which we'll call cfd pek this shared pek is stored on an hsm in both companies' data centers after the ibc cardholder enters their pin, the chase atm encrypts it under its pek and sends it to the chase hsm, requesting that it perform a pin translation from the atm pek to the cfd pek and then send it to first data first data then performs a pin translation from the pin being encrypted under the cfd pek, encrypting the key under its own pek then, the encrypted pin is translated again, encrypting it under the pek established between visa dps and first data, and the process continues to reiterate, each link in the chain must establish a shared key for pin translation to occur typically, the process involves more than a pek most likely, the process would establish an mfk cfd kek key and use the kek to share other keys so that the pek could be swapped out periodically point to point encryption the pci security standards council established the point to point encryption (p2pe) standard in 2012 it stipulates that cardholder information should be encrypted immediately after the card is used with the merchant's point of sale terminal and not be decrypted until the payment processor has processed it pci dss does not require p2pe encryption pci states that if you have a network where clear cardholder data is transmitted, you are within the scope of dss compliance requirements because of this, when companies started encrypting cardholder data, they correctly assumed that they no longer fell within the scope of dss however, pci caught wind of this and considered that if these companies were encrypting cardholder data, they would need to securely manage encryption keys thus, they created the pci p2pe security standard, making its requirements even more stringent than pci dss in reality, there are primarily two types of companies that deploy p2pe in their payment processing transactions retailers that want to reduce risk and don't want to be in the news acquirers that are trying to add value to their service before p2pe, there was no need for hsms for acquirers because the only transactions going through an hsm were pin based transactions now, if an acquirer uses p2pe, every transaction goes through an hsm common p2pe commands this section contains p2pe commands for excrypt, standard, and international command sets excrypt command description dcdk decrypt cardholder data using dukpt ecdk encrypt cardholder data using dukpt ongq translate pan encrypted under an asymmetric key pair to a different trusted public key tcdk translate cardholder data using dukpt tdkd translate cardholder data using dukpt and symmetric keys tkdr translate dukpt data to rsa with specific output data standard command description 388 3des dukpt encrypt/decrypt data 52 data translate international command description m0 encrypt a block of data m2 decrypt a block of data