[Dave Birch] Are you the sort of person who will try using your phone to read this QR code?
In all of the time I’ve had a phone with a camera and an application for reading QR codes, which is quite a long time, I’ve probably used the functionality two, or at a maximum three, times. I wondered if this might be because I am old or because I am lazy or because I am insufficiently inquisitive, but actually it’s because I am normal.
If you really wanted to know about a product that you saw in an ad, wouldn’t you rather type its name into Google on your phone and see what comes up? Is it really faster and better to use a QR code that will direct you to part of a marketing campaign rather than getting a broader sweep of information by simply using the browser that you already use all the time on your phone?
Quite. I hadn’t thought about this until I read the article above, but on reflection I can see that it is entirely true. It’s far quicker to put a couple of key words into Google, because my iPhone doesn’t automatically execute a URL fetch when I wave it over a QR code (I have to find and run the app and then mess about lining up the camera) . And while it’s not the point of this post, it is interesting to note that it’s far quicker to use NFC, because if I tap something active with my Samsung NFC handset, then the URL (or whatever) pops up automagically. This is why I, as apparently do many others, tap on NFC things but ignore QR code things.
The firm, which has so far distributed 24,000 tags on street furniture and in public places around Europe, found that only 1% of the people who have interacted with its AdTag platform did so with an NFC phone — but that this 1% of users accounted for 8% of all interactions.
There is, however, a problem with both easy NFC tags and hassle QR tags. This is a problem that has an easy solution using NFC (although no-one uses it) but no current solution, so far as I know, with QR codes. Let me hand over to someone else to explain what this problem is.
As a journalist, I try to remain unbiased. But, as a consultant, I owe it to my clients to be honest. So, I’m telling every one to be leery of QR codes — they’re evil.
Well, I might not go so far as to call them evil, but they certainly have the potential to enable person or persons unknown to act with evil intent. Here’s how…
While waiting for my decaf, a poster caught my attention. It had a QR code. Acting sufficiently cool, I scanned the code, and started to tap the link. I stopped.
Something’s not right
Something about the URL was off. Then I spotted it, the number zero instead of a lower-case O. I knew what that meant right away. Digital bad guys were on the hunt. Setting up malicious websites using domain names that are misspellings (typosquatting) of popular websites is a common ploy. PaypaI.com is a good example. Did you notice the upper-case I instead of a lower-case L?
I took a closer look at the poster. Someone placed a QR-code printed sticker right on top of the real QR code. Sneaky.
This problem isn’t only about QR codes, but about NFC tags as well. Suppose I see a poster at the train station advertising some terrific new bank account at, for sake of example, Citibank. I tap the advert and find myself at a Citibank website to help people to switch accounts or apply for a credit card. I type in all of my bank details, personal information and so on. But it isn’t a Citibank website: it’s a website run by sneaky Eastern European financial fraudsters who have popped out to the train station and stuck their own NFC tag on the poster. Once tagging becomes mass market, there will be no shortage of these misdirection scams.
There’s an easy way to guard against such scams in the NFC world, because the NFC specifications already include the ability to add digital signatures. Here’s how it works. There is a standard, the NFC Data Exchange Format (NDEF), for storing data on tags. The data is stored in records and there are a number of Record Type Definitions (RTDs) for different types of data (e.g., URLs). There is also an “NFC Signature RTD Technical Specification” which:
Specifies the format used when signing single or multiple NDEF records. Defines the required and optional signature RTD fields, and also provides a list of suitable signature algorithms and certificate types that can be used to create the signature. Does not define or mandate a specific PKI or certification system, or define a new algorithm for use with the Signature RTD. Specification of the certificate verification and revocation process is out of scope.
So, basically, you can create a tag that contains a record with a URL (or whatever) in it and then add a digital signature. I’d rather like it if I had an option on my Samsung NFC phone that said “only action NFC tags that have a digital signature that you can verify”. As I mentioned some time ago, we already know who to use digital signatures properly, so we can see how a secure tag infrastructure might work.
When I’m idling about waiting for the bus, I wave my phone over the poster and the poster sends a digitally signed chunk of data to the phone. Because my mobile operator has a deal with the poster site operator, my mobile phone has the relevant digital certificate in the SIM and can therefore verify the signature when it arrives. The phone now knows that the signature was correct and can go ahead and process the data that was signed.
As an aside, the signatures can be made quite small for cheap NFC tags with limited capacity (see, for example, the paper on “Elliptic Curve Certificates and Signatures for NFC Signature Record” for more details). My point is that the problem of “rogue tags” is not a difficult problem to solve conceptually. There’s even a Google Code project to provide a standard Java library for handling the signature records, although it doesn’t seem to have any code added to it yet.
The goal of the project is to have a free and open source implementation of the Near Field Communication (NFC) Signature Record Type Definition (RTD) that can be used both in mobile devices (MIDP, Android etc) and on the server side (Java SE/EE) for creating signed NDEF messages/tags or for parsing and validating their digital signature.
As far as I am aware, however, no similar mechanism or standard exists for signing QR codes. It’s simply impossible to tell whether a QR code is “real” or not. This has an important implication: when QR codes are used in a more transactional mode, it’s important to think the security through and use them in ways that the lack of security doesn’t matter. A good example is MasterCard’s QkR app begin trialled in Australia at the moment.
Its latest offering is called QkR, an Australian effort with support from the Hoyts chain of movie theaters and Commonwealth Bank. The initial trial run will be at La Premiere cinemas, where customers will be able to order and pay for food and beverages right from their seat with the QkR app. To initiate the transaction a you scan the QR code or tap the NFC tag attached to the arm rest, and a staff member delivers the trough of popcorn and kiddie pool of coke right to your seat.
Students might well pop in to the cinema and put their own QR codes on the seats to direct unsuspecting cinemagoers to porn sites or some other hilarious jape, but it’s hard to steal money because (in this case) it has to go into a merchant acquiring account. Given the natural arms race between transaction services and the army of mountebanks out there, I’d suggest that the industry (i.e., the mobile operator JVs, the major advertising agencies and so on) set aside some time to work out how the secure tag infrastructure might be coaxed into existence and how it might then deliver safety and security to consumers (hint: start by thinking about certificate distribution, because the verification of signatures is the easy part).
By the way, for personal reasons I won’t be able to make it to SXSW this year, so if anyone is going along to the panel on “QR Codes & NFC: When Physical & Digital Collide” I look forward to hearing how the landscape is unfolding.
These are personal opinions and should not be misunderstood as representing the opinions of
Consult Hyperion or any of its clients or suppliers