## 6 Implementation  
The proposed solution was implemented using the permission blockchain framework Hyperledger Fabric (HPL) [39]. Using this framework, we created a blockchain-based SCM system with enhanced access control providing strong confidentiality, data traceability, and non-repudiation guarantees. Figure 2: Two-step transaction infrastructure used to change the ownership of a package in the smart contract in the blockchain. The numbers in the figure refer to the enumerated steps in the text. In this implementation, we consider four stakeholders: supplier, distribution, manufacturer, and safety certification authority. These entities interact with the SCM using a smart contract with their validated credentials as defined in the permission blockchain HPL. Only using the validated credentials can the information in the blockchain be accessed, or can new information be uploaded, obtaining privacy with respect to the external users. The smart contract implements the following functions:  
* Orderpart: the manufacturer executes Orderpart by sending a transaction to the blockchain. It creates the data structures Contract, Objective&Compliance, and PriceA-greement, which contain the information about the requested order, e.g., qualification data or price. * AcceptContract: the supplier accepts the order executing AcceptContract, including in the function the Contract identifier. * SendPart: the supplier executes SendPart to register the SE's public key and link it with the ordered part. * AcceptDeliveryContract: a distributor with access to the blockchain can accept delivering this order by executing the function AcceptDeliveryContract and providing the Contract identifier. * ProposedOwnershipChange and AcceptOwnershipChange: these functions are triggered in order to execute a secure ownership change. Their functionality is detailed in Section 5.2. To avoid the elevation of privileges to modify smart contract data, assertions are placed in each smart contract function to confirm that the triggering user is authenticated with the validated credentials and is part of an organization authorized to execute that specific action. For example, in our scenario, only the manufacturer is allowed to execute Orderpart to order a part from the supplier. If any other organization attempts to trigger the function Orderpart, the validation process of the peers will detect an assertion failure and reject it. Even if actions identified by the smart contracts are strongly regulated, HLF exposes a query engine, which allows any participant in the blockchain to read the state of the ledger. This action is always permitted and is not regulated by the smart contract. Therefore, in order to enforce the least knowledge principle and to maintain data confidentiality, HLF proposes the Private Data Collections (PDCs) functionality to regulate data read access. Firstly, we identify three data structures with different access rights as shown in Table 2. Then, as shown in Figure 3, the Contract structure is stored directly in the blockchain, and therefore the four stakeholders can read it. Instead, Objective&Compliance and PriceAgreement structures are shared using Private Data Collections (PDCs), which send data peer-to-peer via gossip protocol to only the partner(s) authorized to access it. This information is stored in a private database on the peers of the authorized organizations, and it can be read only through smart contract functions. A hash value of each PDC entry is written on the ledger state as proof of existence and can be inspected by every participant on the blockchain. The hash serves as evidence of the transaction, is used for state validation, and can be used for audit purposes [51]. Notice in Figure 3 that one data structure is openly accessed by every participant in the system (yellow line) while the other data containers have restricted access (orange line). Finally, to avoid a spoofing attack on the part's identity, it is important to link it to the public key on the SE immovably.