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).

The project's goals has been to move towards a more uniform way for the traveler to manage machine-readable mobile tickets, which also includes combination tickets, meaning a traveler should be able to present a travel document containing multiple tickets from different transport companies. To achieve this a certain degree of harmonization of technical interfaces and formats is required.

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.

Each participant is therefore given space to develop their own tickets for their own needs. Coordination is done to ensure a common data structure, so that each participant can easily parse the travel document information, and from that retrieve their own ticket information. Minimization of complexity has been sought, while the stored information must be kept as compact as possible so as to make the optical encoding more easily interpreted.

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.

When encoding the data structure for optical encoding, the storage structure shall be compressed using a lossless data compression method (deflate according to RFC 1951) to achieve an even higher degree of machine readability and maximum utilization of the available storage capacity of the optical encoding algorithm.

The logical container then consists of an unordered list of items labeled using a unique identifier, called the participant identifier (PID), used as the key to find a certain participants tickets. Inside this object, the participant can store their own ticket items in an ordered list. Within these ticket items the participant is free to design their own data structure containing the relevant attributes determined to be necessary, such as expiry date and which stops or zones that the ticket is valid for travel between. The following example illustrates the structure of the top level:

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.

The main disadvantage of using a symmetric algorithm to produce the cryptographic authenticity codes are the complex of the key management and the scalability problems associated with it. A device used to authenticate a ticket must have access to all issuers signing keys that the device should be able to verify. In a national infrastructure where tickets can be purchased and spent in a many-to-many relationship, it can quickly become a question of 10000's of units and 100's keys. The key management and distribution can quickly becoming unmanageable. Key material will also over time by exposed to a very large number of people performing installation and service of these units, which are sooner or later likely to compromise them, accidentally or intentionally, which would jeopardize the security of the entire national infrastructure.

Therefore, the starting point has been to use asymmetric cryptography as the mechanism to provide authenticity protection. Asymmetric algorithms are such cryptographic functions where a key pair is used, consisting of a public component and a private component which corresponds to each other in such way that what the signed with the one component can be verified with the other, and vice versa. When using asymmetric cryptography, each ticket issuer generates such a key pair consisting of a private key that is keeps secret and well protected, and a public key which is disclosed to all other participants. Those participants requiring access to the public key, also need to be able to trust the true origin of that public key, to trust that the public key really belongs to the ticket issuer. This secure exchange of public keys is facilitated through the Administrative Body, which also coordinates the assignments of the Participant Identifiers used in the ticket structure.

One drawback of the asymmetrically produced authenticity codes is that they require more data storage space than its symmetrical counterparts. For these reasons the use of ECDSA (Elliptic Curve Digital Signature Algorithm) in accordance with ISO/IEC 14888-3:2006 has been preferred over of the RSA algorithm in accordance with RFC 3447. The latter shall however be supported by all implementations to act as a fallback if the ECDSA algorithm in the future would prove to have cryptographic weaknesses. Both algorithms are based on the difficulty of solving certain mathematical problems. ECDSA is based on the difficulty of computing discrete logarithms, while the RSA algorithm is based on the difficulty of factoring large integers.

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.

At the time of validation or ticket inspection, the data authenticity is verified, however without being able to establish that the travel document presented is, by analogy to the traditional ticket, the original that the issuer provided. The machine-readable travel document can be a copy. And there is no reliable way to print any information to the data carrier, which means that it can not be "punched". It is therefore required to conduct checks to ensure that a ticket is not double spent.

This means that the risks of travelers copying machine readable travel documents between themselves, with the result of several passengers traveling on the same ticket, must be handled. This should be done through a combination of measures, including:

• strict limitation of machine readable travel documents validity time, and

• validating and "punching" of the machine-readable travel documents to the back-end ticketing system.

On the occasions when the machine-readable travel document is stored in an app on a mobile device, there is the possibility to impose additional layers of protection against copying. It is possible to tie the machine-readable travel document to the mobile device in such a way that copying are made much more difficult. Time information in the mobile device's technical environment can be used to create variable data fields related to ticket information, thus making the ticket valid only in that moment.

Another way is to let the mobile device include information that it receives from the physical environment. These fields can then be protected by a signature with a symmetric key known only to the validating devices and the mobile unit. The same mechanisms used for the issuers authenticity protection can be used for copy protection, meaning that the mobile unit adds another signature header containing the information that links the machine-readable travel document to space or time, and then produces a signature including this and the authenticity protected ticket container.

The copy protection may, as previously mentioned, frequently be updated with a time stamp, as well as information obtained from the environment. For example, vehicles equipped with radio beacons using BlueTooth Low Energy (BLE) for transmitting a unique ID of the vehicle can be included in the copy protection. In this way, a ticket is associated to the current specific trip. Other possibilities are opened up if the mobile devices are using an NFC interface, where the validation devices can transmit an unpredictable data string (challenge) which the mobile device is required to include in the signature. There are probably many other ways to achieve such protection, and it is reasonable to allow arbitrary information to be included in the copy protection header.

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 key generation process may be flawed, resulting in weak keys.

• The keys may be exposed by human error.

• The keys may be stolen by external or internal perpetrators.

• The keys may be calculated using cryptanalysis.

The most improbable of these risks can be assumed to be that the keys are compromised using cryptanalysis. To mitigate this risk the MTS1 specification includes a fallback signature algorithm based on a different mathematical problem than the primary.

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.