Given all of the recent credit card breaches at merchants like Target and Home Depot, you may be wondering how your credit card payments could be more secure and out of the reach of hackers. You're not alone!
However, the buzzwords and technical terms surrounding credit cards and mobile payments add up to a virtual soup of technobabble that make understanding it all difficult:
chip & pin
Let's de-mystify it, shall we?
Breaking it down
First, let's look at how the most common - and best understood - credit card payment mthod - the common "swiped" credit card - works.
The "magnetic stripe" credit card has been in use since the early 1970s, and the data encoded in the magnetic stripe is read by the credit card terminal as the card is swiped through. The card may have two or three "tracks" of data, although the third is effectively never used in practice.
The first two tracks of data each contain enough information to make a transaction (largely for redundancy purposes, in case one track is damaged). This information includes:
- Primary Account Number (or "PAN") - the credit card number.
- Cardholder's Name
- Expiration Date
- Card Verification Value ("CVV") - in this case, "CVV1".
- Service Code (defines parameters of the card - ATM vs credit, for example)
One quick note here: The CVV encoded on the magnetic stripe is one of two CVVs present on the card. The other, dubbed "CVV2", is the one printed on the back of the card that you are most likely familiar with. Both serve to establish that the card is "present" during the transaction. In a swiped transaction, the CVV1 is read by the terminal, and in a telephone or online transaction, the merchant will normally ask the cardholder for CVV2. This helps to combat fraud, since CVV1 is not printed on the card and CVV2 is not encoded on the magnetic stripe, the values are (in theory) hard for a criminal to obtain.
When a mag stripe card is swiped, the terminal takes the information above, along with the amount of the purchase, and sends it to an entity known as the "acquirer". There are two elements to an acquirer: a company that sells the terminal hardware and a credit card processing account (known as a "merchant account") to a merchant; and a bank that processes the transaction (known as the "merchant bank"). In some cases, these are two companies; in others, the bank sells the equipment themselves.
Note that there are many paths that can be taken from the terminal to the acquirer. At very small merchants that have low transaction volume, the terminal might dial in to the acquirers network over the phone line. Larger merchants might have an internet connection, and even larger merchants might have computers that record the transactions (for auditing and data mining, perhaps including loyalty card and other information) before sending the transaction data to the acquirer.
The acquirer sends the transaction to the processor - essentially the credit card network - MasterCard, Visa, AMEX, Discover, etc. The networks then route the transaction to the issuing bank (in some cases, the network IS the issuing bank, as with many AMEX cards). There are some exceptions to this rule, and I am overly simplifing it, but suffice it to say that the transaction data has a few places to go before it gets to the bank that issued your credit card (called the "issuing bank" - the folks to whom you pay your bill).
The most important thing to understand here is that the transaction information is not necessarily encrypted as it works its way from the credit card terminal to the issuing bank. Again, this is a general statement, and many of the network links between the various points along the way are secured to some degree. The weakest link - as we all know by now - has been the large retailers, who have wound up with malware in their credit card processing systems that have copied the card information right after it is swiped (and before it can be encrypted at all) and relayed it to the criminals responsible. However, this is actually a recent development. Most credit card fraud previously resulted from lost or stolen cards.
A lost or stolen credit card should, in theory, not be usable by a thief. The cardholder signs the back of the card (which is required in order for the card to be valid; read the back of your card sometime - it will state as much) and the cashier is supposed to compare the signatures. In practice, however, this is totally ignored. I haven't signed a card in several years, and have never had one transaction questioned, even for big ticket items. Some years ago, Citibank offered credit cards with your OWN picture on them as a way to combat fraud. This was worthless as well. As an experiment, my wife and I swapped cards regularly, and were each able to make purchases using a card that belonged to a member of the opposite sex, with a completely different picture, and non-matching signatures. Worse, many retailers now have the customer sign on the terminal's screen, and the signature is never presented to the cashier at all, making it impossible to verify even if the cashier was so inclined.
Chip & Pin to the rescue?
The most widely known method to combat fraud involving lost or stolen cards is the EMV "chip & pin" standard. This standard utilizes a "smart card" that has a chip embedded in it that, when inserted into a compatible terminal, interacts with the terminal to authorize the payment. The terminal accepts a pin code from the cardholder and provides it to the chip. If the pin is authenticated by the card, then the card number is released to the terminal. Therefore, without the pin, you shouldn't be able to use the card. Chip & Pin has been widely used in many areas outside of the US, most notably in Europe and Canada.
However, there are flaws in the system.
First, as a fallback in case the terminal has no pin pad (or the pin pad is not working), the terminal can request that the card authorize a signature in place of the pin entry. Researchers at the University of Cambridge have exploited this to convince a card to authorize a transaction without a pin code while convincing the terminal that a bogus pin (say "0000") is correct. While the attack has practical limitations (it requires hardware that would be difficult to conceal in its present form), it does represent a flaw in the implementation.
The same group of researchers also discovered a flaw in the random numbers generated by the terminal that help to authenticate the transaction; the result being that the numbers might not actually be truly random; indeed, might be predicatable. Someone able to predict these numbers could authenticate unathorized payments.
Further, they also discovered a flaw in the protocol by which these random numbers are themselves authenticated; the terminal provides the random number, but its identity is never validated, leaving open the possibility that another number can be substituted in its place by another entity.
The technically inclined can read the white paper discussing these vulnerabilities here. However, suffice it to say that chip & pin is a great step forward, but not a foolproof way to combat credit card fraud.
Regardless, even if this security were sufficient to prevent use of a lost or stolen card, it should be noted that once the transaction is authorized, the card information still proceeds, unencrypted, the same way in which a swiped card's data does, with all of the same issues of potential interception by criminals.
Technical paper describing EMV and tokenization.
In the United States, the major card networks (MasterCard, Visa, and American Express) have established a deadline of October 2015 for merchants to upgrade their payment terminals to accept EMV (chip and pin) cards. Merchants who fail to do so will be liable for any fraudulent transactions at their stores, rather than the banks assuming it. This is likely to compel most - if not all - merchants to upgrade. Gasoline stations have an additional two years - until October 2017 - to comply. Obviously, this will not solve the problem attendant to the breach of a merchant's network, but it is expected to significantly decrease "traditional" fraud as it has in Europe and elsewhere.
Contactless Credit Cards
Over the last decade or so, various banks began experimenting with "contactless" credit cards - cards that used a radio technology called "near-field communications" - or, more commonly, "NFC". NFC is a close cousin of RFID - radio frequency ID - the radio technology used in cashless toll payment systems and badge-based security systems. The idea was to both encourage more credit card use -- driving up revenues -- and to speed up card transactions, since a simple tap of the card would instantly transfer the data even faster than a swipe. Further, using NFC eliminated the reliance on mag stripes, which often wore out and required replacement of the card ahead of it's expiration date.
Inevitably, security problems were discovered.
The first issue is that the card data isn't encrypted, making the cards essentially the same as mag-stripe cards; and therefore just as vulnerable to interception and cloning.
Second, the card performs no authentication to ensure that it is indeed talking to a legitimate terminal. It simply provides the card data to any NFC system that comes calling - and this has been exploited. While the effective range of a "normal" reader is 3-5cm (1-2"), commonly available NFC readers for PCs have been modified to permit a range of 1.5m (5'). From that distance, a hacker, using easily obtained hardware, can request and receive the card number, cardholder's name, and expiration date through wallets, purses, etc - all while the cardholder remains completely unaware that it has happened.
Note that the CVV1 in this case is not included, but the card data retrieved could easily be used online at sites that do not ask for the CVV2. Alternatively, since there are only 1000 possible CVVs, it could be eventually brute-forced.
Third, passive interception (merely reading the communications between a card and a legitimate terminal as the cardholder makes a purchase) can be done at distances exceeding 15m (nearly 50 feet!). Suitable equipment left in a car parked across the street from a gas station with contactless payment pumps could siphon up any number of cards in short order and with essentially zero probability of detection.
In case this wasn't scary enough yet, there are apps available for Android phones that not only read the data from a card, but can then present it for payment.
Here's some more technical links for those so inclined:
White paper: Vulnerabilities in First-Generation RFID-enabled Credit Cards
Presentation: "Hacking the NFC credit cards for fun and debit"
Let's sum up:
Mag-stripe card: Can be used by pretty much anyone if stolen due to cashier indifference; data sent in cleartext and subject to interception in breaches like at Home Depot and Target.
Contactless card: Can be read/intercepted at a distance over the air; data sent in cleartext and subject to interception just like mag-stripe.
EMV (Chip & Pin): Can be theoretically used/cloned if lost/stolen, but not realistically. Flawed security implementations permit more technically advanced fraud. And, yes, data sent in cleartext and subject to interception just like mag-stripe and contactless cards.
Kicking the security up a notch
There are three well-known mobile payment standards that each increase security to varying degrees over physical cards: Softcard, Google Wallet, and Apple Pay.
Softcard began life in 2012 as "ISIS" (and was recently renamed for obvious reasons). It is an attempt by mobile carriers (AT&T, Verizon, & T-Mobile) to insert themselves into the mobile payment system. Security info on Softcard is sketchy - and Softcard executives did not respond to a request for information - therefore there are only bits and pieces of information to work with.
In a nutshell, Softcard:
- Requires a non-rooted Android phone with NFC capabilities and a special SIM card with a Secure Element.
- Requires the Softcard app, which is unlocked with a 4-digit PIN code
- Utilizes something called a "Protective ID" - described as "A unique transaction ID [that is] sent with each payment transaction, making it more difficult to counterfeit your card.".
- Levarages "a one-use token [that] is created so that your card details are not sent to the merchant."
So it seems likely that Softcard uses some form of tokenization - which replaces the card number with a dummy value that the issuing bank associates to your account. The token is stored in the "secure element" - a tamperproof circuit - in the SIM card. This is seemingly confirmed by Scott Mulloy, Softcard's CTO:
[Mulloy] said that the recent hacking of Target, which included information on more than 40 million payment cards, wouldn't have affected Isis users because of the design of the company's technology. He said each Isis transaction uses a separate authorization code, which prevents a hacker from being able to steal credit card information, as in Target's recent security breach, and use those credit card numbers to make additional purchases.
"The data breach would have happened," Mulloy explained, "but the ability to commit fraud--you can't make that next transaction."
However, what is left unsaid is where the token is converted back into the real card number (PAN). It is at the carrier? This seems likely, meaning that the carriers themselves and the path back to the issuing bank is potentially vulnerable. However, it would also mean that the merchants - the weak link to date - would never see the PAN. Obviously, this is already a big step forward.
Any Softcard response that may be forthcoming will be reflected in a future update to this post.
Google Wallet offers mobile payments via most recent Android handsets with NFC capabilities as well as a physical credit card. You fund your Google Wallet via your credit card (yay!) or your bank account (boo!), and are strongly incentivized to use the latter, since Google will charge you a transaction fee to fund with a credit card (double boo!).
Google Wallet doesn't perform tokenizaton, but instead assigns a one-time virtual MasterCard to your Google Wallet account for each transaction you make. The payment is processed by Google (in effect acting as the acquirer), and the funds deducted from your Google Wallet balance. You can also obtain a physical Google Wallet card for use in online or in-store transactions that debits from your Google Wallet account as well.
The on-time virtual MasterCard expires when a transaction is complete, which means that Google Wallet - when used to tap and pay from an Android phone - is not vulnerable to the same type of card interception suffered by Home Depot & Target.
So for NFC payments, the security, fraud detection, and billing are all concentrated at Google - making them a target for hackers. Google, it must be said, has a good security track record thus far.
However, we can expect that the physical Google Wallet card behaves like a regular mag-stripe card, so this card would appear to be vulnerable to interception.
Apple Pay is not so much a mobile payment platform as it is a mechanism to securely process a standard credit card transaction. Apple Pay implements a standards-based version of tokenization, which in this case replaces the credit card number (PAN) with a substitute value - chosen at random - called a "token". The actual details of the process have not been entirely made public, but here's a combination of what is known and what, therefore, is likely:
- You enter your card information - manually or with the iPhone camera - into the Passbook app on iPhone. Note: Contrary to some claims, you don't take a picture of the card. It is read through Optical Character Regognition - meaning that the iPhone reads the numbers and letters off the card and enters them for you instead of you typing it yourself (and perhaps making a typo).
- iPhone determines if the card belongs to a bank that works with Apple Pay. If so, it looks up the public key that belongs to that bank - likely provided during software updates - and establishes an SSL tunnel with the bank for secure communications.
Some quick notes here:
For brevity, I won't get into public key cryptography or SSL here, except to say that they are very secure and industry-standard ways of establishing secure communications and authenticating that you are communicating with whom you believe you are communicating to. While not infallible, when implemented properly they are very secure,especially for short-duration communications. Secure web pages use this technology.
Apple's security guide that covers Apple Pay states that SSL, rather than the much more secure replacement protocol TLS, is used. It is unclear if SSL is indeed in use (which would be bad) or if Apple just chose to use the more widely recognizable term, but is really using TLS.
- The iPhone and the bank agree on a Device Account Number (I will call it the DAN here, though Apple doesn't use the term) to replace the PAN (this process is not described, but presumably uses pseudo-random numbers that meet the requirements for a legitimate credit card number). The DAN is then encrypted and stored in the Secure Element in the iPhone. At this point, the card is available for use.
- When you use Apple Pay at a merchant, you authenticate using TouchID (your fingerprint) or your passcode. The DAN is then released from the Secure Element along with a one-time authentication code (likely sent in place of the CVV).
The one-time authentication code is only described in terms of what elements are used to derive it; the method in which it is derived is from these elements is unknown. This is a concern, but an educated guess from the nature of the elements in use - I will spare you the details - would be that there is no likely vulnerability here. The elements are presented in the Security guide.
The code is said to be computed in part from a key that is known to "the payment network and/or the issuer". Presumably, since American Express not only issues cards itself but also allows banks to issue cards, this particular phrasing was used to accommodate both possibilities. I.E., American Express might be where the DAN is translated into the PAN, even if AMEX didn't issue the card itself. Following this logic, MasterCard and Visa wouldn't be able to convert the DAN to the PAN, only the actual issuing bank would. Again, an assumption, but a logical (and crucial) one:
- The payment information (DAN and security code) make their way to the issuing bank (or, for AMEX, possibly terminating at AMEX as described above).
- The bank translates the DAN into the PAN and charges the account as it would a traditional "swiped" charge.
The important part here is that the PAN is never stored in the iPhone nor transmitted. Neither is the CVV. The DAN is useless without the one-time code, and since the one-time code cannot be re-used, interception of the DAN and code is pointless, since an attacker cannot (in theory) properly authenticate use of the DAN since it relies on information (how to generate the one-time code) that the attacker cannot know. This means that if Apple Pay had been available and used at Target or Home Depot during the period in which they were breached, that the customers using Apple Pay would not have been affected.
In fact, the only way to gain the requisite information to generate the one-time code is contained in the iPhone, so the attacker would have to steal one. However, the applet that generates it is in the Secure Element, which, you may recall, is not accessible by the operating system. Further, the owner of the phone can invalidate all of the DANs in the phone remotely with the Find My iPhone feature, and presumably with a call to the bank as well.
The other possibility is to attack the bank directly. Of course, this has been a possibility all along; the bank has always (obviously) had all of the credit card information on file, since it issued it and validates it for each purchase.
- Some form of tokenization, likely terminates at the carrier.
- "Protective ID" - perhaps analogous to Apple Pay's one-time security code - to authenticate transactions
- PIN code secures app and authorizes payments
- One-time MasterCard, likely terminates at Google
- PIN code secures app and authorizes payments
- Device Account Number replaces card number, tokenization terminates at issuing bank
- One-time security code authorizes transactions
- Payments authorized by fingerprint or passcode
Let's wrap it all up:
Essentially, there are two categories of credit card payments available today:
Traditional, including mag-stripe, EMV ("Chip & Pin"), and Contactless
These cards offer no security against the types of merchant breaches that have been in the news all too often in the past few years since the actual card number is sent in the clear from the terminal to the issuing bank. While EMV adds some security against card cloning and use of lost or stolen cards, intercepted card values can still be used online or at merchants without chip & pin capability. Contactless cards can be read by malicious parties with a simple Android app or other commonly available hardware.
If at all possible, you should avoid using these card types whenever possible to mitigate against compromise of the card number and subsequent fraud.
Mobile payments, including Softcard, Google Wallet, and Apple Pay
These technologies all offer a form of security that prevents interception of the transaction from yielding anything usable by criminals. To what degree this security extends varies with each solution. With Softcard, it ends with the carriers; with Google Wallet, with Google; with Apple Pay, all the way to the issuing bank.
While none of these technologies have had their entire security methodology fully and publicly vetted, the information that is available demonstrates that their inherent security is far superior to traditional card types.
The downside to each of these payment methods, of course, is that each requires a compatible smartphone. In time, it is expected that the rapid adoption of smartphones and of NFC technology by merchants will accelerate the availability and use of these more secure payment methods - which ultimately benefits us all.