D4.2 SECURE DECENTRALIZED DATA SHARING

CONFIDENTIAL6G has received funding from the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union’s Horizon Europe research and innovation programme under Grant Agreement No 101096435 CONFIDENTIAL COMPUTING AND PRIVACY-PRESERVING TECHNOLOGIES FOR 6G D4.2 SECURE DECENTRALIZED DATA SHARING D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 1 PROJECT INFORMATION Call HORIZON-JU-SNS-2022 Type of Action HORIZON-JU-RIA HORIZON JU Research and Innovation Actions Project start date 01/01/2023 Duration 36 months GA No DELIVERABLE INFORMATION Deliverable WP: WP4 Deliverable Task: Task T4.2 Deliverable Identifier: CONFIDENTIAL6G_D4.2 Deliverable Title: SECURE DECENTRALIZED DATA SHARING Editor(s): NNF Author(s): Amit Kumar Srivastava (NNF), George Saleh (NNF), Nenad Gligoric (ZEN), Ana Kovacevic (ZEN), Stevan Jokic (ZEN), Fabian Schmid (TUG), Julian Thomas (FAU), Jani Suomalainen (VTT), Konstantinos Lessis (WINGS) Reviewer(s): Vera Stavroulaki (WINGS), and Dusan Borovcanin (UVC) Contractual Date of Delivery: 30/06/2024 Submission Date: 03/07/2024 Revision Date 13/12/2024 Dissemination Level: Public Status: Final 101096435 D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 2 Version: 1.0 File Name: CONFIDENTIAL6G_D4.2_Secure Decentralized Data Sharing_v2.0 D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 3 Disclaimer The information and views set out in this deliverable are those of the author(s) and do not necessarily reflect the official opinion of the European Union. Neither the European Union institutions and bodies nor any person acting on their behalf may be held responsible for the use which may be made of the information contained therein. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 4 DOCUMENT LOG VERSION DATE DESCRIPTION OF CHANGE V1.0 03/07/2024 Final version, submitted to EC through SyGMa V2.0 13/12/2024 Revised version D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 5 TABLE OF CONTENTS List of Acronyms and Abbreviations .............................................................................. 7 List of Figures .................................................................................................................. 9 List of Tables.................................................................................................................. 10 Executive Summary ........................................................................................................ 11 1 Introduction ............................................................................................................. 12 2 Enablers for Secure Decentralized Data Sharing ................................................ 13 2.1 Quantum-safe cryptography .......................................................................... 13 2.2 Privacy Preserving ........................................................................................... 14 2.3 Confidential ZKP-enhanced blockchain characteristics .............................. 15 2.4 Anonymous Credentials and Selective Disclosure Credentials ................... 16 3 Secure Decentralized data sharing framework overview .................................. 21 3.1 Data Sharing Process ...................................................................................... 22 3.2 Gaia-X ............................................................................................................... 23 3.3 Nokia Data marketplace .................................................................................. 25 4 Secure Decentralised Data Sharing architecture ................................................ 28 4.1 Edge Layer ........................................................................................................ 29 4.2 Confidential Networking Layer ....................................................................... 29 4.3 Orchestration Layer ........................................................................................ 30 4.4 Application Layer .............................................................................................. 31 4.5 Data Ops Layer ................................................................................................ 38 4.6 DLT Layer ......................................................................................................... 45 4.7 Computation Layer .......................................................................................... 49 4.8 Integration between Orchestration and Computation layers ..................... 53 5 Testing and Evaluation .......................................................................................... 55 5.1 Testing Procedure Development .................................................................... 55 D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 6 5.2 Testing methodology .......................................................................................56 5.2.1 Use case templates ................................................................................. 57 5.2.2 Indicative test use cases for DLT layer testing .................................... 58 6 Conclusions............................................................................................................. 62 References .................................................................................................................... 63 A Appendix .................................................................................................................65 A.1 Distributed ledger technology ........................................................................65 A.1.1 Permissioned DLT ....................................................................................65 A.1.2 Permissionless DLT ................................................................................ 66 A.1.3 Encrypted Streams Channels ................................................................. 67 A.2 Decentralized Identities ................................................................................... 67 D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 7 LIST OF ACRONYMS AND ABBREVIATIONS Acronym/Abbreviation Definition ABAC Attribute-Based Access Control AC Anonymous Credentials AES Advanced Encryption Standard AES Advanced Encryption Standard AI Artificial Intelligence CI\CD Continuous Integration/Continuous Deployment DAG Directed Acyclic Graph DiD Decentralized IDs DIF Decentralized Identity Foundation DLT Distributed Ledger Technology DoA Description of Action ECC Elliptic Curve Cryptography FHE Fully Homomorphic Encryption FL Federated Learning GRPC Google Remote Procedure Calls HE Homomorphic Encryption HSMs Hardware Security Modules IAM Identity and Access Management IDS Intrusion Detection Systems Intel SGX Intel Software Guard Extensions IoT Internet of Things NDM Nokia Data Marketplace PII Personally Identifiable Information PoET Proof-of-Elapsed-Time PoK Proof of Knowledge POW Proof of Work D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 8 PRM Processor Reserved Memory RBAC Role-based Access Control RSA Rivest-Shamir-Adleman SD Selective Disclosure SDK Software Development Kit SIEM Security Information and Event Management SMPC Secure Multi-Party Computations TEE Trusted Execution Environments TEE Trusted Execution Environment TLS Transport Layer Security TP Trusted Party URM User and Role Management URN Uniform Resource Name VCs Verifiable Credentials ZKP Zero Knowledge Proof D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 15 and back. However, HE further provides algorithms in the ciphertext domain that directly carry over to the plaintext domain.  Access Controls and Consent Management: Implementing strong access controls and consent management mechanisms ensures that data is only accessed and used by authorized parties and for specified purposes. This helps individuals maintain control over their data and exercise their privacy preferences.  Secure Multi-Party Computation: Secure Multi-Party computation (SMPC) enables multiple parties to jointly evaluate a function without disclosing their inputs. This allows multiple parties to collaborate on data analysis while preserving privacy. In SMPC, there exist many different trust models and access structures. Typically, the less trust there is between the parties, the higher the workload for the countermeasures, thus, increasing runtime and network constraints. For settings with many parties, robustness might be important. A robust or threshold MPC scheme only requires a subset of clients to be available during computation. 2.3 CONFIDENTIAL ZKP-ENHANCED BLOCKCHAIN CHARACTERISTICS Confidential Zero-Knowledge Proof (ZKP)-enhanced blockchain refers to a blockchain system that incorporates zero-knowledge proofs to enhance the confidentiality and privacy of transactions and data stored on the blockchain. The key characteristics of a confidential ZKP-enhanced blockchain are:  Privacy-Preserving Transactions: Confidential ZKP-enhanced blockchains allow for the execution of private transactions, where the transaction details are hidden from the public. Zero-knowledge proofs are used to verify the validity of transactions without revealing sensitive information, such as the transaction amount or the identities of the parties involved.  Selective Data Disclosure: With ZKP-enhanced blockchains, participants can selectively disclose specific information to authorized entities while keeping the remaining data confidential. Zero-knowledge proofs enable the verification of specific statements about the data without exposing the entire dataset.  Identity Protection: ZKP-enhanced blockchains provide identity protection by allowing participants to prove the validity of their statements or D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 16 transactions without revealing their actual identities. Zero-knowledge proofs enable authentication and verification without disclosing unnecessary personal information.  Auditability and Transparency: While maintaining confidentiality, ZKPenhanced blockchains also maintain the characteristics of transparency and auditability associated with traditional blockchains. Participants can still verify the integrity and validity of the blockchain's history and the overall consensus mechanism.  Data Confidentiality: In addition to transaction privacy, confidential ZKPenhanced blockchains offer enhanced data confidentiality. Zero-knowledge proofs can be used to encrypt or obfuscate sensitive data stored on the blockchain, ensuring that only authorized entities can access and decrypt the information.  Enhanced Security: Zero-knowledge proofs add an additional layer of security and privacy to the blockchain by allowing participants to prove the correctness of their transactions or statements without revealing sensitive information. This reduces the risk of data breaches, fraud, and unauthorized access to confidential information.  Scalability and Efficiency: Confidential ZKP-enhanced blockchains aim to achieve scalability and efficiency while maintaining privacy. Advancements in zero-knowledge proof techniques and protocols enable more efficient computation and verification, allowing for faster transaction processing and improved performance.  Regulatory Compliance: Confidential ZKP-enhanced blockchains can facilitate compliance with regulations that require privacy and data protection. By allowing for confidential transactions and selective data disclosure, these blockchains can provide a balance between privacy and regulatory requirements. 2.4 ANONYMOUS CREDENTIALS AND SELECTIVE DISCLOSURE CREDENTIALS Anonymous Credentials Anonymous credentials enable the verification of specific personal attributes without revealing the underlying identity of the user. They operate on the principle of exchanging cryptographic tokens instead of raw personal data. Essentially, when a user needs to prove a particular attribute (such as age or membership), they D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 17 present an anonymous credential instead of disclosing actual data. These credentials are issued by trusted entities and digitally signed, confirming the validity of the attribute without exposing any identifying information. The process begins with a trusted party generating a secret value and a cryptographic commitment. The secret and commitment are shared with the user (the Holder) and the Issuer. The Issuer, after verifying the Holder's knowledge of the secret, provides a digital signature on the commitment. This creates an anonymous credential that the Holder can present to Verifiers when required. The Verifier then checks the validity of the credential using a Proof of Knowledge (PoK), ensuring that the user possesses a valid credential without ever revealing the secret itself. This framework provides individuals with greater control over their privacy while enabling them to engage in transactions or interactions that require the verification of personal attributes. Applications range from secure authentication and digital identity systems to access control mechanisms and privacy-preserving solutions. For instance, when accessing a restricted online service, a user can prove their membership status without revealing their membership ID or any other personal information. The underlying technology leverages advanced cryptographic techniques, including zero-knowledge proofs (ZKP) and digital signatures, to ensure the security and privacy of the credentials. These techniques make it possible to verify the authenticity and integrity of the credentials without compromising the privacy of the Holder. The effective deployment of an Anonymous Credentials (AC) system requires established protocols: (1) for the issuance of a signature on a committed value without revealing the signed value to the signer, and (2) for demonstrating possession of a signature on a committed value, as suggested in [1]Moreover, it is generally advantageous to have the ability to efficiently revoke ACs, as indicated in [2]. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 18 Figure 1: Sequence diagram for Anonymous Credentials Trusted Party (TP): The Trusted Party is responsible for the initial setup of the system, including generating secret values, commitments, and public keys. It ensures the integrity and security of the system's cryptographic operations. A commitment is a cryptographic construct used to securely bind a value (e.g., a secret) to a specific identifier without revealing the actual value. Commitments are generated by the Trusted Party and shared with the Issuer and Holder for further processing. Issuer (I): The Issuer is a trusted institution that issues anonymous credentials to users based on their verified characteristics or attributes. Issuers digitally sign credentials to attest to their authenticity and validity. Holder (H): The Holder is an individual user who possesses anonymous credentials issued by one or more Issuers. Holders can disclose information from their credentials to Verifiers without revealing their true identity. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 19 Verifier (V): The Verifier is an entity that verifies the authenticity and validity of anonymous credentials presented by Holders. By receiving Proof of Knowledge from the holder, aiming to prove that it holds the secret and valid signature for that secret. Selective Disclosure Credentials Another notable method is Selective Disclosure (SD), which permits the revelation of specific information while concealing other aspects of the credential. This technique allows for the issuance of a credential with multiple confidential attributes to a Holder, who can then selectively present certain attributes encoded in the credential to a Verifier for verification purposes. Theoretically, an SD Credential system can be developed starting from an ACs system, with necessary adjustments to the protocols involved. Selective disclosure credentials enable users to reveal only specific attributes from their credentials while concealing other details. This approach enhances privacy by allowing individuals to disclose only the information necessary for a particular interaction without exposing their full identity or additional attributes. For example, an individual holding a credential with attributes such as name, date of birth, phone number, and address may use the credential to disclose only their age in a specific scenario. The issuer of the credential provides a signature for all the mentioned attributes without necessarily knowing the exact values of those attributes. This allows the individual to choose which information to reveal without involving the issuer each time. This mechanism is particularly useful in scenarios where users must verify certain attributes but want to keep other details private. It supports various applications, including digital identities, secure transactions, and compliance with privacy regulations, by providing a flexible and privacy-preserving way to share information. To implement Selective Disclosure, Zero-Knowledge Proof (ZKP) protocols are modified and extended. These modified protocols enable the issuance of credentials with multiple secret attributes while allowing only a subset of those attributes to be presented to the verifier for verification purposes. This is achieved through the use of a generalized signature scheme and the adaptation of existing ZKP protocols. In this way, a high level of privacy is ensured, along with the ability to selectively disclose information from the credential. To ensure the selective disclosure our algorithm will use a signature scheme and the efficient protocols for D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 20 ZKP proposed by Camenisch and Lysyanskaya [1] relying on principles described in the ETSI report [3] Figure 2: Sequence Diagram for Selective Disclosure Credentials In the first step, the Trusted Party generates secret values, cryptographic commitments, and public keys. These elements are then shared with the Holder and the Issuer. The Holder subsequently requests a digital signature on the commitment from the Issuer. The Issuer verifies that the Holder possesses knowledge of the secret values and generates a digital signature on the Holder's commitment. The Holder can then selectively disclose specific attributes and provide proof of knowledge of the secret values and the digital signature. The Verifier requests verification of the Proof of Knowledge (PoK) for the disclosed attributes. Once the Holder provides the PoK for the disclosed attributes, the Verifier verifies them. Upon successful verification, the Verifier authorizes the service if all proofs are valid. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 21 3 SECURE DECENTRALIZED DATA SHARING FRAMEWORK OVERVIEW This section outlines the secure and confidential data sharing framework and explains the alignment with Gaia-X and the Nokia Data Marketplace. The proposed framework aims to facilitate trustworthy data exchange for various use cases, including confidential analytics, ML model training, and collaborative AI, while complying with stringent data security and privacy requirements. Traditional centralized data sharing models raise concerns regarding data privacy, security breaches, and a single point of failure. Secured Decentralized Data Sharing Framework addresses these challenges while enabling efficient and controlled data sharing. The proposed framework leverages the principles of blockchain technology to establish a decentralized network where data sharing is facilitated through a distributed ledger. This ledger ensures data integrity, transparency, and immutability, enhancing trust among participating entities. Encrypted data storage and communication mechanisms provide an additional layer of security, safeguarding sensitive information from unauthorized access. The framework will enable: • Enhanced security by employing encryption mechanisms to safeguard data at rest and in transit. By utilizing cryptographic techniques, sensitive information remains protected from unauthorized access and potential breaches, reducing the risk of data leaks and cyberattacks. Secure data sharing mechanisms, employing blockchain technologies. • CONFIDENTIAL6G will provide two data fabrics, one based on Permissioned and the other based on Permissionless Distributed Ledger Technology. • Nokia Data Marketplace will be used as an initial implementation, which leverages Hyperledger Fabric blockchain from Linux Foundation. • IOTA protocol with second Layer Identity and Streams encryption framework This concept will be further improved with privacy-preserving cryptographic primitives and enablers developed in WP2, like • Zero-knowledge Proofs, D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 22 • FHE-enabled Smart Contracts and Decentralized IDs (DIDs) coupled with Verifiable Credentials (VCs). • Created frameworks for secure and confidential data sharing will be aligned to Gaia-X standards. • Integration points with both the computation layer (TEE/FHE) and orchestration layer will be defined, so that the data marketplace can be the secure and traceable source of data needed for arbitrary confidential analytic, ML model training or collaborative AI. • Finally, a set of testing procedures will be developed, and they will apply to both the lower DLT layer, as well as on the distributed proxy and other access control mechanisms that will be implemented throughout the task. 3.1 DATA SHARING PROCESS The data sharing process involves the exchange of data between multiple participants or entities in a secure and controlled manner. The participants in the data sharing process can vary depending on the specific context and purpose of the data sharing initiative. Common participants include:  Data Owners: These are the individuals or organizations that possess or have control over the data being shared. They are responsible for determining the permissions and conditions under which their data can be accessed and shared.  Data Consumers: Data consumers are the individuals or entities that request and utilize the shared data for various purposes. They may include researchers, analysts, or other organizations seeking insights or value from the data.  Data Providers: Data providers are entities that supply data to be shared. They may include organizations that collect or aggregate data, such as government agencies, research institutions, or businesses.  Data Custodians: Data custodians are responsible for securely storing and managing the shared data on behalf of the data owners. They ensure that the data is protected, backed up, and accessible to authorized users as per the agreed-upon access controls.  Data Intermediaries: In some cases, there may be intermediaries involved in the data sharing process. These intermediaries facilitate the exchange of data between data owners and data consumers. They may provide platforms, D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 23 APIs, or other technical infrastructure to enable secure and efficient data sharing.  Regulatory Bodies: Depending on the nature of the data being shared and the jurisdiction, regulatory bodies or authorities may play a role in overseeing and enforcing compliance with relevant laws, regulations, and privacy standards.  Technology Providers: Technology providers offer the tools, software, and infrastructure required for secure data sharing. They may provide encryption mechanisms, access control systems, blockchain platforms, or other decentralized technologies to ensure the privacy, security, and integrity of the shared data. 3.2 GAIA-X Gaia-X [4] is not a single entity, but rather a federated, open-source initiative in Europe aimed at creating a secure, interoperable, and sovereign data ecosystem. It is designed to empower European organizations and individuals to control their data, choose who they share it with, and how it is used. It is a collaborative effort involving various stakeholders like governments, businesses, and research institutions, all working towards a common goal: " To give European organizations more control over their data, fostering innovation and economic growth while respecting user privacy and security." Core Principles  Openness and Transparency: Based on open-source technologies and standardized protocols, ensuring everyone can participate and contribute.  Decentralization and User Control: Data remains under the ownership of the provider, who decides who can access it and under what conditions.  Security and Trust: Robust security measures and data protection regulations are paramount to ensure user privacy and data integrity.  Interoperability: Different platforms and services should seamlessly connect and exchange data, regardless of their technology stacks. Key Components  Data Spaces: These are specialized marketplaces or ecosystems for specific data types (e.g., healthcare, automotive). They provide tools and protocols for secure data sharing within that domain. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 24  Gaia-X Federation Services: These services handle critical tasks like user authentication, access control, and trust management across the entire network.  Data Portals: These act as gateways for users to find and access data services offered by various providers within the Gaia-X ecosystem. Technology Stack  Decentralized Technologies: Gaia-X encourages the use of blockchain and other decentralized technologies to empower user control and prevent vendor lock-in.  Standardized APIs: Open and standardized interfaces allow different platforms and services to communicate and share data seamlessly.  Security Protocols: Robust encryption, access control mechanisms, and data protection regulations are essential for ensuring data security and privacy. How Does It Work? 1. Data providers (organizations with valuable data) register their data assets within a relevant Data Space. 2. Data consumers (organizations seeking specific data) search the Data Portal and identify relevant data offerings. 3. Negotiation and Agreement: Data providers and consumers negotiate terms of access, including data usage limitations and privacy safeguards. 4. Data Sharing: Once an agreement is reached, the data is shared through secure channels, facilitated by Gaia-X Federation Services and Data Space-specific protocols. 5. Governance and Monitoring: Continuous monitoring and enforcement of data protection regulations and agreed-upon terms of use ensure responsible and ethical data sharing. Gaia-X Framework and Secure Data Sharing: • Both Gaia-X and secure data sharing frameworks promote a decentralized approach. Data is not stored in a single location but distributed across a network of trusted participants. This reduces the risk of single points of failure and increases user control. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 31 and out based on demand, and ensuring high availability of applications. Examples include Kubernetes, Docker Swarm, and Apache Mesos.  Service Discovery: This component helps in locating services within the network, which is crucial for microservices-based architectures.  Health Checks and Monitoring: These components continuously monitor the health of services and the utilization of resources. They trigger alerts when they detect anomalies. Examples include Prometheus, Grafana, and ELK stack (Elasticsearch, Logstash, Kibana).  Secret Management: This component manages sensitive data like API keys, passwords, and certificates. It provides a secure method to store and manage sensitive information. Examples include Vault, AWS Secrets Manager, and Azure Key Vault.  Orchestration intelligence – Applications can be orchestrated on different cloud, edge, and device platforms. Orchestration intelligence deploys and configures containerized applications based on application provider’s needs and on available information, e.g., of host platform’s capability or security health.  Remote attestation – Application provider can verify trustworthiness of target host and containerization systems before critical containers are deployed. Remote attestation is a method where a host authenticates its hardware and software configuration to a remote party (provider). The Orchestration Layer schedules computations on data it at the Computation Layer. 4.4 APPLICATION LAYER This layer acts as the central nervous system of the marketplace and manages how data is bought and sold. The key components of this layer are: • Identity and Access Management o Auth: Oversees user authentication and authorization. o Access Control: Governs how data is accessed by buyers after purchase. • Reporting & Logs: Tracks marketplace activity. • Monitoring & Alerts: Monitors for security threats. • Subscription: Provides a subscription model for data access. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 32 Identity and Access Management Identity and Access Management (IAM) is a critical framework in the IT sector that ensures the right individuals have appropriate access to technology resources. It involves processes and technologies that manage digital identities and control user access, encompassing authentication, authorization, and user management. IAM systems verify user identities through methods like passwords, biometrics, or security tokens, then grant access levels based on roles or responsibilities. IAM is vital for protecting sensitive data, preventing unauthorized access, and maintaining regulatory compliance in the IT sector. By establishing and enforcing access controls, IAM helps organizations mitigate the risk of data breaches, insider threats, and other security incidents. Effective IAM solutions also improve operational efficiency by streamlining user provisioning, automating access requests, and providing centralized management of user identities and permissions. Authentication Decentralized identity Decentralized identity is a paradigm shift in Identity and Access Management (IAM), transferring control of digital identity from centralized authorities to individuals. Instead of relying on third-party providers to manage and store identity data, individuals own and manage their digital identities using self-sovereign identity principles. This approach utilizes distributed ledger technologies and cryptographic protocols to create verifiable credentials that users can selectively share with service providers. Decentralized identity offers numerous benefits in IAM, including enhanced privacy and security. By eliminating the need for central repositories of identity data, it reduces the risk of large-scale data breaches and unauthorized access. Additionally, users gain greater control over their personal information, deciding which data to share and with whom. This fosters trust and transparency, as individuals are empowered to manage their digital identities autonomously. However, challenges remain in widespread adoption, such as standardization, interoperability between different systems, and user education. Despite these hurdles, decentralized identity represents a promising future for IAM, enabling greater user control, privacy, and security. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 33 Verifiable Credential Verifiable Credentials (VCs) are a cornerstone of modern identity and access management (IAM), offering a secure and privacy-preserving way to manage digital identities. VCs are tamper-proof digital attestations of claims about a subject, issued by a trusted authority. These claims can range from personal information like name and date of birth to professional qualifications or membership status. In IAM, VCs play a pivotal role in enhancing security and user control. They enable individuals to selectively disclose information to service providers, reducing the risk of data breaches and identity theft. By verifying the authenticity and integrity of credentials, organizations can ensure that users are who they claim to be, streamlining access to resources and services. Moreover, VCs support compliance with data protection regulations by minimizing the collection and storage of unnecessary personal data. However, the adoption of VCs in IAM faces challenges like standardization, interoperability between different systems, and user education. Additionally, the complexity of cryptographic protocols underlying VCs may require technical expertise for implementation and management. Despite these hurdles, VCs hold immense potential for transforming IAM, enabling greater trust, privacy, and security in the digital realm. Identities implementation is based on W3C standard and maintains a Decentralized Identity that conforms with managed standards for self-sovereign identity. An URN (Uniform Resource Name) is a method name which is a unique prefix before the actual identity id. Most of the listed projects are using a distributed ledger technology as the underlying network. By knowing the identity URN, the network and implementation can be identified. In addition, the implementation provides standardised implementation for the following functionality:  W3C: IOTA Self-Sovereign Identity (SSI) 1 utilizes the decentralized identifier (DID) standard and the verifiable credential (VC) standard as set by W3C. 1 https://wiki.iota.org/identity.rs/welcome/ D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 34  DIDComm: IOTA SSI utilizes the DIDcomm messaging specification standard as set by the ‘Decentralized Identity Foundation (DIF).  OpenID: In the future IOTA’s SSI solution will also incorporate the OpenID standardized approach. How Authentication will work • Edge device interacts with the data sharing application. • The edge device presents their DID document containing public keys and claims about their identity, along with specific verifiable credentials relevant to the requested data access. • The application interacts with the DLT network (e.g., Hyperledger Fabric, IOTA) to retrieve the device’s DID document and information about the issuers who issued the presented verifiable credentials. • Using cryptographic mechanisms, the application verifies the authenticity and validity of the presented verifiable credentials. This involves checking the issuer's signature, validity period, and revocation status (if applicable). • If the verifiable credentials are successfully verified, the application might proceed to interact with the smart contract. Access Control User and Role Management User and Role Management (URM) is a fundamental aspect of data access control mechanisms, ensuring that the right individuals have appropriate access to sensitive information. It involves defining user roles based on their job responsibilities and assigning permissions accordingly. Roles simplify access management by grouping users with similar access requirements and applying permissions at the role level. In URM, users are assigned to one or more roles, and each role is granted specific permissions to access certain data or perform actions. This approach provides a scalable and efficient way to manage access controls, as changes to permissions can be made at the role level, automatically affecting all users assigned to that role. URM also helps to enforce the principle of least privilege, ensuring that users have access only to the data and resources necessary for their job functions. URM plays a crucial role in protecting sensitive data by preventing unauthorized access, mitigating the risk of data breaches, and ensuring compliance with data protection regulations. It also improves operational efficiency by simplifying access management and reducing the administrative overhead associated with individual D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 35 user permissions. By effectively managing user roles and permissions, organizations can maintain a secure and controlled environment for their data assets. Attribute-Based Access Control (ABAC) Attribute-Based Access Control (ABAC) is a versatile and dynamic approach to data access control, offering granular and context-aware authorization decisions. ABAC defines access policies based on attributes associated with users, edge device, objects, and the environment. Attributes can include roles, departments, or clearance levels, while object attributes may encompass data sensitivity, classification, or location. Environmental attributes can consider time, location, or device type. ABAC's flexibility and fine-grained control make it well-suited for complex and evolving data environments. Access decisions are made by evaluating attribute values against predefined policies, allowing for dynamic and context-specific authorization. For example, a policy could grant access to a data only to edge devices with a specific clearance level who are accessing it from a secure location during business hours. ABAC also supports the principle of least privilege, ensuring that edge devices have access only to the data and resources necessary for their specific tasks. However, ABAC's implementation can be complex and requires careful planning and management of attributes and policies. The increased flexibility also introduces the potential for misconfigurations and security risks. Despite these challenges, ABAC represents a powerful tool for implementing sophisticated data access control mechanisms, enabling organizations to protect sensitive data while ensuring efficient and secure access for authorized users. Attribute-Based Access Control (ABAC) with DID and Smart Contracts • The edge device interacts with the data sharing application. • Edge device presents their DID document and relevant VCs that represent their attributes (e.g., role, location, certifications). • The application interacts with the DLT network to retrieve the edge device’s DID document and information about the issuers of the presented VCs. • The application extracts the relevant attributes required for access control from the verified VCs. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 36 • The application interacts with the smart contract deployed on the DLT network. This interaction involves sending the extracted edge device attributes. • The smart contract retrieves two key pieces of information: o These policies define the required attributes an edge device must possess for access. o These labels represent a level of assurance associated with the data and the service providing access. • The smart contract performs a two-step evaluation: o It evaluates the edge device’s attributes against the access control policies defined for the requested data. o It verifies if the Gaia-X label associated with the user's VC (representing their identity provider) meets the required assurance level specified by the Gaia-X label attached to the data. • If the edge device’s attributes satisfy the access control policies defined in the smart contract, access is granted. • The application facilitates access to the requested data for the edge device. • If the user's attributes do not meet the policy requirements, access is denied. • The application informs the edge device that access is denied due to insufficient attributes. Reporting \ Logs • An Edge device interacts with the application, performing an action that needs to be logged (e.g., data access request, permission change). • The application logs details of the event, including: o Edge Device DID (identity) o Performed action. o Relevant data involved (optional, depending on sensitivity) • The application determines the appropriate log level based on the event's severity (e.g., info for access requests, warning for suspicious activity, error for failures). • Depending on the log level and framework configuration, the application decides whether to log the event on the DLT: o If logging on the DLT is chosen, the event details are sent to the smart contract for further processing. o For less critical events (e.g., info logs), the application might choose to store the logs locally on a secure server. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 37 • (For DLT logging) The application interacts with the smart contract deployed on the DLT network, sending the prepared log data. • The smart contract receives the log data and stores it securely on the DLT ledger. o Success/Failure (H):  Success: If the log is successfully stored on the DLT, the process is complete.  Failure: If there is an issue storing the log on the DLT (e.g., network issues), the application might: • Retry sending the log. • Notify an administrator about the failure for further investigation. Key Points: • DLT storage provides an immutable and tamper-proof audit trail of all logged events, enhancing transparency and accountability. • Smart contracts can be used to filter and control access to specific logs on the DLT, ensuring data privacy. • DLT storage adds an extra layer of security to logs, making them tamperproof and resistant to unauthorized modification. Monitoring, Alerts Monitoring & Alerts component in the application acts as a vital security layer, safeguarding data and promoting a secure data sharing environment. Monitoring and Alert Component continuously monitors the application for suspicious activities that could indicate security breaches or unauthorized access attempts. This includes monitoring data access patterns, and system performance. Upon detecting anomalies, it can trigger alerts for relevant parties (administrators, security teams) depending on the severity of the threat. These alerts provide timely warnings and allow for swift action to mitigate potential damage. Alerts can inform relevant parties about how their data is being accessed and by whom. This transparency builds trust. Subscription Decentralized data sharing framework may involve fees or limitations on data access. The subscription component could be used to: D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 38  Create different subscription plans with varying data access quotas or functionalities.  Track how much data is being accessed by subscribed entities/users/groups.  It can be used to handle any fees associated with data access based on the chosen subscription plan.  It can be used to control how data is being used within the framework.  Subscription component can also be used for billing purposes if the data access involves a cost. 4.5 DATA OPS LAYER The Data Ops layer acts as the backbone for managing data within the secure decentralized data framework. It is responsible for several key tasks:  It involves ingesting data from providers, ensuring it adheres to quality standards, and formatting it for compatibility within the framework.  Data cleaning and standardization processes ensure users' edge devices can access reliable and trustworthy data.  The Data Ops layer enforces data access controls and anonymization techniques to protect user privacy and comply with regulations. Blockchain's immutability ensures data integrity and prevents unauthorized modification.  The Data Ops layer helps users, edge devices discover relevant datasets by implementing search functionalities and categorization systems. Data curation practices ensure the quality and relevance of available datasets.  Data provenance allows to trace the origin and history of a dataset, fostering trust and transparency.  The Data Ops layer interacts with smart contracts, the self-executing code on the blockchain that governs data transactions. This ensures automated execution of data access agreements and secure tokenized payments. Data Security Data security is a paramount concern in today's digital age, where information is a valuable asset. Data access control mechanisms play a pivotal role in ensuring the confidentiality, integrity, and availability of data, safeguarding it from unauthorized access, alteration, or destruction. These mechanisms provide a framework for managing who can access data, what actions they can perform, and under what circumstances. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 39 The proliferation of Internet of Things (IoT) devices and the increasing reliance on sensor networks have revolutionized data collection and analysis. However, the vast amount of sensitive information transmitted by sensors raises significant data security concerns. This document explores the essential data security requirements and principles that must be considered to safeguard sensor communications against unauthorized access, data breaches, and malicious attacks. By understanding and implementing these measures, organizations can ensure the confidentiality, integrity, and availability of their sensor data, ultimately fostering trust and reliability in their systems. Confidentiality Confidentiality refers to the protection of sensor data from unauthorized disclosure. Given the sensitive nature of information transmitted by sensors, maintaining confidentiality is paramount. Encryption is a fundamental tool for ensuring confidentiality. Strong encryption algorithms, such as Advanced Encryption Standard (AES), should be employed to scramble sensor data, rendering it unreadable to unauthorized parties. Secure key management practices, including key generation, distribution, and storage, must be implemented to protect the encryption keys. Integrity Integrity ensures the accuracy and consistency of sensor data throughout its lifecycle. Maintaining data integrity is crucial to prevent unauthorized modification or tampering. Data validation techniques should be implemented to verify the correctness of sensor readings and detect any inconsistencies. Checksums, cryptographic hash functions, and digital signatures can be used to ensure the integrity of transmitted data. By comparing checksums or verifying digital signatures, recipients can verify that the data has not been altered during transmission. Authentication Authentication is the process of verifying the identity of sensors and receiving devices. Robust authentication protocols, such as Transport Layer Security (TLS) or mutual authentication schemes, should be employed to establish trust between communicating parties. Digital certificates and credentials can be used to verify the authenticity of devices. Authentication ensures that data is transmitted only between authorized entities, preventing unauthorized access and potential attacks. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 40 Authorization Authorization defines and enforces access controls to sensor data. Once the identities of devices are authenticated, authorization mechanisms determine the level of access granted to each device. Role-based access control (RBAC) or attribute-based access control (ABAC) can be implemented to define roles and permissions based on the principle of least privilege. This ensures that devices can access only the specific data and functions necessary for their intended purpose, minimizing the risk of unauthorized actions or data misuse. Availability Availability ensures that sensor data is accessible and usable when needed. To maintain availability, it is essential to implement redundancy, fault tolerance, and disaster recovery mechanisms. Redundancy involves duplicating critical components or data to ensure continued operation in case of failures. Fault tolerance mechanisms allow systems to continue functioning even in the presence of faults. Disaster recovery plans outline procedures for restoring systems and data in the event of major disruptions or disasters. These measures ensure that sensor data remains accessible and usable, minimizing downtime and potential data loss. Data Security Principles for Sensor Communications Encryption Encryption is a fundamental pillar of data security, safeguarding sensitive information from unauthorized access and ensuring confidentiality. It involves converting plaintext data into an unreadable format, called ciphertext, using complex algorithms and encryption keys. This process renders the data meaningless to anyone without the corresponding decryption key, effectively protecting it from unauthorized viewing or manipulation. Data at rest refers to information stored on physical or virtual storage devices, such as hard drives, servers, or cloud storage. Encrypting data at rest adds an extra layer of protection, ensuring that even if the storage device is compromised, the data remains inaccessible to unauthorized individuals, devices. This is particularly crucial for sensitive information like financial records, personal data, or intellectual property. Data in transit, on the other hand, pertains to information transmitted over networks, such as the internet or internal company networks. Encrypting data in transit protects it from interception and eavesdropping during transmission, D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 47 keys. All messages exchanged within the channel are cryptographically secured. This ensures data integrity and confidentiality. Messages are stored on a decentralized ledger, ensuring they are immutable and verifiable. The use of a decentralized ledger guarantees that once data is written, it cannot be altered. This provides a secure and trustworthy record of all transactions, which is critical for applications requiring high data integrity. FHE enabled Smart Contract A smart contract is essentially a program stored on a blockchain that runs automatically when certain conditions are met. Some key features of smart contracts include : • They remove the need for intermediaries like lawyers or banks to enforce the terms of an agreement. • Stored on a blockchain, they are tamper-proof and highly secure. • All participants can see the terms of the contract and the execution history. • They eliminate the need for trust between parties, as the code dictates the outcome. How smart contract works: • A service triggers a transaction using their blockchain platform’s SDK(client application), which activates the smart contract. • The transaction is verified by the blockchain network, and the smart contract's code is reviewed. • If the conditions set in the code are met, the smart contract executes the programmed actions. This could involve transferring funds, issuing a document, or triggering another smart contract. • The entire process is recorded on the blockchain, providing a permanent and immutable record of the transaction. Throughout the process, all participants on the blockchain network can see the execution of the smart contract. The entire transaction history is stored securely and permanently on the blockchain, providing a high level of transparency and immutability. A regular smart contract runs on a blockchain, but the data it uses is visible to everyone. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 48 An FHE-enabled smart contract allows computations to be performed on encrypted data, without ever decrypting it. Figure 6: FHE-Enabled Smart Contract Key features of FHE-enabled smart contract include : • FHE allows computations to be performed on encrypted data without the need to decrypt it. This means that sensitive information remains confidential throughout the entire process. • FHE-enabled Smart Contracts enable parties to execute operations on encrypted data, ensuring privacy is maintained. For instance, financial transactions can be carried out without revealing the transaction amounts or the parties involved. • With FHE, data is protected not only during storage and transmission but also during processing. This greatly enhances data security, reducing the risk of data breaches or leaks. Even if a malicious actor gains access to the smart contract, they will only see encrypted data, rendering it useless without the decryption key. • FHE adds an extra layer of trust to smart contracts. Users can confidently engage with smart contracts knowing that their data remains private and secure. This can lead to increased adoption of blockchain-based solutions in industries that demand strict data confidentiality, such as healthcare, finance, and supply chain management. • FHE-enabled Smart Contracts can facilitate secure data sharing and collaboration among multiple parties. They can jointly compute on encrypted data while keeping the underlying information private. This is particularly valuable in scenarios where multiple entities need to collaborate while protecting sensitive data, like research collaborations or industry consortia. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 49 4.7 COMPUTATION LAYER This layer is where the actual data processing and computation happen. It uses Secure Multi-Party Computation (SMPC) and Trusted Execution Environments (TEEs) to ensure the confidentiality and integrity of data during processing. In principle, FHE and TEEs perform computations with confidential data in untrusted settings. While TEEs aim to solve this problem with dedicated hardware, FHE employs cryptographic constructions, allowing the computation directly on encrypted data. While choosing one of the technologies may be compelling, both come with their strengths and limitations. Orchestration Layer needs to be able to send data to the computation layer securely and receive the results of the computations. This involves ensuring the data is encrypted and secure during transit and while being processed. The computation layer in a secure decentralized data sharing framework typically consists of the following components: Secure Multi Party Computation These protocols allow multiple parties to jointly compute a function over their inputs while keeping those inputs private. SMPC protocols are crucial for preserving privacy in decentralized computations. SMPC works as follows:  Input Encryption: Each party involved in the computation encrypts their input data. This ensures that the data remains confidential and is not revealed to the other parties.  Distributed Computation: The encrypted inputs are then used to perform the computation. This is done in a distributed manner, with each party performing a part of the computation on their own encrypted input. The computation is structured in such a way that the result can be obtained without revealing the individual inputs.  Result Aggregation: Once all parties have completed their part of the computation, the results are aggregated. This is done in a secure manner to ensure that the final result is correct and has not been tampered with.  Result Decryption: The aggregated result is then decrypted to obtain the final output of the computation. This decryption is done in such a way that it does not reveal any information about the individual inputs. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 50  Output Delivery: The final output of the computation is then delivered to the parties involved. This is done in a secure manner to ensure that the output is not tampered with during delivery. TEE (Trusted Execution Environment) With the rapid development of the Internet, data security faces new challenges. As a bridge between the underlying hardware and upper layer applications, the operating system plays a critical role in securing sensitive data. The trusted execution environments (TEEs) are special operating systems aiming at preventing the illegal access and tampering of sensitive data. Thus, TEEs have much stricter security requirements than normal operating systems. A Trusted execution environment (TEE) is a hardware extension that aims to provide integrity and confidentiality guarantees to security-sensitive computation performed on a computer where all the privileged software (kernel, hypervisor, etc.) is potentially malicious. [11] Specifically:  Authenticity & Confidentiality of the code running on a TEE is ensured.  The State Integrity of run-time states is also ensured including memory, CPU registers, and I/O; states are stored in persistent memory.  The content of a TEE is dynamic and can be updated during execution.  An “ideal” TEE is secure against all software and hardware attacks.  A TEE is trustworthy and can provide proof of correctness of the executed computation to a third-party.  Provides proof that edge devices are interacting with software hosted inside the TEE (the attestation functionality). A major aim of TEEs is to solve the problem of secure remote computation - execution on an untrusted machine while having integrity and trust guarantees. One example of such a system is Intel SGX, which provides a secure container using trusted hardware to give a remote user the ability to upload the code and data to this container. Several measures ensure the confidentiality of the executed computation and intermediate data. Fully Homomorphic Encryption (FHE) We speak of HE when we have an encryption scheme where operations carry over from the plaintext to the ciphertext domain [12]. In the classical HE setting, a client D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 51 encrypts its data and sends it to a server that can evaluate an algorithm without decrypting. The final encrypted result is then sent back to the client. More formally, we refer to an HE scheme as a collection of algorithms that include ( Key Generation , Encryption , Decryption , and Evaluation ). This section will focus on the aspects relevant to applying HE for secure computation. More precisely, we want to give an overview of the relevant intuitions when choosing an HE scheme for a particular application. Let us first discuss the plaintext domain. The Encryption and Decryption procedures transform data from plaintext to ciphertext and back. However, depending on the HE scheme, different plaintext is supported, and the data for computation has to be encoded first. Usually, the schemes are split into Boolean 2 (CGGI [13], GSW [14]) and Arithmetic (BGV [15], BFV [16] [17], CKKS [18]) HE schemes. One can encode anything with any of the HE schemes using decomposition techniques. Still, in practice, one selects a Boolean scheme for low-precision integers or bits and arithmetic schemes for larger amounts of data or high-precision arithmetic. Next to the plaintext domain, the most important distinctions are the computational capabilities of the Evaluation algorithm. At the core of the security of these HE schemes is so-called noise. During Encryption, a small noise is added to the ciphertext, which can only be removed with the decryption key. With every operation performed, the noises of the involved ciphertexts grow. This effect is most significant for the multiplication of ciphertexts. Decryption is no longer possible when the noise exceeds a certain threshold (i.e., the noise might change the underlying data). Thus, for complex computations, we require a socalled bootstrapping procedure refreshing the noise level in a ciphertext. For Boolean schemes bootstrapping is cheap and in CGGI it is often performed together with every non-linear operation. In arithmetic schemes, on the other hand, bootstrapping is extremely expensive. In practice, the parameters of the schemes are tweaked until the required number of multiplications can be performed without decryption fail. When changing the parameters in arithmetic HE, allowing for more 2 In general, Boolean FHE schemes such as the CGGI or GSW schemes support operations over small precision integers. However, these schemes are optimized for Boolean arithmetic. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 52 multiplications has adverse effects on runtime and memory usage of all algorithms involved. Thus, the fundamental challenge there is to reduce the multiplicative depth as much as possible. Schemes including the bootstrapping operation are called fully-HE (FHE), while the Leveled-HE (LHE) schemes only support a limited number of operations. Given the use case, these limitations have to be considered.  Enables computations directly on encrypted data.  Orchestration layer encrypts the data and analysis/training models using FHE schemes.  Integration point: The orchestration layer sends the FHE encrypted data and models to the computation layer. The computation layer performs operations on the encrypted data and returns the FHE encrypted results. The orchestration layer decrypts the results to obtain the outcome. Intel SGX Intel SGX performs trusted computing, sensitive data and code are loaded and run in a secure zone known as an enclave, where their confidentiality and integrity are protected by strict security. [19] SGX relies on hardware-enforced memory isolation to secure code and data within enclaves. This isolation is achieved by using a special memory region called Processor Reserved Memory (PRM). PRM acts like a secure vault for enclaves, protecting them from unauthorized access by other programs or even the operating system. Here is how it works:  Application Setup: The application identifies the code and data that needs confidentiality. This code is designated for the enclave, while everything else remains in the untrusted region.  Enclave Creation: When confidential operations are needed, the application creates an enclave using SGX instructions.  Execution Switch: The processor switches execution to the enclave, granting access to the secure code and data stored in PRM.  Secure Execution: Only the trusted code within the enclave can access and process confidential data.  Execution Completion: Once the enclave's work is finished, control returns to the untrusted region, and normal execution resumes. Data Flow is as explained below: D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 53  Data Consumer asks for data access.  Data access is evaluated using smart contracts deployed in Hyperledger fabric blockchain platform.  The orchestration layer retrieves encrypted data following access control.  Data is pre-processed while maintaining privacy.  Encrypted data is securely transferred to the computation layer.  The computation layer performs computations on the encrypted data.  The computation layer generates cryptographic proofs attesting to the computations.  The encrypted results and proofs are sent back to the orchestration layer.  The orchestration layer verifies the proofs to ensure data integrity and traceability.  Data Consumer can access the decrypted results. 4.8 INTEGRATION BETWEEN ORCHESTRATION AND COMPUTATION LAYERS Integration points with both the computation layer, such as Trusted Execution Environment (TEE) and Fully Homomorphic Encryption (FHE), and the orchestration layer in a data marketplace are crucial for ensuring data privacy and security. By incorporating technologies like Smart Contracts and Multi-Party Computation, the data marketplace can enforce strong privacy and security guarantees, protecting the stakeholders during data transactions. The integration layer serves as a dedicated portion of an IT architecture that aids the seamless flow of data between different systems, applications, or databases. Think of it as a bridge; it standardizes data formats, ensures data quality, and manages data transformations, making it easier for systems to communicate and share information. This element is an intermediary that is particularly important when two systems do not speak the same "language" or have diverse ways of storing data. It takes information from one system, processes it, and then sends it to another system in a way that the receiving system can understand. This ensures that all parts of a business can access and use its data, even if they rely on different tools or software. The purpose of integration is to connect applications, data, services, and devices, often in complex ways. Through integration, organizations bring workflows together, so they are consistent and scalable. Businesses connect applications, D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 54 data, and processes in a fast, efficient, and automated manner. Connections can run between on-premises, cloud, and edge systems. They can bring together enterprise, partner, third-party, and legacy technologies. For data, integration provides solutions for gathering and processing information from multiple sources, in multiple formats. To integrate applications, sometimes direct API calls are suitable. But sometimes technologies need to communicate asynchronously, through messaging or events. All integration processes need orchestration—a straightforward way to define and run the workflow's logic. Figure 7: Integration and Orchestration D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 55 5 TESTING AND EVALUATION The process of testing is the evaluation of components taking into account specified functional platform requirements. The goal is to identify and rectify bugs, deficiencies, unexpected behaviour and to timely provide corrective measures. We should stress the fact that the testing procedures described in this deliverable will be performed on a technical level, by the development teams of the project themselves and not by real users. Testing in a pilot operation of the platform, falls within the scope of WP5 and will be elaborated there. However, we plan a small-scale testing operation in the context of WP4, which we describe in this deliverable. Testing is, usually, performed on two levels: i) Individual module ii) Integrated system testing. The former refers to the testing of the individual system components with respect to the requirements and the latter refers to the testing of the integrated system itself by assessing the interfaces among the modules and the involved data flow and the expected behaviour of the system “as a whole.” In order to effectively manage the complexity of the final system, testing will be initially performed on an individual module basis before the integration begins. After all modules are verified, then the integration will begin and when it is completed, a final set of tests will be performed mainly in the form of a small-scale pilot operation. 5.1 TESTING PROCEDURE DEVELOPMENT Our initial test plan is based on the following general considerations:  The adoption of a strategy to use. When testing the integrated modules and how the tests will be conducted (i.e., use cases). Our consortium has decided on the adopted methodology which is explained in this deliverable.  What will be tested - (e.g., software modules against set requirements). The modules that will be tested are described within the context of WP4.  What will be the time -frame of the testing (e.g., when it starts and ends). We have followed the task and WP sequencing as described in the DoA (WP4 and WP5). D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 56  Testing responsibilities among involved parties. These responsibilities have already been assigned and follow the corresponding module design and development responsibilities as described in the DoA, especially in WP4.  Pass and fail conditions for each performed test . The partners have proposed themselves the described tests for the modules they developed and thus, have identified accurately these conditions.  Potential risks involved when a test is performed. Actually, no privacy or other risk is foreseen for the described tests as they will be conducted in a restricted context and controlled environment by the involved partners.  Approval of the testing plan from all involved parties. All parties have agreed on the tests and the testing plan as described in this deliverable. 5.2 TESTING METHODOLOGY CONFIDENTIAL6G has decided to adopt an agile testing approach [20]. Briefly, this approach considers testing and development as two intertwined phases and not sequential (i.e., testing following development). This decision was dictated by the tight delivery dates of the modules as well as the requirement for early integration before the use case testing of WP5 takes place. With respect to the practical, separate, and integrated module testing, the generic methodology proposed in [21] will be followed. With respect to system testing, there are generally two main methodologies: (i) Incremental testing, (ii) Non-incremental testing Incremental testing includes several methods:  Bottom-Up approach – this method starts with testing the lower-level components, allowing early detection of issues. It needs drivers to simulate higher-level components that are not yet developed.  Top-Down approach – this method tests the highest-level components first, focusing on the system functionalities, data flows, and interfaces. It minimizes the need for drivers but requires stubs to simulate unavailable lower-level modules.  Hybrid integration – this approach combines Top-Down and Bottom-Up testing. Lower level modules are tested in parallel with their integration into the system, reducing the need for stubs and drivers but requiring more coordination to ensure smooth operation. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 63 REFERENCES [1] J. Camenisch and A. Lysyanskaya, “"A signature scheme with protocols",” Security in Communication Networks, pp. 268-289, 2003. [2] J. Camenisch, M. Kohlweiss and C. Soriente, “"Solving revocation with efficient update of anonymous credentials",” Security and Cryptography for Networks, Springer, pp. 454-471, 2010. [3] ETSI TR 119 476 V1.1.1, "Analysis of selective disclosure and zkp applied to Electronic Attestation of Attributes", 2023. [4] [Online]. Available: https://gaia-x.eu/what-is-gaia-x/about-gaia-x/. [5] [Online]. Available: https://go.dev/. [6] [Online]. Available: https://www.mongodb.com/. [7] [Online]. Available: https://nginx.org/en/. [8] [Online]. Available: https://v2.angular.io/. [9] [Online]. Available: https://grpc.io/. [10] [Online]. Available: https://prometheus.io/. [11] A. Mondal, Y. More, R. H. Rooparaghunath and D. Gupta, “Poster: FLATEE: Federated Learning Across Trusted Execution Environments,” IEEE, 2021. [12] R. L. Rivest, L. Adleman and M. L. Dertouzos, “On data banks and privacy homomorphisms,” Foundations of secure computation, vol. 4, pp. 169-- 180, 1978. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 64 [13] I. Chillotti, N. Gama, M. Georgieva and M. Izabachene, “TFHE: Fast Fully Homomorphic Encryption Over the Torus,” Journal of Cryptology, vol. 33, pp. 34--91, 2020. [14] C. Gentry, A. Sahai and B. Waters, “Homomorphic Encryption from Learning with Errors: Conceptually-Simpler, Asymptotycally-Faster, AttributeBased,” Advances in Cryptology (CRYPTO), vol. 8042, pp. 75--92, 2013. [15] Z. Brakerski, C. Gentry and V. Vinod, “Fully Homomorphic Encryption without Bootstrapping,” Electron. Colloquium Comput. Complex., Vols. TR11111, 2011. [16] Z. Brakerski, “Fully Homomorphic Encryption without Modulus Switching from Classical GapSVP,” Advances in Cryptology (Crypto), vol. 7417, pp. 868-- 886, 2012. [17] J. Fan and F. Vercauteren, “Somewhat Practical Fully Homomorphic Encryption,” IACR Cryptol. ePrint Arch., p. 144, 2012. [18] J. H. Cheon, A. Kim, M. Kim and Y. S. Song, “Homomorphic Encryption for Arithmetic of Approximate Numbers,” Advances in Cryptology (Asiacrypt), vol. 10624, pp. 409--437, 2017. [19] P. Wang, F. T. Y. X. H. Z. and J. Y. , “Secure and Efficient Federated Statistical Tests for Medical Data based on TEE and Secure Resharing Protocols,” IEEE, 2024. [20] C. and J. G. , “Agile Testing: A Practical Guide for Testers and Agile Teams,” Addison-Wesley Professional, 2009. [21] R. P. and B. M. , Software Engineering: A Practitioner’s Approach. , 8th Edition, McGraw-Hill Education, 2014. [22] [Online]. Available: https://nginx.org/en/. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 65 A APPENDIX A.1 DISTRIBUTED LEDGER TECHNOLOGY Distributed Ledger Technologies (DLT) refers to databases distributed across multiple nodes or devices each holding a copy of the ledger and updated individually upon reaching a general agreement known as consensus. DLT allow only controlled distribution and have a high resistance to unauthorized changes. DLT is therefore an ideal solution for the "single point of trust" issue. Key concepts of DLT include consensus algorithms, cryptography, and smart contracts (user defined computations). Various consensus algorithms exist, from computation-based (e.g., Bitcoin's Proof-of-Work) to communication-based (e.g., PBFT in Hyperledger), with hybrid approaches like Proof-of-Elapsed-Time (PoET). Integrity in DLT involves detecting tampering in the ledger records without preestablished trust. Global states of DLTs are protected via a hash tree while cryptographic hash pointers are used to protect the history of blocks. Different DLT technologies have additional features and vary considerably in terms of data structure, fault tolerance, and consensus methods while all the DLT share a reliance on distributed, decentralised peer-to-peer networks and use modular mechanisms. This variation impacts the cost, security, latency, and performance of each DLT instance. Limitations of DLT technologies include scalability issues, lack of interoperability, legal issues, and unproven robustness and resilience. These limitations indicate that while distributed ledgers hold promise, they still face significant challenges that need to be addressed for their widespread adoption and success in various applications. A.1.1 PERMISSIONED DLT While Distributed Ledger Technologies (DLTs) offer tamper resistance, access to the ledger may require adherence to specific policies in certain scenarios. DLTs can be categorized as either permissioned or permissionless, depending on whether nodes need approval to validate transactions and maintain ledger records. In the case of Private Distributed Ledger (PDL) systems, individuals or nodes cannot freely join or exit the DLT network. Instead, they must undergo an authorization D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 66 process and operate under the governance of designated authorities, which may be private entities or consortia. Although permissionless DLT technology has gained popularity due to its accessibility to the general public, PDLs are better suited for use cases that demand certain advantages over permissionless DLT systems. These advantages include lower costs, more frequent transaction recording, cost-efficient consensus algorithms, and fair participation among stakeholders. Effective governance and associated access control policies play a critical role in maintaining PDL systems. Moreover, PDLs can restrict public access to specific information, reducing privacy concerns compared to permissionless distributed ledger systems. Additionally, PDLs have the flexibility to implement more efficient consensus protocols, such as proof-of-stake, to improve transaction speed and reduce energy consumption. A.1.2 PERMISSIONLESS DLT Permissionless blockchains offer a higher level of decentralization. Since anyone can join the network, participate in the process of transaction verification, and maintain the ledger, it ensures that no single entity has control over the entire network. Industries aiming for maximum decentralization might prefer this model to avoid central points of failure and ensure greater security. The Tangle is an opensource, feeless, scalable, and decentralized ledger network, designed to support frictionless data and value transfers. The Tangle has no blocks and no miners and utilizes a directed acyclic graph (DAG) model for its network transaction structure, when an IOTA transaction is sent, the device that is sending (or a third-party service) must validate between 2 and 7 other transactions creating a validation chain that never ends. The validation is done via a simple (compared to other DLT’s) proof of work (POW) calculation for each transaction requiring validation. The Tangle has been specifically designed for integrating with Internet of Things devices, with extremely low resource requirements, allowing low power hardware such as sensors to participate in the network exchanging data and value. This design allows IOTA to play a key role in the IoT domain by bringing data/value transaction immutability and verifiability. The IOTA ledger is maintained by a network of distributed IOTA nodes. IOTA nodes maintain the ledger integrity using the IOTA consensus algorithm. The network is permissionless, in a way that anyone can run an IOTA node. D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 67 A.1.3 ENCRYPTED STREAMS CHANNELS Streams is a second layer protocol leveraging the immutability of transactions stored onto the Ledger. Streams represents encrypted database, with specific interfaces for structuring and navigating secure data through the Ledger. Streams organize data by ordering it in a uniform and interoperable structure. The protocol guarantees the following properties:  Integrity and Authenticity: the data underpinning Streams is stored on the Ledger to guarantee data integrity and availability at all times.  Organization and Analysis: Streams organizes the data from any device into channels and combines them with complimentary data across systems for easy search and analysis. Each channel is identified by a unique address and so each message in the channel. A channel can contain several branches which will be created by Keyload messages.  Confidentiality: Using public key encryption, the data can be stored in an encrypted manner in a channel. Using the same encryption mechanism access to the data can be restricted, so only authorized subscribers are able to read and write to a channel. The subscriptions can only be managed by the creator of the channel which is called the author. A subscriber can only read data from the start of its subscription so previous messages cannot be decrypted by this instance. A pre-shared key, which is similar to a password, can also be used to read previous data or audit the complete channel.  Data sharing: Streams leverages access controls and Tangle capabilities to enable users to keep data private or share data via token, fiat, or data sharing agreements based on the individual channel. A.2 DECENTRALIZED IDENTITIES DIDs are public/private key pairs and can be created for organizations, individuals, and objects. Each identity is represented by a unique public key immutably stored onto the ledger (in our case the IOTA Tangle). Identities and public keys are used to anchor off-chain Verifiable Credentials, certificates containing identity attributes and signed by an issuer identity (using its private key). The issuer itself is an entity with its own decentralized identity. The developed Bridge allows an identified trust root to verify users’ identity. Verified identities can then propagate this verification to other entities (organizations, individuals, objects) using a network of trust approach (see Figure 8). D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 68 Figure 8: SSI Bridge Network of Trust Self-sovereign Identity Bridge provides a standardized framework for integrating decentralized digital identity. In a decentralized identity ecosystem, the following roles are identified: 1. Holders: Holders are the owners of digital identities. They have ultimate control over their data and choose how much and with whom they share their data with. 2. Issuers: Issuers are trusted third parties or authorities that generate and issue credentials to holders, such as health records or identity documents. 3. Verifiers: Verifiers are any third parties that need to verify the authenticity of a holder's data. A verifier might, for example, need to validate that the holder owns a driving license or is above eighteen years of age. Decentralized identities use the ledger immutability to generate Decentralized Identifiers. Such identifiers serve as a reference to a DID Document stored on the tangle. This document contains data such as public keys, enabling the holder to prove ownership over their identifier and personal data. This is possible because keys are unique, and the private key is secretly stored by the owner. In addition, D4.2 Secure Decentralized Data Sharing CONFIDENTIAL6G Horizon-JU-SNS-2022 - G.A. 101096435 69 DID documents can be seen as a folder that references Verifiable Credentials (VCs). Verifiable Credentials are claims about the holder. They can be verified online or in person, and the holder decides who to share them with. Examples of VC’s are driving license, university degree etc., such credentials can be attached to the unique decentralized identifier. The claims of verifiable credentials are not stored on the Tangle, only identifiers needed to verify the credentials are stored on the Tangle. In this case, a verifiable credential can even contain personal information without violating the GDPR compliance.