Ingenico RBA Series

Ingenico manufactures a number of PCI 3.X certified payment terminals. Their terminals allow manual card data entry, magnetic card swipes and contactless card data entry. Their device is shipped with on-board software called Retail Base Application (RBA). RBA versions 12.02 and higher support DUKPT BPS encryption of track data, referred to as OnGuard by Ingenico. It should be noted that for legacy reasons Ingenico's documentation refers OnGuard mode as E2EE encryption and not P2PE.

The following guide outlines how to extract the P2PE data from RBA payloads for processing on Decryptx. As RBA is standardized across all Ingenico devices, the steps outlined below should work on all RBA devices. At Bluefin, we have integrated and verified the following Ingenico RBA series devices:

• Ingenico iPP 320
• Ingenico iPP 350
• Ingenico iSC 250
• Ingenico iSC Touch 250
• Ingenico iSC Touch 480

Obtaining the Payload

Typically, RBA terminals are connected to host computers that run special software referred to as point of sale (POS) applications. POS applications obtain payment data from a paired terminal and sends the data to a card payment processing gateway. Conveniently, Ingenico's developer portal has a number of RBA software development kits for a wide variety of operating systems and development languages. They make it easy for POS applications to obtain data from payment terminals.

In order to obtain data from the terminal, the POS sends an RBA command to a connected device. To capture P2PE data you need two RBA commands, the syntax and output of which are detailed below. In our guide, the text [STX], [ETX], [FC] and [LRC] represent one byte characters for the following: start of transmission, end of transmission, field separator and longitude redundancy check (LRC) check sum.

Sample

The first step is to identify the device's serial number by sending a Health Check (08) command to the terminal.

Request

[STX]08.0[ETX][LRC]

Response

[STX]08.6547[FS]248[FS]309[FS]6259[FS]0000[FS]0109[FS]iPP350[FS]2214106PT010989[FS]3806[FS]1202[FS]0401[FS]1001[FS]0000[FS]0000[FS]14516[FS]12912[FS]2014-04-16[FS]0[FS]UNSUPPORTED_DEVICE[FS]Retail Base[FS]INGNAR[FS]0000[FS]80688474[ETX][LRC]

This data is parsed as follows:

Swiped Payloads

The next step is to send a capture swipe command.

Request

[STX]87.Please Slide Card[ETX][LRC]

Response

[STX]87.0[FS]41249399901612212101912TEST/BLUEFIN1BFFFF99999900F660000B0114331089645004140780=52138380040406783299B50C91A3B8A8302DB5B68F36AAE851960E91C78B1AA699A986957236BB6FAD69F7047F06FF046FF61B1A020BD2016814A2E402305C089BABA1214883E15FB1698[ETX][LRC]

This data is parsed as follows:

📘

How does RBA encrypt swiped card data?

To help you understand how to prepare Ingenico payload data for processing on Decryptx, you need to know how RBA manipulates the card data when encrypting it:

1. The device reads the Track 2 data, e.g., (;4124939999999990=2212101123456789?)
2. It then removes the leading ‘;4’, the ‘=’, and ‘?’ characters (1249399999999902212101123456789).
3. It submits the reduced track data to the device's Crypto processor.
4. The Crypto processor runs BPS Encipher and returns the following encrypted text: (0896450041407805213838004040678).
5. The RBA software adds a leading digit to make output to pass MOD 10 check('1') and adds an '=' after 16 digits to make encrypted data to look like Track 2, e.g., (1089645004140780=5213838004040678).

Processing Swiped Data

To prepare the encrypted payload for decryption, you must reverse RBA's Track 2 data manipulation. To do this, remove the leading digit and the '=' character from the payload and base64 encode it. In this example, the encrypted data is (1089645004140780=5213838004040678). Before sending it to Decryptx it should be converted to the following: (30383936343530303431343037383035323133383338303034303430363738).

After making the API call to Decryptx with the converted data and the KSN (FFFF99999900F660000B), you will get the following decrypted value in the response:

31323439333939393939393939393032323132313031313233343536373839

Before extracting the payment data from the decrypted value, it must be converted to ASCII first. The following is the ASCII version:

1249399999999902212101123456789

This data is parsed as follows:

Keyed Payloads

The following outlines how to extract the P2PE data from a Keyed RBA payload.

[STX]87.0[FS]4124939990161221200001BFFFF99999900F660000A011425M2615003155099705=04025513293F5249D4B0B1BAAD4DFA43528271D4164B3F1532E3FDA2271FB52CA770C5068FD196D644CB1604054AF45E995CA58149F0[ETX][LRC]

This data is parsed as follows:

📘

How do you differentiate keyed payloads from swiped?

Payloads that contain keyed data will always have a Service Code of 000, followed by a language indicator of 0. The Track 2 data is also prepended with a M marker.

📘

How does RBA encrypt keyed card data?

RBA does the following when encrypting card data:

1. It submits the manually entered PAN, expiry, and CVV data (4124939999999990, 2212, 123) to the device crypto processor.
2. The crypto processor runs the BPS Encipher and returns the cypher text (6150031550997050402551).
3. RBA then prepends the indicator of manual entry ‘M’ and a leading digit to make the fake PAN to pass MOD 10 check(‘2’), it also adds ‘=’ after 16 digits to make the data to look like Track 2 (M2615003155099705=0402551).

Processing Keyed Data

To prepare the encrypted payload for decryption, remove the '=', the 'M' marker and the leading digit. In this example you will end up with the following payload 36313530303331353530393937303530343032353531. After making the API call to the Decryptx with the converted data and the KSN (FFFF99999900F660000B), you will get the following decrypted value in the response:

31323439333939393939393939393032323132313233

Before extracting the payment data from the decrypted value, it must first be converted to ASCII. The following is the ASCII data:

1249399999999902212123

This data is parsed as follows:

EMV Payloads

The following outlines how to extract the P2PE data from an RBA EMV payload.

[STX]87.0[FS]476173001016118122019001BFFFF99999901238000350114341438585185678075=015537112599878533221BEA3C5443CFA32650E51470C051A0E96C88BAF5E59658848430E5DF910E0ED31CE0B46BDC26A5773A0866F85B037F4B3FCCD36D8FBA31C3A5589EB88A3901D688[ETX][LRC]

This data is parsed as follows:

📘

How do you differentiate EMV payloads from others?

Payloads that contain EMV data will have a cardholder name length of 00.