Barcode ticket security is a growing issue (we get asked about it all the time) and there aren't any standards yet for preventing unscrupulous individuals from altering the tickets that are issued.
Barcodes are being used as a form of virtual ticket that you can print from your PC at home or show on your phone screen to gain access to airport check-in, bus tickets, train tickets, promotional coupons, to gain access to a venue or be entitled to something valuable.
What do we want to achieve?
Barcode tickets that can be used to allow a virtual transaction, such as on a PC or a mobile phone to provide an instant ticket to the customer, with which they can instantly prove entitlement at a venue.
Ideally, to get the largest acceptance of barcode tickets, the designers of venue ticket systems should be free to integrate the ticket validation in whatever hardware or software they want to, and without any onerous security requirements - that way whatever cash registers (tills/EPOS), handheld scanners or gate systems that a venue uses can be used at their convenience.
Is there a problem?
As an illustration, mobile and print-at-home barcode ticketing on the UK railways is currently limited as follows:
The same problems affect event tickets, gift tokens, and other uses where a more unified approach, and more secure ticket data would enable the convenience of m-ticketing to grow.
So, we need to get something in place that allows interoperability between barcode schemes, and also allows walk-up tickets to be validated without having to propagate all of the ticket databases.
Why do we need Security?
As the value of barcode entitlements go up, more people will take an interest in copying, altering, or re-generating valuable barcodes. Without the security, the ticket cannot be proof.
Why Interoperability?
When a ticket needs to be issued by one party, and checked by another party, then you need some way of the two parties being sure that the ticket is valid, paid for, and has not been altered between issue and scanning.
On public transport, some journeys swap on and off vehicles run by different companies - it is preferable that a single ticket can bought in one place and validated by each different company on the route, rather than the user having to separately purchase and show different tickets.
The data security risk is that, in most cases the ticket generator can be kept in a safe place (locked in your secure e-commerce server) but your ticket checking is distributed thinly around, at the entrances to venues, or often in a mobile devices held by bouncers or ticket-inspectors that can't be expected to keep your devices safe from unwanted attention or theft 100% of the time.
We will describe the security measures for simple (small) 1D barcodes that just contain a number, medium sized barcodes with some details and symmetric seals, right up to large 2D barcodes that contain the full details of the ticket and asymmetric cryptographic signatures to verify authenticity.
SMALL BARCODES (1D, around 12 bytes)
(images are all examples only - don't expect to scan them and get anything useful out of them)
Anti-copying using DRM (Digital Rights Management)
However you deliver a barcode, it has to be presented in a scannable format, which means that an adversary can always scan the ticket, and if they want to, change some details on the barcode and create multiple copies without DRM. People that have barcode delivery systems that use or rely on "forward lock" or DRM to prevent the barcode image being sent from one person to another are being blind to the availability of barcode scanners to beat all of their software. Also consider that OMA DRM for forward locking images downloaded to phones places laughably little protection against an assailant armed with such exotic tools as a web-browser and a text editor.
Anti-copying using a local database at the scanner
Storing the serial number of each ticket scanned, and flagging/halting duplicate scan attempts can detect the most obvious cases of a small group of users copying tickets and sharing them around. You can refuse the second use of the same ticket, and also in your back-office systems start to collate details of which user's tickets are being copied/re-used the most, and lock those users out, or mark their tickets (and future tickets) on a blacklist for 100% inspection in the future, including ID check.
Anti-Editing using Central Database
Simple (small) barcode tickets are just a serial number, and their validity is checked from a database of known tickets, which reveals all of the extra ticket detail, possibly including ID information about the legitimate user of the ticket which might be checked in high value situations.
The problem of this approach is that your ticket checking systems must have up-to-date access to the ticket database. This is fine if all of your tickets are sold many hours in advance, and your local ticket validating system has had time and connectivity to synchronise it's local database with the ticket selling server, but is far less use when people are buying tickets immediately before use, or when your ticket database is too big for your portable ticket checking devices to download and store, or if one ticket vendor doesn't want to give copies of all of their tickets to every single ticket checking agent, because one of the agents may just sell them on!
Live Check Speed and reliability issue:
If you design a ticket checking system that relies on the scanners being connected to the internet, to access a central database to check every ticket, then you may get issues with speed of checking tickets, and therefore the throughput of your entry systems. Especially if you have to check tickets underground or on a moving vehicle.
Additionally, your whole system could become useless from a single point of failure or connection. A huge factor in the design of the Oyster smartcard transport system for London was to make sure that each station could continue to check tickets in milliseconds, even if disconnected or when connectivity was slow. Otherwise any unforeseen issue with central servers or internet connections could bring millions of Londoners to a grinding halt during business rush hour - an expensive and potentially pin-stripe and bowler-hat riot inducing situation, if you are unfamiliar with London!
Offline Ticket Checking
If you can put all of the details of the ticket into a medium or larger barcode, then an offline system can scan the ticket, and instantly know what the entitlement is without the need to access a database. Trouble is, you need to make sure that the ticket is genuine, and not adjusted. There are two major ways to do this:
MEDIUM BARCODES (2D, around 42 bytes, ~27pixel square)
These not only contain the ticket serial number, but can also contain brief details about what the ticket entitles, such as destination, price paid, and valid date, and possibly even some very brief ID information, such as the last 4 digits of the credit card used to purchase the ticket, which could be checked against the user to make sure they are the valid ticket holder.
Anti-Editing using Symmetric Cryptography.
If your ticket issuing server and your ticket checking systems all share a secret symmetric key (symmetric means that all parties use the same key) then the contents of the medium barcode can be encrypted using the secret key. You can either encrypt and hide the contents, or leave the contents in clear text and add a small amount of the encrypted version at the end, as a "seal" or "signature" that can be verified by the scanner. Were an attacker to change the plain text bit of the ticket (such as the date) then after scanning the verifying scanner can encrypt the new plain text, and compare the new encrypted seal with the previous seal in the barcode, and detect an alteration, and can now reject the barcode as a forgery. The moment we can "seal" the contents of the barcode, it means that we can also add customer ID information to the barcode so that a validating agent can check that the correct user is gaining access.
Example format:
sellerIdentifier + ticketNumber + ticketDetails + CMAC
(CMAC is a small message authentication code, around 4 to 16 bytes long, created from the text of the message with a symmetric cryptographic function, using a secret key known only to the ticket seller, and ticket validators)
Suggested encryption scheme: AES 256 based CMAC.
Benefits: doesn't add much data - adding a symmetric seal to the end of a ticket can be done in very little space (you can just put a small portion of the encrypted or hashed version of the ticket into the seal and still provide strong protection) You can even send these medium barcodes in an SMS picture message (not MMS or WAP).
Problems: If a symmetric key is discovered by a thief, they can create and adjust tickets. This becomes quite likely as you have to give every ticket validator copies of every single symmetric key in use, so that they can check tickets. If one piece of ticket validating equipment is stolen, or compromised by a virus, or sold to criminals, then it can reveal the symmetric keys.
The ITSO ticket system makes it difficult for a thief to retrieve keys from stolen equipment by protecting the keys in a smart-card "Secure Module", and closely controlling the development of hardware that works with the smartcard. However, you can only use special hardware and software that is certified for use with ITSO, which increases the costs of integrating new ticketing systems, and expanding ticket reading options. Some organisations resist adopting ITSO ticketing due to the added cost and reduced flexibility (Oyster isn't compatible for one). Even if a symmetric key system doesn't use ITSO, it would need some hardware or cunning protocol to protect against leaking of keys. The big problem is that it would be impossible to detect which agent was losing keys, so if there were business losses, it would be difficult to assign responsibility.
LARGE BARCODES (2D, around 128bytes, ~41pixel square)
These tickets can contain all of the information about the ticket, including detailed ID information, multiple travellers, terms of the ticket, and details about the purchase history and multiple entitlements such as multi-part journeys, reserved seating etc. Some draft standards for Airline tickets and Train tickets require data payloads as large as this for full e-tickets.
Anti-Editing using Asymmetric Cryptography
Modern internet systems use Asymmetric cryptography for just about every secure transaction you do on-line.
Asymmetric encryption is often called Public/Private key cryptography, and means that the two parties use different keys - one of which is kept secret at the server, for creating and signing tickets, but the Public half of the key for validating the tickets can be freely given away (even to your enemies).
Benefits: The public keys, and instructions for their use can be freely distributed to ticket validators, friends, and enemies, for checking the validity of tickets. It means that open source ticket checking software can be made available to allow quicker integration of new scanning systems, and greater flexibility of providers.
Each Ticket issuing party can have their own private key, and give away their public key on a public website for all ticket validators to download and use. The keys would not need to be updated, unless one was stolen, or completely new providers appeared.
If one of the Private keys was lost, through virus, hacking, theft, or deliberate fraudulent activity, then the only new tickets that a thief could create would be from that one ticket issuing source, and that ticket issuer could be held financially liable for fraudulent tickets, without other members of the scheme being affected.
Suggested usage: football tickets or Olympic tickets - these may be sold in many places, and need to be checked in multiple locations, by different organisations. In some cases it may be advantageous for a ticket to entitle certain linked items, such as reductions on food in the olympic village for certain guests. You would need the ticket to be checkable by a food vendor, but you wouldn't necessarily want to equip every vendor with an ITSO hardware module or a large database of tickets. However, if you could provide open software and public keys, then EPOS integrators, mobile phones, and all manner of cheaper scanners could perform scanning and validation of the global ticket without reducing the security of the ticket.
Simple Format of the data inside the barcode:
sellerIdentifier + ticketSerialNumber + ticketDetailsEncryptedBySellersPrivateKey
Suggested Asymmetric encryption standard: 1024bit RSA with PKCS#1
Drawbacks: Asymmetric cryptography creates larger signatures than the symmetric cryptography, and therefore requires larger barcodes to contain them. Some much older (black and white) mobile phones wouldn't be able to display the larger barcodes. However, for walk-up tickets on paper or the modern phones this would not be an issue. You could display these on a mobile which supported MMS or WAP or Java based ticket delivery.
What about ECC instead of RSA?
ECC based Asymmetric encryption could probably be used too, even on the medium sized 40 byte barcodes, but there aren't such clear standards for message encrypt/decrypt with ECC quite yet - we'd be keen to explore this further.
Common Misconception: Small devices haven't got the processing power to cope with Asymmetric Encryption - this is simply not true.
Phones displaying a barcode don't have to process the encryption at all, and phones or PDA's checking the code can do so easily with modern methods. An ancient black-and-white Nokia 6310i could check an 1024bit RSA encrypted barcode in 1 second, a modern mobile phone or PDA could check the code in less than 1/100th of a second. ECC is roughly equivalent to RSA in speed for small keys, and gets faster than the equivalent RSA key as they get bigger.
Suggestion: 2 approaches:
Legacy phones: Use MEDIUM barcodes, which have to be live-checked when being validated in an inter-operator way. Slower, but the only way to use the smaller ticket format without the security issues of having to give away all of your tickets or all of your private keys to third parties.
A standard web-services server interface should be agreed so that one ticket validator can query the validity of a ticket from the Ticket Issuer's database in a standard way.
Operators that trust each other could share secret keys and mirror databases to speed up ticket validation and allow off-line checking, as long as security steps have been taken to help prevent staff leaking keys and ticket databases.
Newer Phones and Print at Home: Use LARGE barcodes with Asymmetric encryption. This allows walk-up tickets to be sold and instantly verified by open standard scanning hardware, even with no database connectivity or secret key distribution.
Less Critical: 2D Barcode Format:
Datamatrix, QR Code and Aztec are all suitable.
Datamatrix is more freely available and has more scanners available, so if it was adopted there would be more choice for providers of scanning hardware. (More choice usually leads to cheaper and lighter hardware.)
Aztec can cope better when there's less whitespace around the barcode, which Datamatrix needs.
We've seen plenty of scanners that read Datamatrix and QR, but fewer that handle Aztec.
Every Aztec scanner reads Datamatrix and QR, and the same data format can be contained in all barcodes, and in most cases the hardware in the scanner makes the difference between one format and the other transparent anyway, as long as the scanner supports the rarer Aztec.
We would go for Datamatrix, but the internal data format and the security model behind it is the most important thing to standardise at this point.
If you are interested in Barcode tickets, please comment on this thread, especially the following: