My interview by Cathleen McCarthy at CreditCards.com about recent breaches, payments with credit/debit cards, EMV migration, etc.
Secure payments with HP Mobile POS: Implementing point-to-point encryption using HP retail solutions
Secure payments with HP Mobile POS: Implementing point-to-point encryption using HP retail solutions is the technical whitepaper which I have created for HP. More information about HP mobile POS solutions can be found here.
Bitcoin creator is reportedly found in Los Angeles by Newsweek reporter.
This is second shutdown event of Bitcoin service provider after recent online exchange Mt. Gox bankruptcy caused by the flaw in Bitcoin transaction processing design. According to the message on Flexcoin website, they are closing their business but still going to publish the details of the attack as soon as they are available.
I was interviewed about recent card data breaches and my book - Hacking Point of Sale. You can listen to the interview here. Thanks to ITS Partners, and personally - to Jacob Crawford (@jake_crawford91) for this interview and for the great quality of the podcast!
The famous German cryptographic machine - Enigma. Thanks NSA for bringing it to the RSA conference.
RSA 2104 - the Cryptographers' panel:
First two of the three RSA "letters" were here -- Ron Rivest and Adi Shamir -- and Whitfield Diffie.
Shamir said that cryptography is not a problem of modern security. There are no breaches associated with the cryptographic algorithms. It's algorithm applications, or implementations that fails.
Hacking Point of Sale is available in local Barnes & Noble bookstore. People still buy books in physical bookstores!
Card data breach at Econofoods in Marquette, MI:
Tadych’s Econofoods in Marquette, MI announced between January 8, 2014 and February 17, 2014 that various customers’ credit card and/or debit card information may have been compromised and obtained by an unauthorized person or criminal network.
This essay was previously published by VentureBeat on February 9, 2014
Recent breaches of payment systems at Target, Neiman-Marcus, and Michaels show that there’s something fundamentally wrong with the payment card data security standard we’re all reliant on, PCI DSS. The original idea of the PCI data security standards was simple but ambitious: The more PCI-compliant merchants out there, the less frequently security breaches occur. In reality, the list of card data breach victims still grows almost every day.
Proponents of PCI standards may say the breaches were made possible because there were violations of one of numerous PCI requirements. For example, the latest version of the standard includes 399 (!) “testing procedures.” Even if it’s true, does it really matter? If even the largest retailers, with their IT departments and security experts, failed to maintain PCI compliance, how can consumers rely on medium and small businesses?
The PCI-compliant merchant environment is similar to a poorly designed nuclear reactor. The cooling water continuously circulates in order to cool down the active zone, and if the pumps stop for a while, the whole thing melts down and blows up. Fortunately for us, modern nuclear stations have multiple backup systems and extra levels of protection. But PCI-compliant payment systems don’t. Security controls dictated by the standards are either ineffective or difficult (and sometimes impossible) to implement and maintain in a brick-and-mortar environment.
Once a hacker discovers a new exploit and sneaks into the merchant’s network, the fortress falls. There is nothing inside that protects the sensitive cardholder data from being stolen.
Most retail point of sale (POS) systems run on special hardware managed by Windows OS, which makes it similar to a standard PC from an application security viewpoint. Payment software, which takes care of credit and debit card processing, can be either a separate app or a part of the POS, but normally it resides on the same physical machine and shares the same computer resources with the POS and other Windows applications.
In order to process credit or debit card transactions, the payment application communicates with the outside world — the payment terminal, POS, and the payment processor — and therefore it must continuously store, transmit, and process the sensitive cardholder data loaded from the cards. The data is stored on magnetic cards in clear text and, if stolen, can be used “as is” in order to produce a counterfeit card.
Several areas of payment application vulnerabilities exist. Sensitive cardholder data, which is the main target for hackers, can be stolen by penetrating one of those surfaces. Designers of payment systems (or security standards for payment systems) must ensure that their product (either software or standard) protects all possible vulnerability areas.
Unfortunately, for some reason, PCI data security standards (and therefore most payment applications) explicitly take care of only one area, data at rest, which is the information stored on hard drives. Perhaps, it happened because, back in 2004, when the standards were created, collecting data at rest was the easiest and therefore most popular way to pump out the credit card data from the retail store. Back then, POS and payment applications were storing and abandoning enormous amounts of unencrypted card data records on every hard drive. So the creators of the PCI standards were focused on encryption of data at rest in order to fix the obvious flaw, while other surfaces were still vulnerable and waiting in the wings.
PCI rules enabled the processing of data in clear text in the RAM (random access memory) of point of sale machine (data in memory) as well as transmitting the unencrypted card data over the local networks. In addition, the payment application was allowed to store its binary and configuration files with no protection so they could be altered by malicious software. Even without going into the details, it is pretty obvious that there are plenty of ways to attack the PCI-compliant payment application.
RAM scraping, or Memory Parsing, probably is the most reliable way to steal the cardholder data from a PCI compliant POS by exploiting the unprotecteddata in memory area. A special piece of software installed on a POS machine continuously scans the entire computer memory, or sometimes even a specific POS application process, looking for magnetic track data containing the sensitive cardholder information. A RAM scraper filters out only useful information from an enormous stream of memory data using a special technique — regular expression, or regex. Most likely, this memory parsing technique was used to steal the card data in Target, Neiman-Marcus, Michaels, and many other breaches.
PCI requirements, which were designed with large data centers in mind, are hardly feasible in the reality of the retail store environment. PCI DSS puts an unnecessary burden on merchants who spend a lot of resources on compliance instead of investing in robust security technologies.
Let’s take just a couple of examples. Requirement 10 — “Track and Monitor All Access to Network Resources and Cardholder Data.” Can you imagine a large supermarket chain, operating hundreds of stores with thousands of POS machines, effectively monitoring the activity of each and every device in real time? Or Requirement 12 — “Maintain a Policy That Addresses Information Security for All Personnel.” Imagine a family restaurant owner creating a security policy for its waitresses. Most people in the retail industry don’t know much about information security, and they shouldn’t have to, because security features should be provided by the payment system out of the box.
So if PCI standards are failing to protect retailers, is there anything that can be done to stop the breaches? Chip & PIN (EMV) cards, already adopted in Europe and Canada, are much more secure than the regular magnetic stripe cards that are still used in the US. However, full transition to EMV, even if started today, would take several years.
Fortunately, there is an existing security technology that can be implemented to protect magnetic stripe cards: point-to-point encryption (P2PE), also known as end-to-end encryption. The concept of P2PE in general is simple: The data in clear text is encrypted on one end of the system and decrypted on the another end. When applied to the payment systems, it means that the data is encrypted at the point of card entry — magnetic stripe reader (MSR) — and decrypted only in the remote data center of the merchant’s payment processor. If P2PE is implemented correctly, the sensitive data in clear text never touches the memory, hard drives, or network inside the retail store.
You’d be surprised, but P2PE is pretty old as it’s been used by the same payment card industry to protect debit PIN numbers for many years. However, instead of investing in well-known technology and forgetting about the massive breaches once and for all, the industry decided to implement the bulky and ineffective PCI standards. It’s important to note, however, that PCI DSS is still helpful in many cases, for example, to protect ecommerce servers or payment processor data centers, where access to unencrypted card data is really necessary.
Unfortunately, it is helpless in the hazardous environment of brick-and-mortar stores.
(Disclaimer: The views and opinions expressed in this article are mine and do not necessarily reflect the official policy or position of HP.)