So, until some “velocity checks” (counters) are added to CVV2 validators, this is the lowest hanging card. The funny thing is that, since it only takes 6 seconds, changing the CVV every hour doesn’t really work, here, so the new Motion Code is not a good countermeasure.

Smart card hardliners will tell you that this isn’t a smart card issue. Sure, but it’s related, mostly because however high, there is always a lowest hanging card. Smart cards (with EMV) have been quite efficient at curbing card-present fraud, because the chip computes a dynamic verification code for every transaction. During the EMV rollout, fraud was taking place in countries where smart cards were not used. As this rollout is getting closer to completion, this opportunity is slowly going away.

The new lowest hanging fruit is online transactions. EMV doesn’t work online, mostly because all attempts to introduce card readers on normal PC’s have failed, so our smart cards are useless here. And because consumers haven’t been used to use their cards’ chips during online transactions, they won’t do it on mobile transactions either.

Sadly, commerce is moving online these days, so it is not good news to find the lowest hanging fruit there. The CVV2 check will be fixed, and more merchants will use 2-channel verification methods like “Verified by Visa”. Then, it is not obvious to know what will be the new lowest hanging fruit.

One solution is to use mobile payment, which offers a much better security these days. It works for in-person payments, and it is starting to work for online payments made on phones. I haven’t seen mobile payment used for to verify online transactions not made on a phone, but this would be very easy to do.

The main message of this presentation is that payment in wearables is going beyond basic plastic bands and special watches. The new trend is now that payment is being integrated into normal fashion accessories, like the Swatch deployment in China, or the integration of payment in the latest Jawbone UP4. These deployments are linked to a payment scheme: China Union Pay for Swatch, and American Express for Jawbone. Still, it is exciting to see mobile payment integrated into generic devices that you mostly get for other things (like, you like the watch, or you like the fitness tracking features and band design. Here, payment is just an extra feature, which is likely not the main reason for selecting the object.

From a sales point of view, this looks important to me. If payment is successful in these first deployments, it could lead the way to many more similar objects. As a longtime user of vision glasses, my glasses would be the perfect object for payment, as I wear them in almost all circumstances (plus, the form factor is interesting for fitting an antenna).

This does raise a few security-related questions:

• Transfer. Such devices all come with some kind of enrollment process, for instance through the UP mobile application for Jawbone. This is nice, but the life of the object continues beyond enrollment. A fitness tracker may be given or sold to another person, and it is reasonable to expect that the payment feature will need to be disabled, and potentially reenabled later (and again).
• Loan. A fitness tracker is very personal, a watch a bit less (my teenage daughter can borrow mine if she happens to like the design), and I am sure that some other payment-enabled wearables will be shared, at least in a limited community. I am happy to share my watch, but I want the payment feature to be disabled when that happens.
• Steal or lose. Here, the problem is that these payment-enabled objects become an extension of our wallet. Losing one is very much like losing a wallet, and this may become dangerous, especially for people who only use the payment feature very occasionally. Also, checking that the person using such an object is legit will be difficult or at least different.

I don’t own any of these devices, so I don’t know how they handle that. Maybe that all these issues, and more, have already been sorted out technically. Yet, there is a human aspect to that will also need to be field-tested. The users need to be aware that they are wearing payment cards. Not much of an issue when you only have one payment-enabled object, but this could become a problem if we get more and more such objects.

But then, these are interesting problems, and I can’t wait to find my own payment-enabled fashion statement, and to see how this evolves in the near future.

The reasoning goes on with a comparison of the security merits of a credit card number stored on Passbook and a real card. Read the paper for the details, but an obvious comparison is that a real card is easier to lose/steal (because we stick to our phone more than we stick to our wallet), and also easily accessible (the phone will be at least somehow encrypted, requiring some technical skillls to access the card numbers). In addition, credit cards are easily replaceable, and they usually entail a zero liability insurance for the end-user.

What surprised me is the conclusion: “convenience wins in the consumer mind”, and more specifically, “convenience may win out over a little risk”. From the risk analysis, my feeling is that using Passbook is actually less risky than carrying real cards, and even if one doesn’t agree with that, zero-liability means that, for the customer, the risk is the same: zero.

Although we agreee that security is a way to reduce risk globally, there are many different ways to reduce risk for every actor. For the end-user, in that specific case, the key aspect is the zero-liaility insurance offered by the credit card company. If there is a major security flaw in Passbook, there may be a problem between Apple and credit card companies, but end users should remain largely unaffected. The worst thing that could happen to them is to lose the convenience of Passbook if credit card companies deny to Apple the right to store card numbers in it.

Just another friendly reminder that our job as security providers is not just to randomly increase security of things, but to actually reduce the level of risk for an actor, which should be our customer. Banking smart cards are sold to banks, not to end users, and there is not reason to change this relationshp when the cards are dematerialized into software: our customers are the banks, and we need to reduce their risk (which, hopefully, can help them offer a zero-liability insurance to their customers at a better cost).

Disclosure: I just finished reading Brice Schneier’s Liars and Outliers: Enabling the Trust That Society Needs to Thrive, which may explain why I have this unusual high-level view of security. Good book, by the way.

Every card is identified by a card number, an expiration date, and a cardholder name. Naturally, there is more to it, and the interesting thing is that this “more” depends on the card you have and the way you use it. Let’s consider three examples of payment in the US:

• In a standard store. In such an interaction, your card is present. You swipe it, and provide a signature if required. In that case, the security code is encoded in your card’s magstripe. This code is often called CVC1 in jargon (Card Verification Code 1).
• On Internet. In such an interaction, the merchant can’t see your card: this is a card-not-present transaction. Therefore, you need to provide the code. Here, it is the 3- or 4-digit code that is printed somewhere on your card. This code is different from the one on the magstripe, and it is called CVC2 in jargon.
• In a store with contactless payment. In that case, instead of swiping your card, you tap it. When you do that, the card generates a Dynamic CVC, based on a secret it contains and on a random number provided by the terminal. In that case, a different code is generated on each transaction.

On every transaction, there is a code, but this code depends on the transaction type. The two first ones are easy to steal from you: The CVC2 is printed on your card, and the CVC1 can be read in 2 seconds with a $5 skimmer. Naturally, in that case, this security measure is only a small part of risk management, and there is more. For instance, since merchants have the best opportunity to steal these codes from you, banks are very good at detecting that fraudulent transactions come after a transaction at a given merchant.

With a contactless card, the code is generated dynamically for each transaction. This means that, even if someone intercepts your communication (which remains rather easy, since it happens over-the-air), the code that they intercept can only be used for this particular transaction, an not for a new one. Basically, it is useless.

In the US, mobile NFC payment uses the same technology as other contactless payments, which makes it rather secure. In addition, it is not possible to turn off a contactless card, whereas a mobile phone’s card emulation mode is usually only active when the phone’s screen is on (i.e., when you actively use it).

Outside the US, things are even better, because card transactions use a more sophisticated cryptographic protocols, which include an authentication of the cardholder (the (in)famous PIN). This is actually quite efficient, and fraud statistics in France show that most fraud is based on magstripe and Internet sales.

Finally, one last authentication method. Chip-based payment cards can also be used to secure Internet transactions. Some companies like Vasco sell small card readers that generate authentication codes dynamically, allowing these codes to be used to secure a single Internet transaction. This brings the security of in-person EMV payment to Internet payments.

Naturally, like usually in security, this is all a question of trade-offs. It is only worth investing in such technologies if the fraud is high enough. Card companies seem to believe that something is needed in the US now, since chip-based credentials will be required by 2015 in the US.

You can read the papers to get all the details on this attack. Basically, they have been smart enough to use a salt before hashing the PIN value to avoid brute-force attacks. However, they haven’t been smart enough when they decided to store the salt just next to the hashed PIN value. Of course, with these two pieces of information, it takes at most 10,000 attempts to find the PIN (just check the video of the attack if you doubt that this is a very small number).

But hey, it’s just an attack/vulnerability. Maybe the first one, most likely not the last one. What surprises me most is that all these wallet programs insist on Common Criteria certifications of the Secure Elements, very complex certification programs for SE applications, and yet they leave behind this kind of basic vulberability in the mobile application, whose security does not seem to be formally evaluated by anyone. At least, the SIM/eSE security specialists should be able to sleep well for a while: they are unlikely to be the best target for real attackers, with such low-hanging fruit.

What really puzzled me from the zvelo guys is their analysis of what needs to be done. Their first step is correct: this PIN (which is used to open the wallet, not to validate a transaction) should be stored and verified in the Secure Element. Now, what surprises me more is their next statement:

Basically, by moving the PIN verification into the SE itself, this might constitute a “change of agency” responsible for keeping the PIN secure. The fear is that Google might no longer be responsible for the security of the PIN, but rather the banks themselves. If this is in fact the case, then the banks may need to follow their own policies and regulations regarding ATM PIN security which obviously, and rightly, receive a great deal of scrutiny.

Now, this doesn’t look good. First, about the ownership of the SE. I am not sure what the deal between Google and the phone vendors is, but I would say that the SE is owned either by Google or by the phone vendor. After all, they are the ones who control the SE’s master keys.

Even if we don’t consider that, Google would not store the PIN in somebody else’s application. I am sure that they have their own app in the SE, that they would use this app to manage their little PIN. This is very easy to do with Java Card, and I am sure that they can develop this addendum easily.

Finally, as mentioned above, this PIN is not an ATM PIN, because it is not linked to a specific transaction. When you enter the PIN, it opens the wallet, but it does not authorize a transaction. It is the digital equivalent to putting a four-digit combination lock on your wallet (which is exactly what Google is claiming).

Nevertheless, the story remains interesting, and it reminds us of the complex ecosystem behind NFC payments. For instance, did the banks consider the Google PIN in their risk analysis of the Google wallet? Well, if they did, the Google PIN is now a bit weaker. It is not broken, though: a combination of malware and physical access to the phone is still required to make a fraudulent transaction.

To conclude on a positive note, the end of the zvelo article is a good list of recommendations. If you keep your phone clean and locked, the bad guys will have to find a better vulnerability.

This sounds interesting, and I will be listening to the show (maybe not live, but I will definitely get the podcast). I listened many times to France Culture’s science shows, and they are usually serious and interesting. Of course, the question (in English, how to enhance the security of bank cards?) is already a bit aggressive, and I am sure that some people would even challenge that question, claiming that there isn’t much to be enhanced. Well, we’ll see on Friday.

There are a few exceptions to that rule. If you are lucky enough to be in a place that accepts American Express, these cards will be accepted even if they don’t have a chip (this is quite natural, since even those issued in Europe have no chip). But in many cases, you may well be really out of luck. Consider the subway example, for instance. In many places, it is becoming common to close all tellers at late hours, only to leave automated machines. And if you can’t get them to work, well, things may get ugly.

Things are only going to get worse, and apparently, some American companies have understood that. According to the NYTimes, Travelex is getting ready to issue prepaid smart cards for its customers in a bout a year from now. That means that, in a while, we should see American tourists with smart cards. And if it works, we are quite likely to start seeing American businessmen with smart cards as well, as corporate cards for international travellers will start having them as well.

Good news for smart cards? Not necessarily. If we consider that only 20% of all Americans have a passport, this also caps the number of Americans with that specific need. Most likely not the killer reason for American banks to switch to smart cards, which are still considered too expensive to manage.

This approach is interesting, because it makes it harder to use forged cards in face-to-face transactions. In this particular context, it reduces the differentiation of smart cards. Nevertheless, such approaches are interesting for security, at least to remind the smart card industry that their solutions are costly, and that there may be other ways to decrease the risk associated to payment (or any other application).

OK. But let’s try to analyze this a bit deeper.

First, the attack:

• It relies on cloning. A good point for smart cards, which claim to be more difficult to clone.
• It can interest organized crime. We are talking millions here. If this can be repeated, it is a strong point in favor of good security, because the attackers can invest a few thousand dollars in breaking the card.

Again, I told you so! But I also need to bring up a few not so strong points:

• No authentication issues. Apparently, in these attacks, the attackers know the PIN code, either because they own the original card, or because they stole the PIN code with the card (not that hard, try it while waiting in supermarket of money dispenser lanes).
• A key part of the attack consists in hacking a server somewhere, to make a system believe that a card has no limit (or a very high limit). No card involved here, so no good point for a smart card.

Of course, I will now tell you that these arguments don’t hold.

• Smart card PIN authentication also authenticates the card. When performing an EMV transaction, the PIN is verified by the card, and that fact allows a cryptogram to be generated. When the payment terminal or server verifies its cryptogram, it will know that the user has been authenticated and the original card has been used. That links authentication to cloning, which is good for our case.
• About servers, there is nothing to say. There are so many breaches in all kinds of servers worldwide that nobody would rely solely on servers for reaching a good level of security.

So, I can now safely conclude that this attack would not work without actually cloning the card, which means that smart cards are better than magstripe, because they are in all cases harder to clone (even on cards with very poor security, there is no command to get the value of the secret; some kind of attack is required to get it). In addition, since the potential revenue is important, such schemes may interest organized crime, which means that they should be able to get the secrets out of at least the weakest available cards.

That leads us to the bleak side of things. A typical smart card in use today has been issued in 2007, by a bank who selected a platform vendor in 2005 after one year of negotiation with a card certified in 2003. And since 2003, a lot of attacks have been invented, and I am quite convinced that at least most CC-approved labs would be able to break these cards.

As a conclusion, I would say that smart cards are a good defense against these attacks, because they significantly raise the cost of preparing for the attack. However, I have no clue of the amount of money that it would cost to break a typical card used today, and this may still be very accessible to your typical mafia guy.

There is a recent pilot that puts Moneo (the French electronic purse) on mobile phones, allowing a few students to pay their meals with their phones. Olivier Méric, director of BMS, the company that issues Moneo, has provided the following quote (my translation):

Students will received a mobile phone equipped with the Moneo function. A secure element is embedded without being integrated in the SIM card.

The pilot is then labeled as “multi-operator“, because the students don’t have to change mobile operator. On the other hand, the pilot is “single-bank”, and also “mono-terminal” (a Nokia 6131 NFC). It’s funny that the operators are not quoted on this one.

The good news is that people are pushing the use of two Java cards on a single phone (the Nokia 6131 NFC integrates a Java Card chip). The bad news is of course that, although this approach is multi-operator, the fact that it is single-bank and mono-terminal does not sound that good. I am a customer at several banks, I like to choose my phones, and I don’t think that I am that unusual.

This news item really reminded me of the conclusions of last spring’s SIM conferences: “NFC is the future, … if we find a business model”. Until then, we technical people will have to keep working, keep saying that the technical solutions are available, and hope that the business guys will find a deal. Only then will the real fun (i.e., the real deployments) begin. With 1, 2, or more Java Card platforms on every phone.