## 6 Implementation
In public blockchains, e.g., Bitcoin or Ethereum, the identity of a transaction sender is cryptographically generated by its public key; therefore, each identity is linked with a unique private key, and it is immovable. However, in Hyperledger Fabric, the identity is linked with the public key through a certificate, and, in the case of the part, it is issued by the supplier. Then, the supplier could also issue a second certificate for a part's identity with another SE, which would allow for a package donation. To avoid this threat, when a part is registered in the SCM, the SE's public key is also stored in the smart contract. Then, in every change in ownership, the identification mechanism of HyperledgerFabric has to be modified to assert that the public key of the SE is the same as the stored public key as shown in Figure 4.  
With this solution, we have created a secure and fully functional smart contract that distinguishes between the privileges of users when accepting transactions and delivering information to the stakeholders. Using this same mechanism, other private collections can be created for other uses and more complex data access policies can be defined if necessary. At the same time, this mechanism maintains blockchain's reliability in the private collections since the hash of the private data is stored in the blockchain consortium. To test and validate the capabilities offered by this approach, we used an actual HSM with NFC, and NFC readers, which interact with the smart contract deployed in a privacy-preserving blockchain. To facilitate this process, each participating organization deployed an NFC reader comprising an ACR122U NFC Reader and a Raspberry Pi \begin{table}
\begin{tabular}{c c c} \hline \hline
**Structure** & **Description** & **Access Rights** \\ \hline \multirow{4}{*}{Contracts} & Agreement between the manufacturer and the & Supplier(R/W), \\  & supplier. It contains common data such as & Distribution(R/W), \\  & name and number of the components, expected & Manufacturer(R/W), \\  & delivery date, and all the logistic details & Aviation Authority(R) \\ \hline \multirow{4}{*}{Obj\&Comp.} & Each component is linked to objectives or \\  & requirements expressed by the manufacturer. & \\  & The same data structure contains the & \\  & compliance measurements that the supplier & \\  & provides to prove adherence to the & \\  & requirements. Requirements and quality & \\  & measurements are considered sensitive data & \\  & since they contain intellectual property and & \\  & related information. & \\ \hline \multirow{2}{*}{PriceAgr.} & Each contract has an economical agreement & Supplier(R/W), \\  & & linked to it. & Manufacturer(R/W) \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Data assets and protection policies. Figure 4: New lines used to identify the parts using their public key instead of their IDs. Figure 3: Secure architecture of a modern blockchain-based SCM applied to manufacturing use case. 4B, as illustrated in the setup in Figure 5. To execute the test, we used a configurable smart-card, SecoraTM ID S V1.1 [48], attached to the parts. This smart card possessed the necessary secure functionalities required for our proposed solutions, bringing us closer to market implementation.