POS Device Intergration

The following section covers the details of POS Device integration (particularly PIN based transactions). PIN transactions are encrypted either using Triple DES DUKPT or Triple DES Master/Session encryption architecture. The combination of Acquirer and type of device used determine the encryption architecture chosen.

iVeri provides facilities where PIN transactions can be process in either mode Live or Test.For security reasons, a key cannot be used in both modes Live and Test. Therefore, a device is either loaded for mode Test or mode Live.

A Device that is to be used for mode Live must be injected with a key within an iVeri Trusted Centre using the appropriate encryption architecture.A Device that is to be used for mode Test may be injected by a merchant, or within the Trusted https://centre.to/ change a device from mode Test to Live, device has to be reinjected with a key within an iVeri Trusted Centre.A merchant wishing to perform a Live Debit with PIN transaction requires an approved device that has been injected appropriately by the appropriate distributor.

PINBlock encryption via Triple DES DUKPT encryption

The DUKPT PINBlock encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with an Initial PIN Encryption Key (IPEK) and Initial Key Serial Number (IKSN). Whenever a PIN block is required from the device, a counter is incremented, which indicates a PIN Encryption key. When performing a Debit with PIN, the PINBlock is sent encrypted using the PIN Encryption key, along with the current KeySerialNumber (which indicates the device and the current counter value).

Key Injection for DUKPT Mode Test

There is one Test IKSN and IPEK that is public knowledge. When a Device is to be injected with the Test Device Master Key, it can be done either within the iVeri Test Loading Centre, or by the merchant. When a device is loaded with a test device master key by the merchant, then the merchant must contact their iVeri Distributor with the device information: Make, Model and Serial Numbe

The Test values are:

IKSN: FFFF0000030000000000

IPEK: 02B50748B58B7C4452E22E39DE560CE2

PINBlock encryption via Master/Session encryption

Master/Session keys are Double Length and are sent to the iVeri Gateway in Hexadecimal format.

The Master/Session PINBlock encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with a Device Master Key. A merchant periodically sends a request for a session key (GetDevicePINKey) which is returned encrypted under the Device Master Key. When performing a Debit with PIN, the PINBlock is sent encrypted using the current session key.

Key Injection for Master/Session Mode Test

There is one Test Device Master Key that is public knowledge. When a Device is to be injected with the Test Device Master Key, it can be done within the iVeri Test Loading Centre, or by the merchant. When a device is loaded with a test device master key by the merchant, then the merchant must contact their iVeri Distributor with the device information: Make, Model and Serial Number.

The Test Device Master Key is: 375DE602546843B68089911652E951CB

(MAC: CA40C1F2)

Get Device PIN Key

The command “GetDevicePINKey” (which is only relevant for PINBlock encryption via Master/Session) has the following mandatory input parameters:

DeviceMake

DeviceSerialNumber

Unlike other commands to the iVeri Gateway, “GetDevicePINKey” does not require the input parameter ApplicationID. Using iVeri Enterprise in iVeri https://client.net,/ this can be prepared using the following syntax:

enterprise.prepare("Security", "GetDevicePINKey", new Guid(), mode);

or using java:

enterprise.prepare("Security", "GetDevicePINKey", "", mode);

“GetDevicePINKey” must be called if “Debit with PIN” or “Balance Enquiry” reply with the Result code: “Device PIN Key expired” [20]. It should be called upon startup and every 24 hours, or 200 transactions thereafter. “GetDevicePINKey” returns the following output parameters, which can be stored for later usage with “Debit with PIN” and “Balance Enquiry”:

DevicePINKey

MACDevicePINKey

Track2 encryption via Master/Session encryption

A POS Device Integration architect has the option sending the Track2 to the iVeri Gateway in an encrypted format. This optional functionality is there as an extra security measure against someone sniffing the data between the device and the server communicating with the iVeri Gateway.

The Master/Session Track2 encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with a Track2 Master Key. A merchant periodically sends a request for a session key (getTrack2SessionKey) which is returned encrypted under the Track2 Master Key. When performing a transaction or a balance enquiry, the Track2 is sent encrypted using the current Track2 session key.

Track2 Key Injection for Master/Session Mode Test

There is one Test Track2 Master Key that is public knowledge. When a Device is to be injected with the Test Track2 Master Key, it can be done either within the iVeri Test Loading Centre, or by the merchant.

The Test Track2 Master Key is: BFE60D7685A24C15BC8FFBFE137C8C86

(MAC: 2F3BC80A)

Track2 encryption via Dukpt encryption

A POS Device Integration architect has the option sending the Track2 to the iVeri Gateway in an encrypted format. This optional functionality is there as an extra security measure against someone sniffing the data between the device and the server communicating with the iVeri Gateway.

The Dukpt Track2 encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with a Track2 IPEK (initial pin encryption key). This IPEK is different from the one injected for Dukpt PIN encryption. For this encryption, the following are mandatory input parameters together with the Track2 tag:

DeviceSerialNumber

DeviceMake

Track2KeySerialNumber

Track2 IPEK Injection for Dukpt Mode Test

BDK: 1534C275CDB5DCE015D952AB208AC1DA (MAC: B3D647B5)

IKSN: FFFF8000030000000000

IPEK: 5EC604C6F4D5EC3223F5B1BCC2AD6DD2

PAN encryption via Dukpt encryption

A POS Device Integration architect has the option sending the PAN to the iVeri Gateway in an encrypted format. This optional functionality is there as an extra security measure against someone sniffing the data between the device and the server communicating with the iVeri Gateway.

The Dukpt PAN encryption process flow is the following: A Device (with a DeviceSerialNumber and a DeviceMake) is injected in a Trusted Centre with a Track2 IPEK (initial pin encryption key). This IPEK is different from the one injected for Dukpt PIN encryption. For this encryption, the following are mandatory input parameters together with the PAN tag:

1. DeviceSerialNumber
2. DeviceMake
3. PANKeySerialNumber
   

Debit with PIN and Balance Enquiry

The merchant determines if the card is PIN based typically via a local bin list (section 17.6.4). If it is PIN based, the merchant reads in the PIN from the PED, and obtains an encrypted PINBlock.

A PIN based request is identified by the existence of a PINBlock tag. The existence of the PINBlock tag implies Track2, DeviceSerialNumber, DeviceMake and DevicePINKey is mandatory. 

Account Type is 'Savings' or 'Cheque' or 'Credit' or 'NotSpecified'.

Debit with PIN

The mandatory Amount tag refers to the total transaction amount. The optional CashAmount tag is any cash portion of the transaction. Therefore, always Amount >= CashAmount.

Normal Withdrawal: CashAmount = Amount

Normal Sale: CashAmount = 0 (or not specified) 

Combined Sale and Withdrawal: 0 < CashAmount < Amount

The only time the balance of a PIN based card can be increased using iVeri is by Voiding a previous transaction.

Balance Enquiry

Obtain the balance of the PIN based account in the currency of the account.

Using iVeri Enterprise, this can be prepared using the following syntax:

enterprise.prepare("Enquiry", "Balance", applicationID, mode)

Test environment for PIN cards

iVeri Test cards are available upon request. The Result Codes responded within the PIN based issuer simulator for Mode Test are as follows:

“4242424242424242” returns the following:

 The Current Balance for PAN 4242424242424242 for the current merchant testing is stored in memory, and is manipulated in the following manner:

Initial amount is: 10,000.00 (max balance)

Reset to max balance upon service restart

Decreased after a successful debit.

Replenished to the max balance if the CurrentBalance goes below 10.00 (min balance).

If a Void is received, then CurrentBalance is increased. Since a Void could be received after a replenishment (or service restart), CurrentBalance is forced to be less than or equal to max balance.

Determining if a card is PIN based.

A merchant determines the card is PIN based by using a local BIN list in conjunction with the Track2 information read from a card. The BINLookup download within the File Transfer mechanism (section 22) may be used to refresh a local BIN list. merchant can determine if the card is PIN based in the following manner:

The BINLookup download within the File Transfer mechanism (section 22) is used to populate a local BIN list. It can be refreshed daily.

The Track2 of the card is read within a card reader

The PAN is determined from the Track2 (see section 10.3)

The PAN is checked against the local BIN list.

If the initial digits of the card PAN is found on the BIN list then based on the IsPINCard attribute:

If there is no BIN list available (or if the initial digits of the card PAN are not found on the BIN list), then:

If the PAN starts with 50, 56, 57, 58 or 6 then Prompt for PIN

Else if Position #3 of the Track2 Service Code (see section 10.3.1) is in {0,5,6,7} then Prompt for PIN

Else do not prompt for PIN.

EMV Transactions

The introduction of smart cards based on the EMV standard (EMV: Europay, MasterCard, Visa) is progressing worldwide. More and more banks rely on secure transactions for payments. With the migration from magstripe to EMV chip, banks can offer their customers the utmost in security. EMV chip technology prevents unauthorized access to card information and helps fight fraud.

Coding for EMV data

The following is a code snippet in C#:

EMV Request Tags:

enterprise.setTag("EMV_AuthorisationRequestCryptogram", authorisationRequestCryptogram);

enterprise.setTag("EMV_ApplicationIdentifier", applicationIdentifier);

enterprise.setTag("EMV_ApplicationInterchangeProfile", applicationInterchangeProfile);

enterprise.setTag("EMV_CardSequenceNumber", cardSequenceNumber);

enterprise.setTag("EMV_ApplicationTransactionCounter", applicationTransactionCounter);

enterprise.setTag("EMV_ApplicationVersion", applicationVersion);

enterprise.setTag("EMV_CardHolderVerificationMethodResult", cardHolderVerificationMethodResult);

enterprise.setTag("EMV_CryptogramInformationData", cryptogramInformationData);

enterprise.setTag("EMV_IssuerApplicationData", issuerApplicationData);

enterprise.setTag("EMV_TerminalCapabilities", terminalCapabilities);

enterprise.setTag("EMV_TerminalType", terminalType);

enterprise.setTag("EMV_TransactionType", transactionType);

enterprise.setTag("EMV_TerminalVerificationResult", terminalVerificationResult);

enterprise.setTag("EMV_UnpredictableNumber", unpredictableNumber);

enterprise.setTag("EMV_TransactionStatusInformation", transactionStatusInformation);

EMV Response Tags:

enterprise.getTag(“EMV_IssuerAuthenticationData”);

enterprise.getTag(“EMV_IssuerScriptTemplate1”);

enterprise.getTag(“EMV_IssuerScriptTemplate2”);

enterprise.getTag(“EMV_ResponseCode”);