Verizon Business reveals details of Encryption Key Compromises

Verizon Business recently held a webinar titled “Don’t be the next victim on PIN-Based attacks.”

In the webinar, they revealed that there have been several PIN breaches, as well as the details behind the most common attacks against encrypted debit PIN’s. While the method of obtaining the encryption keys may vary, the commonality of these attacks is that they occur when criminal organizations enter a system in the payments infrastructure and are able to take over, or control, the HSM (Host Security Module) that is used for debit key translation between different payment system processors. These attacks can occur against both financial institutions as well as retailers that have installed HSN’s for PIN translation.

The top threats identified in the webinar are:
• PIN Block Translation Attack
• HSM API Brute Force Attack
• Lack of Unique Keys per Device/Zone
• Use of weak keys

The PIN Block Translation attack takes advantage of a weak PIN encryption format included in HSM’s for compatibility reasons. The format, called IBM/Diebold only has 10,000 possible PIN combinations. The standard ANSI x9.8 PIN Block format has 1,000,000,000,000,000,000,000,000,000 combinations. In this attack, criminals first breach the payment system network and then gain control of the HSM. Commands are entered to have the HSM build a table of all keys encrypted in the IM/Diebold format. They then use the PIN translation capability of the HSM to translate all DES or TDES encrypted PINs into the IBM/Diebold format, using the IBM/Diebold encryption key that they also load into the HSM. Then they simply look up the encrypted PIN in the table and they get the unencrypted PIN from the table.

A note – Verizon reports that gaining logical access to the HSM is easier than many people think and also occurs with much more frequency as well.

The HSM API Brute Force attack is similar to the PIN Block Translation Attack, but it does so without taking advantage of the IBM/Diebold format. Like the PIN Block Translation Attack, this also requires logical access to the HSM, gained by criminals after breaching the payment system network. Hackers break the encrypted PINs basically like solving an algebra problem by executing millions of commands to the HSM until they are able to determine the encrypted PIN. These commands are usually requested via batch or script files. This attack does not require a high degree of difficulty, but it does require much more time and processing power.

The Lack of Unique Keys per Device/Zone, is generally an attack that only occurs against retailers, although some ATM networks and gateways have also been breached as they are still using Master Session keys. This attack is usually aided by finding encrypted PIN block information in places like TLOG files and again uses a brute force type of attack against the encrypted PINs.

The fourth common method of attack against encrypted PINs takes advantage of weak DES (single DES) keys. In 1998 in a high-tech lab environment, DES keys were cracked in 56 hours. In 2007, DES keys can be cracked with a server costing less than $10,000 in 6 days.

There is also a Russian criminal gang that offers a fee-based DES cracking service. Ship a POS PED to the gang overnight and they will return the DES keys within 72 hours for $250,000, or you get your money back.

They also presented some best practices to reduce the impact of a PIN encryption key compromise as well as some ways to minimize the impact if a debit encryption key is breached.
• Replace any HSM’s that support the IBM/Diebold format, or upgrade the software so that it no longer supports the IBM/Diebold format.
• Do not use Master Session keys, as a breach of one location’s keys will provide them access to encrypted PIN’s from all devices.
• Review HSM logs and look for high volumes of unusual transactions like PIN translations.
• Review access to the HSM and make sure that only authorized programs are able to send it commands.
• Upgrade to TDES keys as they are much much more difficult to breach than single DES keys.
• Make sure you terminals are securely mounted and terminals in storage and transit are properly protected so they cannot be sent to Russian criminal gangs to have their encryption keys removed.
• As per current PCI requirements, a key should only be used for a single purpose. This limits the impact of a breach if one key is compromised. This is why the PCI PIN security requirements require encryption keys to be used for a single purpose only. (i.e. Debit PIN encryption, terminal authentication, end to end encryption, file signing, etc.)

The webinar was presented by Chris Novak, Managing Principal, Forensics Americas and Matthijs van de Wel, Managing Principal, Forensics EMEA

MasterCard Clarifies Remote Key Injection Requirements

A month ago MasterCard issued a bulletin about how and what terminals can be upgraded to TDES keys for debit PIN encryption. The bulletin seemed to indicate that Remote Key Injection would not be allowed as a way to upgrade terminals to TDES keys.

Here is an updated statement from MasterCard:

"Last month, MasterCard issued a Security Bulletin to provide guidance on how point-of-sale terminals could be upgraded from triple-DES capable to triple-DES compliant encryption. In the Security Bulletin, MasterCard provided guidance stating that the most secure option to upgrade the terminals is to follow PCI PIN Security Requirements and have the upgrade performed at a key injection facility. However, our customers and vendors can use Remote Key Injection services to upgrade the terminals if those services meet all aspects of the PCI Pin Security Requirements."

This has also been clarified with an additional statement from MasterCard as follows:

"MasterCard has strict rules relating to Pre-PCI terminals, in order to assist our Acquirers meet the Visa Triple DES mandate we confirmed via the security bulletin that Pre-PCI terminals could provided they were Triple Des capable, (Which all Pre-PCI terminals should be) then they could be upgraded to become triple Des compliant.

Now in order to achieve this, the upgrade must be undertaken as per the PCI PIN Security Requirements ( This is our standard process been around for years nothing new or different). This has nothing to do with requiring the terminals to be PCI POS PED approved as per the latest articles. With regard to remote key injection, then as I have already mentioned, our preference is that vendors use a Key injection facility. However if you offer RKI, then provided you can confirm this will be undertaken as per the PIN Security Requirements then that is permitted.

With regard to PCI approved terminals being upgraded, as these terminals are still approved then these terminals can also be upgraded to TDES Compliant, again provided it is carried out against the PCI PIN Security Requirements, but as this was already allowed and nothing changed, we did not include it in our original bulletin."

The net of all this is that Remote Key Injection can be used, but it must be a process that meets the PCI PIN Security Requirements. These are a comprehensive set of requirements for protecting the integrity of encryption keys.

VISA 7/1/10 Mandate Clarifications

There has been much confusion over the impact to a retailer who does not meet the Visa July 1, 2010 mandates for payment security.

To review, there are three different mandates from Visa that must be met by US merchants by July 1, 2010. These are:

· All non-certified payment terminals on which PIN debit transactions are conducted must be removed from service. This includes any terminal that is not either VISA PED or PCI PED.

· All debit card PINs must be encrypted in TDES from the payment terminal

· All applications that “store, process, or transmit cardholder information” must be PA-DSS or PABP compliant.

So what is the impact of not conforming to one or more of those mandates?

First, in all cases, if the retailer suffers a data breach and cardholder information is compromised, then all liability passes to the retailer if the breach was in part the result of the retailer not being compliant with these mandates. Various studies put the cost of a cardholder breach in the range of $125 to $225 per compromised record. (Not card records actually used fraudulently, but all cardholder records that were exposed by the breach.) The Ponemon Institute publishes an annual study of the cost of a data breach which is available on their web site.

The costs of a breach that a retailer would be subject to include the following:

·Investigation costs by themselves, the card associations and the banks that issued the compromised cards.

·The costs borne by the issuing banks to re-issue the compromised cards

·The actual costs of fraudulent purchases made on any of the compromised cards

·Fines from VISA which would be assessed against the acquiring bank who would pass them to the retailer’s processor who would pass them to the retailer

·In addition, the retailer would have their own legal, PR, IT, forensics and remediation costs, which of course they would also have to bear even if they were compliant at the time of the breach.

What costs would a retailer face if they are non-compliant with the July 1st, 2010 mandates? These may vary by which of the mandates the retailer is not compliant with.

·Use of non-certified payment terminals after July 1, 2010 (Does not apply to Fuel Dispensers, there are different requirements for that.)

- While Visa has not issued a statement about the enforcement of thus mandate, it is reasonable to expect that they will fine acquiring banks who have merchants using non-compliant terminals. This could start on July 1, 2010, or sometime after that date. VISA has not publically published their enforcement plan for this mandate yet. It would be pure speculation to estimate the size of these fines.

Use of Master Session or Single DES (DUKPT) after July 1, 2010
- Visa has already announced, in their April 2009 TDES update that they will begin fining acquires who have merchants using other then TDES on 8/1/12. It is safe to assume that in most cases those fines will be passed onto the merchants in non-conformance with the mandate.

·Use of non PA-DSS (or un-expired PABP) applications after July 1, 2010.
- Visa has confirmed verbally to me that they plan on fining acquirers as of July 1, 2010 if they have merchants that are not in compliance with this mandate. The amount of this fine is likely to be in the same range as the fines for PCI DSS non-conformance ($5,000 t0 $25,000 per month), although I expect a lower tier fine for Level 4 merchants. I would guess that these would be assessed monthly for as long as the merchant remains non-compliant.

In summary, there are two types of costs and fines a merchant could be subject to if they do not meet Visa’s July 1, 2010 mandates: first non-compliance fines for non-compliance with the mandates, some of which be assessed starting on that date; and breach fines and other breach related costs in the event of a breach that was in part based on the merchant’s non0compliance with these payment security mandates.