Account Based QR Ticketing - My Grand Design
I was asked recently how I would design an account-based QR code ticketing solution. That is a simple question. But it would require more than one article to even just scratch the surface.
It brought back memories of discussions about static offline authentication and other topics which I thought are buried and forgotten under the thousands of pages of EMV specification and the long-winded migration from magnetic stripe to chip cards.
But here we go again. The good old magnetic stripe swipe under the "modern" guise of a QR code scan.
Nevertheless, I am old enough to remember most of it and decided to take a quick shot in this article.
Risk Management
The management of fraud risk in a QR ticket system is based on technical standards, dispute resolution rules and operational procedures. For the QCAT system, I summarized some of it here: (1).
No matter how much we try to anticipate how the system can be exploited, there will be weaknesses in the setup that we will not forsee. This is one thing I learned while working for Visa many years ago, customers will inevitably tinker with the system on purpose or stumble upon ways to exploit weaknesses by sheer coincidence.
Some of the weaknesses or risk we will know but judge them to be less severe and decide to accept potential losses instead of eradicating the risk altogether. This only works if the grantor of the concession does not blow small risk events out of proportion with ridiculous fines[1].
These are the high level risk management features I would consider essential for an account-based QR ticketing system to be viable:
Dynamic (that is frequently regenerated) QR codes
Offline static data authentication via asymmetric algorithm
Fast entry/exit record upload
Plan for a medium term (5 years) transition of QR image to mobile NFC interface
Allow for minimal overdraft without closing the account immediately
The QR Data Format
This is a topic that often gets the most attention, but is probably the least important one.
I have covered the general encoding requirement that I believe are appropriate in section 10.1 of the QCAT standard which is available here (2).
In summary, the QR Code is encoded as defined in Section 3.2 of EMV Customer Presented QR Specification (3). The encoding follows ASN.1 and BER encoding rules.
This means that each field in the ticket data is encoded with a Tag, a length and a value. the tag identifies the field, the length provides the number of bytes in the value and the value carries the actual content of the field.
|
Under no circumstance should issuers be allowed to deviate from the encoding rules. Many QR codes I have analysed misuse templates as "raw data storage", do not follow tag encoding rules or disregard the defined data elements in favor of proprietary data that is opaque to all other system participants[2] |
Security Features
Offline Authentication
The QR code data must be protected by offline static authentication of the QR code data. The validator/gate must be able to determine whether the QR code is entirely fake or whether it was generated by an authorized issuer. It prevents the creation of entirely fake QR codes but does not stop copying the QR code.
Unfortunately offline authentication needs either symmetric Cipher-based MAC for a 4 bytes signature or asymmetric cryptography with a minimum of about 64 bytes signature (Ed25519 / ECDSA).
The QR data format should allow different authentication protocols, for instance by using a signature version.
Any new version would need to be implemented in all validators and gates to preserve interoperability. Therefore, it makes sense to introduce multiple signature algorithms right from the start. See the QCAT documents for an example how this can be achieved: (4).
| Feature | Symmetric | Asymmetric |
|---|---|---|
Key Management |
Expensive. Distribution of keys to all issuers and to all automated gates and validators |
Only public keys need to be stored on validators and gates. |
Key Storage on Validators/Gates |
Requires secure storage (SAM or secure storage) |
Keys are public. Requires assurance that no unauthorized public keys are stored. |
Speed of validation |
Faster |
Slower |
Signature Size |
Small. CMAC can be 2 to 4 bytes long |
Requires at least 64 bytes. Entire cryptogram need to be stored to preserve integrity of cryptography |
Security Level |
High in foreseeable future. |
May require increase of key length within the next 10 years. Less of a problem with Elliptic Curves. Problem with RSA. |
Key Sharing with QR Issuers |
Master keys need to be shared with issuers. Usually through issuer SAM that allows creation of certain number of signatures |
Need establishment of trust hierarchy. Issuer generates their own keys and only need to get a certificate from scheme level certificate authority. |
Suitable for use in physical transit cards |
Yes. Supported by popular chip platforms like DesFire |
Requires something like white label EMV cards, which are likely more expensive and implement a slower protocol with NFC reader. |
My QR code design would allow for at least two signature versions: 4 Byte 128-AES CMAC and 64 Byte Ed25519 / ECDSA Signature. The use of symmetric signature should be confined to online authentication and paper tickets, meaning that there is no need for the distribution of SAM or symmetric keys to validators and gates.
Blacklisting
As much as possible, blacklisting should be achieved on the issuer side. Whenever the issuer encounters a ticketing transaction without insufficient funds, it should prevent the passenger from creating another transit QR code.
It does not seem to make sense for the issuer to generate the QR ticket and let the validator or gate apply the blacklist which came from the issuer of the QR code in the first place.
The blacklist should be reserved for offline fare media such as physical EMV or transit cards, and for fraud management purposes.
Key Management
Offline authentication requires distribution of keys (secret symmetric or public asymmetric) to all validators and gates. Symmetric crypto algorithms also requires managing the distribution of SAMs, unless the validation device contains a secure storage space (basically a built-in SAM).
Managing symmetric keys is costly and difficult. It is much easier to distribute public key certificates to all devices. The distribution mechanism "only" needs ot ensure that no keys from unauthorized certificate authorities can be introduced.
Symmetric keys also need to be shared with issuers, which is not the case with the secret keys of the scheme certificate authority’s key pair. With asymmetric algorithms only one certificate creation ceremony is required for every new key the issuer introduces.
The scheme provider needs to establish a certificate authority, at least for the QR data signatures. The scheme should also seriously consider NOT to use symmetric keys, even for NFC transit cards.
Dynamic vs. Static QR Data
Strictly speaking, QR data is always static. It cannot react to challenges from the scanning device. In addition, the industry is misusing the terms "dynamic" for QR codes that are transaction specific and "static" for QR code that are unique to the merchant but remain the same for each transaction.
When I speak about dynamic QR codes, I mean the frequent creation of new QR codes for the same transaction.
The cryptographic signature of the QR code depends on the QR code creation time and changes together with the creation time every few seconds. That way a copied QR code must be used within a few seconds to remain valid.
In most environments it would be impractical to copy and use the QR code in such short timeframe. Dynamic QR regeneration therefore creates some protection against multiple use of the same QR code ticket.
My QR code design would make dynamic QR codes mandatory in a sense that the issuer would be fully liable for multiple use of the same static QR codes.
Relationship of QR Code Standard and NFC Transit Card
The main function of a QR code and an account-based NFC transit card are the same. Both protocols provide enough information to the validator to settle the fare with the issuer of the QR code or the Transit card.
In the case of the QR code, the data is conveyed by scanning and decoding the QR image, in the case of the NFC card the data is conveyed via electromagnetic fields. Of course, other than the QR code, the NFC card can be authenticated offline.
As soon as the passenger is using a mobile phone, the only reason not to use the NFC interface would be mobile phones without NFC and the cost of moving from the simple creation of QR images to the more demanding NFC protocol.
The type, meaning and format of the data used in both systems should therefore be the same or at least very similar. You could say that the NFC Transit Card is just another way to "transfer" the QR data to the validator.
Timing requirements.
If we assume that the system must be able to let 30 passengers per minute through a gate, then the time per passenger is two seconds.
This includes scanning the QR code, making a decision, opening the gate, letting the passenger through and closing the gate. Any solution that attempts an online connection for every entry and exit transaction probably has less than one second to do so.
The network round trip time is somewhere between 50ms to 100 ms, leaving about 900 ms for processing. This can be done, but the network availability, resilience and throughput must be extraordinary high.
If the system entirely relies on realtime authorization, everything will come to a standstill when the network or backend system is down.
Knowing the network quality and the rather nonchalant way the eWallets and banks take their payment functionality offline, I would say the system must be at least have offline capabilities to continue function for extended periods without network or backend.
QR Code vs. Ticket vs. Account
The lifetime of the QR code, the account and the ticket are independent.
The account information changes every time a new token is issued. The account itself remains relatively constant for many transactions. The ticket should remain the same for each trip, which may be hard to achieve with QR codes. The QR code itself changes frequently to prevent multiple use.
Ideally, entry and exit transactions should be linked by ticket reference. This is more complicated than it sounds, as the passenger may close the mobile phone application and generate a new QR code when exiting.
Since the ticket issuer and the QR code app do not know whether the passenger has exited already on the same QR code that was used on entry, it is difficult to decide whether a new ticket number should be generated.
Using the account number to link entry and exit record is possible in principle, but may have the same issue as the ticket reference number because the QR code generator may request a new token for every newly generated QR code, which changes the account data in the QR code.
I believe the best solution is a combination of a relatively static ticket reference number combined with the entry and exit timestamp. This will allow matching based on the chronological sequence of records. Different transaction upload schedules need to be taken into account. The frequency and timing of changing the ticket reference number remains an unresolved problem.
Generally, the account reference should only be meaningful to the issuer of the QR code. The AFCS only needs enough data to calculate the fare and to decide which issuer is liable for it. How the issuer get the money to settle the transaction and from whom they get it should be of no concern to the AFCS.
This does not mean that one company cannot run both an issuer and an AFCS L4 system. However, it means that the design of the system does not mix those two realms.
Should paper tickets be supported?
Paper ticket have no role to play in an account based system, however single journey tickets may be backed by a "temporary" account which holds the ticket price. In fact, this may be a good design choice as the processing would be the same as for "real" account based tickets.
Paper tickets have two downsides. One is that fast and reliable scanning of a warped or crumbled paper ticket is difficult. The second is the static nature of the QR code signature, which makes detection of multiple scans of the same ticket almost impossible.
For mass transport, I would advise against aper tickets. For long distance buses or trains, a paper QR ticket may work. The QR specification should allow for this.
Dispute Resolution Rules
The rules should be as simple as possible, but not any simpler.
In this high-level article I can only list some principles which I think should apply. A more complete set of rules would require a lot more thought.
-
The customer must pay the issuer for every ticket that was created by them and accepted at a validator or automated gate. The assumption is that only the customer can generate the ticket and must have used it themselves or has given it somebody else.
-
The issuer must pay for every valid ticket accepted by following all rules at a validator or gate. The AFCS provider cannot be asked to do more than what is agreed upon. If, all rules are followed and all checks are performed and all transactions are uploaded on time, there is no reason why the AFCS provider or the transport operator should be liable.
-
A valid ticket is a ticket created with the correct cryptographic signature. If an AFCS provider does not check the signature or accepts a ticket with an invalid signature, then there is no reason why the issuer who had nothing to do with the creation of the ticket should be liable.
-
The acceptance rules would be designed around QR data such as expiry periods, validity domains and other data elements that the acceptor must check. If an AFCS provider accepts a QR code that has expired, was issued for another validity domain (i.e. created for a train ride, but used for on a Jeepney) or has some other applicable restriction encoded in the QR data, then the AFCS provider should be liable.
-
The account number (tokenized or not) is only meaningful to the issuer and is not used by the AFCS provider for anything else than potentially entry/exit record matching.
Once the records have been matched and the transaction settled, the account data should be deleted. The AFCS provider or transport operator do not need to keep a record of who travelled when and where.
-
And lots more …
Not Covered in this Article
-
Support for trips that touch multiple operators and modes of transport
-
Prepaid Tickets (see (2))
References
(1) AF Payments, Ingo Noka, “QR Code Standard for Transport Ticketing - Risk Management.” GitHub, Sep. 2019, [Online]. Available: https://github.com/afpayments/QCAT_QR_TICKETING_STANDARD/blob/cccdb3805abd83f1a1b0bb8a77bea7ea0c7e9656/qr-code-ticketing-risk-management.adoc.
(2) AF Payments, Ingo Noka, “QR Code Standard for Transport Ticketing - Standard.” GitHub, Sep. 2019, [Online]. Available: https://github.com/afpayments/QCAT_QR_TICKETING_STANDARD/blob/cccdb3805abd83f1a1b0bb8a77bea7ea0c7e9656/qr-code-ticketing-standard.adoc#qr-code-standard-for-transport-ticketing—standard.
(3) EMVCo, “EMV Code Specification for Payment Systems (EMV QRCPS) - Merchant-Presented Mode,” EMVCo, LLC, Technical Standard, Nov. 2020.
(4) AF Payments, Ingo Noka, “Public Key Management System for Signature Algorithm Version 1 and 2.” GitHub, Sep. 2019, [Online]. Available: https://github.com/afpayments/QCAT_QR_TICKETING_STANDARD/blob/cccdb3805abd83f1a1b0bb8a77bea7ea0c7e9656/qr-code-ticketing-key-management.adoc.
Copyright Sources
OpenClipart, “Vector clip art of dream house.” Free SVG website, Aug. 2015, Accessed: Jun. 02, 2026. [Online]. Available: https://freesvg.org/vector-clip-art-of-dream-house.