Comments

Alex • October 5, 2016 6:31 AM

So basically, you have an hour-long RSA token attached to your card? It’s interesting that no-one thought of it earlier…

Hugo Botas • October 5, 2016 6:48 AM

What stops somebody from brute forcing cvv? Not to mention that a chance in 999 is not that bad, given enough CC

Venereo • October 5, 2016 7:37 AM

In Portugal any debt card is eligible to a nationwide service called Mbnet: you just generate virtual credit card number per transaction or per seller. You chose maximum values and you can cancel them anytime. Can’t really understand why isn’t this adopted everywhere

Andy • October 5, 2016 7:40 AM

@Venereo Citibank already offers that functionality in US. I use it all the time but it requires a cumbersome login and setup on computer

Badfood • October 5, 2016 7:42 AM

I have to wonder how this works. I’d guess they use a PRNG and store an initial seed at the bank, then they update it every hour or update it whenever a transaction goes through according to how many hours its been since the last transaction. If that’s the case, you have to wonder about the security of the RNG and the storage of the seed. That’s just my theory though.

DaftViking • October 5, 2016 7:56 AM

Is there a fire risk if someone decides to shred one of these cards? Lithium batteries generally don’t deal well with being punctured, and your typical shredder is full of combustible material…

Cley Faye • October 5, 2016 7:58 AM

I wonder about technical issues like out-of-sync clock on the card.

Whatever they use to renew the code hourly, if the desync gets too big over time it won’t work. Maybe they measured the clock offset over time and allow older/newer code for a bigger time window or use extra precise timer. When we use similar software auth. token on things like smartphone we can rely on the clock staying updated, but not on a smartcard.

It’d be interesting to know how this affect the security of the whole thing.

Scott • October 5, 2016 8:38 AM

@DB @Cley Faye
I expect there will be a few seconds of overlap where two CVVs would work. If the drift plus network delay is larger, I’d guess that the transaction would could back denied, just as if you had mistyped something, and you’d succeed when you try again. The verification computer could also use transactions like these to determine the card’s clock drift.

Clive Robinson • October 5, 2016 8:59 AM

Now the first question that springs to my mind is “sequence”…

A thousand hours is aprox 42days so in the three years its going to go full range around over 26 times.

Now three questions arise,

1, Is it the same sequence 26 times?

2, Whatever the sequence length is it actually unique to each card?

3 Is the sequence tied to the card / account number in some way that could be determined?

I would hope for “No, Yes and No” but who knows…

A furtther question arises which is just how strong is that LVD after all the ABA card formate does have thickness limitations.

Ewan Marshall • October 5, 2016 9:04 AM

One big problem, since when are CVV’s actually required for credit/debit card transactions? Last I checked CVVs are store choice and are incentivised by the bank giving the store a lower fee rate on chargebacks, but as they are not allowed to be stored (terms of PCI-DSS), they can not be used for recurring payments or systems like amazon one click purchasing and are therefore not required for a transaction.

Scott • October 5, 2016 9:54 AM

@Clive Robinson
Until Oberthur releases their source code we can’t know. It would be so easy to implement a known cryptographic PRNG, securely started with a random seed during manufacturing, and publish the details, but I’ll bet they won’t until the first paper showing a break.

Guillaume • October 5, 2016 10:58 AM

@Ewan Marshall

I have never seen an online transaction that doesn’t ask complete card info, including CVV (Frenchman here). I’m not even sure french banks give the option of not asking for it.
But then, our culture regarding credit cards (well, we call them so but they’re actually debit cards to you) is quite different from the US…

SB • October 5, 2016 11:07 AM

I’ve never understood why one can pay with a (non secret) card number – without providing a handwritten signature or using a PIN – while one cannot (AFAIK) pay by giving only a check number or an account number.

David Leppik • October 5, 2016 11:37 AM

@Clive:

I certainly should hope they don’t repeat; it would actually be harder for them to repeat than to not repeat, considering that the textbook insecure pseudorandom number generator* has a much higher period than that. In fact, with only 3 digits, there may be enough entropy to get away with an insecure PRNG.

Smart cards (even Java-based ones) have been around since the 1990s, and if it has enough CPU power and memory to do anything, it has enough to use a real (possibly overkill) secure PRNG.

*Linear congruential PRNG, see Donald Knuth, The Art of Computer Programming, Volume 2, Section 3.2.1. And yes, I just copied that reference out of Java’s documentation, which has included that reference for about 20 years. In the old days they included the source code in the documentation to encourage compatible implementations. Java uses a 48-bit seed, providing 32 pseudorandom bits; the remaining 16 bits are there to keep it from being obvious that it’s essentially going through a list of all possible seeds in a weird order.

Shachar • October 5, 2016 1:09 PM

Just one week after the post about making security systems accessible….

So how am I supposed to give my credit card to recurring payment sites/ebay/Amazon one click?

Shachar

Steve • October 5, 2016 2:00 PM

Great. A credit card with a lithium battery in it.

That means I can’t just dispose of the card by feeding it to the shredder.

One wonders how one can dispose of an expired car both securely and without polluting the environment even more than we already do.

JasonR • October 5, 2016 2:59 PM

I personally prefer BankAmerica’s ShopSafe (MBNA originally implemented it, before BofA purchased them): Online generated temporary credit card number + CVV that is tied to your real account, but lets you set a maximum purchase amount and expiration date (minimum of 2 months). I use this exclusively for online purchases and “subscriptions.” I believe CitiBank or CapitalOne has a feature like this as well.

I used it just yesterday to sign up for a phone app that wanted it for a annual “subscription.” I figured I would try it out (only $10/year), and if I found it useful, I would renew it in a year with another temporary credit card. If I didn’t find it useful, it would fail to renew as the CC would be expired, and nothing more for me to do (other than uninstall the phone app, if I hadn’t already done so).

So, it is both a security feature for theft and a “scam” feature. By “scam” I mean things that automatically renew in the fine print without asking you again (because, it was in the fine print). It has saved me a number of hassles over the users.

No brick unshat • October 5, 2016 3:51 PM

OT The blind squirrels find a nut: FBI bags an insider who is appropriately contemptuous of his NSA COTR but not quite clever enough. This is apt to happen as profit recapture and the drive for scale impair contractors’ (in this case, Booz, Allen’s) recruiting standards.

https://assets.documentcloud.org/documents/3123427/Harold-Martin-NSA.pdf

As NSA is exposed as a bunch of murderous military dipshits fapping over your pubescent daughters’ selfies, human rights defenders naturally proliferate. And associate. Degenerate states rot from within with the help of the outside world.

Clive Robinson • October 5, 2016 4:16 PM

@ Scott,

but I’ll bet they won’t until the first paper showing a break.

Yes I might have a side bet on that posability to 😉

@ David Leppik,

<

blockquote>Smart cards (even Java-based ones) have been around since the 1990s, and if it has enough CPU power and memory to do anything, it has enough to use a real (possibly overkill) secure PRNG.

Whilst that is true, you forgot the fact that they are not “electricaly power” limited. Such cards get the power they need from the smart card reader.

This on the otherhand has to be continuously powered for the LCD, RTC and the leakage current of a quiescent CPU, for three years on a very small battery.

As a rough rule of thumb when it comes to battery powered you look to save every CPU cycle you can, be it full speed or standby speed. Full blown secure crypto algorithms are generaly CPU cycle hungry.

It’s funny you should mention Knuth, I’ve been looking over the past few days to get the complete set for my son, and the fourth volumes for my own set. It turns out that in the UK currently only volume 1 and one of Volume 4 are available in book shops, unless… You want to pay through the nose for a special presentation set for volumes 2 and 3…

Yes I buy through book shops for a couple of reasons. The first is I view them as a social good and thus am happy to pay the premium. Secondly Amazon in the UK could apparently not find a delivery company that could find my house… But for some reason they would not use the Royal Mail that can find my house and do deliver even though they had the option on their Web site. Also Amazon had a price premium of their own in the UK on the sort of books I want compared to their US pricing so, they were actually not a good deal at the time. And for large corporates I have a “one strike and you are out” rule when it comes to the sort of level mess up they made.

Northern Realist • October 5, 2016 5:53 PM

Interesting, but would be better if they could use a longer and variable length CVV code – would make it much more secure…

Ewan Marshall • October 5, 2016 7:55 PM

@Guillaume

Look at UK or US amazon where they operate one click, and if you go through far enough to payment information, you’ll notice CVV is not asked for in the form. Same goes for subscription services that need to do recurring payments like netflix. If they do ask for the CVV for a recurring transaction, they are not allowed to store it by terms of PCI-DSS so can only use it for the first transaction at most.

@Shachar
As I have already noted, CVV is not required for card transactions anyway, and PCI-DSS forbids saving the CVV currently, so such services only use it on the first transaction or not at all. Merchant using CVV means they get a better rate on charge back fees for that transaction than one where CVV wasn’t checked but it can not be used in all circumstances.

Stan Smith • October 5, 2016 10:15 PM

Iterations of smart functionality beyond the chip have been around for a while (e.g. Visa Codesure). Good timing now with fraud trends for card-not-present. Definitely more feasible than portable chip readers, and rides rails of existing data fields merchants send in auth request message today. Fraud will need to be much faster, similar trend happing with ARQC pre-play attacks (narrow window to exploit until customer tries next transaction online)

Thoth • October 6, 2016 6:30 AM

Q: What type of battery is used ?
A: Thin film battery.

Q: Where is the RNG ?
A: It uses the same RNG as the smart card controller. The display controller would poll or receive data from the samrt card controller and dCVV generation executes inside and relies on the keys stored in the smart card controller. Below are links to patents describing the invention. Smart card RNGs are rated according to AIS.31 standard “TRNG” but as many of you can debate endlessly about the strength of the RNG, the one fact is you have no resources to “write your own RNG” in the smart card. Too small to do so. So, just live with it I guess…. until you have invented some way to make a secure RNG on a smart card.

Q: Can the numbers be extended beyond 3 digits ?
A: Technically yes but practically no. Reason ? It’s a standard that’s in place so every must follow standards whether they like it or not. If you want to know more, go and dig up EMV and PCI standards and don’t skip pages. That’s how difficult it is to be a security engineer where on one hand you know the algorithm is crap but on the other hand you must sell a product that works as the standards say. You can either choose to spill your own rice bowl like what @Clive Robinson did once or you can live with it.

Oh, and not to forget, if you try to debate with those people on the board or with power, you would definitely lose be slammed with the door in the face until they feel their profit margin is in danger.

Q: Can the dCVV be made to expire faster (say 20 minutes) ?
A: Technically yes but practically no again. Reason ? Standards. As a security engineer, you have to learn to read the standards and follow the books and design the products because you are not the “security architect” (people with power, cash and influence). You are just trying to scrap some cash for a living.

Q: I want to shred my dCVV enabled cards but they have a battery in it. What should I do ?
A: I have published online with an image of how a smart card chip looks like and I have already described how to destroy it. Search for the link using the website’s search bar. So you want to destroy the PAN number, name, other details … you can technically shred it as some of these cards have dotted lines for you to card accordingly but what I would recommend is to take your time to peel the layers of the card skin to be more thorough.

Q: Why are the dCVV technology not pushed out after already existing for so many years ?
A: Ask the EMV and PCI standards. The banks take a very long time to upgrade. Some of the systems are still sitting on old IBM Main Frame (Z80 for some of my customers) and they are still using single key DES ciphers (just to mind you) and running good old Cobol. Have you ever imagined how much you have to change by simply changing a single technology ? The merchant’s payment terminals and POS systems, the clearing house terminals, the backends … the HSMs … you have a ton of things to move.

Everything is easier said than done until you really tried doing them. There are a lot of factors involved just to keep it short and simple. Another consideration the payment industry have to take into consideration is the end users. Try explaining to a grandma about the upgrade of CVV to dCVV and I think she will simply tell you all she wanted was cash withdrawal from the ATM and nothing more. Why would she go her way out to upgrade her card ?

Most consumers don’t care a thing about security anyway and when the bank pushes a new scheme (probably less than half-decent in security due to all the lag time) nobody really bothers. If the customers don’t care, the banks wouldn’t be all too interested to jump into such projects in the first place.

Q: Security of 3 digit dCVV that changes every hour is too weak.
A: Yes it is weak but do keep in mind the payment industry sets goals and objective and the dCVV is to remove the low hanging fruits of a static CVV and they got what they wanted. Theyt could have aimed abit higher and made it more robust but as I said previously, no one cared about the project and so it fell into dis-use for a long time. Usability is also an issue. The higher the security, the less likely the usability is and the less take-up rate by end users. You can blame the payment industry for trying to push the blame on the customer’s side but most of the customers don’t care about their own security anyway. It’s after all a self-destructive negative cycle that will never end because both sides keeps blaming each other and who wants to step up to the plate and offer your assistance ?

The payment industries have rolled out all sorts of secure tokens and initiatives including secure keyfob calculators and so on but if you are the end user, would you prefer to carry a bunch of thin pieces of plastic or carry bulky keyfobs one for each bank or service ? There is a definite trade-off between usability and security and the payment industry have to make a decision. So far, most customers do not care and only a very small faction are security cautious which are raising the issue. The noise is still not loud enough until it hits a critical mass to create change.

Q: What should I do now ?
A: Minimize online purchases and use “buffer” accounts to conduct online purchases. Set correct limits on your cards and always check your bills. If you are more security cautious, use a hardened PC. There is very little you can do except for those I described for the common people.

Links:
– https://en.wikipedia.org/wiki/Thin_film_lithium-ion_battery
– https://www.google.com/patents/US20120153028
– https://www.google.com/patents/US8387866
– http://www.smartcardalliance.org/secure/events/20160404/CORAL-SEA-1-2_WED_315_DUBOIS_NIDS-SCA-FinTech-Final.pdf
– http://paymentcardtools.com/visa-dynamic-cvv

Clive Robinson • October 6, 2016 9:58 AM

Further to Thoth’s points above, it is probably worth looking at the history of the “Secure Electronic Transaction” (SET) protocol[1].

It was quite a mammoth effort to come up with a secure protocol. You can find the original documentation (several thousand pages) and work your way through it. There are even a couple of books about it.

Back in 2000 I had to look into it and why it failed.

There were many reasons given buy various PR types but when you cut through that cr4p it turns out that the real reason was it was very unpopular with merchants and their customers.

From the card holders position it was actually worse than ordinary credit cards due to it removing the deniability of purchase they had with old CC’s…

And the “customer” is always right…

The simple fact is back in the last century card holders most certainly did not want security that bound them.

Since then the payment card industry has adopted a more softly softly aproach to security that externalises their risk. And the banks care not how much security the card holders have just their ability to take transaction charges without having to swallow the cost of fraud…

That’s the short and long of it, you the card holder get stuck with the cost of fraud where ever and when ever the Payment Card Industry and the Banks can.

Just to make it clear, the transaction fees on fraudulant transactions is immense, they do not want to give that up, thus they will fight every attempt where they can to cut into their bottom line. The real question about these security initiatives is who actually pay for them, you can be certain it’s neither the payments industry or the banks.

Interestingly a number of merchants are trying to sue the industry for the costs they are having to take a hit on due to these initiatives. The payment industry has faught hard to get the case dropped but the judge decided to let it proceed as there is sufficient merit. The fun will realy start if the merchants get to make it a class action, that realy will hit the payment industries bottom line…

[1] https://en.m.wikipedia.org/wiki/Secure_Electronic_Transaction

ab praeceptis • October 6, 2016 10:07 AM

Good and knowledgable comment, @Thoth.

As Thoth (painfully but correctly) explains, as soon as any matter touches banks and state agencies (and insurances, …) it gets brutally slow and tenacious.

So, when looking at this case, one must understand the correct question – which was not “How to create some kind of secure credit card?” but rather “how to make the CC system somewhat more secure without any significant changes?”

Whatever solution one comes up with must most importantly not change the infrastructure or the processes outside of the banking/CC processing centers.
Webshops must work like usual, a gazillion of small terminals all over the world must continue to work with so much as a firmware update, in short, *damn everything” (outside a few central processing centers) must not change whatsoever.

That doesn’t leave much room. The CVV is one of the extremely few parameters one could possibly play (if not, indeed, the only one).

But it’s better than one might think at a first look. The fact, for instance, that CVVs are only 3 digits (which per se looks ridiculous in terms of security) is not really a problem. Reason: Central processing. In other words, the central processing system would notive attempts to try all 3-digit numbers, unless one would do it v e r y … slowly. Which leads to a really nice benefit of the french system: An attacker is limited to 1 hour within which he must test all 3-digits numbers; that would leave him with ca. 3,5 seconds per attempt and that would be easily noticed by the central system. (Note: This is mathematically not perfectly correct but easily good enough for practical purposes).

As for the PRNG I wouldn’t be worried. Any halfway decent one will do the job well enough because a) it’s output will not be used directly but rather be mangled with some crypto (e.g. from transactions).
I assume that those cards create a small number of bytes for that purpose at each transaction. As those same data are available at the central processing site the PRNG mangling of a card are known or, in other words, the central site knows what CVS to expect at any point in time.
As an attacker is very unlikely to have those same data available, he wouldn’t know the state of the PRNG even if he knew the algorithm, because that mechanism would reseed the PRNG at each transaction.

I don’t know that particular company but them being french I see reason to assume that the math behind their system is flawless. Finally, again, the question wasn’t how to create a secure CC but how to make it more secure. And that IMO has been successfully done.

Ergo Sum • October 6, 2016 10:25 AM

@JasonR…

I like the Bank of America Shopsafe feature as well and been using it since MBNA rolled it out. I’ve never had a any problems with Shopsafe numbers and do use it for reoccurring payments as well. It does remind me of the free Java based credit card generators from the hey-days of the web, or .com era. Back in those days, when the CC numbers weren’t even verified with online purchases…

Tom • October 6, 2016 1:05 PM

Cahoot in the UK used to offer a totally digital card, with a changing full number, so it really was single use. Got canned for no good reason.

Captain Ned • October 6, 2016 5:44 PM

I wonder if the chip contacts could be used to give a few joules to the battery every time it’s used in a chip-enabled terminal??

Thoth • October 6, 2016 6:16 PM

Chip reader circuitry would only touch the ISO7816 contact chip and that’s about it. The thin film battery cannot be recharged if that’s what you are asking. It’s a use and dispose card solution.

TJ • October 6, 2016 7:59 PM

okay..

CVV is a field on almost every online cart form for all nationality of online stores.. It’s also used for a lot of over-the phone transactions like towing companies who don’t use mobile POSi. It all depends on the processing service they use; some out-right refuse to do a transaction without a CVV and there is nothing Joe Six-Pack’s Towing can do about it..

EMV actually works if you get rid of all the vulnerable “modes” in the POSi. After decades of research there is really no attack on the actual isolation or crypto. Unless of course anyone who has been in ITsec longer than ten-years still believes in “secure coding practices”; at least where the code actually does stuff on wide attack surfaces and is at least thousands of bytes of PE or ELF. The guy who is going to find a use-after-free or heap overflow in your software sure hopes you do.. Why do you think companies like Google and Microsoft evolved to using sandboxing in !!EVERYTHING!!? It’s not simply because they aren’t as skilled as YOU!

trsm.mckay • October 6, 2016 9:24 PM

@Thoth — Nice post. Not too surprised if there were still some single-DES POS terminals somewhere in the world, but hopefully not too many. I believe we got rid of most of them in the USA by mid-2000’s. Mainly by the financial entities raising the transaction fees for single-DES terminals, similar to the approach the USA is going through with EMV transition. It was a long run, from the early 90’s when the standards groups tried to get them to change, and even with an asymmetric kicker (slightly more expensive HW to support PKI key management, but a large savings by avoiding the need for secure symmetric key injection centers), it was a very slow and expensive process.

@Clive — SET had other issues too. I have always thought the biggest strike against it was the creation of a new entity (clearinghouse) that did not correspond to any of the existing players; and without a clear financial benefit for the new entity (thus none of the existing entities wanted to take on the new role). It also suffered from academic arrogance for actual implementation. Ideally a HSM API only permits keys to be used for very specific actions, and protects them against misuse like oracle attacks. Forget the details now, but we had to expose a key more than we preferred in order to make a practical API. The academics refused to make a minor change to the protocol, claiming specialized hardware would solve the problem (I was working for one of the top 2 financial HSM vendors at the time, and suffice to say they were mistaken).

But those are quibbles, I agree with your primary point about shifting of liability for fraud being the driver. In my semi-naive 1990’s view, the UK banks seemed to be very anti-consumer compared to the US Banks. Little did I know what was coming down the line, the current Wells Fargo scandal of opening unneeded accounts to max out fees is just the latest from when US banks (and others like Enron, Telcos) decided that it was OK to ignore ethics and repeat business in order to milk their customer base for maximal amounts of money.

Thoth • October 6, 2016 11:24 PM

@trsm.mckay

“The academics refused to make a minor change to the protocol, claiming specialized hardware would solve the problem (I was working for one of the top 2 financial HSM vendors at the time, and suffice to say they were mistaken).”

Sadly, it’s the armchair academics vs. the field engineers. It is always very difficult to bring bith sides into agreement to get a security protocol up and this is also very pronounced when you have a huge organisation and house both of them on your payrolls. The cryptographers would throw a bunch of formulaes and the engineers would try and tinker and fit their formulaes to the hardware or software.

A very good example is smart cards where you have constrained surfaces to work with. AES-GCM is usually recommended if you can afford but the fact most smart cards are still using ECB or CBC only modes for their AES and DES engine is down to resource and silicon area. There is only that much transistor room you can fit into a tiny smart card. The armchair idealist would rant about GCM being superior while the engineer trying to write GCM in JavaCard to fit into a smart card applet would have a hell of a time.

As I have ranted in the past, many cryptography protocols work so poorly when done on smart cards with the huge resource usage since their cryptographer authors only took the point of view of a standard X86 or 64 bit CPU and rarely the view of a 8/16 bit smart card.

Reality isn’t what it seems to be and cryotography protocols and algorithms have to be designed to be more close to practical world for most of them.

Drone • October 7, 2016 5:09 AM

“There’s a new French credit card where the CVV code changes every hour.”

…until the battery dies.

Once upon a time I had a temporal key dongle with a couple of buttons and a tiny LCD display that did a similar function. My bank at the time insisted on using it. After two years the battery died. The user isn’t allowed to service the battery. Once the battery dies, the dongle is bricked as far as the user is concerned. While the dongle still functions, if the user attempts to open the device or tamper with the battery, the thing bricks itself.

I had to personally take the dongle to a specific bank branch located far away, wait in line, show I.D., sign a paper, turn over the dongle, then wait a week or two until they sent me a new dongle (or the same dongle with a new battery) via the highly unreliable government-run mail system. During that waiting period, no electronic bank transactions can be performed.

If the dongle is lost in the mail the whole process must be repeated, but ONLY after the user files a report with the police, and pays for the new dongle.

Needless to say, I stopped using that bank. The Bank’s name you ask? Bank Central Asia (BCA) in Indonesia.

These security devices are a theoretically a great idea – but not so much in practice.

Happy Customer • October 7, 2016 3:03 PM

thanks @Thoth, ab, Clive,

slightly OT: Talking about battery life, not for the this MotionCode card, but for the EMV smartcard reader by Todos
/like here, http://www.tatrabanka.sk/en/personal-banking/account-and-payments/electronic-banking/card-reader.html#about-the-reader
I can tell that after MANY (more than 8 for sure) years of usage, almost daily, sometimes couple times, the battery in there still works.

There exists also smaller keychain reader (unfortunately not displayed/not found at webpage), no first-hand “lifetime” experience with that one.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.