The security of the BoB infrastructure relies heavily on strong cryptographic mechanisms to secure data integrity and data origin authentication. Secure management of the private encryption keys are therefore of utmost importance. This chapter provides an overview of which types of keys are used, and what they are used for.

Metadata

The Metadata, as described here and MTS4, are secured using both client- and server-side keys. The client-side keys are used for adding, updating and removing metadata pertaining to a participant. The server-side keys are used to sign the Metadata before it is being distributed to the participants, and hence needs to be validated by the receiving party.

For this reason, a participant need to generate its own Participant Metadata Administration Keys, which is a ECDSA or RSA public-private key pair. The exact parameters which shall be used are documented in MTS5 section 3.1.

The Administrative Body responsible for conducting the Coordination Function has a corresponding key-pair. The public part of the key-pairs need to be exchanged between the Participant and the Administrative Body in a secure way. This key exchange generally include out-of-band mechanisms such as verifying the authenticity of the public keys over the phone or meeting in-person.

Through the Metadata, the Participants are then able to subsequently exchange other types of keys securely. Therefore, it is of utmost importance that the keys used for administrating and managing Metadata are kept secure. These keys need to be rolled (changed) if there is the slightest suspicion they have been compromised.

Authentication keys

The authentication of end-entities within the BoB infrastructure relies upon a federated approach based in assertions in the JSON Web Token (JWT) format. These assertions are cryptographically signed, and the public component of such keys used for signing are exchanged through the Metadata as explained above.

In addition, each end-entity requires its own keys to be able to authenticate to the Authentication Service. The preferred way of doing this in the BoB Infrastructure is to generate a key-pair and a self-signed certificate for each such entity. The private key is used in the authentication phase to retrieve an assertion which can be used for accessing other services, both internally and across organisational borders. Such assertions shall have an expiry time, after which the end-entity is required to re-authenticate to the Authentication Service. A reasonable life-time is the time of a work-shift, such as 8-9 hours.

Keys used in the authentication phase may be rolled (changed) on a predefined schedule if the participants entity management supports it. Rolling keys may be motivated by the fact that keys may be stored in devices installed in non-secure environments, such as vehicles and hand-held devices.

Ticketing keys

Two types of key-pairs are used in the Ticketing process. The first is the Manifest Signing Key, which the Price- and Product Service utilises to issue manifests to the Sales Channel. These manifest can then in the next step be sent to the Ticketing Service to request the issuance of the corresponding ticket. The Ticketing Service will check the signature attached to the manifest by the Price- and Product Service and, if it validates the authenticity of the manifest, issue the ticket. This implies the Ticketing Service needs to trust the Price- and Product Service's public keys. However, this is an internal key exchange with needs to happen within a participants own infrastructure, hence the Manifest Signing Keys are not distributed through the metadata.

The other type of keys, the Ticket Signing Keys, are used by the Ticketing Service to ensure the authenticity and integrity of issued tickets. These tickets need to be distributed to all participants who shall be able to trust tickets issued by that Ticketing Service. These keys are named mtbPublicKeys in the metadata. Rolling such keys on a schedule requires some planning, as already issued tickets otherwise may become invalid. As a rule of thumb, there needs to be a validity overlap of a new and a emanating key of the maximum signature life-time plus distribution time of the new key. The distribution time of a new key is governed by the minimum interval each participant is required to retrieve new metadata. For metadata managed by Samtrafiken, that interval is currently 48 hours. Please refer to MTS4 for more information on how to determine this interval and other aspects affecting a key roll-over schedule. 

It is recommended to restrict the life-time of signatures generated by the Ticket Signing Keys, not only to be able to manage key roll-overs smoothly, but also to minimise risks for duplication of high-value ticket. The signature life-time is set using the exp parameter in the Issuer Signature Protected Header (refer to MTS1 section 2.4). Under all circumstances, the signature does not have to be valid beyond the life-time of the ticket. For tickets with a validity longer than a few days, it may be appropriate to restrict the signature life-time to be shorter than the tickets own life-time, hence requiring the traveller to renew the signature with some frequency. Reasons behind this may be to counter attempts to duplicate electronic tickets by downloading it into a device, and then report the device as lost (disconnecting it from any networks) and retrieve the same ticket into a new device. A traveller could then violate the business rules by using the same ticket in several devices. It may also be possible to print certain tickets on paper, where duplication will be trivial. This may also constitute reasons for requiring regular updates (and re-printing) to limit the value of such tickets.

It should also be noted that such policies need to be complied to by any participants authorised to combine and re-distribute any participants issued tickets. The concept of combining and re-distributing a ticket works by an entity, such as a sales channel, retrieves tickets from several different participants, removing the outer structure of each of them, combining them into one and subsequently adds its own signature. A participant can indicate, through the metadata, which other participants are allowed to re-distribute tickets and what the maximum life-time of such signatures may be.

Device keys

Device keys are used to provide a layer of copy protection when electronic tickets are held in different types of portable devices, such as smart phones and tables. In such devices, a ticket are usually optically represented. Perhaps the most evident way to mis-use such tickets would be to make a screen shot and send to a friend, which would be able to view the screen shot and present it to the optical reader of a validating device. To limit such possibilities it is recommended to include some information relating to time or location within the outer signature (refer to MTS1 section 2.5), such as a time stamp which updates frequently. A reasonable update interval may be a few seconds, allowing some lee-way for time skew of the portable device. This outer signature is created using the unique Device Key.

Such Device Keys may be created using a Key Derivation Key (KDK) which is common to an application providers (usually a sales channels) all devices. This KDK can then be shared among the participants which should be able to validate the device signature protection. The KDK is a symmetric key which needs to be held confidential to any adversaries. For this reason it is not exchanged through the Metadata, but rather provided bilaterally using the Device API endpoint, and then only to authorised entities. 

How a Device Key is derived from the KDK is described in MTS2. As Device Keys are stored in non-secure environments, it is appropriate to regularly roll them. Likewise, it is also reasonable to rotate KDKs, as they are distributed over a potential large number of participants and devices. The required timing for updating the KDK is determined bilaterally between the participants, which would also affect any roll-over schedules. KDKs are generally valid for as long as they are available though the Devices API. During a roll-over several KDKs will normally have to be available, and the receiving party should accept them all as valid. As a key is no longer available through the API, it must be removed from all validating devices.

It is expected that Device Keys will have a shorter life-time than the corresponding KDK. For this reason, each KDK can result in any number of subkeys per device. These subkeys are identified using a delimiter in the kid parameter. Refer to MTS2 section 2.3 for more information pertaining to the key id.