Date: Thu, 28 Mar 2024 13:35:43 +0000 (UTC) Message-ID: <27955386.5.1711632943877@623a7dccca58> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4_397042816.1711632943876" ------=_Part_4_397042816.1711632943876 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The security of the BoB infrastructure relies heavily on strong = cryptographic mechanisms to secure data integrity and data origin authentic= ation. Secure management of the private encryption keys are therefore of ut= most importance. This chapter provides an overview of which types of keys a= re 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 pa= rticipant. 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 t= he receiving party.
For this reason, a participant need to generate its own Participant Meta= data 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 Func= tion 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 secu= re 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 exc= hange other types of keys securely. Therefore, it is of utmost importance t= hat 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.
The authentication of end-entities within the BoB infrastructure relies = upon a federated approach based in assertions in the JSON Web Token (JWT) f= ormat. These assertions are cryptographically signed, and the public compon= ent of such keys used for signing are exchanged through the Metadata as exp= lained above.
In addition, each end-entity requires its own keys to be able to authent= icate 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, bo= th 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 prede= fined schedule if the participants entity management supports it. Rolling k= eys may be motivated by the fact that keys may be stored in devices install= ed in non-secure environments, such as vehicles and hand-held devices.
Two types of key-pairs are used in the Ticketing process. The first is t= he Manifest Signing Key, which the Price- and Product Service utilises to i= ssue manifests to the Sales Channel. These manifest can then in the next st= ep be sent to the Ticketing Service to request the issuance of the correspo= nding ticket. The Ticketing Service will check the signature attached to th= e manifest by the Price- and Product Service and, if it validates the authe= nticity of the manifest, issue the ticket. This implies the Ticketing Servi= ce needs to trust the Price- and Product Service's public keys. However, th= is is an internal key exchange with needs to happen within a participants o= wn 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 Ticketi= ng Service to ensure the authenticity and integrity of issued tickets. Thes= e tickets need to be distributed to all participants who shall be able to t= rust tickets issued by that Ticketing Service. These keys are named mtbPubl= icKeys in the metadata. Rolling such keys on a schedule requires some plann= ing, as already issued tickets otherwise may become invalid. As a rule of t= humb, 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 par= ticipant is required to retrieve new metadata. For metadata managed by Samt= rafiken, 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 t= he Ticket Signing Keys, not only to be able to manage key roll-overs smooth= ly, but also to minimise risks for duplication of high-value ticket. The si= gnature life-time is set using the exp parameter in the Issuer Signature Pr= otected Header (refer to MTS1 section 2.4). Under all circumstances, the si= gnature does not have to be valid beyond the life-time of the ticket. For t= ickets with a validity longer than a few days, it may be appropriate to res= trict 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 tick= ets by downloading it into a device, and then report the device as lost (di= sconnecting it from any networks) and retrieve the same ticket into a new d= evice. 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 reas= ons for requiring regular updates (and re-printing) to limit the value of s= uch 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 issu= ed tickets. The concept of combining and re-distributing a ticket works by = an entity, such as a sales channel, retrieves tickets from several differen= t participants, removing the outer structure of each of them, combining the= m into one and subsequently adds its own signature. A participant can indic= ate, through the metadata, which other participants are allowed to re-distr= ibute tickets and what the maximum life-time of such signatures may be.
Device keys are used to provide a layer of copy protection when electron= ic tickets are held in different types of portable devices, such as smart p= hones and tables. In such devices, a ticket are usually optically represent= ed. 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 s= hot and present it to the optical reader of a validating device. To limit s= uch possibilities it is recommended to include some information relating to= time or location within the outer signature (refer to MTS1 section 2.5), s= uch 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 d= evice. This outer signature is created using the unique Device Key.
Such Device Keys may be created using a Key Derivation Key (KDK) which i= s common to an application providers (usually a sales channels) all devices= . This KDK can then be shared among the participants which should be able t= o validate the device signature protection. The KDK is a symmetric key whic= h needs to be held confidential to any adversaries. For this reason it is n= ot exchanged through the Metadata, but rather provided bilaterally using th= e 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 dis= tributed over a potential large number of participants and devices. The req= uired timing for updating the KDK is determined bilaterally between the par= ticipants, which would also affect any roll-over schedules. KDKs are genera= lly 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 receiv= ing 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 c= orresponding KDK. For this reason, each KDK can result in any number of sub= keys 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.