Just a short note to share that OLS has received word from our QSA via a “PCI Certificate of Validation” Letter for our newly launched hosted payment service offering OLS.Host.

Congrats to our Operations, Systems and Security Gurus for all of their hard work on this !

I had a call yesterday about approved TG-3 (Which is now called TR-39 ) ANSI PIN Block Formats.

The TR-39 Audit Procedures state that ISO 9564–1 Format 0 (ISO-0) and Format 3 (ISO-3) are the only approved formats:

4.1.3 X9 Approved PIN Block Formats

Documented procedures exist and are followed that ensure any cleartext PIN-block format combined with a PIN encryption process has the characteristic that, for different accounts, encryption of the same PIN value under a given encryption key does not predictably produce the same encrypted result. (Note: any cleartext PIN block, formats 0 and 3 meet this requirement, as specified in X9.8-1).

Reference X9.8-1 – Sec. 4(c), Sec. 6.2, Sec. 8.3.1, Sec.8.3.2, and Sec. 8.3.5

In case you are curious here are Visa’s PIN Security Requirements

Requirement 3:

For online interchange transactions, PINs are only encrypted using ISO 9564–1 PIN block formats 0, 1 or 3. Format 2 must be used for PINs that are submitted from the IC card reader to the IC card. Other ISO approved formats may be used.

This requirement further states:

PINs enciphered using ISO format 0 or ISO format 3 must not be translated into any other PIN block format other than ISO format 0 or ISO format 3. PINs enciphered using ISO format 1 may be translated into ISO format 0 or ISO format 3, but must not be translated back into ISO format 1.

(This last paragraph addresses an attack on Pin Blocks that can be translated in to format 1 on a HSM which would expose the clear PIN)

Let’s take a look at a few Pin Block formats:

For our examples:

P – PIN Number

F – Hex 0xF

A- Last 12 digits of PAN not including check digit

R – Random Hex Character (0-9, A-F)

Let us use the account number 4111111111111111 and PIN Number 1234 (examples use a PIN Length of 4 but could be 4-12 digits)

“Pin Pad” format or IBM 3624

PPPP FFFF FFFF FFFF

our Pin Block

1234 FFFF FFFF FFFF

Notes: Not allowed and is an old legacy method – not approved to be used.

ISO-0

04PP PPFF FFFF FFFF   (0 = ISO-0 Format, 4 = length of PIN)

XOR with

0000 AAAA AAAA AAAA (Formatted PAN)

our Pin Block:

0412 34FF FFFF FFFF

XOR

0000 1111 1111 1111

=

0412 25EE EEEE EEEE

Notes: Introduces variability in the PIN block by XOR’ing with a Formatted PAN – Best practice is to use ISO-3 instead of ISO-0 as there are attacks against ISO-0

ISO-1

1412 34RR RRRR RRRR (1 = ISO-0 Format, 4 = length of PIN)

our Pin Block:

1412 348D 665A C5A3

Notes: Introduces variability in the PIN block by using Random padding chars – Best practice is not to allow HSM’s to accept or use this PIN Block format. Not allowed by TR-39 but is VISA.

ISO-3

34PP PPRR RRRR RRRR (3 = ISO-3 Format, 4 = length of PIN)

XOR with

0000 AAAA AAAA AAAA (Formatted PAN)

our Pin Block:

3412 34C8 CBA4 285C

XOR

0000 1111 1111 1111

=

3412 25D9 dAB5 394D

Notes: Introduces variability in the PIN block by using Random padding chars and  by XOR’ing with a Formatted PAN – Best practice is to use this format.

OLS is in the market for a sales representative.

Please refer to our LinkedIn job posting for more details.

We have implemented a new component to our Java and jPOS fueled Payment Switch – OLS.Switch which we have called the CaseSwitch. The vast majority of our switching algorithms are based on either the determination of CardType – which dictates which outbound endpoint we send that transaction to, or on Card Bin Ranges.

An example of a Bin Range:

If a CardNumber’s Bin or IIN – matches our Bin Range configurations – We will select the appropriate EndPoint. In this example if we have a VISA or MC Card we switch it out to a FDR Gateway. If we were connecting to a to MasterCard MIP or Visa VAP or DEX then we would have a MC and VISA EndPoint defined with our BankNet and VisaNet interfaces and switch the transactions to those endpoints.

An example of a Card Type:

We have certain transaction types that we know where they go because of their Card Type – Many of these are internal authorization hosts such as implementations of Authorized Returns, MethCheck, Loyalty, Couponing. Others are transactions where the transaction type also dictates the card type – such as those to GreenDot, InComm and other external hosts where a BIN Range lookup is unnecessary.

Source (Port) Based Routing

We recently had a requirement for Source-Based Routing – where depending on the source port that would dictate the outbound transaction path(s).

In our Server we accept the incoming transaction and then place a Context varaible we call PORT that tells us which Server Port the transaction came in on. One we have that additional data we can perform a Logic Branch in our Transaction Manager that looks like this.

This allows us to define transaction paths based on the incoming port of the server, so in this example.

<participant class=”com.ols.switch.CaseSwitch” logger=”Q2″ realm=”Switch”>
<property name=”switch” value=”PORT” />
<property name=”case 5001" value=”LookUpResponse Log Close Send Debug” />
<property name=”case 5002" value=”QueryRemoteHost_xxx Log Close Send Debug” />
<property name=”case 5005" value=”QueryRemoteHost_yyy Log Close Send Debug” />
<property name=”default” value=”Log Close Debug” />
</participant>

Port 5001 – we perform an authorization locally

Port 5002 – we switch out the transaction and reformat it to endpoint xxx – message format and interchanges requirements.

Port 5005 – we switch out the transaction and reformat it to endpoint yyy – message format and interchanges requirements.