2.2.2 Transaction Flow
[SELECT APPLICATION]
A transaction starts by selecting the desired application, which should be supported by both the card and the terminal. The command used for this purpose is SELECT, identi ed by CLA = 0x00 and INS = 0xA4. There are two ways to select an application: select by name using 1PAY.SYS.DDF01, or select by Application Identifier (AID). The former requires a further READ RECORD command (CLA = 0x00, INS = 0xB2) to select the applications under the directory 1PAY.SYS.DDF01, while the latter can select an application directly.
[GET PROCESSING OPTIONS - AFL, AIP]
Following application selection, the terminal will issue a GET PROCESSING OPTS command (CLA = 0x80, INS = 0xA8) which should retrieve the Application Interchange Profile (AIP) and Application File Locator (AFL). The AIP contains information about the type of authentication supported while the AFL tells the terminal which records (list of objects) should be read from the card to perform the transaction.
...
[READ RECORDS SPECIFIED IN AFL - CDOL1, CVM]
The next step is to read the records specified in the AFL by using the READ RECORD command. The most important objects are the Card Risk Management Data Object List 1 (CDOL1) and the Cardholder Verification Method (CVM) List. The CDOL1 specifies which data should be included in the first GENERATE AC command, while the CVM list enumerates the methods that can be used to authenticate the card user (e.g. PIN or signature). In the Chip and PIN system, as its name suggests, the most common CVM is the plain text PIN (there is an option to encipher the PIN but this is not used in the UK).
[GET PIN TRIAL COUNTER]
The next step of the transaction is to get the PIN try counter by means of the GET DATA command (CLA = 0x80, INS = 0xCA). The PIN try counter represents the number of trials the card user has to correctly enter the PIN before the card becomes locked (it can then be unlocked by the issuer bank). If the counter is greater than zero the user is asked to enter the PIN number into the numerical pad of the terminal. At this point the terminal can either verify the PIN online by requesting confirmation to the issuer bank, or ask the card (online) for confirmation. The most common method is the online version.
[VERIFY PIN]
Thus the next step is to send a VERIFY command (CLA = 0x00, INS = 0x20) to the card with plain text PIN as the command data. If the PIN is correct the card simply replies with a success status (SW1 = 0x90, SW2 = 0x00).
[GEN AC - REQUEST APPLICATION CRYPTOGRAM - USING CDOL1]
The last step of a transaction is to request an application cryptogram from the card using the GENERATE AC command (CLA = 0x80, INS = 0xAE).
This request may be for an Application Authentication Cryptogram (AAC) which requests canceling a transaction, an Authorization Request Cryptogram (ARQC) which request an online transaction (i.e. confirmation from issuer bank) or a Transaction Certificate (TC) which requests an offline transaction (i.e. no confirmation from the issuer bank).
The terminal sends a list of objects as specified by CDOL1 which generally includes the transaction amount, the Terminal Verification Results (TVR - 5 bytes indicating the status of the transaction as seen from the terminal perspective), the transaction date and an unpredictable number.
The card then uses its private key (only known by the card and the issuer bank) to compute a Message Authentication Code (MAC) over a set of bytes that include the data sent with the GENERATE AC command. If the card accepts the transaction it returns a MAC of the same type (AAC, ARQC or TC) or at a lower level (where AAC = level 1, ARQC = level 2 and TC = level 3). If the card decides to reject the transaction it will return a MAC of type AAC.
This request may be for an Application Authentication Cryptogram (AAC) which requests canceling a transaction, an Authorization Request Cryptogram (ARQC) which request an online transaction (i.e. confirmation from issuer bank) or a Transaction Certificate (TC) which requests an offline transaction (i.e. no confirmation from the issuer bank).
The terminal sends a list of objects as specified by CDOL1 which generally includes the transaction amount, the Terminal Verification Results (TVR - 5 bytes indicating the status of the transaction as seen from the terminal perspective), the transaction date and an unpredictable number.
The card then uses its private key (only known by the card and the issuer bank) to compute a Message Authentication Code (MAC) over a set of bytes that include the data sent with the GENERATE AC command. If the card accepts the transaction it returns a MAC of the same type (AAC, ARQC or TC) or at a lower level (where AAC = level 1, ARQC = level 2 and TC = level 3). If the card decides to reject the transaction it will return a MAC of type AAC.
[2nd GEN AC USING CDOL2]
In online transactions there may be a second GENERATE AC command issued by the terminal where the command data is according to CDOL2 instead of CDOL1. An illustration of the entire transaction flow is presented in figure 2.6.
nice post, but how do we generate ARQC? is there any formula to get ARQC, I think one of the parameter is CDOL1, but how we get the ARQC value? thank you
ReplyDelete