Over the public Internet network it is possible to implement a hybrid Peer to Peer model with a common interface at each actor's node and a central certificate authority.
Afterwards, a Peer to Peer communication is performed between involved players.
The peer-to-peer communication is based on technical standards for the common Interface described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I.
4.2.12.3.
Security
To achieve a high level of security, all messages must be self-contained, which means that the information in the message is secured and the receiver can verify the authenticity of the message. This may be solved by using an encryption and signing scheme similar to email encryption.
4.2.12.4.
Encryption
Either asymmetric encryption or a hybrid solution based on symmetric encryption with public key protection must be used, due to the fact that sharing a common secret key among many players will fail at some point. A higher level of security is easier to achieve if every actor takes responsibility for its own pair of keys, even though a high level of integrity of the central repository (the key server) is required.
4.2.12.5.
Central Repository
The Central Repository must be able to handle:
— metadata — structured data describing the content of messages,
— Public Key Infrastructure (PKI),
— Certification Authority (CA),
The management of the central repository should be under the responsibility of a non-commercial co-European organisation. Where the Central Repository is in use in conjunction with the TAP TSI (2), development and changes must be in line with TAP TSI (2) in order to achieve optimum synergies.
4.2.12.6.
Common Interface
A Common Interface is mandatory for each actor in order to join the rail interoperability community.
A Common Interface has to be able to handle:
— message formatting of outgoing messages according to the metadata,
— signing and encryption of outgoing messages,
— addressing of the outgoing messages,
— authenticity verification of the incoming messages,
— decryption of incoming messages,
— conformity checks of incoming messages according to metadata,
— handling the single common access to various databases.
Each instance of a Common Interface will have access to all the data required according the TSI within each Wagon keeper, LRU, RU, IM, etc., whether the relevant Databases are central or individual (see also document ‘TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages’, Chapter 1.6, listed in Appendix I).
Where a Common Interface is in common use with the TAP TSI (2), the development and changes must be in line with TAP TSI (2), in order to achieve optimum synergies. Based on the results of authenticity verification of incoming messages, a minimum level of message acknowledgement can be implemented:
(i) positive send ACK;
(ii) negative send NACK.
A common interface uses the information in the central repository in order to manage the above tasks.
An actor may implement a local ‘mirror’ of the central repository to shorten response times.
4.3.
Feedback