I have created the info page for my upcoming book:
Bitcoin Payments: Implementing Secure Crypto Transactions
The security experts report that beginning in early September, the payment data systems at Kmart stores were purposely infected with a new form of malware (similar to a computer virus). This resulted in debit and credit card numbers being compromised.
If you are not familiar with Tor yet you should learn about it. In a nutshell, Tor is a system for anonymous Internet browsing. You can install Tor software and browse the Internet anonymously. If you are using Tor along with Bitcoin, you can enjoy the Internet freedom and privacy.
This is Kickstarter project which is supposed to create the Tor hardware box. Anonabox should be more safe and convenient than Tor software as it routes all the traffic from your Ethernet connection through Tor network.
Does the Apple Pay token contain cardholder data? (Updated with more details about tokenization implementation)
This essay was previously published in VentureBeat on September 25, 2014.
Updated with more details about tokenization implementation on October 3, 2014.
Apple Pay could be a big deal for the payment industry because — besides all the other business and marketing considerations — it looks pretty attractive from a security point of view. Here’s why:
1. Two-factor authentication on every transaction — “something you have” (iPhone) + “something you are” (fingerprint). The security level is higher than Chip & Signature — “something you have” (your card) — and is similar to chip and PIN — your card as “something you have” plus PIN as “something you know”. However, the biometric fingerprint is usually stronger than 4-digit PIN, which can be guessed or stolen through skimming. Therefore, the Apple Pay’s cardholder authentication is stronger than even chip and PIN, meaning that there are fewer fraud risks for merchants, issuers, card brands, and service providers.
2. Using tokenization technology, however it is implemented or called, means that merchants are not exposed to card data in clear text, which in turn means that the merchant’s payment acceptance systems do not have to be PCI compliant anymore. Unfortunately, this does not help traditional retailers much, since their systems (POS + payment terminal) must be PCI compliant anyway in order to process regular payment cards. However, it opens the door for a new way of payment acceptance — virtually, any device with NFC chip (for example, a business or even consumer grade laptop or tablet) can “legally” accept Apple Pay and not worry about PCI compliance. Of course, this statement requires some proof, that’s why I am looking for more details about Apple Pay’s tokenization system.
The security of Apple Pay’s tokenization system is still questionable. Based on information I found so far, the payment token (at least the one used for in-app purchases, as the company has not released enough technical details about in-store purchases) contains encrypted cardholder data — primary account number, expiration date, and cardholder name — which in my opinion reduces the Apple Pay security score a bit.
Below is the fragment of Payment Token Format Reference from the PassKit reference.
It is still unclear whether this is the token format that is being sent from the iPhone device to the payment terminal during an “in-store” Apply Pay session. However, according to Apple, “The PassKit framework provides APIs for Apple Pay. The StoreKit framework provides APIs for In-App Purchase.”
There is another statement from the same Getting Started with Apple Pay document that proves that the payment tokens (and therefore iPhone’s secure element) contain encrypted card data: “The alternative is to provide your own server-side solution to receive payments from your app, decrypt payment tokens and interface with the payment provider.”
Note that this statement specifically targets the in-app purchases, and I am not sure whether the same token is used for in-store purchases or whether the in-store token, even if it has the same format, in fact contains the card data. In any case, it looks like at least the in-app purchase token does contain the encrypted cardholder information.
This fact contradicts Apple’s claim that no card data would be stored on the iPhone device. Usually, “no card data” means that there is no cardholder data at all, even in encrypted form. Some tokenization implementations, for example, use randomly generated tokens that cannot be reversed back to the original PAN (primary account number).
How difficult is to trick the Apple Pay system in order to decrypt the payment token and retrieve the original card data? That’s still an open question, but I am sure hackers have started thinking about it already. Another question is whether Apple is using the same token (or the same data inside the token) for in-store purchases, i.e. whether the in-store token contains the same card data elements as the in-app token.
I hope Apple will release more technical details about its “in-store” tokenization technology to the public so security experts can review it, calculate the risks, and determine the level of security.
Update on tokenization implementation, October 3:
Apparently, Apple Pay uses "network tokenization" - a technology implemented by payment brands (Visa, MasterCard, Amex) and supposedly based on common "EMV tokenization" approach (the spec was released by EMVCo in March 2014). There is a confirmation at least from Visa for the first part. However, unfortunately, there is no official confirmation for this information from Apple as well as there are no technical details available about Visa Token Service or other brands' tokenization implementations (for example, whether they are compliant with EMVCo spec or not) . Anyway, such implementation scheme, with connection between "network tokenization" (like Visa Token Service) and "EMVCo tokenization", would make sense. Let's assume this is true so we could imagine how it works before we get the actual details.
"Network tokenization" would address some concerns expressed in my original article and provide answers to some questions. For example, it explains the "device primary account number" field in the picture above. In the "network tokenization" scheme, the token looks the same as the original PAN (19 digits starting from the payment brand's identification prefix such as "4" for Visa) . "Device PAN" probably means that the token is encoded in this field rather than the original PAN.
"EMV tokenization" uses the format-preserving token which looks like regular PAN but has a special BIN range dedicated by the payment brands for tokens. Thus, the fact that the token is used instead of the original PAN is transparent for existing merchant and payment processing systems. "De-tokenization" is done by payment network (Visa, MC, Amex, etc.) - after transaction authorization request passes the gateway, processor, and acquirer, but before it hits the issuer. This is the first main difference of EMV tokenization from "classic" tokenization implemented by payment gateways and processors, where transaction is "de-tokenized" before it even reaches the acquirer and the network.
Second difference is the way the token is generated and consumed. In "classic" tokenization, the token is usually generated at the back end (merchant's, gateway's, processor's, or acquirer's data center) - only after the authorization request is processed using cardholder data in clear text. This is necessary in order to deliver the original PAN to the point of tokenization which is located at the data center far away from the merchant's point of sale. So the cardholder data is still vulnerable for attacks, unless it is protected by point-to-point encryption, which is still relatively rare due to its high implementation costs for merchants. In Apple Pay, the token is generated and stored in iPhone (the exact details of this mechanism are still unclear so it is a whole separate topic for future research and post). Therefore, the cardholder data in clear text never travels through the merchants' systems.
And third difference: since Apple Pay apparently uses EMV Contactless protocol for communicating the data between the iPhone device and merchant's payment terminal during transaction, the token is always accompanied by the cryptogram - a piece of additional dynamic encrypted data which changes for each transaction and allows the payment terminal and the tokenization system to authenticate the cardholder and validate the token. Hopefully, the token is invalid without the cryptogram, otherwise, it could potentially be used just as regular PAN for any transaction.
Finally, some good news for consumers and merchants: there is an indication that "Apple Pay like" systems can be implemented by other mobile payment providers. Here is important quote from Visa website which is worth mentioning:
Now you can offer consumers a broad range of simple digital payment options, while protecting their sensitive information from fraud. Whether you want to enable mobile payments with Apple Pay or Android devices, create a frictionless e-commerce experience with Visa Checkout, or securely maintain cards on file, Visa Token Service provides the unifying platform.
It means that the payment brands do not intend to keep their tokenization technology limited for Apple private use only, and so payment solutions similar to Apple Pay can be implemented by other mobile payment solution providers such as Google.
Although all these assumptions sound reasonable, many of them still require official confirmation and additional explanation which are highly anticipated from Apple.
As I predicted in previous posts, the wave of card data breaches is growing and sweeping away everything (meaning, above all things, PCI-compliant merchants) in its path. Brian Krebs stated in his blog that the point of sale software, which is created by Signature Systems and used by Jimmy John's and other retailers for payment processing, was not PCI (PA-DSS) compliant as its formal validation expired in 2013. This fact can be a good excuse for PCI Security Council to blaim the merchants again and say that the breach was made possible because they were not PCI compliant. We all know this isn't true, and PCI compliance wouldn't help them to avoid the breach, as it didn't already for many others. In most cases, including those recent breaches, the attack is done using RAM scraping, aka memory parsing - a special technique that exploits the payment application vulnerability which cannot be mitigated by PCI standards.
My first take on Apple Pay security in this article published by VentureBeat.
Apple Pay is looking pretty attractive so far from a security perspective. But it’s tokens could be cause for concern...
The carding industry is constantly evolving and developing new methods of cashing out the stolen credit card data. In addition to standard ways described in my book Hacking Point of Sale, there are a couple of new techniques. Perhaps, those methods are not exactly new but just recently came to my attention.
1. Using gift card as a "new body" for stolen credit card (this information is received from the source working for one of the major payment brands).
The stolen track data is encoded into the plastic decorated as a gift card (or even original gift card is re-encoded with stolen track data). Most gift cards do not have any customer identification information and physical protection features of credit cards, so there is no way for store attendant to authenticate the cardholder. At the same time, gift cards are processed automatically by most point of sale systems in a way similar to credit cards.
2. Using online affiliate programs to make purchases and earn commissions.
The stolen cards are used to purchase goods through online affiliate programs which are intended to sell various pills etc. The cashing out effect is achieved by carders working as affiliates and earning commissions on each such purchase made through their affiliate account.
At the core of the affiliate program is a partnership of convenience: The affiliate managers handle the boring backoffice stuff, including the customer service, product procurement (suppliers) and order fulfillment (shipping). The sole job of the “affiliates” — the commission-based freelance marketers who sign up to promote whatever is being sold by the affiliate program — is to drive traffic and sales to the program.
I'm writing a new book: Bitcoin Payments: Implementing Secure Crypto Transactions.
Implementing Bitcoin explains all aspects of Bitcoin acceptance for merchants (both ecommerce and brick-and-mortar) from the angle of payment technology and security. The book explains the basics of crypto currencies, and compares Bitcoin with other “altcoins” as well as with existing credit card payment systems. The book also describes the security of crypto-payments from the viewpoints of both payer and payee. Importantly, Implementing Bitcoin contains hands-on step by step instructions for merchants on crypto payment acceptance such as integration of ecommerce website and retail POS with Bitcoin payment processors. The book also contains helpful practical guidance on how to select an appropriate Bitcoin wallet and how to build a Litecoin mining rig.
I'm planning to finish the manuscript by the end of year, for publication by Wiley in April 2015. Here is the brief description of the table of contents, but the final version can be different.
Part I, Foundations, sets the scene for the following two parts (which are focused on implementation details of crypto-currencies and crypto payments).
Chapter 1, Evolution of Payments, reviews the Bitcoin predecessors and compares them with crypto currencies
Chapter 2, Basics and Principles, covers the main distinctive properties and core design principles of Bitcoin.
Chapter 3, Elliptic Curves, explains public key encryption in layman's terms, without much math so everyone could understand
Part II, Under the Hood, is aimed to people who want to understand the technical details of Bitcoin implementation.
Chapter 4, Implementation and Network, describes the Bitcoin network implementation: from client software to Bitcoin transaction and Blockchain.
Chapter 5, Mining, explains the process of creating (“mining”) the Bitcoins and other crypto currencies out of thin air
Chapter 6, Services, covers all the additional services that are not part of the crypto currency core.
Part III, Crypto Payments in Action, describes all varieties of crypto payments from personal money transfers to online purchases to large retailers, explaining the challenges and recommendations for each group of payers and payees.
Chapter 7, Money Transfer, covers all the aspects of one-on-one crypto payments from viewpoints of both payer and payee.
Chapter 8, Online Payments: Ecommerce, explains how to accept crypto payment at ecommerce website, including all possible challenges and security issues.
Chapter 9, In-Store Transactions: Brick-and-Mortar Merchants, explains how to accept crypto payment at retail brick and mortar store.
Appendix A, Catalog of Crypto Currencies, contains the list of all currently available altcoins with description of their main properties and technical characteristics such as method of mining, full transaction confirmation time, time interval between the blocks, creation date, market capitalization, current exchange rate, final total of coins, mining rate, current Hashrate, and more.
Appendix B, Glossary of Terms and Abbreviations, deciphers the abbreviations and defines the terms used by crypto payments community.
This is good article comparing Apple Pay and digital wallet cards.
I had two comments, though.
1. There is another startup (in addition to Coin) that tries to capitalize on reanimation of dying magnetic stripe technology - Loop. I have published an article about Coin and Loop in VentureBeat:
2. I have PayPal debit card (by the way, it is MasterCard, not Discover). Now, as soon as I get my new shiny iPhone 6, theoretically, I can add this card to Passbook and pay with my PayPal account through Apple Pay! Wouldn't it be cool and funny? However, I don't think Apple will allow this because it looks like they are going to control which issuers are participating. I don't think that this is the case with Coin and Loop - they would love to allow as much cards and issuers as possible. Not that I like the concept of Coin and Loop - I am against any attempts to reanimate the dying magnetic stripe technology (by the way, Apple Pay is also based on magnetic stripe cards, but it does it in elegant form, as always). So the important point is that Apple Pay can be limited according to Apple preferences. We have to have a common standard that would be based on Apple Pay technology.