# Comparison of Distributed Tamper-Proof Storage Methods for Public Key Infrastructures
## 3 Concepts and Evaluation Methods
### Public IPFS-Filecoin
#### Hyperledger Fabric
Nevertheless, modern cryptographic signature schemes are more often used in these communication scenarios. This process is also fostered by more modern and potent hardware on the sensor side that allows for faster signing of data packets. The authenticity of data is crucial in most industrial scenarios since no malicious sensor nodes shall be able to intervene within the network, e.g., by using unauthenticated data requests or by acting as a Man-in-the-Middle (MitM) and manipulating well-intended data packets. Therefore, [PERSON] et al. proposed a novel public key exchange scheme based on the Near Field Communication (NFC) as a transport medium [7]. The main idea of the concept assumes that each sensor is capable of signing a given data packet using its own secret key \(SK_{S}\). The resulting signature can be verified using the corresponding public key \(PK_{S}\). In practice, this basic concept works until a malicious actor joins the network and begins signing his own data packets. Therefore, the proposed NFC-KE concept involves a central PKI-like entity, called _Signing Hub_, that is responsible for verifying access to the network and thus allowing for communication. Since only previously authenticated publickeys will be added to the system, this process is called an _authentic public key exchange_. The Signing Hub is comprised of a TPM connected, in this case, to a Raspberry Pi microcontroller. Additionally, it has an NFC-Reader attached to its serial port allowing for NFC tags to be read and written. The main challenge-response protocol of the NFC-KE is depicted in Figure 1.  
The fundamental working principle of the NFC-KE requires a physical Proof-of-Possession scheme to be performed between the Sensor Node and the Signing Hub. Using the NFC, which requires a close physical distance for communication, a cryptographic token can be exchanged between the two parties, thereby implicitly proving authorization due to the low likelihood of an unauthorized NFC-communication. For further details on the NFC-KE, the reader is referred to the original paper [7]. Due to its lightweight setup and its ability to be implemented using low-cost hardware, the NFC-KE scheme is a valid candidate for low-resource PKI replacement in Industry 4.0 and Industrial Internet of Things (IIoT) environments in general. The NFC-KE in its basic variant is susceptible to arbitrary file-tampering if an attacker is able to exploit a potentially unknown software vulnerability, e.g., by infiltrating the Raspberry Pi microcontroller. The properly exchanged authentic public keys of the Sensor Nodes are stored as certificate files on the Signing Hub. If an attacker had access to the filesystem, arbitrary upload and manipulation of said files could be possible. In the worst case, an attacker could be able to inject a nonauthorized public key and thus circumvent the whole authorization mechanism. This, therefore, creates a general single point of failure, as well as a setup vulnerable to public key tampering. To remedy this problem, [PERSON] et al. also proposed an extension to the former NFC-KE protocol that is using the HLF Blockchain for a more decentralized data storage of the public keys [25; 26]. The new approach essentially replaces the standard filesystem-based storage approach of the NFC-KE scheme in favor of a Blockchain-based approach. Instead of storing and implicitly validating the newly exchanged Sensor Node's public key on the Signing Hub device itself, this functionality is outsourced to an external Blockchain Platform, in this case, HLF. The authors showed that using their approach, the NFC-KE experiences, on the one hand, a decrease in performance while, on the other hand being more tolerant against system outages, tampering attempts and unauthorized access due to the higher redundancy and tamper resistance of the HLF platform. For their new approach, the authors introduced two new network participants, one being the Application Server and the other being the HLF instance (s. Figures 2 and 3).