# Decentralized Documentation of Maritime Traffic Incidents to Support Conflict Resolution
## 4 Concept  
As already described in the requirements from Section 2.4, it is crucial for trustworthy documentation that it can be verified that the recorded data has not been changed intentionally or unintentionally. This assurance can be provided by timestamp authorities which is fast and efficient compared to alternative approaches such as blockchain technologies for the certification of data [13, 40]. Therefore, this paper presents a TSA-based concept to document critical traffic incidents in a decentralized scenario. The certification process of TSAs is analogous to the certification processes of a PKI. However, in this case, an authority is used to certify the existence of a date at a specific time instead of the identity of an entity (c.f. Figure 1). For this purpose, the requestor sends its data that should be certified in hashed form to the TSA. This is done to reduce the payload and to avoid exposing the actual data to the TSA. The TSA adds the current timestamp to the transmitted data hash and hashes the data again. The TSA then sends the signed document back to the requester. The requester needs to persist the original data and the TSA's digital signature. If the requester wants to prove that their data has existed at a certain point in time and has not been changed, they can verify this cryptographically in two steps (c.f. Figure 2). In the first step, a hash is created based on the data using the same hash method that was applied by the requester during the timestamp process. Subsequently, the exact timestamp at which the TSA has signed the data is added to this hash. This document is hashed again with the hash procedure used by the certifying TSA. In the second step, the cryptographic signature of the document is decrypted using the TSA's public key. The hash that was derived in this process is then compared with the hash value from step 1. If the two values match, the verification was successful, and it can be assumed that the data already existed at the specified time. If the two hash values differ, there can be many reasons for this. For example, it is possible that the data was changed or that it was signed at a different time. Regardless of the reason, the verification failed in this case. In this way, it is possible to verify whether data was available at a certain point in time by utilizing a TSA. However, the main issue with using an authority to establish trust is that all the trust depends on the authority itself. Thus, the signature of a TSA has only some value if the parties, to whom something should be proven, also trust this single TSA. Consequently, if an architecture is built based on only one authority, this directly leads to a problem if only one of the involved parties does not trust this central TSA. Especially in the global maritime domain, in which many different stakeholders from various fields and nations meet, an agreement on a worldwide central authority is not feasible. The utilized architecture must therefore ideally support the use of arbitrary TSAs, so that the  
Figure 1: Timestamping process between a requester and a TSA [41]. Figure 2: Verification process of timestamped data [41]. parties involved can individually agree on a single or a set of trusted TSAs in the specific situation. In this way, trust is maximized as each participant can communicate their trusted TSAs instead of choosing from a predefined set of authorities. Since the participants in a traffic event usually do not know each other beforehand, the agreement on the set of jointly trusted TSAs must happen before a critical traffic situation. Figure 3 shows the proposed architecture that enables the involved stakeholders to document their data in a trustworthy and decentralized scenario without using a central instance for coordinating the agreement on a TSA. The entire architecture consists of five components:  
* P2P-Network--Basis for communication between the involved participants of an incident that should be recorded.