D4.4: TBOM Security and Trust Mechanism (first version)

D4.4 – TBOM Security and Trust Mechanism (first version) PROJECT Project Number 101120962 Project Acronym RESCALE Project Title Revolutionised Enhanced Supply Chain Automation with Limited Threats Exposure Start Date 01.10.2023 Programme HORIZON-CL3-2022-CS-01-02 DELIVERABLE Deliverable Type R - Document Report Workpackage WP4 Deliverable Lead ICERT Editors Alessandro Visintin Contributors ISI, AEGIS, INT, EISI, CBRL, DIE, UNSPMF, ICERT, BNR Dissemination Level Public Abstract This document presents the security and trust mechanisms for TBOM within the RESCALE project. It outlines a robust framework that leverages blockchain technology, cryptographic methods, and smart contracts to ensure the integrity, authenticity, and confidentiality of TBOM data. The document details the selection criteria for the blockchain platform, with a focus on Hyperledger BESU, and explores the integration of IPFS for distributed storage. It also addresses compliance with international standards and regulatory requirements, including GDPR and cybersecurity regulations. The security framework encompasses identity-based access control, permissions management, and integration with external PKI services. Disclaimer The information in this document is provided “as is”, and no guarantee or warranty is given that the information is fit for any particular purpose. The content of this document reflects only the author’s view – the European Commission is not responsible for any use that may be made of the information it contains. The users use the information at their sole risk and liability. This project has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No 101120962 D4.4 – TBOM Security and Trust Mechanism (first version) Document Revision & Quality Assurance Internal Reviewers 1. Danijela Boberic Krsticev - (UNSPMF) 2. Konstantinos Latanis - (S5) Revisions Version Date Partner Overview 0.1 22/07/2024 ICERT ToC 0.2 02/09/2024 ICERT Sections structured 0.5 21/11/2024 ICERT Finished draft 0.6 29/11/2024 ICERT, UNSPMF, S5 Internal review and text updated 0.7 04/12/2024 ICERT Text updated 0.9 07/12/2024 ISI, AEGIS Final comments 1.0 10/12/2024 BNR Final version RESCALE – Public – Page 2 / 61 Table of Contents 1 Introduction 7 1.1 Scope&Contribution............................... 7 1.2 Relation to Work Packages, Deliverables, and Activities . . . . . . . . . . . . . 7 1.3 Contribution to Work Package 4 and Project Objectives . . . . . . . . . . . . . 8 1.4 Structure of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 Security and Trust Framework for TBOM Management 9 2.1 Supply Chain Security, Trust Models, and Compliance . . . . . . . . . . . . . 9 2.1.1 Security Challenges and Trust Models in Supply Chains . . . . . . . . 9 2.1.2 Compliance with Standards and Regulatory Requirements . . . . . . . 11 2.2 Technical Mechanisms for TBOM Security . . . . . . . . . . . . . . . . . . . 13 2.2.1 Core Security Features, Cryptography, and Additional Attributes . . . . 14 2.2.2 Identity-Based Access Control and Permissions Management . . . . . . 15 3 Ledger Infrastructure for the Trusted Bill of Materials 17 3.1 Selection Criteria for the Ledger Platform . . . . . . . . . . . . . . . . . . . . 17 3.1.1 Justification for Using Blockchain as a Ledger . . . . . . . . . . . . . . 17 3.1.2 Key Criteria for Selecting the Blockchain Platform . . . . . . . . . . . 18 3.2 Overview of blockchain platforms . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.1 BESU as the Preferred Ledger for RESCALE . . . . . . . . . . . . . . 21 3.2.2 Consensus Mechanism, Security, and Governance in BESU . . . . . . . 23 3.3 The Role of the InterPlanetary File System in the Trust Storage Architecture . . 26 3.3.1 Introduction to IPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.2 Integration of IPFS in the Trust Storage System . . . . . . . . . . . . . 28 4 Smart Contract Implementation for TBOM Management 30 4.1 General Properties of Smart Contracts . . . . . . . . . . . . . . . . . . . . . . 30 4.1.1 Introduction to Smart Contracts . . . . . . . . . . . . . . . . . . . . . 30 4.1.2 Benefits of Smart Contracts for TBOM Management . . . . . . . . . . 32 4.2 Smart Contract Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1 Basic Implementation: HashStorage.sol . . . . . . . . . . . . . . . . . 33 4.2.2 Advanced Implementation: HashManager.sol . . . . . . . . . . . . . . 35 4.2.3 Comparative Analysis of Implementations . . . . . . . . . . . . . . . . 37 5 Rescale Trusted Storage Architecture and Implementation 40 5.1 ArchitectureOverview .............................. 40 5.1.1 Confidentiality, Integrity and Availability . . . . . . . . . . . . . . . . 40 5.1.2 The networking system . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.1.3 Certification Authority Integration . . . . . . . . . . . . . . . . . . . . 42 5.1.4 Key Management System . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Implementationstrategy.............................. 44 5.2.1 TrustStorageNode............................ 44 5.2.2 TrustStorageClient............................ 50 6 Potential Challenges and Risks 54 6.1 Scalability and Performance Concerns . . . . . . . . . . . . . . . . . . . . . . 54 6.2 Security Risks and Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . 54 3 D4.4 – TBOM Security and Trust Mechanism (first version) 6.3 Legal and Regulatory Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.4 Integration Complexities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.5 User Adoption and Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7 Roadmap and Future Work 57 8 Conclusions 59 RESCALE – Public – Page 4 / 61 List of Figures 1 CertificateIssuanceFlow............................... 42 2 Certificate Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3 Trust Storage module structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4 Sequence diagram of add document() operation. . . . . . . . . . . . . . . . . . . . 52 5 Sequence diagram of get document() operation. . . . . . . . . . . . . . . . . . . . 53 6 Sequence diagram of deprecate document() operation. . . . . . . . . . . . . . . . 53 5 D4.4 – TBOM Security and Trust Mechanism (first version) List of Abbreviations ABI Application Binary Interface. 44 BFT Byzantine Fault Tolerance. 18 CA Certification Authority. 42, 43 CI/CD Continuous Integration and Continuous Deployment. 10 CID Content IDentifier. 27–29, 51, 52 CSR Certificate Signing Request. 42 DPoS Delegated Proof of Stake. 21 EEA Enterprise Ethereum Alliance. 21, 23 EVM Ethereum Virtual Machine. 21, 55 GDPR General Data Protection Regulation. 1, 12, 13, 22, 55 IBAC Identity-Based Access Control. 15, 16 IBFT Istanbul Byzantine Fault Tolerance. 21–25 ICT Information and Communication Technology. 12 IPFS Inter-Planetary File System. 1, 8, 26–29, 40, 41, 44, 48, 50–52, 54, 59 JWT JSON Web Token. 14 KMS Key Management System. 43 PKI Public Key Infrastructure. 1, 14–16, 57 PoA Proof of Authority. 22, 24, 25 PoS Proof of Stake. 18, 20, 21, 24, 25 PoW Proof of Work. 18, 20, 22, 24 QBFT Quorum Byzantine Fault Tolerance. 22–25, 44–46 RBAC Role-Based Access Control. 13, 57 SBOM Software Bill of Materials. 12 TBOM Trusted Bill of Materials. 1, 7, 8, 11–18, 28–33, 38–41, 43, 54–57, 59 TPS Transactions Per Second. 21, 22 TTP Trusted Third-Party. 11 ZKP Zero-Knowledge Proof. 14, 41, 57 RESCALE – Public – Page 6 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 1 Introduction The RESCALE project works to improve supply chain security by design, focusing on automating the assessment of software and hardware components to minimize vulnerabilities. The purpose of this project is to develop detailed cybersecurity audit processes and build reliable systems with strong security assurances. Through systematic analysis and improvement of each layer in computing systems, RESCALE creates and applies new methods and tools throughout the supply chain. This document outlines the project’s progress by detailing the security and trust mechanisms for Trusted Bill of Materials (TBOM), along with relevant background and considerations. 1.1 Scope & Contribution This document outlines the security and trust approaches for the TBOM, including a review of current technologies and plans to implement them in practice. It gives the RESCALE project, especially Work Package 4 (Task 4.3), key details needed to build a secure and reliable TBOM system. The security and trust methods are described in enough detail to start development, but since this document comes out before full implementation begins, we expect that some unexpected issues may arise. We will summarize any needed changes to these methods in a later document. 1.2 Relation to Work Packages, Deliverables, and Activities This document originates from Task 4.3 in Work Package 4, but it’s also connected to Work Packages 3 and 5. Connection to Work Package 3. Task 4.3 produces a secure storage module for TBOMs. This secure storage module provides a robust and reliable repository for storing the TBOMs generated in Work Package 3. The integration ensures that the security assessment results and TBOMs produced in Work Package 3 are stored securely and with integrity, enhancing the overall security posture of the RESCALE framework. Connection to Work Package 5. The security and trust mechanisms developed in Task 4.3 will undergo testing and validation as part of the overall system demonstration in Work Package 5. This validation process in Work Package 5 will provide practical information on the effectiveness of the TBOM security framework and the secure storage module in real-world scenarios. Feedback from Work Package 5 demonstrations may inform potential refinements to the security and trust mechanisms. Deliverable D4.4 is an important part of building a secure supply chain, focusing on making TBOMs safe and trustworthy. These security and trust features are key to the goals of the entire project. RESCALE – Public – Page 7 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 1.3 Contribution to Work Package 4 and Project Objectives Deliverable 4.4 is a result of Task 4.3 in Work Package 4. It contributes to achieving two key objectives of the RESCALE project: 1. Objective 1: Design and develop a complete toolbox to audit and increase the security of supply chain based on emerging technologies for both hardware and software modules. 2. Objective 3: Provide a Trusted BOM approach that will infuse trust in software and hardware supply chain and promote trusted updates. For Objective 1, the deliverable proposes the design of the Trust Storage module that provides a secure way to store TBOMs in a decentralized fashion. This module is a core component of the toolbox for enhancing supply chain security, leveraging emerging technologies for both hardware and software modules. As for Objective 3, the deliverable adds to the TBOM security construction by providing a platform where TBOMs can be stored, retrieved, and deprecated while ensuring core cryptographic properties. This contribution directly supports the Trusted BOM approach, infusing trust in the software and hardware supply chain and promoting trusted updates. 1.4 Structure of the Document The rest of this document is structured as follows. • Section 2 presents the Security and Trust Framework for TBOM Management. It covers supply chain security challenges, trust models, compliance requirements, and technical mechanisms for TBOM security. • Section 3 describes the Ledger Infrastructure for TBOMs, including selection criteria, justification for using blockchain, and an overview of Hyperledger BESU. It also discusses the role of Inter-Planetary File System (IPFS) in the trust storage architecture. • Section 4 details the Smart Contract Implementation for TBOM Management, covering general properties of smart contracts and specific implementations. • Section 5 outlines the RESCALE Trusted Storage Architecture and Implementation, providing an architecture overview and implementation strategy. • Section 6 discusses potential Challenges and Risks, including scalability concerns, security risks, and legal/regulatory challenges. • Section 7 presents the roadmap and future work, covering planned enhancements, further smart contract development, and integration with other RESCALE components. • Section 8 concludes the document. Each section provides detailed information on key aspects of the TBOM security and trust mechanisms, from high-level frameworks to specific technical implementations and future plans. RESCALE – Public – Page 8 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 2 Security and Trust Framework for TBOM Management 2.1 Supply Chain Security, Trust Models, and Compliance This section explores the critical security challenges and evolving trust models within modern supply chains, focusing on the complexities and risks associated with global software and hardware inter-dependencies. Section 2.1.1 outlines the primary security risks and trust mechanisms emerging in response to the heightened threat landscape, covering areas such as code integrity, counterfeit hardware, and dependency management. Section 2.1.2 then addresses the importance of adhering to international standards and regulatory frameworks to ensure supply chain resilience and regulatory compliance. 2.1.1 Security Challenges and Trust Models in Supply Chains In the contemporary digital landscape, supply chains for software and hardware components are increasingly distributed, complex, and interdependent. This inter-connectivity, while essential for accelerating innovation and reducing development costs, introduces considerable security vulnerabilities. The dependence on third-party components and global distribution networks has turned supply chains into lucrative targets for adversaries aiming to infiltrate systems at scale. Notably, recent high-profile incidents, such as the SolarWinds [2] and Log4j [12] breaches, have underscored the need for robust security measures within supply chains, prompting a shift towards new trust models and heightened security standards. Supply chains encounter numerous security challenges [25] stemming from their reliance on third-party components and extensive integration processes. These challenges are multifaceted, affecting both software and hardware domains, and necessitate a holistic view of supply chain security: Code Integrity and Software Tampering. In an era of modular software development, software applications rely heavily on third-party libraries, frameworks, and packages, often sourced from open-source or commercial vendors. This reliance introduces risks of code tampering or insertion of malicious code. Attackers can modify source code to insert malware or back-doors that may remain undetected, as third-party software undergoes limited scrutiny during integration. Ensuring code integrity through cryptographic signatures and strict version control mechanisms is critical to preventing such risks. Counterfeit and Malicious Hardware Components. Hardware components sourced globally are vulnerable to counterfeiting and tampering. Counterfeit hardware can degrade system performance or introduce latent vulnerabilities, while malicious hardware may include embedded threats that can compromise downstream components. Hardware Trojans [30], for instance, are unauthorized modifications introduced during manufacturing that can be activated later to disrupt functionality or extract sensitive information. This threat underscores the need for robust validation processes and a verified chain of custody across hardware supply chains. Dependency Management and Cascading Vulnerabilities. Modern software applications are RESCALE – Public – Page 9 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) only authorized users can access the TBOM: Signature Verification at Transaction Time. Each transaction on the blockchain requires a cryptographic signature from the sender, generated using the sender’s private key, which corresponds to a unique public blockchain address. This signature serves as a digital identifier, establishing the sender’s identity at the transaction level. When a user initiates a transaction, the blockchain network verifies the signature against the sender’s public address, authenticating the transaction and confirming the request’s origin. This signature verification process ensures that only entities with cryptographically verified identities can interact with TBOM data, enforcing IBAC principles by tying access to verified identities. Additionally, the private/public key pairs used in this process can be associated with external PKI services, enhancing the level of trust in the system. By linking blockchain addresses to PKI-verified certificates, the framework gains higher assurance of the identity’s authenticity, reducing risks associated with key compromise or impersonation. This integration with external PKI strengthens the TBOM’s security by validating not only the ownership of cryptographic keys but also the legitimacy of each user’s identity according to recognized PKI standards. Smart Contract Access Verification through Sender Address. Beyond signature verification, smart contracts introduce an additional programmable layer of access control. Smart contracts within the TBOM framework contain predefined rules that enforce permissions based on the sender’s blockchain address. When a transaction is submitted, the smart contract checks the sender’s address against an authorized list or defined access levels embedded in the contract. If the sender’s address is not recognized or lacks the required access level, the smart contract automatically rejects the transaction, preventing unauthorized access to TBOM data. This smart contract-based verification mechanism allows for dynamic, role-based access control. TBOM administrators can define permissions according to roles such as supplier, auditor, or verifier—directly within the smart contract, linking access rights to specific identities. By embedding permissions into smart contracts, the TBOM framework aligns with IBAC principles, ensuring that only designated roles with verified identities can access, modify, or validate TBOM entries. RESCALE – Public – Page 16 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 3 Ledger Infrastructure for the Trusted Bill of Materials 3.1 Selection Criteria for the Ledger Platform This section examines the foundational technologies and architectural components underpinning the RESCALE project’s TBOM framework. Section 3.1.1 provides a comprehensive justification for employing blockchain technology as the core ledger system, highlighting its unique attributes that align with RESCALE’s requirements for security, transparency, and decentralization. Section 3.1.2 delves into the selection criteria for choosing an optimal blockchain platform, presenting a detailed comparison of prominent solutions. 3.1.1 Justification for Using Blockchain as a Ledger A ledger is fundamentally a record-keeping system, designed to log transactions, events, or changes in data over time in a secure, organized manner. Traditionally, ledgers have been pivotal in finance, logistics, and supply chain management, where each transaction or alteration must be logged and validated to ensure accuracy and trust among stakeholders. Commonly used ledger examples include: •Centralized Financial Ledgers. Managed by banks or financial institutions, these track transactions between accounts, ensuring transparency and regulatory compliance within a centralized structure. •Distributed Databases. Used in corporate settings to record asset movements, regulatory compliance logs, or audit trails, enabling multiple users within the organization to interact with a unified data source. •Digital Health Records. Distributed yet tightly regulated, these ledgers track patient information and medical history, balancing the need for privacy with authorized access across health networks. While these traditional ledgers are effective in specific scenarios, they are limited by centralized control, which often introduces risks of tampering, inconsistencies in record-keeping, and single points of failure. Blockchain presents an innovative approach to ledger management, particularly for decentralized and secure applications like RESCALE. Unlike traditional ledgers, blockchain is decentralized, meaning it operates across a network of nodes that collectively verify and maintain the integrity of each transaction. Each block in the chain contains a cryptographic hash of the previous block, a timestamp, and transaction data, making the chain inherently secure and resistant to tampering. In contrast to centralized ledgers, blockchain operates without a single point of authority, distributing verification across its network of participants. This decentralization enhances transparency, resilience, and trust in the recorded information—a critical factor for the RESCALE RESCALE – Public – Page 17 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) project, which aims to secure supply chains against complex vulnerabilities and enhance trust between stakeholders. Blockchain’s unique attributes align well with RESCALE’s TBOM requirements, offering the following essential properties: •Security and Immutability. The cryptographic backbone of blockchain ensures that once data is recorded, it cannot be altered or deleted without consensus from the network, making it highly tamper-resistant. This immutability is critical for maintaining the integrity of the TBOM across the supply chain, where modifications to component data could otherwise go unnoticed. •Transparency and Accountability. Blockchain’s distributed nature allows all participants to independently verify the contents of the ledger, creating a transparent and accountable record for each transaction. For RESCALE, this means that all supply chain stakeholders can validate TBOMs directly, fostering trust across entities without relying on a central authority. •Automation and Self-Execution via Smart Contracts. Blockchain enables programmable, self-executing transactions through smart contracts, which operate based on pre-defined rules. This automation is essential for RESCALE’s compliance and auditing needs, as it allows smart contracts to perform routine checks and validations automatically, reducing overhead and ensuring that the TBOM remains compliant with standards at all times. •Decentralization and Resilience. Unlike centralized ledgers that are vulnerable to outages and breaches, blockchain’s decentralized architecture enhances resilience, with each node maintaining a complete copy of the ledger. This ensures continuity and data integrity, even if parts of the network experience failures, supporting RESCALE’s goal of a secure, robust supply chain system that minimizes risks of data loss or tampering. 3.1.2 Key Criteria for Selecting the Blockchain Platform To choose the most suitable blockchain, a set of criteria evaluates blockchain platforms’ capabilities against the project’s needs: •Type. Distinguishes between public, permissioned, and private (local deployment) blockchains. This defines the level of openness and control over data access and transactions. •Consensus Mechanism. Determines how network participants agree on transactions, affecting security, energy efficiency, and transaction speed. Common methods include Proof of Work (PoW), Proof of Stake (PoS), and Byzantine Fault Tolerance (BFT). •Scalability. Measures transaction throughput in terms of transactions per second, critical for high-demand applications. •Security. Evaluates resistance to vulnerabilities, ensuring that data integrity and trust are maintained. •Interoperability. Assesses the blockchain’s ability to interact with other chains and systems, enhancing integration flexibility. RESCALE – Public – Page 18 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) •Governance. Describes the decision-making framework for protocol changes, affecting adaptability and evolution. Governance can be on-chain (protocol-encoded) or off-chain (managed by entities). •Cost. Measures transaction affordability, often essential for scalability in supply chain applications. •Developer Ecosystem. Reflects the size and activity of the blockchain’s developer community, influencing available resources and tool support. •Privacy: Indicates the confidentiality and privacy options provided by the blockchain, crucial for secure handling of sensitive supply chain data. •Compliance. Assesses the platform’s ability to meet legal and regulatory requirements, particularly significant for applications in regulated sectors. Building on the core properties needed for a secure and efficient ledger infrastructure in RESCALE, a set of specific evaluation metrics guides the selection of a blockchain platform. These metrics focus on critical aspects such as security, scalability, and interoperability, which align with RESCALE’s requirements for a trusted, resilient TBOM system. Table 1 summarizes these parameters, providing explanations and methods for quantifying each to support a structured comparison of candidate blockchain platforms. RESCALE – Public – Page 19 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) Table 1: Comparison metrics to assess blockchain platforms suitability. These metrics consider the essential factors impacting security, scalability, and integration capability, among others. Parameter Explanation Importance Quantification Type Distinguishes between public, permissioned, and private blockchains Determines decentralization level Public, Permissioned, Private Consensus Mechanism Describes how network participants reach agreement on transactions Affects security, speed, and energy efficiency Type of consensus mechanism Scalability (TPS) Measures transaction throughput High throughput is critical Numeric value representing TPS Security Assesses resilience to attacks and vulnerabilities Ensures data integrity and trustworthiness Qualitative assessment Interoperability Ability to integrate with other blockchains and external systems Enhances integration flexibility Qualitative assessment Governance Framework for decision-making on protocol updates Affects adaptability On-chain or offchain Cost (Tx Fees) Transaction costs required for conducting transactions Impacts affordability Numeric value in USD Developer Ecosystem Size and activity of the developer community Resource availability for development Qualitative assessment Privacy Level of data confidentiality and privacy Important for data protection Qualitative assessment Compliance Ability to meet regulatory and legal requirements Critical for regulated industries Qualitative assessment 3.2 Overview of blockchain platforms In the rapidly evolving landscape of blockchain technology, several platforms have emerged as prominent solutions for various use cases and it is essential to provide an overview of the most notable blockchain platforms. Ethereum (ETH) [9] is a decentralized, open-source blockchain platform known for its robust smart contract capabilities and extensive developer community. It is transitioning from a PoW to a PoS consensus mechanism with Ethereum 2.0 to improve scalability and reduce energy consumption. Ethereum’s native cryptocurrency is Ether (ETH). Transaction fees on Ethereum can be variable, ranging from $1 to over $50 depending on network congestion. Despite potential high costs, Ethereum’s widespread adoption and strong ecosystem make it a leading platform for decentralized applications. RESCALE – Public – Page 20 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) Binance Smart Chain (BSC) [3] is a high-performance blockchain network that uses Delegated Proof of Stake (DPoS) consensus. It offers high scalability and low transaction fees (around $0.10). BSC is compatible with the Ethereum Virtual Machine (EVM), allowing for seamless porting of Ethereum dApps. It provides a balance between performance and cost, making it popular for decentralized finance (DeFi) projects. However, the centralization of governance under Binance is a consideration for users seeking more decentralized platforms. Cardano (ADA) [15] uses the Ouroboros PoS protocol, emphasizing security and formal verification for smart contracts. It offers moderate scalability (250 Transactions Per Second (TPS)) and low transaction fees (around $0.17). Cardano’s governance is conducted on-chain through Cardano Improvement Proposals. It is designed for regulatory compliance and scientific rigor, attracting projects that prioritize security and sustainability. Solana (SOL) [20] combines Proof of History with PoS to achieve very high scalability (65,000 TPS) and extremely low transaction fees (about $0.00025). Its rapid growth and efficient consensus mechanism have made it a strong contender for dApps requiring high throughput. Solana’s governance is managed off-chain by the Solana Foundation, and the ecosystem is expanding quickly with substantial support for developers. Polkadot (DOT) [10] is designed for interoperability and scalability, using a Nominated Proof of Stake (NPoS) consensus mechanism. It allows multiple parachains to operate in parallel, offering high throughput and low transaction fees (0.05−0.10). Polkadot’s on-chain governance model enables DOT holders to participate in decision-making. It is suitable for projects requiring cross-chain communication and robust governance. Quorum [6] is a permissioned blockchain platform based on Ethereum, optimized for enterprise use. It supports Istanbul BFT and Raft consensus mechanisms, ensuring high performance and private transactions. Quorum has no native transaction fees, with costs tied to infrastructure. Its compatibility with Ethereum tools makes it a practical choice for enterprises looking to leverage Ethereum’s capabilities in a private setting. Corda [29] is a permissioned blockchain platform designed for financial services, focusing on privacy and scalability. It uses pluggable consensus mechanisms with notary services to ensure transaction validity. Corda does not have native transaction fees, and costs are related to infrastructure and maintenance. Its high level of privacy and compliance features make it suitable for regulated industries and consortiums requiring confidential transactions. Hyperledger BESU [23] is an open-source Ethereum client designed for both public and private permissioned network use cases. It implements the Enterprise Ethereum Alliance (EEA) specification and supports multiple consensus algorithms, including Proof of Work, Proof of Authority, and Istanbul Byzantine Fault Tolerance (IBFT) 2.0. BESU offers robust privacy features, permissioning capabilities, and enterprise-grade performance, making it highly suitable for complex business networks. 3.2.1 BESU as the Preferred Ledger for RESCALE After careful evaluation of prominent blockchain platforms, Hyperledger Besu emerges as the optimal choice for the RESCALE consortium. This selection is based on several key factors that align with the project’s objectives and requirements, particularly in revolutionizing supRESCALE – Public – Page 21 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) ply chain automation across diverse industrial sectors. The findings from the comparison are summarized in the Table 2. BCP TYP COM SCA SEC INT GOV COS DEV PRI CPL ETH PUB POS 15-30 HIGH LOW ONC $1-$50+ HIGH LOW LOW BSC PUB DPOS 90-100 MID HIGH CEN ˜ $0.10 HIGH LOW LOW SOL PUB POH POS 60K65K HIGH LOW OFF ˜ $0.00025 MID LOW LOW DOT PUB NPOS 1K HIGH HIGH ONC ˜ $0.05- $0.10 MID LOW MID QRM PER IBFT, Raft 150-2K HIGH LOW OFF NF MID HIGH HIGH CRD PER PLG 15-1.5K HIGH HIGH ONC, OFF NF MID HIGH HIGH BES PUB, PER POW, POA, IBFT, QBFT 500-1K HIGH HIGH ONC, OFF CUS MID HIGH HIGH Table 2: Comparison of Blockchain Platforms. The blockchain platforms (BCP) are abbreviated as ETH (Ethereum), BSC (Binance Smart Chain), SOL (Solana), DOT (Polkadot), QRM (Quorum), CRD (Corda), and BES (Hyperledger Besu). The type (TYP) of blockchain can be either Public (PUB) or Permissioned (PER). Consensus mechanisms (COM) include Proof of Stake (POS), Delegated Proof of Stake (DPS), Proof of History (POH), Nominated Proof of Stake (NPS), Istanbul BFT (IBF), Raft (RAF), Pluggable consensus (PLG), Proof of Work (POW), Proof of Authority (POA), and Quorum BFT (QBFT). Scalability (SCA) is measured in transactions per second, with thousands expressed as K. Security (SEC), Interoperability (INT), Developer Ecosystem Quality (DEV), Privacy (PRI), and Compliance (CPL) are rated as LOW, MID, or HIGH. Governance (GOV) can be On-Chain (ONC), Off-Chain (OFF), Centralized (CEN), or Customizable (CUS). Cost (COS) is expressed as a range in dollars, with some platforms having no native fees (NF) or customizable costs (CUS). Hyperledger Besu’s unique ability to operate in both public and permissioned environments provides RESCALE with unparalleled flexibility. This dual-mode capability allows for seamless integration with existing supply chain systems while maintaining the option to interact with public networks when necessary. Such versatility is crucial for a project of RESCALE’s scope and ambition. Furthermore, Besu’s support for multiple consensus algorithms (PoW, Proof of Authority (PoA), IBFT, Quorum Byzantine Fault Tolerance (QBFT)) offers the ability to finetune its blockchain infrastructure to meet specific security and performance requirements. This adaptability is particularly valuable in a research and innovation context, where different use cases may demand varying levels of decentralization and transaction finality. In terms of performance, Besu strikes a balance between high throughput and decentralization, with a transaction capacity of 500 −1KTPS. While not the fastest in raw TPS, its scalability is more than sufficient for most supply chain applications and can be optimized further if needed. This ensures that the RESCALE platform can handle increasing transaction volumes as the project expands. Equally important are Besu’s high ratings in security, compliance, and privacy, which are critical for a project dealing with sensitive supply chain data. These features align well with the stringent security requirements of Horizon Europe projects and the need to adhere to regulations such as GDPR. The high interoperability rating of Besu is another significant advantage for RESCALE, facilitating easier integration with existing enterprise systems and potential future cross-chain operations. This is essential for a project aiming to create a RESCALE – Public – Page 22 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) comprehensive supply chain solution. Besu’s support for both on-chain and off-chain governance provides RESCALE with the necessary tools to implement a governance structure that balances decentralization with the need for consortium-level decision-making, crucial for managing a complex, multi-stakeholder project within the Horizon Europe framework. From a resource management perspective, Besu’s customizable cost structure allows RESCALE to optimize transaction costs, ensuring efficient use of project resources. This is particularly important for a publicly funded research initiative where cost-effectiveness is a key consideration. While rated as moderate in developer ecosystem quality, Besu benefits from the broader Hyperledger community support, providing RESCALE with access to a wealth of resources, documentation, and potential collaborations within the open-source blockchain community. When compared to other platforms, Hyperledger Besu offers distinct advantages. Ethereum and Binance Smart Chain, while popular, lack the privacy features and customizability required for a complex supply chain project. Solana offers high performance but falls short in privacy and compliance aspects crucial for EU-based projects. Polkadot provides good interoperability but lacks the specific enterprise features that Besu offers. Quorum and Corda, while strong in privacy and compliance, do not offer the same level of flexibility in terms of public/permissioned deployment options. 3.2.2 Consensus Mechanism, Security, and Governance in BESU Hyperledger Besu is an open-source Ethereum client designed for both public and private permissioned network use cases. Developed under the Hyperledger umbrella, Besu implements the Enterprise Ethereum Alliance (EEA) specification, offering a robust, flexible, and enterprisegrade blockchain solution. Its architecture is built to be highly modular, allowing for easy implementation and upgrading of key blockchain features. A key strength of Hyperledger Besu is its full compatibility with the Ethereum ecosystem. It supports all standard Ethereum APIs and can run the same smart contracts and decentralized applications as other Ethereum clients. This compatibility ensures interoperability with the broader Ethereum network while providing additional features tailored for enterprise use. Besu’s enterprise-focused design is evident in its enhanced privacy features, permissioning capabilities, and performance optimizations. It offers pluggable consensus algorithms, role-based access control, and private transaction management, addressing the specific needs of businesses and consortiums. These enterprise-grade features, combined with Ethereum compatibility, make Besu an ideal choice for organizations looking to leverage blockchain technology in a secure, scalable, and compliant manner. Consensus mechanism Hyperledger Besu supports multiple consensus mechanisms, each designed to meet different network requirements and use cases. The following are the primary consensus protocols available in Besu: •QBFT is an enterprise-grade evolution of the IBFT 2.0 protocol, developed by ConsenSys. It is designed for improved scalability and processing requirements in enterprise networks. QBFT operates on a round-based consensus model where validators take turns proposing blocks. It requires a minimum of four validators to be Byzantine fault tolerRESCALE – Public – Page 23 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) ant and provides immediate finality, meaning that once a block is confirmed, it cannot be reverted. QBFT is particularly well-suited for networks requiring high security and transaction finality. •IBFT is the predecessor to QBFT and shares many of its characteristics. It also requires a minimum of four validators and provides immediate finality. IBFT 2.0 is designed to be more effective for large-scale blockchain networks compared to its original version. While still supported, it is generally recommended to use QBFT for new implementations due to its improvements over IBFT 2.0. •Clique (PoA) is a simpler proof of authority consensus mechanism that can operate with as few as one validator. Unlike QBFT and IBFT 2.0, Clique does not provide immediate finality and can experience forks. It is faster in terms of block creation but is generally recommended for test networks rather than production environments due to its lower security guarantees. •Proof of Stake (PoS) is used on the Ethereum mainnet and public testnets. In proof of stake, validators are chosen to create new blocks based on the amount of cryptocurrency they hold and are willing to ”stake” as collateral. While supported by Besu for compatibility with Ethereum networks, it is not typically used in private, permissioned networks. •Etash (PoW) is the original consensus mechanism used by Ethereum. It relies on computational work to validate blocks and secure the network. While supported by Besu, it is primarily used for small development networks or for maintaining compatibility with older Ethereum configurations. For the RESCALE project, QBFT emerges as the optimal consensus mechanism due to several key factors. It provides enterprise-grade security through Byzantine fault tolerance, crucial for maintaining network integrity against potential malicious actors or node failures. In supply chain management, where transaction certainty is paramount, QBFT’s immediate finality ensures that confirmed transactions cannot be reversed or altered. As an improvement over IBFT 2.0, QBFT offers better scalability, essential for RESCALE as the network grows and transaction volumes increase. It strikes a balance between security and performance, offering faster block times compared to proof of work while maintaining robust security guarantees. QBFT is designed for permissioned networks, aligning with RESCALE’s need for a controlled, enterprise-focused blockchain environment. Unlike proof of work, QBFT does not require intensive computational resources, making it more environmentally friendly and cost-effective for long-term operation. It also allows for precise control over the validator set, enabling RESCALE to manage network participants effectively while maintaining decentralization. Security Hyperledger Besu offers a comprehensive set of security features that position it as a robust choice for enterprise-grade blockchain applications, particularly in permissioned network environments. When compared to other blockchain platforms, Besu’s security model stands out in several key areas, combining the strengths of both public and private blockchain solutions. At the core of Besu’s security offering is its approach to privacy and confidentiality. By implementing private transactions through integration with Tessera, a privacy manager, Besu allows RESCALE – Public – Page 24 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) for confidential transactions between specific parties without exposing details to the entire network. This approach strikes a balance between the openness of public chains like Ethereum and Binance Smart Chain, which offer limited privacy features, and the strict privacy of enterprisefocused platforms like Quorum and Corda. Besu’s method provides the flexibility needed for complex enterprise use cases while maintaining a degree of transparency. Complementing its privacy features, Besu offers comprehensive permissioning capabilities at both the node and account levels. This granular control over network access surpasses what’s available in public blockchains like Ethereum or Solana, and is comparable to the permissioning capabilities of Quorum and Corda. Such fine-grained control is crucial for consortium and enterprise use cases where controlled access is paramount. Besu’s security model is further enhanced by its support for multiple consensus algorithms, including IBFT 2.0, QBFT, and Clique PoA. This flexibility allows networks to choose the most appropriate consensus mechanism for their specific security and performance needs. While platforms like Ethereum have transitioned to PoS, and others like Solana use unique consensus mechanisms, Besu’s variety of options provides greater adaptability for different network configurations. In terms of smart contract security, Besu inherits Ethereum’s capabilities but adds enterprisegrade features. It allows for disabling certain opcodes to prevent potential attacks, a feature not commonly found in public blockchains. This level of control over smart contract execution environments is comparable to other enterprise platforms like Quorum, providing an additional layer of security for critical business logic. While Besu itself does not handle key management, it integrates seamlessly with external key management systems. This approach, similar to that of Quorum and Corda, allows for more robust and flexible key security compared to public blockchain nodes that often manage keys internally. It enables enterprises to leverage existing security infrastructure and policies for key management. For privacy-enabled networks, Besu assumes a level of trust among node operators, an approach similar to Quorum and Corda but differing from public blockchains where trust is minimized. Besu recommends using consensus mechanisms that support transaction finality (like IBFT 2.0) for production environments, enhancing security in private network setups. Besu’s design also considers regulatory compliance, making it suitable for industries with strict regulatory requirements. Its permissioning and privacy features, combined with the ability to create detailed audit trails, put it on par with other enterprise-focused platforms in terms of compliance readiness. This is particularly important for sectors dealing with sensitive data or operating under stringent regulatory frameworks. As an Ethereum-compatible client, Besu offers better interoperability with the broader Ethereum ecosystem compared to non-Ethereum based platforms. This allows for easier integration of existing Ethereum tools and smart contracts while still maintaining enterprise-grade security features. The open-source nature of Besu, being part of the Hyperledger project, also contributes to its security profile. It benefits from community scrutiny and contributions, potentially leading to faster identification and resolution of security issues, an advantage over proprietary solutions. Governance Hyperledger Besu offers a flexible governance model that supports both on-chain and off-chain governance processes, making it adaptable to various organizational needs. This dual approach allows networks to leverage the benefits of blockchain technology while maintaining the flexibility to incorporate traditional decision-making structures. RESCALE – Public – Page 25 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 4.1.2 Benefits of Smart Contracts for TBOM Management Smart contracts serve as a secure register for current TBOM hashes, verifying sender authorization during execution to prevent unauthorized modifications. They maintain an immutable history of changes through event triggers, enabling traceability and auditability of TBOM lifecycles. This approach ensures automated, secure management of TBOMs, reducing tampering risks and providing a reliable record of modifications. By combining hash registration, sender verification, and historical tracking, smart contracts enhance the integrity and transparency of TBOM management throughout the supply chain. The blockchain-based TBOM system provides robust cryptographic protection for all TBOM data, ensuring its integrity and confidentiality. Every operation on a TBOM is recorded in a tamper-evident manner, creating an unalterable history of changes that can be audited at any time. The decentralized nature of blockchain storage significantly reduces single points of failure, enhancing the overall resilience of the TBOM system. An immutable audit trail of all TBOM-related activities (such as generation and deprecation) is maintained, providing a comprehensive and trustworthy record of every interaction, modification, and verification process. This level of security and immutability instills confidence in the TBOM data, crucial for making informed decisions in supply chain management. The RESCALE TBOM system offers real-time visibility into the status and history of each TBOM, allowing stakeholders to track changes and updates as they occur. A traceable chain of custody is established for all components, from raw materials to finished products, enabling precise tracking of each item’s journey through the supply chain. Every interaction between stakeholders and TBOMs is transparently recorded, creating a comprehensive log of who accessed, modified, or verified TBOM data. This transparency extends to the easy verification of component origins and modifications, allowing quick identification of potential security risks or compliance issues. The increased transparency and traceability foster trust among supply chain participants and facilitate rapid response to any identified issues. By reducing the need for manual intervention in TBOM management, the RESCALE system significantly cuts operational costs and improves overall efficiency. The automated processes enable faster processing and validation of TBOMs, accelerating supply chain operations and reducing time-to-market for new products. The system minimizes errors and discrepancies in TBOM data through automated checks and validations, ensuring high data quality and reducing the costs associated with error correction. Auditing and compliance processes are streamlined, with automated reporting and real-time access to TBOM data, reducing the time and resources required for these critical activities. These efficiency improvements not only reduce direct costs but also enhance the overall competitiveness of organizations adopting the RESCALE TBOM system. The RESCALE TBOM system facilitates direct peer-to-peer interactions between supply chain participants, reducing reliance on centralized authorities for TBOM verification. This disintermediation of trust replaces traditional third-party guarantors with smart contract code, ensuring that agreed-upon rules are enforced consistently and impartially. The reduced dependence on intermediaries increases the autonomy of supply chain stakeholders, allowing for more direct control over their operations and data. By removing intermediaries, the system reduces transaction costs, speeds up processes, and minimizes the risk of information manipulation or bottlenecks caused by centralized authorities. This direct interaction model fosters a more RESCALE – Public – Page 32 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) collaborative and efficient supply chain ecosystem. The blockchain-based TBOM system enables instant propagation of TBOM changes across the network, ensuring that all participants have access to the most current information. This realtime synchronization provides a unified view of TBOM data for all authorized parties, eliminating discrepancies and reducing the risk of decisions based on outdated information. The system generates real-time alerts and notifications for critical TBOM events, such as detected vulnerabilities or compliance issues, allowing for rapid response to potential risks. Continuous reconciliation of TBOM states across the supply chain ensures data consistency and integrity, even in complex, multi-tiered supply networks. This real-time capability enhances decisionmaking, risk management, and overall supply chain agility. 4.2 Smart Contract Implementation This section delves into the implementation of smart contracts within the RESCALE project. Section 4.2.1 introduces the HashStorage.sol contract, a basic implementation designed for single hash storage. SectionSection 4.2.2 presents the more advanced HashManager.sol contract, which offers a scalable solution for managing multiple hash values. SectionSection 4.2.3 provides a comparative analysis of both implementations, discussing their strengths, limitations, and associated costs. 4.2.1 Basic Implementation: HashStorage.sol The HashStorage.sol smart contract (Listing 1) represents a fundamental approach to storing and managing hash values. This implementation is designed to provide a straightforward and efficient solution for single hash storage, catering to basic use cases in supply chain management and digital document verification. The contract utilizes a single storage variable, implemented as a struct named HashIn f o, to hold the hash value and its associated owner address. This approach ensures a one-to-one mapping between an account address and a hash, providing a minimalistic yet effective method for hash storage on the blockchain. The use of a struct allows for easy expansion of stored data if future requirements necessitate additional fields. The HashStorage contract incorporates several key features that make it suitable for basic hash management scenarios. Primarily, it stores a single hash value using the bytes32 data type, which is optimal for representing cryptographic hashes such as SHA-256. This choice ensures efficient storage and gas usage. The contract associates each hash with the public address of the account that created it, leveraging the msg.sender variable to automatically link the hash to the transaction initiator. This association enables straightforward access control, preventing unauthorized modifications to the stored hash. The simplicity of the HashStorage contract is one of its strongest attributes. With minimal code complexity, it reduces the potential for errors and simplifies the auditing process. This straightforward design also contributes to lower gas costs for deployment and execution compared to more intricate implementations, making it an economical choice for projects with basic hash storage needs. RESCALE – Public – Page 33 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) Code Structure and Main Functions The HashStorage contract (Listing 1) begins with the contract declaration and includes state variables for storing the hash information and a boolean flag to track whether a hash has been set. The contract implements four main functions that provide complete CRUD (Create, Read, Update, Delete) functionality: •setHash(bytes32 hash): Allows users to store a new hash, creating the initial entry. •getHash(): Retrieves the stored hash and its owner’s address, providing read access to the data. •deprecateHash(): Permits the owner to deprecate the stored hash, offering complete data lifecycle management. These functions are complemented by events (HashSet, HashDeprecated) that log state changes, enhancing transparency and facilitating off-chain tracking of contract interactions. // SPDX -License - Identifier : MIT pragma solidity ^0.8.0; contract HashStorage { // Struct to hold the hash info struct HashInfo { bytes32 hashValue ; // Stored hash address owner ; // Owner of the hash } // State variables HashInfo private storedHash ; bool private isHashSet ; // Flag to track if a hash is already set // Event for hash changes event HashSet(bytes32 indexed hashValue, address indexed owner ); event HashDeprecated(bytes32 indexed oldHashValue , address indexed owner ); // Set a new hash function setHash(bytes32 _hash ) external { require( _hash != bytes32(0) , " Invalid hash "); require(!isHashSet , " Hash already exists . Use updateHash to modify."); storedHash = HashInfo ({ hashValue : _hash , owner : msg . sender }) ; isHashSet = true ; emit HashSet (_hash , msg . sender ); } // Get the stored hash function getHash() external view returns (bytes32 hashValue , address owner ) { require(isHashSet , " No hash stored ."); return ( storedHash . hashValue , storedHash . owner ); } // Delete the stored hash RESCALE – Public – Page 34 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) function deprecateHash () external { require(isHashSet , "No hash stored to deprecate ."); require( storedHash . owner == msg .sender , " Caller is not the owner "); bytes32 oldHash = storedHash . hashValue ; delete storedHash ; isHashSet = false ; emit HashDeprecated (oldHash , msg . sender ); } } Listing 1: HashStorage.sol 4.2.2 Advanced Implementation: HashManager.sol The HashManager.sol smart contract (Listing 2) represents a more sophisticated approach to managing multiple hash values. This implementation is designed to provide a scalable and efficient solution for storing and managing multiple hashes, catering to complex use cases in supply chain management and digital document verification within the TBOM framework. The contract utilizes a combination of a mapping and an array data structure to efficiently store and manage multiple hash values. The primary storage mechanism is a mapping (hashMapping) that associates each hash value (bytes32) with a HashInfo struct containing the hash’s index in the array and the owner’s address. This approach allows for constant-time lookups of hash information. Additionally, a dynamic array (hashList) stores all hash values, enabling enumeration and efficient updates. This dual-structure approach ensures optimal gas usage for various operations while maintaining the ability to track all stored hashes. Code Structure and Main Functions The HashManager contract (Listing 2) begins with the contract declaration and includes a struct definition for HashInfo, followed by state variables for the mapping and array. The three main functions form the core of the contract’s functionality, implementing an adapted version of CRUD for blockchain where deletion is not possible: •add(bytes32 hash): Adds a new hash to the system, ensuring uniqueness and valid input. •read(bytes32 hash): Retrieves the index and owner of a given hash. •deprecate(bytes32 hash): Marks a hash as deprecated, effectively removing it from active use while maintaining historical data integrity. Each function includes necessary checks to ensure data integrity and proper access control. The update and delete operations are particularly noteworthy for their gas-efficient implementations, which maintain the integrity of the hashList array while minimizing storage operations. RESCALE – Public – Page 35 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) // SPDX -License - Identifier : MIT pragma solidity ^0.8.0; contract HashManager { struct HashInfo { uint256 index ; // Index position in the ‘hashList ‘ array address owner ; // Owner of the hash } mapping(bytes32 => HashInfo ) private hashMapping ; // Mapping hash value -> HashInfo bytes32[] private hashList ; // store all hash values // Events for CRD operations event HashAdded ( bytes32 indexed hashValue, address indexed owner ); event HashDeprecated(bytes32 indexed hashValue , address indexed owner ); function add ( bytes32 _hash ) external { require( _hash != bytes32(0) , " Invalid hash "); require( hashMapping [ _hash ]. owner == address(0) , " Hash already exists"); hashMapping [ _hash ] = HashInfo ({ index : hashList . length , owner : msg . sender }); hashList . push ( _hash ); emit HashAdded ( _hash , msg . sender ); } function read(bytes32 _hash ) external view returns (uint256 index, address owner ) { require( hashMapping [ _hash ]. owner != address(0) , " Hash does not exist "); HashInfo memory hashInfo = hashMapping [ _hash ]; return ( hashInfo .index , hashInfo . owner ); } function deprecate ( bytes32 _hash ) external { require( hashMapping [ _hash ]. owner != address(0) , " Hash does not exist "); require( hashMapping [ _hash ]. owner == msg . sender , " Caller is not the owner "); uint256 index = hashMapping [ _hash ]. index ; uint256 lastIndex = hashList . length - 1; if ( index != lastIndex ) { bytes32 lastHash = hashList [ lastIndex ]; hashList [ index ] = lastHash ; hashMapping [lastHash ]. index = index ; } hashList . pop () ; delete hashMapping [ _hash ]; emit HashDeprecated (_hash , msg . sender ); } } Listing 2: HashManager.sol RESCALE – Public – Page 36 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 4.2.3 Comparative Analysis of Implementations This section provides a comprehensive comparison between the HashStorage.sol (Listing 1) and the HashManager.sol (Listing 2) implementations, highlighting their respective strengths, limitations, and associated costs. HashStorage.sol offers simplicity and efficiency for basic use cases. Its straightforward design makes it easy to understand, implement, and audit, reducing the potential for errors and vulnerabilities. The contract’s minimal functionality results in lower gas fees for deployment and basic operations. For simple proof-of-existence scenarios or single-user applications, HashStorage.sol provides a clean and uncomplicated solution with comparable efficiency to more complex implementations. However, HashStorage.sol simplicity comes with significant limitations. The contract only supports storing a single hash, which may be insufficient for more complex use cases. Its lack of scalability is a major drawback, as each new hash requires a new contract deployment. This approach becomes impractical and costly when managing multiple hashes, especially in large-scale operations. HashManager.sol offers a more robust and flexible solution for complex supply chain scenarios. Its ability to store multiple hashes makes it suitable for managing numerous components that need to be tracked. The contract’s scalability is a significant advantage, as it can handle an increasing number of hashes without requiring new deployments. This makes it more efficient for large-scale operations and complex supply chain management systems. HashManager.sol maintains an array of all hashes, allowing for easier enumeration and improved traceability. Despite its higher complexity, HashManager.sol optimizes gas usage for operations like updates and deletions, which is particularly beneficial when managing many hashes. However, the advanced features of HashManager.sol come with trade-offs. The more sophisticated design may be harder to understand and audit, potentially increasing the risk of bugs or vulnerabilities. The initial deployment of HashManager.sol is more expensive due to its increased functionality and storage structures. While the difference in basic operation costs is minimal, setting a hash in HashManager.sol is marginally more expensive than in HashStorage.sol. To illustrate the cost differences, the following table presents gas costs and their equivalent prices in Euros, based on values updated as of October 2024 (ETH price of C2381 and average gas cost of 20.85gwei): Operation HashStorage HashManager Gas Cost (C) Gas Cost (C) Deploy 757,351 37.60 1,132,103 56.20 Set Hash 90,216 4.48 92,750 4.60 Update Hash 33,305 1.65 59,754 2.97 Delete Hash 30,578 1.52 33,506 1.66 Table 3: Gas costs and prices for HashStorage.sol and HashManager.sol operations As shown in Table 3, while HashManager.sol has a higher initial deployment cost, the differRESCALE – Public – Page 37 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) ence in operational costs is relatively small. The choice between these implementations should be based on the specific requirements of the TBOM management system, considering factors such as scalability needs, gas cost constraints, and the complexity of the supply chain being modeled. Leveraging Transaction Data for Cost-Effective Storage While smart contracts provide robust functionality for managing TBOMs, storing large amounts of data on-chain can be expensive. For frequent operations or storing small pieces of data, leveraging transaction data can be a more cost-effective solution. This approach involves encoding data within the transaction itself, rather than storing it in contract storage. pragma solidity ^0.8.0; ... event DataAssociated(bytes32 indexed tbomHash , bytes32 indexed corollaryHash ); function associateData ( bytes32 _tbomHash , bytes32 _corollaryHash) external { emit DataAssociated(_tbomHash , _corollaryHash); } function getAssociatedData(bytes32 _tbomHash ) external view returns (bytes32[] memory ) { // This function would be implemented off - chain by querying event logs // It ’s included here for completeness , but would not be part of the actual contract } ... Listing 3: TBOMDataAssociation Contract Listing 3 shows an example of how to use transaction data for storage in Solidity. Rather than storing associations directly in contract storage, the function emits an event to associate a TBOM hash and a corollary hash. While leveraging transaction data to store simple data offers a cost-effective solution, it is essential to consider the potential drawbacks compared to using smart contract fields for data storage. Storing data through transaction events, such as emitting logs, can significantly reduce gas costs, especially for frequent operations. However, this approach introduces several challenges that must be carefully evaluated. One of the primary concerns is the difficulty of querying and accessing the data stored in transaction logs. Unlike direct access to smart contract fields, which allows for straightforward retrieval of values through function calls, accessing event logs requires off-chain processing. This means that developers must implement additional mechanisms to listen for events and parse the log data, adding complexity to the system architecture. For instance, while a smart contract can return associated corollary hashes directly through a function call, retrieving this information from logs necessitates a more cumbersome process involving event subscriptions and filtering. Moreover, transaction logs are not inherently structured for complex queries or relationships. RESCALE – Public – Page 38 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) When using smart contract storage, developers can utilize mappings and arrays to organize data efficiently. In contrast, event logs typically require additional logic to reconstruct relationships between different pieces of data. For example, if multiple corollary hashes are associated with a single TBOM hash, reconstructing this association from logs may require iterating through numerous events instead of simply accessing a mapping. Another limitation of using transaction data is the lack of built-in data integrity checks that smart contracts provide. Smart contracts can enforce rules and validations on stored data through function modifiers and access controls. In contrast, when relying on event emissions for data storage, there is no inherent mechanism to ensure that the emitted data is valid or consistent with the rest of the system’s state. This could lead to scenarios where inconsistencies arise between the state represented in logs and the actual state of the smart contract. Additionally, while emitting events can be cheaper in terms of gas costs for frequent operations, it may not be suitable for all use cases. For example, if an application requires real-time access to associated metadata or analysis results tied to TBOM hashes, relying solely on transaction logs could introduce latency and inefficiencies in retrieving necessary information. RESCALE – Public – Page 39 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 5 Rescale Trusted Storage Architecture and Implementation 5.1 Architecture Overview The Rescale Trusted Storage Architecture is designed as a distributed system for managing TBOM in supply chain security. The architecture is organized around a network of nodes, each serving as an atomic unit of the system. Each node in the network consists of two primary components: a Hyperledger BESU node and an IPFS node. The BESU node provides blockchain functionality, ensuring immutability and distributed consensus for the stored data, while the IPFS node offers decentralized storage capabilities, allowing for efficient handling of larger data sets. The BESU RPC API is exposed directly, allowing authenticated and authorized access to the blockchain network. IPFS, however, is accessed through a REST service, which acts as a controlled interface. This architecture ensures that clients cannot unpin documents from remote IPFS nodes without proper authorization, maintaining the integrity of stored data. The network model of the Rescale Trusted Storage is designed as a public permissioned network. The public aspect allows user interaction with the network, promoting transparency, while the permissioned aspect ensures that only a restricted group of nodes can perform operations on the network, maintaining control and accountability. This balance between accessibility and security is crucial for the system’s integrity and usability. Regarding scalability and partner integration, the architecture is designed with a partner-centric approach. The system is structured to create one node per partner, allowing for clear delineation of responsibilities and data ownership. This design facilitates the onboarding of new partners and management of partner-specific data and operations, enhancing the system’s adaptability to diverse supply chain ecosystems. 5.1.1 Confidentiality, Integrity and Availability The ledger component serves as the foundation for ensuring data integrity within the TBOM ecosystem. By leveraging the immutable nature of blockchain technology, each entry in the TBOM is recorded in a tamper-evident manner. This immutability is achieved through cryptographic hashing, which links each block to its predecessor, creating a chain of information that is extremely difficult to alter without detection. The consensus mechanisms inherent to blockchain systems play a crucial role in maintaining the integrity of TBOM data. These mechanisms ensure that all nodes in the network agree on the state of the ledger, validating new entries before they are added to the blockchain. This distributed validation process significantly reduces the risk of unauthorized modifications to TBOM records, as any attempt to alter data would require consensus from the majority of the network. The IPFS component ensures data availability within the TBOM ecosystem. By leveraging its distributed nature, IPFS provides a robust and resilient storage solution for TBOM data. Each piece of information is stored across multiple nodes in the network, significantly reducing the risk of data loss due to node failures or network disruptions. The content-addressable nature of RESCALE – Public – Page 40 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) IPFS also enhances data integrity, as each file is uniquely identified by its content hash, making it easy to verify the authenticity of retrieved data. The client library and rest service plays a crucial role by providing a simplified interface for interacting with nodes in the system. Its primary purpose is to abstract the complexities of node communication and TBOM operations, offering developers and users an easy-to-use set of tools for interacting with the Trust Module. Currently, the library focuses on ensuring confidentiality within the CIA triad through message encryption, protecting sensitive information during transmission between clients and nodes. Key features include abstraction of node communication, payload preparation, authentication handling, operation abstraction, and error handling. The library manages underlying network protocols and security mechanisms, prepares data for TBOM operations, incorporates authentication mechanisms, simplifies common operations, and provides robust error handling. By implementing end-to-end encryption, it significantly enhances the security of the TBOM system, particularly for data in transit. Future plans for the client library include expanding its capabilities with additional security features, such as ZKP technologies, which would enable selective disclosure of information without revealing all associated data. 5.1.2 The networking system The Rescale Trusted Storage Architecture presented in Figure 3 incorporates three distinct networks, each serving a specific function in the system’s operation: the P2P Discoverability Network, the RPC API Exposure Network, and the Trust Storage Network. The P2P Discoverability Network facilitates node discovery and synchronization for both BESU and IPFS nodes. It utilizes peer-to-peer protocols, specifically the Ethereum DevP2P protocol for BESU and the InterPlanetary networking stack for IPFS. This network is exposed to the public internet to enable dynamic node discovery and synchronization, employing various mechanisms such as DNS-based discovery and distributed hash tables for efficient node location and connection. In contrast, the RPC API Exposure Network provides a standardized interface for interacting with BESU and IPFS nodes. This limitation minimizes the potential attack surface by ensuring controlled interaction with the nodes’ APIs. The RPC network supports methods for querying blockchain data, submitting transactions, interacting with smart contracts (for BESU), and managing and retrieving content (for IPFS). Serving as the primary operational network, the Trust Storage Network is designed as a public permissioned network, striking a balance between accessibility and security. The public aspect allows for transparency and user interaction, while the permissioned nature ensures that only authorized nodes can perform operations on the network. Within this network, the REST service functions as a controlled gateway between users and the Trust Storage nodes, abstracting the complexities of direct node interaction and providing a secure, standardized interface for authenticated and authorized access to the system’s functionalities. RESCALE – Public – Page 41 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) ipfs bootstrap rm all if [[ -n "$IPFS_BOOTSTRAP_IP" && -n "$IPFS_BOOTSTRAP_ID" ]]; then ipfs bootstrap add "/ip4/$IPFS_BOOTSTRAP_IP/tcp/4001/ipfs/$IPFS_BOOTSTRAP_ID" fi All default bootstrap nodes are removed (ipfs bootstrap rm all). If specified, a single custom bootstrap node is added. This process is essential for creating a closed, private IPFS network by controlling peer discovery and connections. The script’s behavior is controlled through three environment variables: IPFS SWARM KEY, IPFS BOOTSTRAP IP, and IPFS BOOTSTRAP ID. When these environment variables are set, the node can be configured to participate in an already existing private IPFS network. Conversely, if these variables are not set, the script adapts to create a new private network. In this case, a new swarm key will be generated, effectively starting a new private network. Additionally, the node will not have any bootstrap nodes configured, making it the first node of a new network. REST Service overview The REST service is implemented in Rust using the ntex web framework. The service acts as a secure intermediary between clients and IPFS nodes, providing controlled access to the IPFS RPC API. This approach addresses the need to expose certain IPFS functionalities remotely while maintaining security and control over the node’s operations. The REST service exposes two primary operations: •Create: Allows clients to pin new documents to the IPFS node •Cat: Enables clients to retrieve documents from the IPFS node These operations are crucial for remote interaction with IPFS nodes. The service is built using Rust and the ntex web framework, which provides a robust and efficient foundation for handling HTTP requests. The main structure of the service is defined in the main function: #[ ntex :: main ] async fn main () -> std :: io :: Result <() > { web :: HttpServer :: new (|| { web :: App :: new () . service (api :: create :: create ) . service ( api :: cat :: cat ) }) . bind (("0.0.0.0" , 4040) )? .run () . await } This setup initializes an HTTP server that listens on all network interfaces (0.0.0.0) on port 4040. It registers several services, including the create and cat operations. Dockerization of the Trust Storage Node RESCALE – Public – Page 48 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) To facilitate easy deployment and multi-platform distribution, the BESU node, IPFS node, and REST service are each containerized using separate Dockerfiles. This approach ensures consistency across different environments and simplifies the deployment process. The Dockerfiles employ a multi-stage build process, which offers several advantages: reduced final image size by excluding build tools and intermediate artifacts; improved build performance through parallelization of independent stages; enhanced security by minimizing the attack surface in the final image; Simplified maintenance by separating build and runtime environments. The Dockerfile for the BESU node begins with an Ubuntu 24.04 base image to compile BESU from source: FROM ubuntu:24.04 AS builder ... RUN git clone --depth 1 --branch 24.9.1 https://github.com/hyperledger/besu RUN cd /besu && ./gradlew installDist The final stage sets up the runtime environment: FROM ubuntu:24.04 AS final ... COPY --from=builder /besu/build/install/besu /opt/besu/ Similarly, the IPFS node is built using a dedicated Dockerfile, starting with Ubuntu 24.04 to compile IPFS from source: FROM ubuntu:24.04 AS builder ... RUN git clone --depth 1 --branch v0.30.0 https://github.com/ipfs/kubo.git RUN cd /kubo && make build The runtime environment is then set up in a separate stage: FROM debian:latest AS final ... COPY --from=builder /kubo/cmd/ipfs/ipfs ./ The REST service is compiled using a Dockerfile that employs the official Rust image: FROM rust:1.82.0 AS rustcompiler COPY ./rest/ /app WORKDIR /app RUN cargo build The final stage creates the runtime environment: RESCALE – Public – Page 49 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) FROM gcr.io/distroless/cc ... COPY --from=rustcompiler /app/target/debug/gatekeeper /opt/rest/gatekeeper Each Dockerfile configures its respective environment and exposes necessary services for its component. The containers are designed to expose multiple ports: 30303 and 4001 for BESU and IPFS P2P communications respectively, 8545 and 5001 for their RPC interfaces, and 4040 for the REST service. The P2P ports (30303 and 4001), the BESU RPC port (8545) and the REST port (4040) are publicly accessible through port forwarding, enabling network discoverability and external use. In contrast, the IPFS RPC port (5001) is configured to be visible only to localhost, restricting access to local services within each container. This setup ensures that each node can participate in its respective network and offer REST services while maintaining the security of RPC interfaces. 5.2.2 Trust Storage Client The Trust Storage Client is implemented as a set of Python modules that facilitate interaction with the Trust Storage system, ensuring compatibility with other Rescale components. This implementation provides secure communication and data management within the distributed storage system, utilizing JWT tokens for authentication and integrating with both IPFS and BESU blockchain. Key Features •PEM-formatted Key Authentication: Uses PEM-formatted key files for authentication, keeping sensitive key material on the client side. •JWT Token Security: Implements JWT tokens for secure communication with the REST service. •Two-Step Document Addition: Adds documents to IPFS and records their references in the BESU blockchain. •Secure Document Retrieval: Verifies document existence in the blockchain before retrieving from IPFS. •Document Deprecation: Allows logical invalidation of documents without altering IPFS content. Environmental Variables The Trust Storage Client relies on several environment variables for configuration and security: •REST ENDPOINT: The URL of the REST service for IPFS interactions. •BESU ENDPOINT: The URL of the BESU blockchain node. RESCALE – Public – Page 50 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) •CLIENT PRVKEY PATH: File path to the client’s private key in PEM format. •CLIENT PUBKEY PATH: File path to the client’s public key in PEM format. •CONTRACT ADDR PATH: File path to the smart contract address. •CONTRACT JSON PATH: File path to the JSON file containing the smart contract ABI. If any of these variables are missing, the client will raise a ValueError with a message indicating which environment variable is not set. Key Components •truststorageclient.py: Main interface for document operations. •restclient.py: Handles REST API interactions with IPFS. •besuclient.py: Manages interactions with the BESU blockchain. •utils.py: Provides utility functions for key management. IPFS Interaction (restclient.py) •add ipfs(document: dict) -> str: Adds a document to IPFS, returning the CID. •get ipfs(cid: str) -> str: Retrieves a document from IPFS using its CID. • Uses JWT for secure communication with the REST service. BESU Blockchain Interaction (besuclient.py) •add besu(cid: str) -> None: Records a document’s CID in the blockchain. •get besu(cid: str) -> None: Verifies a document’s existence in the blockchain. •deprecate besu(cid: str) -> None: Marks a document as deprecated in the blockchain. • Implements low-level blockchain interactions, including transaction management and smart contract calls. Core Methods (truststorageclient.py) The truststorageclient module provides three main methods for managing documents within the Trust Storage system. These methods encapsulate the core functionality of adding, retrieving, and deprecating documents. •add document(document: dict) -> str (Figure 4) –Adds a document to IPFS using add ipfs(). –Records the IPFS CID in the BESU blockchain using add besu(). RESCALE – Public – Page 51 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) –Returns the CID of the added document. •get document(cid: str) -> dict (Figure 5) –Verifies the document’s existence in BESU blockchain using get besu(). –Retrieves the document from IPFS using get ipfs(). –Returns the document as a dictionary. •deprecate document(cid: str) -> None (Figure 6) –Marks a document as deprecated in the BESU blockchain using deprecate besu(). Client REST Service IPFS Node BESU Node (JSON, prvkey, pubkey) jwt(json, prvkey) (jwt token, pubkey) verify(jwt) add ipfs(JSON) CID CID sign tx(cid, prvkey) add besu(signed tx) tx result Figure 4: Sequence diagram of add document() operation. Utility Functions (utils.py) 1. generate ec(folder=None, curve="secp256k1") • Generates an Elliptic Curve key pair (secp256k1 or secp256r1). • Creates both private and public keys in PEM format. • Optionally saves keys to PEM files in a specified folder. text 2. pem to hex(keypath: str) • Converts a PEM-formatted private key to the hexadecimal format required by BESU. • Ensures the key is a secp256k1 curve key. RESCALE – Public – Page 52 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) Client REST Service IPFS Node BESU Node (CID, prvkey, pubkey) get besu(CID) jwt(CID, prvkey) (jwt, pubkey) verify(jwt) get ipfs(CID) JSON JSON Figure 5: Sequence diagram of get document() operation. Client REST Service IPFS Node BESU Node (CID, prvkey, pubkey) deprecate besu(CID) Figure 6: Sequence diagram of deprecate document() operation. RESCALE – Public – Page 53 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 6 Potential Challenges and Risks The implementation of the Trust Storage module within the RESCALE project, while offering significant benefits for supply chain security and transparency, also presents several challenges and potential risks. This section outlines these concerns and proposes mitigation strategies to address them effectively. 6.1 Scalability and Performance Concerns As the TBOM system grows and evolves, maintaining high transaction throughput and low latency becomes increasingly challenging. The blockchain ledger and IPFS storage may face performance bottlenecks when dealing with large volumes of data or frequent updates, potentially impacting the system’s responsiveness and efficiency. To mitigate these scalability concerns, several strategies can be employed. Implementing sharding techniques can distribute data processing across multiple nodes, effectively balancing the load and improving overall system performance. Utilizing layer-2 scaling solutions, such as sidechains or state channels, can offload transactions from the main chain, reducing congestion and improving transaction speed. Additionally, optimizing smart contract code and data structures for efficiency can significantly enhance the system’s performance. Employing caching mechanisms and content delivery networks can further improve data retrieval speeds, ensuring that the TBOM system remains responsive even as it scales. 6.2 Security Risks and Vulnerabilities The decentralized nature of blockchain technology, while offering many security benefits, also introduces unique vulnerabilities. Smart contract vulnerabilities could potentially expose the system to attacks or unauthorized access, compromising the integrity of the TBOM data. Key management and access control present significant challenges, especially in a decentralized environment where traditional security measures may not be applicable. Furthermore, the system may be susceptible to various blockchain-specific attacks, such as 51% attacks or smart contract exploits, which could undermine the trust and security of the entire TBOM framework. To address these security concerns, a multi-faceted approach is necessary. Conducting regular security audits and penetration testing of smart contracts and the overall system can help identify and address vulnerabilities proactively. Implementing multi-signature wallets and hardware security modules for key management can significantly enhance the security of cryptographic keys. Utilizing formal verification techniques to mathematically prove the correctness of smart contracts can minimize the risk of exploits. Additionally, implementing robust access control mechanisms and regularly updating security protocols can help maintain the system’s resilience against evolving threats. RESCALE – Public – Page 54 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 6.3 Legal and Regulatory Challenges The implementation of a blockchain-based TBOM system raises several legal and regulatory concerns, particularly regarding data protection and cross-border data transfers. Compliance with data protection regulations like GDPR could be complex, especially concerning data immutability and the right to be forgotten, which are inherently at odds with blockchain’s immutable nature. Cross-border data storage and transfer regulations may pose challenges for a globally distributed system, potentially limiting the TBOM’s effectiveness in international supply chains. Moreover, the legal status and enforceability of smart contracts in different jurisdictions could be uncertain, potentially complicating dispute resolution and contract execution. To navigate these legal and regulatory challenges, engaging legal experts specializing in blockchain and data protection is crucial to ensure compliance. Implementing privacy-preserving technologies like zero-knowledge proofs can help achieve GDPR compliance while maintaining the benefits of blockchain transparency. Designing the system with data localization options can address cross-border data transfer issues, allowing for compliance with various regional regulations. Developing clear terms of service and user agreements that address legal uncertainties can help establish a solid legal foundation for the TBOM system’s operation. 6.4 Integration Complexities Integrating the Trust Storage module with existing supply chain systems and processes may present significant technical challenges. Ensuring interoperability between different blockchain networks and external systems could introduce complexities that may hinder seamless adoption and utilization of the TBOM system. To address these integration challenges, developing standardized APIs and integration protocols for seamless connection with existing systems is essential. The choice of Hyperledger BESU as the blockchain platform for the TBOM system offers significant advantages in terms of interoperability. BESU’s EVM compatibility enhances the system’s flexibility and compatibility with the broader Ethereum ecosystem and EVM-based blockchain networks. This compatibility allows for easier integration with existing Ethereum-based tools, smart contracts, and decentralized applications, potentially simplifying the integration process with various supply chain systems. 6.5 User Adoption and Training The complexity of blockchain technology may present challenges in user adoption. However, the implementation of the Trust Storage client significantly simplifies this process for both producers and consumers of TBOM data. This client acts as an intermediary layer, abstracting the underlying complexities and providing a more accessible interface for stakeholders. To further facilitate adoption, developing intuitive interfaces for the Trust Storage client can make the system more user-friendly for non-technical stakeholders. Creating targeted documentation and training programs focused on client usage can equip users with the necessary RESCALE – Public – Page 55 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) skills to interact with the TBOM system efficiently. A phased roll-out of the Trust Storage client, coupled with a feedback mechanism, can allow for iterative improvements and ensure the system meets user needs effectively. RESCALE – Public – Page 56 / 61 D4.4 – TBOM Security and Trust Mechanism (first version) 7 Roadmap and Future Work As this initial version of the TBOM Security and Trust Mechanism concludes, significant opportunities remain to further enhance and expand the capabilities of the system. The following roadmap outlines key areas for future development and research, aligned with the overarching goals of the RESCALE project and the broader objectives of the Horizon Europe program. Enhancement of Security and Trust Mechanisms Building upon the foundational security framework established in this deliverable, the next phase will implement more advanced cryptographic techniques to bolster the privacy and security verification processes within the TBOM ecosystem. A primary focus will be the integration of ZKPs, which will facilitate the selective disclosure of sensitive information without revealing the underlying data. This advancement aligns with the European Union’s emphasis on privacy-preserving technologies and data minimization principles. It is important to note that the current solution does not yet support integration with a certification authority. By leveraging established PKI frameworks, the aim is to ensure interoperability with existing systems while elevating the overall security posture of the TBOM implementation. This integration is a critical aspect that will be addressed in the final version of the module. Additionally, there is no existing integration with a key management system, as the Rescale framework must still incorporate this component. Defining a proper key life-cycle management strategy will also be essential to ensure robust security practices. An additional area of development will be the implementation of advanced checks on TBOM content, including Proof of Computation and Attestation mechanisms. These features are vital for proving the veracity of the data stored within documents and will require either attestation or proof of computation capabilities, or a combination of both. This approach will provide greater assurance of the integrity and authenticity of information stored within the TBOM, aligning with the EU’s goals for increased transparency and accountability in digital systems. Expansion of Smart Contract Functionality The current implementation of smart contracts in the TBOM framework provides a solid foundation for automated trust and security management. However, there is potential for more sophisticated applications. The next phase will explore the development of advanced smart contracts capable of performing automated compliance checks against evolving regulatory frameworks and industry standards. Additionally, experimentation with more nuanced access control mechanisms within the smart contract architecture is planned. This will include the implementation of RBAC systems, allowing for more granular and context-aware permissions management. Such advancements will contribute to the European Union’s objectives for enhanced cybersecurity and data governance in digital infrastructures. Integration with other RESCALE modules Moving forward, a critical focus will be on the seamless integration of the TBOM Security and Trust Mechanism with other modules developed within the RESCALE project. This integration will be essential for realizing the full potential of the secure supply chain management system. RESCALE – Public – Page 57 / 61