Encryption options from the POS/Payment Device/Terminal

matrix-computer-screen

There are a few different ways of implementing "encryption" from the POS/Payment Device/Terminal, I though I’d look at a few in a short post:

1) Tunneling – using existing applications and their connections over an encrypted tunnel   e.g.over a VPN, SSH, stunnel, etc. This approach doesn’t require any changes to devices or message formats or the payment "server"

2) Transport level – using TLS/SSL over TCP/IP Sockets – or at a higher level (web server/web service) using HTTPS. – devices needs to support the ability and make this type of connection, message formats are not modified.

3) Data Element or Field level — if you only want to encrypt the PAN or other specific fields, and these fields are defined to support the increased length required of the encrypted payload  — this requires changes to the message formats, devices and payment "server" software. Consider truncating the Account Number/Track Data in DE 2 or DE 35 in ISO8583  for use of displaying purposes on the terminals screen or receipt and consider using another Private ISO field for the payload.

The approach will depending on what the "devices" sending the transaction can support, both from a connection perspective as well as a software perspective. I’d also recommend consider using asymmetric encryption rather than symmetric here, as then the devices would not have the ability to "decrypt" as they would not have the private/secret key, and would help with eliminating private key storage at the device level if you choose option 3. There are implementations that use HSM’s and the DUKPUT algorithm as well.

We have an implementation of #3 that I wrote about here. — relevant paragraph below:

Some of our implementations of OLS.Switch supports field or data element level encryption that is passed on from the Point of Sale system to our switch. The main thing that allow us to perform this is that:  We or our customer "own/control" the POS message format to us and can adapt and handle the programming of the POS System and POS message formats – our account number fields are not limited to 16 digits – we can handle a much large encrypted value. So over the wire – these implementations are "protected" from eavesdropping or sniffing.

I plan to write more on E2EE (End to End Encryption) in the coming weeks as well, so stay tuned !

Detecting swapped PIN Pads at the Payment Switch

images

 

My colleague Andy Orrock writes an excellent post, "Methodology for watching PIN Pad Switches" which discusses a detective control that we put in place in OLS.Switch to detect when a PIN Pad has been changed at the point of sale, along with real time alerting of the event.

 

Digital Transaction has an article here, that discuses this type of attack, another summary is here and quoted below:

Investigators say the men would enter supermarkets late at night, distract the cashier and swap a PIN pad with an alternate machine that recorded each customer’s financial data. They could swap the equipment in as little as 12 seconds, prosecutors said.

After a while, the men would return, retrieve the machines and harvest the credit and debit card information. At least six supermarkets in Rhode Island and Massachusetts were targeted, and 238 people lost money.

Another consideration to make, is the physical security of payment terminals and pin pads, such as bolting them down or using locking stands and regular inspections.  See Verifones PIN Pad Security Best Practices for more.

When End-to-End Encryption is really not End-to-End.

I’m reading a lot about solutions that implement end-to-end encryption, where account numbers and track data is encrypted and can utilize a Hardware Security Module (HSM) and DUKPT or other encryption algorithms from the point-of-sale. I thought it important to share what data is actually encrypted in the payment system.

 

Here is a list in no particular order:

Gateways:

(contact me and I’ll add you if you are not listed)

 

Most of these are ISO’s that sell you a merchant account and access to their gateway that uses "end-to-end" encryption and that it will shift the PCI and PA-DSS burden from you to them, if you are a merchant, some claim you don’t even need to go through PCI compliance because you don’t have access to the card numbers or the encryption keys to decrypt the cards (Please also see this post on this subject).  This is all really good stuff, I’ve written about End-to-End Encryption before and am a big proponent of it. This can help prevent "sniffers" and card capturing malware from capturing track data and account numbers in the clear as they traverse your internal network. Attackers would either need to install card skimmers or gain access to encryption keys, or use brute force methods against captured encrypted data to capture data at your store.

But it isn’t really End-to-End Encryption.

Let look at two examples:

  1. A typical small merchant using a payment gateway
  2. A large retailer or processor/gateway that uses a payment switch

 

A typical small merchant that uses a payment gateway:

Slide2

 

A large retailer or processor/gateway that uses a payment switch

Slide1

( uses leased lines to connect directly to a Payment Processor (FDR, Chase/PaymentTech, Fifth Third, MPS, etc ) or Interchange Network (VisaNet, BankNet, etc )

Let’s say that you are using a gateway or even a switch that supports an encrypted message format from the point-of-sale (POS). The area in RED in each diagram shows where the account number traverses the payment networks in clear text. At the small merchant example from the Gateway to the rest of the network – the account number and track data and CVV2/CVC2 data is sent in the clear. In the direct connect model with the Payment Switch (which actually just operates as a local gateway) from the payment switch to the rest of the network. So End-to-End is really not End-to-End at all. (it depends on where you define end :)  This should also explain why End-to-End Encryption in its current state would not of prevented the breach at Heartland Payment Systems – as a processor they need to connect and communicate over the interchange networks using TCP/IP connection and ISO-8583 messages to these endpoints.

 

Why is this ?  The Payment interchange networks and message formats that processors and the Interchange networks use does not support this in their current message formats (primarily ISO-8583) There is no room in the current implementations of Visa’s Base1, MasterCard’s MIP, or FDR’s message formats for example. Data Elements can be added to support this, but would require massive changes to Payment Systems infrastructures and systems.

 

Does any one have any solutions for this ? Please provide comments below — I’ll provide a follow-up blog post with some of my ideas.

 

Remember that End-to-End is really not End-to-End, it may shift or transfer some of the compliance "burden"  from the merchant to that of the processor, but still exists in clear text on private networks and at processors.  Oh, and tokenization and secure card vaults would work the same way here, the cards need to be translated to their raw value to ride the payment networks.

iPhone Credit Card Terminal

screenshot-iphone-terminal-testvisa-thumb

innerfence has developed an iPhone App called the Credit Card Terminal.  It is a thin application that acts as a front end and uses an Authorize.net Merchant account using the Authorize.net API over SSL. Looks pretty neat and a useful option for mobile acceptance of credit cards.

Looks like innerfence is a Authorize.net reseller, since you can use any authorize.net merchant account – I suggest you shop around the the best rates, theirs appear to be a little high.

I’ll put this in the "Why didn’t I think of that ?" category.

 

EDIT:  Check out this link to the innerfence blog where there is a video on the app, and its integration to another iPhone App – Ring It Up Point of Sale.

Fun with Card Readers and Encoders/Writers

I received a MSR505c Card Reader/Writer in the mail today. I use and have a need to create test cards that have magstripes for a variety of purposes; The main one being a way to test/demo our issuer based products from Point-of-Sale (POS) systems and payment terminals.

 

I thought I create a short screencast to show how this works, which is provided below:

Some considerations to note:

It is extremely easy to "clone" a payment card using a device such as this, and the entry point from a cost and availability perspective is low (~$300 range). In a follow-up blog post, I’ll write about Maktek’s MagneSafe and MagnePrint products to detect card cloning at a magstripe level.

Picture 19

Virtual Point of Sale (OLS.vPOS) & Virtual Terminal (OLS.vt)

Here is a snapshot of what my desk looks like: you can see a magtek USB card reader and a few magnetic striped cards; expired pre-paid credit, gift and merchandise return cards that used for testing purposes here.

cards

I’ve been developing some small tools that allows for us to send transactions via a swipe in a .NET windows based application as well as in a Java Web based version to a test instance of OLS.Switch. I used to (and still do) just pipe binary message dumps over netcat pointed to our OLS.Switch’s configured server port for this specific message format.

for example:

$ cat visa_credit_sale.dump | nc 192.168.1.50 33000

where visa_credit_sale.dump would just be a binary file of the message

$ hd visa_credit.sale.dump

would look like this (intentionally blurred and is a test card number)

10-2-2008 8-23-24 PM

Here is a shot of the Virtual Point of Sale System:

OLS vpos

and a shot of the Virtual Terminal:

ols.vt
VT Response

Basically you can swipe a card or key-enter a card on the virtual terminal and depending on the configuration of OLS.Switch – (I’m using bin based routing here in this test setup)

Cards that start with:

  • 4 – Visa
  • 5 – Mastercard
  • 6011 – Discover

go to our FDR North (ChasePaymentTech) Simulator and and return a simulated response.

  • 3 – Amex

go to our American Express Simulator

  • 7 – Stored Value

go to our Stored Value Systems Simulator

  • 6 – OLS Stored Value

get switched to our own instance of OLS.Issuer – our authorization host which is not a simulator.

The vPOS and VT are sending in messages in the Visa K/Visa D or otherwise known and Visa Gen II message format (one of the incoming message formats that we support from the device side) and depending on the card type, we are building the appropriate outbound message according to the interface specs (generally an ISO8583 variant), hitting our simulators to get different responses based on amount prompting or in the case of the OLS Stored Value cards, it uses the card files, velocity and limit checking, card status and other authorization rules to authorized the card.

The neat thing? an end-to end transaction take less then 50ms on a sub $1000.00 test server on a local lan.

10-2-2008 8-30-17 PM

 

Here is a link to a PDF that shows the full transaction flow.

demo

Dave & Busters got busted – Sniffed Credit Cards

Dave & Busters (aka Chuck e Cheese for adults and with adult beverages) appears to be the latest in news stories of Data Breaches including magnetic stripe and track 2 data.
From Wired “International Hackers Indicted for Sniffing Credit Cards from Dave & Busters”

“The government said the Dave & Buster’s hackers illegally accessed 11 of the national chain’s servers and installed packet sniffers at each location. The sniffers vacuumed up “Track 2″ data from the credit card magstripes as it traveled from the restaurant’s servers to Dave & Buster’s headquarters in Dallas, according to the indictment.”

In my post titled, “Encrypted Traffic from within the PCI Zone” I discuss that we have adapted OLS.Switch‘s point-of-sale (POS) TCP/IP interface to accept POS payment messages across the store’s PCI Zone (Protected network zone where CC Data would transverse) but include an encrypted account number field or data element instead of the clear text PAN (Primary Account Number), in the PAN field.  So this would act as a deterrent to network sniffing

That being said — it appears that there was a lack of montioring or mis-configuration or lax physical security around the POS, wiring closet, and network cable runs.

Again: I wouldn’t be surprised that if in future revisions of the PCI DSS – traffic from POS systems on private networks will be required to be transport encrypted in a tunnel or require encrypted fields/data elements.

BTW, Dave & Busters does have a pretty cool private stored value system and game card that you place in their games inorder to play and reload to play more.

EDIT:  CIO has an article here:   This is probably the best quote from the article.

Unfortunately for the criminals, Gonzalez’s code had some problems

In April 2007 it bombed its first test, on a point-of-sale server at the Dave & Buster’s in Arundel, Maryland. “The packet sniffer malfunctioned … and no credit or debit card account information was captured, ” Lynch said.

Even when the packet sniffer worked, the hackers were forced to keep returning to the Dave & Buster’s network and restarting their malicious software, Lynch said. A bug in the packet sniffer caused it to shut down whenever the computer it was monitoring rebooted.

Does your Payment Switch handle non-payment transactions and message formats ?

PseudoephedrineAs a financial payment switch and switch vendor, we need to be agile, adaptable and expandable to support different formats that are required by our customers. See The New Normal – for one of our more complex acquirer side integrations.

One of these initiatives consisted of developing an interface to switch incoming MethCheck Pseudoephedrine Inquiry transactions from the Point-of-Sale to OLS.Switch, and then switched out to another end-point for further processing.

While most message formats in the payment space follow the ISO-8583 standard, we do have many end-points that we need to interface with that are either fixed length or variable length, we call these FSD messages. In the MethCheck implementation we used a FSD based message format for request and response messages. Our role here was to pass a customer defined buffer from the POS system to the end-point, though our switch and pass a response buffer back to the POS system

FSD Request

<schema>
<field id="header" type="K" length="7">OLSMETH</field>
<field id="0" type="N" length="2">    <!--tran type -->
<field id="41" type="A" length="5">    <!--store number -->
<field id="46" type="N" length="19">   <!--tran id -->
<field id="meth-trans-info" type="AFS" length="452">
</schema>

FSD Response

<?xml version="1.0" encoding="UTF-8"?>
<schema>
<field id="header"             type="K" length="7" >OLSMETH</field>
<field id="0"                  type="N" length="2" /> <!--tran type -->
<field id="41"                 type="A" length="5" />  <!--store number-->
<field id="46"                 type="N" length="19" /> <!--tran id-->
<field id="39"                 type="A" length="2"/>    <!-- Result Code-->
<field id="meth-trans-reply"    type="AFS" length="255" />
</schema>

We have a very easy way of creating and populating these messages.

FSDMsg fsd = new FSDMsg ("file:cfg/meth-");
        FSDMsg msg = (FSDMsg) ctx.tget (REQUEST);

        fsd.set ("0", msg.get("transaction-code"));
        String storeNumber = msg.get ("store-number");
        fsd.set ("41", storeNumber);

        TranLog tranLog = (TranLog) ctx.tget (TRANLOG);
        if (tranLog != null) {
           fsd.set ("46", ISOUtil.zeropad (Long.toString(tranLog.getId().longValue()), 19 ));
        }

        StringBuffer sb = new StringBuffer();
        sb.append (msg.get ("register-logon-nbr"));
        sb.append (msg.get ("meth-entry-mode"));
        sb.append (msg.get ("meth-id-format"));
        sb.append (msg.get ("meth-id-data"));
        sb.append (RS);
        sb.append (msg.get ("meth-person-info"));
        sb.append (RS);
        fsd.set ("meth-trans-info", sb.toString());

In less then a week’s time in development (testing and user acceptance testing will take longer) – we were able to add an interface to our switch to handle this non-payment transaction type.

Encrypted Traffic from within the PCI Zone

securitylockThe first thing that typically happens with the design of PCI network configuration is that an inventory of all systems/processes involved in the storage, processing, or transmitting cardholder information is performed, and a network diagram that shows where these systems live is produced. The prevailing wisdom over the last few years has been to create a “PCI Zone” using network segmentation which is basically a separate network zone (QSA’s like to say VLAN ) where all of the cardholder systems are that has stateful firewalls and well defined firewall rules for both incoming and outgoing traffic. This is a very important scope reduction technique, that lets you focus on implementing the security controls that are mandated by PCI in the environment of the data and systems that need protection.

Within the PCI Zone – PCI requirements allow for non-encrypted card numbers to be sent across the internal network. (Requirement 4: Encrypt transmission of cardholder data across open, public networks )

I think Rich Mogull said it best: “Corporate networks are like candy bars: hard on the outside, soft and chewy on the inside,”. The PCI Zone is still soft and chewy in some regards.

There are some rumors and speculation that a PCI Compliant merchant, Hannaford supermarket chain’s POS system (like many other merchants) does not send encrypted data between the point of sale and the branch server.

Some of our implementations of OLS.Switch supports field or data element level encryption that is passed on from the Point of Sale system to our switch. The main thing that allow us to perform this is that:

We or our customer “own/control” the POS message format to us and can adapt and handle the programming of the POS System and POS message formats — our account number fields are not limited to 16 digits – we can handle a much large encrypted value. So over the wire – these implementations are “protected” from eavesdropping or sniffing.

I wouldn’t be surprised that if in future revisions of the PCI DSS – traffic from POS systems on private networks will be required to be transport encrypted in a tunnel or require encrypted fields/data elements.

Also related to this subject: Dr. Neal Krawetz has a very good White Paper called Point-of-Sale Vulnerabilities. Read it!!!