...

2.1 Design of electronic machine-readable tickets

One of the first objectives of the BoB project was to develop a common method for reading and validating electronic tickets, which implies designing basic and common principles for machine-readable electronic tickets that can be stored on any form of carrier. For example represented in an optical code format that can be displayed both at mobile devices backlit displays or by printing the code on paper, as well as via transmission over different types of air interfaces (e.g., NFC).

...

While it is clear that different actors have different needs and requirements, both technical and business-wise. A too far-reaching unification of the technical solutions has been identified as risk rather drive the costs and inhibit the development, contrary to the aim of harmonizing. The specifications developed within the project therefore defines only the parts must necessarily be common to achieve the synergies referred to.

2.2 Optical encoding

Electronic tickets may need to be transferred using an optical code format. Hence it is necessary to determine the type of optical encoding to use, so that it is technically possible for different participants to read the information in these codes. Within the transportation sector, the optical code format specified in ISO/IEC 24778:2008 (Aztec) as been dominant, as it is relatively easy to interpret, encode large amounts of information and are free to use.

The optical code format in accordance with ISO/IEC 18004:2006 (QR)  is another similar alternative, which is capable of storing a sufficient amount of information, but that is somewhat harder to decode. Under difficult lighting conditions with vibrations, cracked phone screens, et cetera, is simplicity to parse code and the ability to recover data is a very important factor. Meanwhile judged Aztec code can store enough information to be viable in the context provided. The project has therefore chosen to base using Aztec Code in the defined specifications.

2.3 Coordination of ticket data structure

Different participants have various requirements for data storage on their respective tickets. Some information need only occur on certain tickets. If you travel by train or coaches perhaps there is reservation, which may not occur in normal city traffic, and so on.

...

To facilitate the implementation of the specifications standardized techniques are used to the furthest extent possible. The possibility of using standard software libraries reduces development time and lower implementation costs, taking advantage of already developed and tested methods.

2.3.1 The basic data structure

To enable the flexible solution that has been the goal throughout the design project, the starting point was to design a logical container, which in turn can contain any number of tickets with different contents. The solution has been to design a data structure with a number of data types. The data structure should be able to store strings, numbers, the boolean data type (representing true or false) in unordered and ordered lists. JSON (JavaScript Object Notation) according to RFC 6901 is a text-based compact way to express such data structures, and used very frequently in modern information exchange over the Internet. JSON may also be represented in binary format CBOR (Concise Binary Object Representation) according to RFC 7049, which significantly reduces the size of the data structure and has therefor been selected as the transport encoding of the storage structure.

...

Typical ticket attributes that with high probability are common to many actors have also coordinated, for example, different forms of metadata linked to the ticket. This could include ticket ID, the type of traveler ticket is issued to (adult, senior citizen, et cetera), and the preferred language of the traveler. Using such coordinated attributes facilitates interoperability between different actors on a ticket level. However, it is still also possible to supplement the coordinated attributes of their own to the extent required.

2.3.2 Authenticity of ticket information

To be able to ascertain who has issued a particular ticket and to ensure it has not been tampered with requires the ticket information to be provided with a cryptographic authentication code. Traditional Travel Cards have used so-called symmetric cryptography to produce such authenticity protection. The symmetric functions uses the same encryption key to produce the seal as to verify that it is genuine. The reason for using symmetric cryptography have primarily been limitations in the computational capacity of the hardware used to produce and verify the authenticity of the code.

...

Although the two algorithms share some characteristics, it has been deemed appropriate to establish requirements for devices and software, which may be used for a relatively long time in the payment and ticketing systems, so that they can use both algorithms. The specifications therefor mandate the RSA algorithm with a greater key length as a fallback algorithm. In this way it is possible to meet the threats that may arise in the long term, both by changing the algorithm, as well as switching to a higher cryptographic strength (as a result of a larger key length).

The format for the authenticity protection

Using these specifications the ticket data container can be provided with strong electronic signatures to ensure data authenticity and integrity. The generation of the signature implies a signature header is attached to the ticket data container, and both of these parts are enclosed by the electronic signature. The information contained in the signature head is thus also authenticated and protected against manipulation.

The format of the authenticity code follows the JWS (JSON Web Signature) standard as specified in RFC 7515. For JWS to be applicable to CBOR-coded items, certain customizations had to be made which are defined in the BoB specifications. As of writing, there is an ongoing development of such a standard within the IETF, called COSE (Constrained Object Signing and Encryption). COSE is however not compatible with the BoB adaptation, and to introduce COSE support would require that a new version of the electronic ticket format is introduced. COSE, however, is a slightly more compact structure than the more simple customizations made within the BoB project, which could be an advantage in certain applications.

2.3.3 Copy protection

The machine-readable travel document is carrying information which can only be read in a certain devices. Upon inspection, it can not be assumed that the document can be verified as an authentic original, in the same way as a paper ticket that has been equipped with the issuers seal and other security features.

...

Crucial to the strength of the protection mechanisms is that the symmetric key material used by a device to create the copy protection is not too easily copied. A signing key stored in a mobile device can of course be compromised by the person who has physical control of the device. This may require that the device stores the key in a hidden manner so as to require special knowledge to disclose it. Regardless, if the device key can not be protected in its hardware, it will be possible to reveal the key using some effort. One way to address this risk is to also roll the devices' own keying material sufficiently often, to reduce the value of compromising a device key to make it less attractive for fraudsters to invest the necessary time and effort to compromise it. Therefor, it is recommended to establish a roll-over schedule of the cryptographic keys used for deriving the device keys.

2.4 Security Considerations

When designing a mobile ticket scheme using the BoB specifications, several important security aspects must be considered. These can not pre-emptively be accounted for in this handbook, but must be identified, categorized and analysed though a continuous risk evaluation process. As input to the risk analysis the following topics should be taken into account:

2.4.1 Tickets' validity time

Machine-readable tickets distributed to travelers through for example an App or e-mail can be copied. Although ticket information authenticity and integrity can be ensured through strong cryptographic methods, there is no way to determine whether copying has taken place.

For this reason, it is reasonable to limit the tickets validity time. What validity time constraints are appropriate is determined by how often it is possible to re-new a ticket using the back-end systems. For example, a purchase of a travel pass which is valid for one month, may result in daily tickets being issued which is valid for 48 hours. This can be achieved by limiting the validity of the issuer signature rather than the ticket's own validity. It also allows the mobile device to be disconnected for some time, and still obtain the updated ticket information before the previous one expires. This way, the risks of ticket information of more significant value is copied between devices can be mitigated. In some systems, it may also be possible to issue the tickets just before the trip is started and might also only apply to that particular trip, thus further limiting the ticket validity of the information.

2.4.2 Device Signature protection

In addition to restricting the MTB life-time, this specification allows for an extra level of protection using the Device Signature as previously described. Even though it is possible to hide the devices' keys in the device itself using obfuscation techniques, it must be recognized that some of these keys can and probably will be compromised. Good practices to mitigate these risks this may be to generate new device keys with some frequency.

If device signatures can not be used, for instance tickets which are printed on paper by the traveler, other controls may have to be in place to mitigate the risks for duplication of tickets, for example by including the travelers name in the ticket to make it personal. Another option can be to require on-line validation of the ticket, in situations where it is possible to prevent a ticket from being double spent.

2.4.3 On-line checking of tickets' validity

Regardless how the copy protection is designed, it will likely remain opportunities, albeit limited, to copy ticket information for use by multiple travelers. To conduct on-line checking and "punching" of ticket information is an important component to protect against copying. If it is possible to wait for control response from the back-end system is determined by the requirements on how fast a validation must be completed. In a subway gate with very high throughput of travelers, validation may need to complete within in a few tenths of a second, while on a bus in rural areas can wait up to a few seconds. If the response can not be obtained within this period, it is reasonable to let the traveler on-board and add the validation event to a queue while waiting for a response from the ticket system. The ticket should be sooner or later register as used in the ticketing system.

If there are signs that some ticket may copied, it can trigger a ticket to be put on a blacklist which is promptly distributed to all validation devices in which the ticket would otherwise be valid. Such a function can suppress systematic fraud attempts where reliable synchronous on-line validation may not be possible.

2.4.4 Fraud detection and suppression

Even when using limited MTB life-times and dynamic Device Signatures, the risks for duplication of MTBs can not be completely eliminated. There is a balance between practicality and how short life-times a MTB and the Device Signatures can be given. Inevitably, there will be a time window in which it will be possible to (re)distribute a MTB for use by more than one traveller.

Several other approaches could be combined to mitigate the residual risks to acceptable levels. Most notably, there should be fraud detection mechanisms in place to recognize suspicious travel patterns and impossible conditions. These transactions may be flagged for investigation, and proper action can be taken. Ability to take proper action to fraud or fraud attempts can be assumed to be one of the most effective methods to suppress such behavior among travelers.

2.4.5 Protection of Personally Identifiable Information (PII)

When developing a ticketing system with electronic tickets an implementor must take into account the requirements to protect travelers' privacy. Large scale collection of personally identifiable information (PII) to the central system may not lead to the ability of to map an individual's private life. Public transport authorities are prohibited to make significant intrusion into individuals' personal privacy, if it is done without the consent and it involves monitoring or mapping of the individual's personal life. This is regulated in the Swedish constitution (2 kap. 6 § regeringsformen). All transport companies, whether public or private, is required by law to minimize the amount of personal data processed, and thus do not collect more personal information than is necessary for the purposes of the processing. This follows from the Swedish Personal Data Act, Personuppgiftslagens 9 § f (SFS 1998: 204), and the upcoming Data Protection Regulation (General Data Protection Regulation (EU) 2016/679), Article 23.1. It should in this context be noted that the processing of data relating to legal offenses is specifically regulated by 21 § of the Swedish Personal Data Act (SFS 1998: 204).

As a rule of thumb, it should be possible to travel anonymously travel vis-a-vis both the operator of a transport and the transport company. Privacy-enhancing technology can be used in each step in the processing of privacy sensitive data, and as previously mentioned, this minimization of the data collected and processed, for example by using pseudonymous identities. In this way it may be possible to collect information that makes it possible to detect fraud, hold fraudsters accountable, produce statistics and provide customer support, while the individual's right to privacy is respected.

2.4.6 Key management

The security of the machine-readable travel documents relies heavily on strong cryptographic mechanisms to secure data integrity and data origin authentication. Maintaining the confidentiality of the private encryption keys are therefor of utmost importance. The confidentiality of cryptographic keys can be compromised in a number different ways, for instance;

...

The other risks mentioned here are related to the issuers operating environment. One effective control to mitigate significant parts of the risk is to generate, store and use the private keys in Hardware Security Modules (HSMs). Use of HSMs for MTB signing is encouraged. However, if a MTB ticket issuer decides not to use HSMs, a key roll-over schedule should be established where the frequency of the key roll-overs are proportionate to the exposure of keys to external networks, other systems and personnel.

2.4.7 Input data validation

As a machine-readable travel document is decode and processed, it implies receiving data from untrusted devices into systems which may be of mission-critical nature. To minimize the risks associated with this attack vector, all input fields must be properly and thoroughly validated by data types, lengths and contents. The Issuer Signature shall also be verified before any processing of the contents of the MTB takes place.

...