We’ve seen an increase in attacks that circumvent a single point of failure, allowing criminals to access systems undetected, and to compromise card data. A significant change in PCI DSS 3.2 includes multi-factor authentication as a requirement for any personnel with administrative access into environments handling card data. Previously this requirement applied only to remote access from untrusted networks. A password alone should not be enough to verify the administrator’s identity and grant access to sensitive information,
Finally, PCI DS Council noticed that two factor authentication could resolve a lot of security problems and prevent a lot of breaches.
My article in City A.M. about mobile and crypto payments: Apple Pay, one year later: Why mobile payments have failed to catch on as we're still looking for something better
This essay was previously published by VentureBeat on December 13, 2015
When Apple Pay was first announced back in September 2014, I was very enthusiastic about it. Finally, a dream come true! Someone, and not just someone but the biggest company in the world, had come up with a new generation of payment technology that would combine mobile and biometric forces. The long chain of disappointments, however, started almost immediately.
First, it turned out that the “new technology” was nothing more than just a dexterous combination of our old, limping friends — plastic magnetic bank cards and EMV (EuroPay, MasterCard, Visa) chip cards — seasoned with shiny TouchId (which isn’t a new technology either, to be honest). Well, I thought, remembering the classics, maybe there is nothing new under the sun and Apple Pay isn’t an exception. At least it provided a more convenient way of payment than the older predecessors it imitated behind the scenes. So I patiently waited for the upgrade (not timed with either an iPhone or major iOS release) that would bring me Apple Pay.
While waiting for Apple Pay to arrive, I decided to learn more about the details of new technology. But it turned out that Apple hadn’t bothered to provide an exact technical description of Apple Pay components, which led to multiple speculations and concerns about its level of security. For example, it was unclear whether the actual card PAN (Primary Account Number) or its “scrambled” version was stored on the device.
Finally, Apple Pay arrived on October 20, 2014, and I managed to enter in one of my cards. It did not accept all of my plastics, however. In fact, it did not accept (and still doesn’t) the one I use for day-to-day grocery shopping. No matter, I rushed to the closest grocery store to impress myself and the cashier.
Unfortunately, the store’s payment terminal ignored all my attempts to wave the phone using various trajectories. The cashier asked me what I was trying to do. When I explained, she did not seem to understand. Finally, I pulled out my card, finished the transaction, and headed to another store, where I experienced the same situation. It turned out that most merchants didn’t — and still don’t — support Apple Pay. Eventually, I found one that did and managed to make my first Apple Payment. It worked surprisingly quickly and smoothly.
However, problems began with my second or third payment. My transaction was declined. A second attempt did not help. The cashier told me I didn’t have enough money in my account. Since it was actually a debit card behind the Apple Pay mask, I started worrying about my bank account: had it been hacked? Fortunately, since I could not use Apple Pay in most stores, I still carried my plastic cards with me. So I swiped a card through Apple Pay (the same card that had been declined just a minute earlier), and, lo and behold, it passed. I thought the mistake was an occasional glitch that Apple would soon fix. But when I tried to use Apple Pay several days later, the result was exactly the same. That was my last try. I didn’t want to explain to skeptical cashiers anymore that I did actually have money in my account.
Now I am even more convinced that systems like Apple Pay, Android Pay, and Samsung Pay, which just pretend to be new technology but in fact are complicated (and therefore unreliable) superstructures based on multiple old mechanisms, must eventually be superseded by completely new things. For example, Bitcoin or future cryptocurrency technology based on the Bitcoin concept but supported and enhanced by the banking and payment industries would be good candidates for universal payment systems for several reasons.
First, cryptocurrencies are open source protocols not linked to particular brands like Apple Pay or Android Pay, which makes them more attractive and accessible for everyone. Second, they are totally new, revolutionary technology compared to magnetic stripes and even EMV, which are already 30 – 50 years old (remember that most existing mobile payment solutions are still using plastic cards underneath their shiny modern facades).
Finally, Bitcoin, unlike plastic cards (and mobile payments!), is much more secure as it is based on strong cryptography and does not have a single point of failure in its implementation. At least in theory. But that is topic for separate discussion.
Interesting article about new Google approach to access control for enterprise applications. I agree with their approach because it seems that BeyondCorp is neither more nor less than just another implementation of web app with two factor authentication (2FA) by client certificates plus Web Application Firewall (WAF) functionality and some elements of risk based authentication, so there is nothing really revolutionary. I guess it fits mostly large enterprises as it requires significant additional hardware, software, and human resources (I like the author’s job title – “site reliability engineering manager”), unless there will be specialized hardware/software/services which are designed, implemented, and supported by third party vendors (Google?).
Note that the “privileged networks” still exist “behind the scenes” – in order to support all internal application deployments (such as database servers, etc.) and access control infrastructure. In fact, all the BeyondCorp elements in Figure 1 (see below) are located in privileged network, which is still accessed using “old fashion” ways such as remote VPN etc. Only the front end (they call it “access proxy”) is accessible from “unprivileged network”, so there is nothing unique in this model – in fact, it is used by most web applications hosting providers who can say that they are implementing some limited version of BeyondCorp too.
In a typical simplified case, the provider's data center (DC) environment is such a "privileged network", which serves the web applications’ back end and access control infrastructure (see red marks in the picture below). WAF can be used as an “access proxy”. The second authentication factor -- such as SMS, email, or Google Authenticator -- is a replacement for the device certificates utilized by BeyondCorp (which are just another classic example of the second “something you have” authentication factor implementation). The only element that is probably missing is the risk-based authentication, but there is always room for improvement.
This new authentication method offered by Yahoo looks awkward, from both user experience and security point of view:
1. User experience – keying in one time password each time I want to log in – is this the solution? Copy/Paste from KeePass is much more convenient.
2. Security – yes, it is single factor, and it is ugly factor because anyone who can either steal or borrow for just 2 minutes your phone now can access your account. Password only is ugly as well, so only combination of two factors provides some reasonable level of protection.
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.
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...
I'll be doing two one-hour book signings at Black Hat USA 2014 and DEF CON 22 conferences in Las Vegas:
Black Hat USA 2014:
August 6, 2014, 5:30 pm
Mandalay Bay Conference Center, Tripwire booth 141
(I'll be doing a short presentation before the book signing)
DEF CON 22:
August 8, 2014, 11:00 am
Rio Hotel & Casino, No Starch Press community table in Vendor Area
I don't think the palm scanner as an authentication method will make it into a mainstream of retail payments, at least not in the US. It is bulky, and most important thing - requires significant physical interaction with the device, which customers try to avoid. I believe the future belongs to personal, contactless payment devices and gadgets, such as smartphones and smart cards equipped with biometric sensors, which would allow the buyers to interact with the merchant's payment system without physical contact.
Biometric scanner on mobile phone is interesting feature that might be helpful to enhance security of mobile payments, as well as simplify the payment process and reduce the transaction processing time.