EMV is a payment method based upon a technical standard for smart payment cards and for payment terminals and automated teller machines which can accept them. EMV originally stood for 'Europay, Mastercard, and Visa', the three companies which created the standard.EMV cards are smart cards, also called chip cards, integrated circuit cards, or IC cards which store their data on integrated. Price: $100buy software directly here: @x2allahmail: x2carder22@protonmail.comdisclaimerthis video is intented only for bu. EMV chip card transition in U.S. Different than elsewhere Unlike other regions of the world, chip card introduction hasn’t been legislated or mandated by the government. As a result, we’ve had kind of an uneven implementation across the country.
The testing of the EMV payment application differs significantly from regular POS application. In which, there are many additional scenarios including for offline/online transactions and security that need to be covered.
Calculate Cryptogram ARQC/ARPC for EMV ISO8583 including key derivation and session key. EMV Level2 Kernel is library for embedded systems (such as PIN pad, EFTPOS, ATM). Library implements payment operations with MasterCard/Visa smartcards and supports all features within the EMV Level 2 specification. Project contains PC-based test.
Transaction Processing Comparison – Magstripe Vs EMV
Magstripe Transaction Flow
To understand the difference in the flow for testing Magstripe vs EMV, the following are some points to consider:
Magstripe is easily cloned
Terminal performs little or no risk assessment
Authorization/Capture Message
Track data is often in the clear
The authentication data is static
Authorization/Authentication
Risk assessment performed at the host
Host cannot recognize cloned cards
Transaction flow would be as follows:
Transaction initiated from Terminal to Acquirer system
Acquirer forwards it to card association
Card association forwards it to Issuer
Issuer responds back with the Auth Code and transaction flows back in the same fashion up to the Terminal
EMV Transaction Flow
EMV Transaction flow will be as follows:
EMV transactions begin with a data exchange between the card and the terminal.
When a customer uses a chip card at the terminal, the terminal communicates with the card to obtain all the information needed to determine if the transaction can be processed offline or must be processed as an online transaction
Kernel processes the offline data authentication – SDA, DDA, CDA, fDDA
Kernel performs the CVM based on Terminal and Card Capabilities – PIN, Signature, CDCVM
If the terminal determines the transaction must be processed online, the terminal sends a Read Record Command to the card to retrieve the Card Data Objects List (CDOL1). The CDOL contains a list of EMV tags and value lengths that the card needs from the terminal
The terminal uses information from the CDOL to compile a list of ‘values only’ that is sent to the card in an authorization request cryptogram (ARQC) Generate AC command
The card validates the information from the terminal and, if the data is formatted correctly, sends a response to the terminal containing the ARQC, Application Transaction Counter, and Issuer Application Data.
The terminal uses the information from the card, as well as the tags and values that the terminal sent to the card previously and sends a request to the Acquirer.
The Acquirer maps the message from the terminal into the message format required by the Issuer or designated Gateway.
The Gateway/Interchange/Switch must send the tags and values from the terminal to the Issuer unchanged. If the values are modified in any way, the Issuer will not be able
to validate the ARQC. The Issuer receives the message and generates a response using the following process
When the Issuer receives the message, the Issuer generates its own ARQC by reconstructing the block of data used when the card generated the ARQC. The Issuer then validates that its Issuer-generated ARQC matches the card’s ARQC (sent in the message).
About the 9F10 tag in the request message: The 9F10 tag is used to identify what key file index should be used (that is, it identifies the keys on that card), and contains the cryptogram version number (CVN). The Issuer uses the CVN to determine the type of algorithm to use when generating a session key and the cryptogram’s block of data.
The Issuer uses the request message’s ARQC, as well as the Authorization Response Code (ARC) when generating the authorization response cryptogram (ARPC).
The Issuer sends the ARPC and any Issuer scripting back to the card in the response.
Again, it’s imperative that the information sent back to the terminal and card for the cryptogram goes through the Gateway/Interchange/Switch and the Acquirer unchanged. If anything is modified or changed during the transfer process, the card cannot validate the ARPC.
When the terminal gets the response, it sends the card the ARPC in an external Authentication command.
The terminal can now send the card any applicable Issuer script commands (that is, Application Protocol Data Unit (APDU) commands such as PIN change, application block, or card block) to be processed, or to be used in the completion message. If the card approves the ARPC and an APDU command has been sent to the card, even though an Issuer script may not be relevant to the current transaction, the command will be executed. The card then responds to the device with a status command that indicates whether the command was executed successfully. (This example addresses only Issuer Script APDU commands. There are other APDU commands as well, but those commands occur offline between the Card and the terminal—that is, those commands are not sent by the Issuer.)
Test Considerations for Various Entities
This section covers the Testing considerations that encompass Issuer, Acquirer, Switch and so forth in the EMV transaction Flow. The entities taken into consideration are:
Acquirer
Switch/Gateway/Interchange
Issuer
Acquirer EMV Processing Considerations
As an Acquirer, Merchant, Merchant Acquirer, or Terminal Driver, the implementation of EMV can affect several aspects of transaction processing. Organizations will likely need to develop tests the address needs such as:
Testing ATM and POS configurations for compatibility with both chip cards and magnetic stripe cards
Testing EMV message processing capabilities, including
Testing ability to recognize and correctly process properly (and improperly) formatted EMV messages
Testing ability to recognize and correctly process valid (and invalid) EMV message contents
Testing fee processing
Testing any required information handling for card or account management
Testing ability to properly map the EMV tags or tokens in received messages to the correct tags and tokens required in the EMV messages one send to others
Switch/Gateway/Interchange EMV processing considerations
As a Switch network, Gateway, or Interchange, primary challenge is EMV message mapping and validation. Organization will likely need to develop tests the address needs such as:
Testing validation of the EMV message
Testing ability to recognize valid (and invalid) data in the EMV message contents
Testing your ability to recognize properly (and improperly) formatted EMV messages
Testing ability to correctly map the EMV tags or EMV tokens before you forward the transaction
Ensuring one examines the correct EMV tags or EMV tokens when you receive a response message
Testing fee processing
Testing any required information handling for card or account management
Testing switch availability, and testing to ensure ability to process a higher volume of online transactions
Issuer EMV processing considerations
Emv Arqc
Issuers face more challenges than the other entities in the EMV transaction processing flow. Not only do Issuers face the difficulty of simulating their various endpoints during testing, they must also ensure their EMV messages are properly formatted and contain the correct content, including managing the cryptogram. In addition, current card management systems and risk management systems must be evaluated and updated to accommodate the new chip cards and associated EMV processing.
Your organization will likely need to develop tests the address needs such as:
Ensuring host correctly processes transactions regardless of the terminal’s capability to accept chip cards
Ensuring EMV message is properly formatted and that its contents are valid
Testing validation of the cryptogram sent in the request message, and ensuring Host Security Module (HSM) generates the correct cryptogram for the response
Testing the management of the keys on the card and on the host
Testing your ability to process Issuer scripts (that can potentially damage your test cards)
Girmiti team has strong expertise in using the certification tools to evaluate the applications.
Also ensure your card management system and fraud/risk management systems have been successfully updated to support chip card transactions.
Our Team helps and works closely with related companies, to understand the existing scope, current business scenarios, flows of the existing systems, to provide the consulting solutions to Build, Architect, Enhance Features, Design, Develop, Test, Support, Maintain existing system and UAT.
Know more about our technology services Read more....
For more information please contact us at info@girmiti.com
One of the primary benefits of EMV is that it significantly reduces counterfeit fraud. This is accomplished by the use of an application cryptogram. By validating the application cryptogram that is generated by the chip card, the issuer or the terminal can be confident that the card has not been cloned or counterfeited. There are several types of application cryptograms, we will review the ARQC and the ARPC which are the two online cryptograms used within EMV. In an EMV transaction flow when a chip card is used at a chip enabled ATM or POS device and the transaction is sent online to the host for authorization the chip card will generate an application cryptogram called the authorization request cryptogram or ARQC. The issuer may then generate an application response cryptogram or ARPC.
Let's take a very high-level look at how the ARQC and the ARPC are generated and verified. This discussion focuses on the primary steps and data involved in the generation and verification of these two cryptograms.
Generating the ARQC:
To generate an ARQC, the chip requires three pieces of information.
- A specific set of EMV tags
- Card master key (key for authentication)
- Hash function (hash algorithm) or MAC
Let's look at each of these components individually. A chip that contains a financial application from MasterCard, Visa, American Express and so forth must comply with EMV Co specifications. Each financial application on the chip will contain many fields called EMV tags. These tags house the data necessary to support the exchange of information between the card and the terminal. Tags also contain the information necessary to generate and verify the various application cryptograms.
One of the EMV tags in the card is tag 8C. The card risk management data object list 1 also known as CDOL1. This tag contains a list of specific tags that the chip is to use when generating the ARQC. In the EMV specification referenced below you will see the list of 10 EMV tags that are the recommended minimum set of data elements that are to be used when generating any application cryptogram.
EMV specifications from the various payment systems such as MasterCard, Visa, American Express and so forth can mandate additional tags for this list. For example, the cardholder verification results is usually included, no one usually requires fewer tags than those shown here. Note that some of the tags in this list contain data provided by the chip enabled terminal instead of the chip card.
Check with the EMV specification for the particular payment system or network you are interested in to find out exactly what EMV tags that system or network requires for ARQC generation.
The second piece of information that is required in order to generate an ARQC is a key. When the chip is personalized by the issuer, that is, when information specific to the individual cardholder is injected into the chip one or more keys are included depending on the functions the card will support. A specific symmetric key is required in order to generate an ARQC. This key can go by many names such as:
- The card master key
- The key for authentication
- The cryptographic key
- The application cryptogram master key
We will refer to it as the card master key. The card master key is derived from an issuer master key. The card master key is unique for each chip card and can even be unique for each application on a chip card. This is because information specific to the cardholder such as the PAN and PAN sequence number is part of the data that is used to generate the card master key. Since there can be more than one card master key stored in the chip, there's an index associated with each key that identifies each key as key number one, key number two and so forth.
The third piece of information that is required in order to generate an ARQC is a hashing algorithm also known as a hash function. The hash function is used to reduce a large string of data to a more manageable size. Some specifications may use a MAC'ing operation to reduce the data. Now let's walk through an example to see how all of these pieces fit together.
The actual algorithm that is used to generate a cryptogram is proprietary for each icc specification so be sure to check with the relevant ICC specification for your situation this is just an example. The chip looks at the CDOL1 to find the list of EMV tags it needs. Then it retrieves the data from each of those tags. This example uses the list of EMV tags that are recommended by EMV CO with sample values in each field as you can see in the table below:
All of the field values in the above table are concatenated. Resulting in a very long string of data. The hash function or MAC operation is then applied to the long string of data, to reduce it to a more manageable size. The result is then encrypted using the card master key. The result of this step is a 16 character hexadecimal ARQC. The chip saves the ARQC internally in EMV tag 9F26. This tag is then passed to the issuer, and the authorization request, along with the index of the card master key that was used to generate the ARQC. The EMV tags that are specified in the CDOL1 are often sent to the issuer in their transaction requests. However check with the individual network specifications for your situation to see exactly which EMV tags any particular specification supports. For this discussion we will assume that the card issuer is the entity that will receive the transaction requests, perform the EMV validation and authorize the transaction.
Emv Software With Arqc
Another party such as a network could perform these functions on behalf of the issuer. In that case the network would need to have the appropriate keys and the other components required to perform these functions for the issuer. But in our example the issuer receives the transaction request that includes the ARQC and the issuer will attempt to validate the ARQC. This validation is performed within a hardware security module(HSM). Issuers must make sure that their HSM supports the necessary commands and that the message sent to the HSM, to request ARQC verification contains all the required information and that the values sent to the HSM are appropriate for the card that was used in the transaction.
The HSM will not attempt to break down the ARQC that was generated by the chip card. Instead it will use the card master key and a hash function or Mac algorithm plus key index sent from the chip card to generate its own ARQC.
The result will be compared with the ARQC that was generated by the chip card. If the two match then the ARQC generated by the chip card is valid. If the two do not match, the problem is usually the result of mismatched keys, the wrong key index or incorrect data passed to the HSM by the issuers application software.
In our example the issuer will send an authorization response cryptogram or ARPC to the chip card as part of the authorization response. In this case the command that is sent to the HSM to verify the ARQC may indicate that the HSM is to generate in the ARPC if the ARQC can be successfully validated.
To generate the ARPC, the HSM will use a specific set of EMV tags, the card master key and either a Triple DES or AES algorithm. In our example only the ARQC from the request and the authorization response code generated by the issuer will be used when generating the ARPC. Check the individual payment scheme specifications to verify what EMV tags are required for your situation.
There are several accepted methods that can be used to generate an ARPC. In our example the HSM will compute a value by XOR'ing the issuer response code against the ARQC. The result will then be encrypted using the card master key and either a Triple DES or AES algorithm. The result of this encryption is a 16 character hexadecimal ARPC. Since the data elements, keys and algorithms used to generate the ARPC can vary, check with the individual payment system or network specifications for further details.
The ARPC is used by the chip card to validate that the transaction response was sent by the genuine issuer. The chip card will not attempt to break down the ARPC that was generated by the issuer, instead it will generate its own ARPC. In our example we'll assume that the issuer sent an ARPC and the transaction response and the terminal passes the ARPC to the chip card. In order to validate the ARPC the chip card will XOR the ARQC against the issuers response code and encrypt the result just as the issuer's HSM did in our example. The resulting ARPC will be compared with the ARPC that was generated by the issuer. If the two match then the ARPC generated by the issuer is valid. If the two do not match but the transaction was approved by the issuer the chip card will typically tell the terminal to generate a reversal, since this situation could be indicative of fraud or at the very least it may indicate a problem with the keys or some other data element in the card or the issuers application software or the HSM.