On-Card Displays

This is impressive: a display that works on a flexible credit card.

One of the major security problems with smart cards is that they don’t have their own I/O. That is, you have to trust whatever card reader/writer you stick the card in to faithfully send what you type into the card, and display whatever the card spits back out. Way back in 1999, Adam Shostack and I wrote a paper about this general class of security problem.

Think WYSIWTCS: What You See Is What The Card Says. That’s what an on-card display does.

No, it doesn’t protect against tampering with the card. That’s part of a completely different set of threats.

Tags: , , ,

Posted on September 19, 2006 at 2:18 PM • 40 Comments

Comments

Chris • September 19, 2006 2:50 PM

Yep.

Saw this reported on in July. You can also get ’em with built in lights and magnifiers. Sounds, too — “Cha-Ching!” :^)

Israel Torres • September 19, 2006 2:52 PM

Ok. Really… Who will be the early adopters to “pimp” out their cards with multicolored LEDs that dance around while the chip does it processing (all the while masking itself from revealing the internal workings).

Israel Torres
Argggg (my pirate usage for the day)

Jason • September 19, 2006 3:19 PM

I’ve been wondering about this:

Does a security device that has its own UI still count as two-phase authentication?

An interactive smart card or even a crypto-enabled PDA don’t seem to suffer from most of the attacks that have been used successfully (and repeatedly) against 2-phase systems in recent years.

Not Anonymous • September 19, 2006 3:51 PM

This is really great news. I would happily pay a modest fee to have my bank card upgraded to use this technology.
A few years ago, the UK MoD adopted “RLI Remote Access” using approved VPN software in conjunction with a keyfob device that generates a keynumber every few minutes. Using this system, normal phone lines can be used to connect to MoD Restricted networks (through BT telephone exchange).
http://www.publicservice.co.uk/pdf/pfi/winter2001/p28.pdf
I know from experience how fussy the MoD are about connecting the RLI (their private internal network) to the Internet so if the banks implement this correctly, it will be a really big step forward for consumer security.

The only downside I can see is the part of the document that says “The display card will potentially be able to display all sorts of information to its users;”. I really think it is important to concentrate on getting the basic security engineering correct. The more gimmicks and eye candy they build in, the more complex it becomes which makes the chances of the card’s security being defeated higher.

Carmudgeon • September 19, 2006 4:18 PM

The bigest single factor to stand in the way of the adoption of technology like this will still be cost. Banks are still too cheap to give you the security you deserve.

I have watched this for the past ten years as companies have tried to sell smart card technology in the US. When a smart card costs $5 a piece (I’m sure less by now, but even so) and a mag stripe card costs $.75, the banks are going to continue to field mag stripe cards.

Kerry • September 19, 2006 4:29 PM

An important thing about this is that it can display transaction history, which IMHO is a more important function than the much over-hyped 2-factor authentication.

Imagine an LCD display-card with a stored value of $100. You can use it to pay for things at a shop over the counter, or insert it into a card reader on a PC to buy things over the Internet. As you pay, the amount stored is deducted and a record of the transaction is made for you to check how much was deducted and when (maybe also recording by whom). With authentication and authorisation all the way from the merchant to the physical card its harder for anyone to remove stored value from the card. If your PC is infected with malware which tries to remove money from the card, it will either fail to authenticate/authorise or if that mechanism is defeated then the user will immediately be aware of the deduction (it will show on the card’s display) and can report it to their bank.

The display adds an extra loop of verification which involves the actual human holding the card – they can immediately see and check transactions on the display, whereas at the moment they have to put all of their trust in the incomprehendable computers which perform the authentication and authorisation of transactions on their behalf.

Realist • September 19, 2006 5:38 PM

The card fails at 2-factor if it is lost or stolen. So we’ll likely see an increase in card thefts — although this will somewhat slow the identity thefts as theives will have tio collect one card at a time now…

And I wonder how long it will take before someone “cracks” the display code?

Filias Cupio • September 19, 2006 5:58 PM

I can just see how this will likely be implemented:

Plug card into computer. Visit internet bank site. Make a transaction. PIN number appears on the card, you type in the PIN to authenticate the transaction. Bank boasts about how secure they are.

But if your computer is compromised, the transaction you just authenticated may not be the one you asked for. Let’s hope (or act to ensure) they display the transaction details on the card.

(I still like the confirmation-by-text-message system. It isn’t as secure as a well-designed smart-card-with-display system, but for most people doesn’t require any additional hardware. And it is more secure than a poorly designed smart-card-with-display.)

Kerry • September 19, 2006 6:15 PM

@Filias

A better system would be for the card to display the destination account and the $amount of the transfer for the user to check, then display a one-time PIN for the transaction.

The problem with text-messaging systems is that you can’t really trust the cellular network, or the phone, or just about anything between you and the bank. A tamper-evident card which has enough smarts to form a secure association between itself and the bank at the far end, and can assure the user through its display that it has a secure association, is much more trustworthy.

JohnS • September 19, 2006 6:53 PM

I’m obviously behind the curve here – could someone explain, or point me to an on-line explanation, of how an average credit card user would use such a thing?

Not Anonymous • September 19, 2006 7:28 PM

@JohnS

The card still has a traditional credit card number that has to be swiped or entered in SHTTP web page when presented either in person or on a secured web page.
There is a clock built into the card that keeps track of time reasonably accurately (drift is less than 1 minute per year).
There is a number on the LCD display based upon a hash of the time (this is the tricky bit).
The merchant must have access to the services of a supplier with time synchronised hardware that can validate the hashed time presented by the card in real time.
Basically, the credit card number, hashed time and PIN number or special extra digits on the back of the card (for properly verified web transactions) must match against the combination of verifiable information held by the credit card companies/speciliased security providers.
If all the parts don’t line up, then the transaction is not valid.

RLI Restricted Access (see my previous post) builds in the possibility that the user might have to wait a minute or two to try again if the key fob time and telephone exchange time have drifted a bit. This could be problematic in a commercial environment where there is pressure to keep the customer queues moving. Allowing a degree of tolerace e.g. checking against time hashes +/- 2 minutes might be a solution here.

At the moment, there is no standard mechanism for the consumer to supply the hashed time key as well as their credit card PIN when presenting the card in person. This is perhaps the most challenging problem.

Despite the complexity, I think this is a good idea, if implemented well – even if only for online web transactions, it could really help cut down card fraud.

Davi Ottenheimer • September 19, 2006 8:34 PM

Nice. This could go for any unique consumer numbering system really.

Perhaps instead of a VIN, for example, your car would have a display of a number that only the manufacturer could verify as authentic.

The downside, as you mention, is how prone to failure this technology can be. At least a pocket full of Franklins doesn’t run out of batteries or lose a contact, at least not yet.

DoubtingThomas • September 20, 2006 12:12 AM

PKI and smart cards were gong to save us. RFID was gong to save us. EMV was going to fix credit card fraud.

Now, a thin card display that is really too small to read and manipulate is going to save us?

IMHO when Bill Gates smart card enables the world the world will be wired for smart cards and you won’t need or want a local display on the card. Security agruments aside, Microsoft dominates regardless.

This is an expensive, niche technology. My cell phone has a much more usable display. If it about local displays, why aren’t more of these applications available for my phone which I alway carry?

Early adopters beware. This too shall pass…

mejeep • September 20, 2006 1:33 AM

First of all, I remember an ad for flexible LCDs by Polaroid in 1989 (http://userwww.sfsu.edu/~swilson/papers/researchinsp.html). My credit-card sized calculators mostly suffered from broken connectors between the LCD and the rest (PCB or flex-strip).

The ever-changing number sounds like a SecurId type system: a rolling code. Many chip makers already use that for their RKE (Remote Keyless Entry) systems but without a display.

I was a SmartCard advocate but American Express, Visa and MasterCard all abandoned their contact-based SmartCard before the programs could possibly reach the critical mass required for success. Target Stores all had SmartCard readers at their registers but I only learned of their “virtual coupon” program (using the credit card’s SmartChip) when I saw the announcement that the program was being cancelled. I have several AmEx readers (USB, serial port) since they were free during the program and particularly after cancellation. So we /almost/ had Smart Card authentication at home to secure e-commerce.

Even Sun Microsystems seems to be backing off: SmartCard readers were standard equipment in all their SunRay “thin client” X-terminals and PCs, now it’s an available option.

Long ago I remember the headline “smart bombs, dumb soldiers”. Analogously, we’re facing Smart Cards vs. stupid business practices.

Jan Egil Kristiansen • September 20, 2006 3:26 AM

Isn’t the keyboard a weaker link than the display? I have entrusted my PIN to several hundred keyboards.

A keyboard used for my PIN only will show wear on the 3 or 4 digits my PIN contains.

If we could trust our mobile phones, a smart card reader there would be nice. If…

bob • September 20, 2006 7:10 AM

I would be happy to use one of these. But I would not expect to pay more, the savings in fraud reduction (not elimination) should make it pay off for the bank; all it would save me is hassle in unscrewing an identity theft.

rory • September 20, 2006 7:46 AM

mejeep – smart cards certainly do not appear to be going away. for high value banking, they are pretty much de rigueur, and even my new Dell laptop has a built in card reader. Look at Gemplus website for an indication of how successful a market they have. Over time, the trend is for them to be rolled out to lower value clients as well as the existing corporate banking customers.

But I agree with you – it will all come down to the processes and people in the end:-)

rich • September 20, 2006 10:59 AM

@bob
You said “the savings in fraud reduction (not elimination) should make it pay off for the bank.”

I used to think that. Then I saw the numbers for a large US bank (100 million customers). It cost two or three times as much to provide two-factor authentication than they lost in online fraud. Also, their fraud losses in walk-ins at branches dwarfed online fraud, and the walk-in fraud was aided by fraudulent government-issued IDs.

cmills • September 21, 2006 5:56 AM

@kerry:

“A better system would be for the card to display the destination account and the $amount of the transfer for the user to check, then display a one-time PIN for the transaction.”

The basic concept of this token is that it generates these codes autonimously, that is without having to communicate with another device.

As far as the cost of this schnazzy looking device, if it’s $20 or less, I’d gladly pay it for the extra security measure. Transactions would still not be secure, but it would present another hurdle that would effectively mitigate the risk of some script kiddie small timer who buys some card numbers on the black market.

David • September 21, 2006 6:18 AM

erm
I subscribe to the theory that my SSN is mine, the Credit Card number is the banks.
I am not unwilling to help them by taking reasonable care of the card, but I am absolutly unwilling to assume any additional fiscal responsibility for compromises to the bank’s or a merchant’s security.
I see this as a technology which when compromised will place the blame (and responsibility) back on the consumer.

cmills • September 21, 2006 4:44 PM

@david

point taken, but in this day and age, companies now realize that no security measure is infallible, and they can no longer automatically shift the blame to the customer. As for the cost, it will either be absorbed by the company as a cost of doing business, or it will be universally accepted as a service fee. Identity theft is enough of a hassle that it is in my interest to protect my credit card information.

Ilya • September 21, 2006 10:29 PM

“One of the major security problems with smart cards is that they don’t have their own I/O”

Smart cards with USB form factor address this issue. There are quite few of such combines a card, a reader and a flash in a single USB token. Although at the end USB traffic is not so trustfull either.

Clive Robinson • September 22, 2006 6:38 AM

A question, why should I trust the display simply because it’s on the card and not in the base unit?

How do I know it is actually know the display is working via a secure protocol through the chip on the card and it’s not simply the card piping the data through from the card reader writer base unit.

The problem is not one of displays on the card but establishing a trusted path.

In reality I can no more trust the display on the card than I can the display on the unit I plug the card into.

At the end of the day there are very very few ways to establish and verifty a trusted path. In practice the only one that gets within sniffing distance with current cost effective technology is to use two entirly seperate channels between the source and the destination entities. Both entities perform a mutual authentication on both paths and also by crossing the paths (where the authentication is such it can be done by a human brain which is the problem bit ;).

Frank Cusack • September 22, 2006 2:21 PM

Highly flawed article. The errors make it evident that this is a
marketing piece, not a news or analysis piece (in case you were
confused :-)).

With this baby you make them two-factor style, fusing something you
know (your card number), with something you definitely have in your
possession (your card).

No, that would still be one-factor. If you have the card, you have
the number as well. It’s just a little better than the system that
exists today, with CVV codes. Thieves with just the card #’s
(probably stolen from some online db with poor security processes)
can’t use them because they don’t have the CVV code, in theory. In
practice, in violation of PCI requirements, some vendors (the same
ones with weak security processes which allow card #’s to be stolen)
store the CVV. This was just (Aug 29, 2006) highlighted as the
number one security vulnerability by VISA. So an OTP on a consumer
card serves as a dynamic CVV. In either case (static or dynamic CVV),
authentication is one-factor, not two-factor. But the single factor
is “changed” from something you know to something you have. “Changed”
is in quotes because the CVV is already supposed to enforce something
you have, but doesn’t succeed in all cases. The dynamic CVV ensures
that the factor is something you have.

Financial applications are, arguably, the hottest and most promising
markets for display technology cards, thanks to nearly one-year-old
Federal Financial Institutions Examination Council (FFIEC) guidelines,
recommending that institutions to bear the burden of incorporating
two-factor authentication methodologies into their offerings to
enhance security.

So now the article promotes the FFIEC guidance (effectively a
requirement) for two-factor authentication, also a misrepresentation.
The FFIEC guidance is to implement reasonable controls, not necessarily
two-factor authentication. The FFIEC has recently (Aug 15, 2006)
issued a clarification explicitly pointing out that multifactor
authentication is not a requirement.

My conclusion is that this one-factor/two-factor confusion and the
FFIEC misrepresentation is not just a misunderstanding, it is a
dastardly marketing deception!

Why would a cardholder care?

Here’s one reason: in growing digital-transaction real-world scenario,
where more and more purchases are made online, the party on the
other end receives your card number and security code, but theres
no way of knowing that you actually are the one holding the card.
No biggie … until some ID-stealing thief’s trying to purchase a dozen
iPods online using your number.

Sorry, but a cardholder does not care about this (or should not).
The Fair Credit Billing Act limits cardholder liability for fraudulent
transactions to $50. Many issuing banks go further and have no
cardholder liability.

Card issuers should care, and the reason for that should be to
reduce fraud expenses. However, even the current fraud detection
techniques (such as analysis of purchasing patterns), coupled with
punishment, are probably more cost effective than using a display
card. Issuing millions of display cards probably costs more than
it’s worth (the cost of display cards is VERY high compared to
today’s simple credit card). Even if multifactor authentication
is selected as a technique to combat fraud, either the grid card,
or dynamic CVV delivered via SMS seems to be a better choice
(just as effective and MUCH cheaper).

“If you’re a bank in America, you can brand the card, personalize
the card, and add OTP functionality to the card itself. It’s the
logical next step in the evolution of a payment card for secure
online authentication.”

According to Ms. de Rotstein, technology such as Aveso’s allows for
easy integration of electronic displays into high-volume printed
products such as credit cards …

Perhaps, but not as pictured. The picture, an Aveso card, shows
that the battery is in the space where the credit card numbers are
embossed. Banks in America must emboss cards to support offline
transactions, and the battery will not survive embossing. So the
battery would have to stay only in the top half of the card, and
therefore will have to be much smaller. This will significantly
affect the life of an already expensive card, increasing the cost
to the bank even further thanks to more rapid replacement cycles.
An alternative would be to use deposition, but this is also expensive
(compared to embossing), and not as durable.

There is a [big] place for a display card, but a bank card isn’t it.

Frank Cusack • September 22, 2006 2:23 PM

One of the major security problems with smart cards is that they
don’t have their own I/O.

Smartcards do in fact have their own I/O (of course), it is how
they communicate to a reader. Handheld, standalone (not connected
to any computer), and therefore trusted, readers are becoming more
popular and allow smartcards to be used as OTP systems. Yes, it’s
more clunky for the user than the more common use of an online
reader, but the point is that smart cards can already be used today
as independent trusted authentication devices. That’s not to say
that an embedded display on a smart card isn’t useful — for one
thing it’s one less component (the reader) that has to be trusted.
There’s a lot more that could be said here, but let’s leave it at
that for now.

This statement also has an error of implication. The article does
not say anything about a smart card and in fact the displays mentioned
in the article cannot be placed on a smart card, because they do
not meet ISO 7816. My company, TRI-D Systems, is already in
production with the only ISO 7816 compliant display card. We have
other features the competition can’t touch as well. http://www.tri-dsystems.com

What’s not stated on our web page is that we use a flexible LCD
technology, whereas the competition uses different (non-LCD) display
technology. The advantage of LCD is that it’s far easier for us
to integrate into existing chips, in fact we’ve already produced
OEM samples for several large OTP vendors. This is difficult for
the other displays as the vendor has to design new electronics.

Also not stated is that our customers (both OEM and direct end user)
can choose algorithms at will, whereas our competition limits
customers to their proprietary (in some cases) or HOTP algorithms.
Even when using HOTP, our competition is like every other vendor
and keeps source code to themselves … not very trustworthy IMHO.
Not only do we make source code available, customers can run their
own code if they like. This is a big deal when the product being
sold is a trust anchor (if you will) for most everything else.

When not part of a smart card, display cards are “just” a new form
factor for the same old tokens in use today. But we shouldn’t
discount the improvement in convenience, which increases user
acceptance and is a Good Thing. We see the main advantages of our
card as:

  • improved form factor over other tokens
  • integrated prox
  • integrated smart card
  • integrated ID (custom print badging)
  • enroll-on-card match-on-card biometric
  • source code
  • same cost as current hardware tokens

None of those tie the display to the smart card functionality. We
do plan on either using an external [handheld, “trusted”] reader
or embedding tactile buttons on the card for use as PIN and transaction
input to the card, but this is mainly to assist with offline
authentication.

As far as having trusted output from a smart card, I’m not sure
this buys a lot. Would you verify each transaction? Users aren’t
going to do that.

I guess it’s useful to have transaction data (signature input) be
displayed, when using a non-trusted reader. This is useful for
cash transactions, but as I argued in an earlier comment, the cards
are too expensive to be cost effective. hmm … for stored value
cards this might be valuable protection (that consumers would be
willing to pay for), but in the US these aren’t popular.

Are there other good uses of tying the display to the smart card?

Frank Cusack • September 22, 2006 2:24 PM

@Not Anonymous

This is really great news. I would happily pay a modest fee to have
my bank card upgraded to use this technology.

Why? You are already indemnified against loss.

Frank Cusack • September 22, 2006 2:25 PM

@Carmudgeon:

The bigest single factor to stand in the way of the adoption of
technology like this will still be cost. Banks are still too cheap
to give you the security you deserve.

Which is a good thing. Banks should give you the security that is
most cost efficient.

Frank Cusack • September 22, 2006 2:26 PM

@Not Anonymous:

There is a clock built into the card that keeps track of time
reasonably accurately (drift is less than 1 minute per year).

No there isn’t. The cards in the article do not have a clock, they
are event based. No one except my company, TRI-D Systems
(www.tri-dsystems.com), has production capability to build time-based
cards today. For competitive reasons, I won’t go into why that is.

There is a number on the LCD display based upon a hash of the time
(this is the tricky bit).

Actually that part is quite easy.

Frank Cusack • September 22, 2006 2:26 PM

@DoubtingThomas:

This is an expensive, niche technology.

wrt banking yes.

wrt enterprise authentication, you are right, it is expensive —
to produce. But for the customer, it’s actually cheaper than current
solutions even when used solely as an OTP token. But then add in
the very high integration capabilities (id badge, prox, etc., as I
pointed out in an earlier comment) and it is far cheaper and more
user friendly than the current solutions.

It’s certainly not niche.

Flexible Friend • September 22, 2006 4:30 PM

@Frank Cusak

Thanks for feedback. It appears I have mixed up systems.
Just for the record, the time clock element is crucial to RLI Remote Access (RLI RA). In retropect, I skimmed over an important detail.
In RLI RA, the time hash is unique for every clock, except an identical device/system at the BT exchange. This may seem implausible at first glance but I assure you this is so.
When a use logs into RLI RA, the time hash entered into the VPN client (read from the key fob) and the time hash at the BT exchange simply must match. This is what I meant by “tricky” – establishing an infrastructure of real time synchronised clocks.
You may say to yourself “well after a few years it won’t work”. Correct! going from memory, the service has to be bought every few years.
It’s a pity you cannot discuss the issues about accurate clocks in you company’s products but I have seen it done for keyfobs.
Perhaps separating the keyfob from the credit card is actually a security advantage anyway?

Flexible Friend • September 22, 2006 4:41 PM

@Frank Cusak

“Why? You are already indemnified against loss.”

Even if that is true (I thought the first £50 of friaud is lost in UK?), I suspect that the process of dealing with credit card fraud is NOT FUN. Surely the banks will not just say “OK, there’s your money back”. Personally, I’d much rather not be in that situation. Never mind my selfish motives, wouldn’t it be a good thing to just stop credit card fraud?

Frank Cusack • September 23, 2006 1:06 AM

@Flexible Friend:

In RLI RA, the time hash is unique for every clock, except an
identical device/system at the BT exchange. This may seem implausible
at first glance but I assure you this is so.
When a use logs into RLI RA, the time hash entered into the VPN
client (read from the key fob) and the time hash at the BT exchange
simply must match. This is what I meant by “tricky”

That is indeed tricky.

Perhaps separating the keyfob from the credit card is actually a
security advantage anyway?

Good point. That may be true, I’ll have to give it some thought.

Frank Cusack • September 23, 2006 1:21 AM

@Flexible Friend:

£50 of friaud is lost in UK?

That is what the law says in the US also ($50), but visa goes further to $0.
It’s a good way to promote use of credit cards.

Surely the banks will not just say “OK, there’s your money back”.

I had my credit card stolen once a long time ago, maybe 15 years
back? Back when carbon paper was used to make two copies of a
credit card transaction receipt. I didn’t lose the actual card,
but someone apparently stole the carbon from the trash. A fraudulent
charge was made on the same day at the same store. I don’t recall
how I learned about it, but yes it was that easy to get my money back.
I was not liable for $50 even.

This past valentine’s day, I ordered flowers which never arrived (ouch).
My card was still charged. I called the issuing bank to initiate a
chargeback. The only hassle I got was the rep asked if I had contacted
the merchant first. I explained that I had called several times over
several days and each time after navigating through a complicated
telephone automated attendant menu, would either get disconnected
or transferred to a busy signal. Also, I emailed multiple times
and never got a response. The rep refunded the charge right there,
however I did receive notice in the mail later that the charge might
appear again pending merchant dispute. (Later the merchant acknowledged
the chargeback.) Not fraud, but I hope a reasonable real-life example of the
banks not putting too much onus on the consumer for liability.

Ben Aston • September 26, 2006 10:25 AM

Surely the banks will not just say “OK, there’s your money back”.

I had £1500 stolen from my account after my (debit) card was cloned at a modified ATM.

I reported the event to the police, met with my bank manager to confirm what had happened and the money was credited to my account shortly thereafter.

I thought the process was very straightforward considering the amount stolen and the fact that it wasn’t even a credit card.

TaSK • September 27, 2006 2:36 AM

Having both a display and a keyboard on a card is a good idea. In fact, it is even patented. See: http://www.stabell-kulo.net/patent

Notice that the patented design would meet the ISO standard (on the lower part of the card). This is very useful (to say the least). To savour the full text you need to decrypt from Norwegian, but the references should be understandable even without dechipering.

[TaSK@/]

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.