The lowest hanging card

The latest news on six second card hacking is very entertaining, and frankly, not reassuring. This thing is just as simple that it is stupid. The CVV2/CVC2 is a secret number computed by banks using a secret key, so they are validated by the issuing bank. Apparently, most (all?) of them have chosen not to count failed validation attempts from different sources. So, once you obtain raw card data (with no CVV2), you only need one attempt on 1000 sites to find the 3-digit value (it gets worse, read a few articles on this).

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.

Resilience for Connected Objects

Attacks occur, especially on IoT. While it is very hard to avoid an attack altogether, we can minimize its consequences. The first factor to consider is the impact of an attack; there are many ways to analyze such impact, for instance from a financial or technical point of view. In a very simple analysis, we […]

IoT Security as Externality: Cluelessness, Denial, and more

Not my problem. That’s the 3-word definition of an externality: something that you don’t need to deal with, because the adverse consequences are not affecting you directly. This has been an issue for cybersecurity forever (Schneier, 2007), and it is widely known that the issue is particularly pressing with IoT (Schneier again, 2016). I have […]

Logical Attacks in the Java Card security landscape

Logical attacks on Java Card have been known for a long time, and they have also been a focus of a lot of academic research, which still continues today. Earlier this week at Cardis 2016, there have been two presentations on logical attacks. I will not discuss the details of the attacks that are being […]

SMS-based 2-factor: Good or Bad?

Wired published recently an article about how SMS-based 2-factor authentication is not good. This article is making a buzz, and an article appeared on that topic in Fortune. The basis for these articles is that SMS-based authentication is not associated to something you have (your phone), but with something you are loosely associated to (your […]

Java Card software attacks

There have been two papers at SSTIC’16 that outline the limits of bytecode verification in the context of Java Card. One of the papers, by Guillaume Bouffard and Julien Lancia, describes a bug found in Oracle’s bytecode verifier through fuzzing (yes, it’s been fixed). The second one, by Jean Dubreuil, outlines several logical and combined […]

Beyond Java Card

When Java Card was created, the market for smart cards was quite simple: chip vendors would design specific chips, chip vendors would develop an operating system for the chips and produce cards embedding the chip. Since then, this market has become much more complicated. For traditional payment and ID, changes are minimal, as card vendors […]

Java Card LinkedIn stats

I was looking for updated statistics on Java Card, so I turned to LinkedIn to look at the Java Card skill. The information available is declining a bit (for instance, there is no trend or relationship to age any more, or at least I couldn’t find it). Yet, it reveals interesting information. Over 3000 people […]

Inside Java Card: From APDUs to CAP File and Interoperability

As promised in the previous post, here are a few Java Card stories. Over the almost 20 years of Java Card history, many design decisions have been taken on the product: some successful, some less successful. Here are a few stories of these discussions/decisions. API vs. APDU Before Java Card, a smart card specification consisted […]

Java Card, a farewell

My Oracle story has ended, and with it my Java Card story, at least for now. I started working on the technology in February 1997, and I have never been very far from the technology for almost 20 years. However, Java Card is not in the scope of my next job, as I will focus […]