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 !

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.

Internet Crime Compliant Center (I3C) : Preventative Measures – Hardware Security Modules

hsm The Internet Crime Complain Center (I3) released a memo on December 15th 2008 – titled Preventative Measures:

“Over the past year, there has been a considerable spike in cyber attacks against the financial services and the online retail industry. There are a number of actions a firm can take in order to prevent or thwart the specific attacks and techniques used by these intruders.”

There are 12 Recommendations here, 11 of those, that in all honestly, should not be new to any one addressing IT Security or PCI Compliance – I can map each of these 11 to a PCI requirement:

  • Recommendation 1,2,4,6,8 : maps to PCI 2.2.x   “Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.”
  • Recommendation 3: maps to PCI 6.5.x  “Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes”
  • Recommendation 5: maps to PCI 7.2.x “Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.”
  • Recommendation 7: maps to PCI 8.5.13  “Ensure proper user authentication and password management for non-consumer users and administrators on all system components”
  • Recommendation 9,10: maps to PCI 1.3.x “Prohibit direct public access between the Internet and any system component in the cardholder data environment.”
  • Recommendation 11: maps to PCI 1.2.1  “Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.”

The last one is a little different and or not as common as the items above:

Recommendation 12: Ensure your HSM systems are not responsive to any commands which generate encrypted pin blocks. More specifically, HSMs should not accept commands that allow plain text PINs as an argument and respond with encrypted PIN blocks.

HSMs are normally used to verify Personal Identification Numbers (PINs), generate PINs used with bank accounts and credit cards, generate encrypted Card Verification Values (CVVs), generate keys for Electronic Funds Transfer Point of Sale systems (EFTPOS), and generating and verifying Message Authorization Codes (MACs). These systems, if accessed by an unauthorized intruder, can provide the attacker the ability to discover the appropriate PIN number for a corresponding credit or debit card. Therefore, in an effort to prevent this, HSMs should be configured to disallow “in the clear” PINs as an argument for performing its tasks.

This recommendation discusses configuration options with Hardware Security Modules or HSM’s. There is a attack that allows an attacker to derive how a PIN is encrypted if the HSM Allows for functions that allow a Clear PIN as an input an attacker can send various clear PINs and analyze the output from the HSM.

At one of our acquiring clients we communicate with a Thales 8000 HSM. The functions that we are are for PIN Translations for Debit/EBT Transactions. The functions that we use for this do not involve a clear pin, we receive an encrypted PIN Block from the Point-of-Sale and PIN-Pad that we translate to a different PIN Block under a different encryption key to the Debit/EBT Networks and/or providers.

Looking at the “Thales — Console Reference Manual” – I see this option:

Select clear PINs: Yes or No

This enables the clear PIN support via host commands „NG? and „BA?. Authorised state is
a requirement for these commands to be processed by a host application.
Note: This is a security risk unless precautions are taken at the host.

The Manual states that this is clearly a bad thing:

2009-01-06_1636

So for Requirement 12 – Make sure that you are not using any “Clear PIN’s” and any function that allow “Clear PIN’s” as an argument are not enabled.