Software as a Service (SaaS) stands as a successful distributed computing model widely used by both companies and individual users to execute diverse tasks. However, it is important to note that when using SaaS, clients typically submit a variety of personal data to obtain a personalized service. The integrity of this submitted data cannot always be guaranteed, as users might lack insight into its subsequent management or protection once it reaches the service provider. Moreover, depending on the plan purchased, this data may be subject to collection and analysis by the service provider, potentially impacting its privacy and security.

In this context, our proposal aims to establish a connection with a service provider to enable the reliable transmission of information by leveraging Distributed Ledger Technology (DLT) to ensure data integrity through its immutable and decentralized properties. This becomes particularly critical in scenarios such as the one depicted in Fig. 1, where the path of information and its potential manipulation are uncertain. The implementation of DLT serves as a crucial element in safeguarding data integrity of transmitted or stored information. Furthermore, it guarantees that the recorded data remains accessible to potential future service providers.

Simplified architecture of computing services using user data from wearables. Client transmits sensor data to an IoT cloud-based infrastructure, which then returns computed results for verification by any connected party offering services

Full size image

The model shown in Fig. 1 imposes constraints on use cases where the user aims to preserve the anonymity of their identity. This applies to both individuals who prioritize privacy and organizations seeking to maintain confidentiality while using third-party services without compromising information about their activities. These constraints raise several challenges associated with the conventional SaaS model, requiring innovative alternative approaches to mitigate risks posed by vendors. Such approaches should empower users to remain anonymous or selectively disclose information while holding the service provider accountable for the claims made regarding services provided.

This scenario would become even more complex if the user could allow different providers to process their requests in a decentralized manner. Consequently, the user could compare results or establish rewards based on the service that delivers the best or quickest response. Alternatively, this scenario could also involve the utilization of data streams for such processes.

Starting from the premise that conventional Internet technology does not entirely meet the requirements of the aforementioned scenarios, this work examines and proposes a potential and configurable framework that combines emerging and established technologies to address the mentioned challenges. Two of these emerging technologies are Internet of Things and DLT.

Internet of Things (IoT) has the potential to extract a wealth of information from wearables that are used daily by the majority of the population. Several services are offered based on data collected from average users, including medical services such as preventive and precision medicine.

Regarding DLT, it is essential in addressing data authenticity and integrity from wearables, providing a decentralized and tamper-proof data record that ensures data control. Several DLT networks aim to tackle these issues, but performance and specific use cases have been taken into consideration when assessing the choice of potential DLTs for the proposal presented in this research.

We focus on a DLT specifically designed for IoT, IOTA, which is based on a Directed Acyclic Graph (DAG) architecture. IOTA overcomes current DLT limitations, particularly those associated with blockchain, which is another decentralized, immutable ledger technology used for recording transactions across multiple devices. Unlike blockchain, this DAG provides scalability, feeless transactions, and efficient data transfer.

Furthermore, we consider the use of Fully Homomorphic Encryption (FHE) to provide a higher level of privacy when transmitting information to a service provider for utilization, as typically in current schemes, data is transmitted unencrypted, posing a significant risk to user anonymity. However, it is important to note that employing FHE leads to a larger ciphertext expansion when compared to other encryption schemes. In fact, homomorphically encrypted data results in large ciphertexts derived from user information, presenting a challenge for transmission over DLT networks. This is because DLT networks typically impose limitations on the volume of information that can be transmitted, while simultaneously providing substantial integrity and immutability in terms of data transmission.

Inspired by the work of Rydningen et al. [1], Fig. 2 illustrates the relationships among the key technologies integrated into this study. Moreover, it can be observed how the synergy of these technologies fosters attributes such as data integrity, privacy, and anonymity, alongside scalability and interoperability.

Key technologies covered in this research and their relationships

Full size image

In conclusion, this paper demonstrates how DLT enables the transmission of large ciphertexts derived from personal user information through data streams. This approach preserves user privacy, ensures data integrity, and allows service providers to process the information. Additionally, the proposed approach can be applied to a wide range of use cases involving sensitive user information.

The rest of this paper is structured as follows: Section2 introduces the related work that forms the foundation of this research. Section 3 describes the technologies used in this research. Section 4 outlines the methodology followed. Section 5 presents the proposed architecture. In Sect. 6, the results and discussion are reported. Finally, the conclusions and outlook of the study are provided in Sect. 7.

This section presents a literature review focusing on articles that explore the use of both DLT networks, some specifically targeting IoT devices, and FHE as a cryptographic privacy scheme in the context of personal data sharing. The review primarily emphasizes the sharing of medical data among IoT devices, as it is a common type of sensitive data utilized by service providers.

2.1Cloud-Based Applications Powered by FHE Schemes

Applications where FHE models work in a cloud environment are still in an early stage of development. This is reflected in the article by Marcolla et al. [2], which presents a comprehensive analysis of homomorphic encryption, encompassing both theoretical and practical aspects. Their work not only explores the applications of FHE in fog and cloud computing but also includes an evaluation of existing libraries and tools, along with their performance.

Currently, weaknesses and inefficiencies have been identified when processing large volumes of data in FHE cloud models. The work proposed by Wang and Malluhi [3] exposes an efficient fully homomorphic symmetric key encryption scheme that is deemed suitable for privacy-preserving computing in the cloud. Additionally, FHE schemes not only result in inefficiencies but, in some cases, lead to impractical systems. The research of Martins and Sousa [4] presents a systematic FHE-based cloud computing model in which a wide range of homomorphic functions are available for commonly used applications, such as image processing and machine learning.

In connection with the above, Bos et al. [5] present scenarios for implementing homomorphic encryption to ensure the privacy of medical data. Furthermore, they have successfully implemented a working model on a cloud service for conducting predictive analysis while preserving the confidentiality of medical data. Similarly, Page et al. [6] propose a system that couples healthcare monitoring techniques with analytic methods to extract relevant information from patient data without compromising privacy taking into account that the system is based on FHE. With this in mind, Lee et al. [7] expose an approach focused on machine learning, demonstrating that the use of FHE schemes yields results similar to those obtained with non-encrypted data models.

Nevertheless, it is worth noting that while the articles reviewed above delve into various aspects of FHE and DLT, the transmission of data over a DLT network falls outside the scope of all of them.

2.2IoT-Based Applications Leveraging DLT Networks

When it comes to the IoT field involving DLT networks and the search for synergies between both technologies, there are some works, such as the one by Farahani et al. [8], in which opportunities, challenges, and solutions for both the convergence of IoT and DLTs are discussed. As a result of this exploration, the integration of DLT networks within IoT leads to numerous IoT-based applications, including smart homes, intelligent transportation, supply chains, smart healthcare, and intelligent energy, as shown in the work of Zhu et al. [9]. An illustrative example of this integration is the study from Lupascu et al. [10], in which they propose an architectural framework for Industrial IoT that ensures authentication and guaranteed integrity through the use of DLT for an immutable and transparent registry.

Furthermore, the use of DLTs within IoT introduces new security and privacy challenges. Paavolainen and Nikander [11] discuss the security implications on the use of DLT for IoT systems, accompanied by use case examples.

With regard to data transmission over a specific DLTs, Gangwani et al. [12] demonstrated and assessed how the IOTA data communication protocol supports the transmission and retrieval of sensor data from IoT devices through this DLT network when compared to a non-protocol approach. Similarly, Akhtar et al. [13] propose an enhanced communication system between IoT devices for a future machine-to-machine (M2M) economy, based on the IOTA data communication protocol.

Concerning the transmission of health data through IOTA, Brogan et al. [14] discuss how DLTs can ensure the authenticity and integrity of data generated by wearable and embedded devices, and how the IOTA communication protocol can securely transmit such information. Recent work by Rydningen et al. [1] also supports IOTA’s data structure as a promising candidate for medical data management. These findings are based on a systematic review of ten primary papers published from 2018 to 2021 covering the knowledge areas of health data management in relation to IOTA, blockchain, and IoT.

Additionally, Vanin et al. [15] propose a model based on distributed hash tables and blockchain networks to store and distribute encrypted health data, introducing concepts like data stewards and shared data vaults. However, the introduction of these new elements comes with limitations, such as cost generation and the requirement for individuals who wish to share their data to undergo a registration process.

Similar to the research conducted in this paper, Carelli et al. [16] present a cryptographic protocol that enables data exchange over the IOTA network using constrained devices. However, their study does not consider the interaction among devices or the evaluation of the protocol’s performance over the DLT.

Although previous works have utilized DLT networks for data exchange, these networks have not been primarily considered for the transmission of large homomorphically encrypted ciphertexts.

2.3Contribution of this Work

The proposed classification of the related work clearly highlights a gap between the two examined research areas. While previous studies have investigated data transmission across different DLT networks and the sharing of FHE-encrypted information in cloud-based architectures, none has specifically addressed the integration of sharing homomorphically encrypted data through DLT networks designed for low-end devices, such as IOTA.

Furthermore, the aforementioned approaches assert the feasibility of emitting and accessing data streams over distributed ledgers. However, these prior studies do not consider the transmission of homomorphically encrypted data using FHE schemes. Additionally, many of the works involving data transmission through a DLT, such as the one used in this study, rely on an earlier version of the IOTA data communication protocol known as Masked Authenticated Messaging (MAM). Nevertheless, IOTA Streams represents the enhanced version of this communication protocol.

Our proposal focuses on the transmission of encrypted data through a DLT network via data streams, integrating both the usage of a distributed network for sharing information with a service provider and the application of FHE to maintain the confidentiality of the user’s information while it is employed for computing services. This approach ensures a secure environment by addressing essential security requirements, including data confidentiality and integrity. Additionally, this study includes a comprehensive performance evaluation of the proposed architecture’s efficiency.

A real-world example of the proposed work could be found in the medical field, where wearable devices, which are typically low-capacity, would be used to collect health-related measurements such as heart rate and blood pressure. In this scenario, the data collected would be encrypted using FHE due to its highly sensitive nature to ensure the highest level of privacy, despite the significant computational overhead. This encrypted data would then be transmitted through a DLT network using data streams to a service provider for processing and analysis. This method would enable a secure and continuous transmission of data, preserving the integrity of the information while maintaining user privacy and control over how their information is shared.

This section outlines the core technology stack employed in this study, with a particular emphasis on IoT-focused DLT, exemplified by the IOTA platform. Also, the IOTA Streams protocol and its function in enabling secure data streams within a DLT are explored. Moreover, the concept of FHE as a cryptographic method is introduced. This method presents challenges in transmitting the resulting ciphertexts over DLT networks due to its considerable computational overhead.

3.1IoT-Focused DLT: IOTA

DLT is characterized as a database where digital data is replicated, shared, and synchronized across a network of computers. These computers adhere to a consensus protocol to ensure accurate and eventual data updates. Bitcoin [17] exemplifies DLT in a fully decentralized context, while Ethereum [18] provides a broader framework, enabling the development of diverse applications. Furthermore, a multitude of other DLTs have emerged to leverage this technology for various applications and real-world scenarios.

As of the time of writing, within the domain of IoT-focused DLT networks, IOTA stands out as the best alternative, owing to its advanced technology and core functionalities.

IOTA is a DLT network designed for the exchange of value and data among IoT devices. Setting itself apart from other DLT blockchain-based networks, the IOTA protocol employs the Tangle [19] data structure. The Tangle is a unique form of a DAG where, unlike traditional blockchains, transactions are embodied as edges within the graph. Once transactions are validated, nodes verify and broadcast them across the network using the IOTA gossip protocol. To validate transactions, nodes are required to solve a cryptographic puzzle similar to the Proof-of-Work (PoW) [20] found in certain blockchain-based networks. However, in IOTA, the computational burden of its PoW algorithm is considerably lower compared to PoW blockchains, rendering it an optimal network for IoT devices due to its minimal computational requirements.

Accordingly, scalability is a fundamental aspect in communication among IoT devices, and the Tangle offers several features that enhance it. Notably, there are no fees for broadcasting transactions to the network, transactions can be processed concurrently rather than sequentially, computational costs are significantly lower compared to blockchains, and there are no miners since each node can issue its own transactions. These attributes establish IOTA as the preferred choice for transaction issuance, data storage, and ensuring data integrity, guaranteeing traceability and data immutability. Additionally, it is possible to attach zero-value transactions (data) to the Tangle, enabling encrypted data streams on the network through a second-layer ledger protocol called IOTA Streams. Hence, these diverse features of IOTA justify its selection as the primary DLT in this study.

3.2Data Streams Protocol

Because of its feeless nature, IOTA enables a wide range of applications, setting it apart from other DLT networks. Furthermore, complementary solutions have been introduced, such as IOTA Streams, which operate within its ledger. This framework enables the development of secure messaging protocols over any transport layer, encompassing encryption, decryption, signing, and key-based authentication management for data streams.

In IOTA, nodes are responsible for both sending and receiving messages, communicating with other nodes and connected clients. In this context, a message is a data object which consists of information transmitted through the network. At the same time, a structured aggregation of interconnected messages is referred to as a channel. Each message contains essential information about its type, structure, and payload if attached. Payloads serve as attachments to include additional data within transactions and can either be masked or public. Thus, different message types within Streams channels are required to handle specific actions. These messages must be transmitted by different roles, including authors, subscribers, or publishers.

• Author: The creator and owner of the channel, taking on the publisher role.

• Subscriber: A user of the channel who can integrate information from diverse streams sourced from the Tangle into applications. Additionally, subscribers can contribute data to streams using various message types.

• Publisher: A role within the channel that enables the transmission of non-encrypted data openly visible to all participants. Publishers also have the option to restrict or secure their data through public key encryption, allowing controlled access or complete privacy for specific authorized subscribers.

The channel author generates the keys to be shared among authorized subscribers. These authorized subscribers have the capability to securely send, read, or authenticate the contents of messages sent by the author or other publishers. It is important to note that once access is granted to a subscriber, it cannot ever be revoked. Therefore, to restrict access, a new branch generation or a new access policy must be sent within the branch. This policy change or new branch generation ensures that subscribers cannot process data beyond the point of the policy change or new branch generation. The collection of these interconnected messages within a channel forms a branch, as depicted in Fig. 3, which can assume a single or multi-form.

• Single branching: Uses a linear sequence to synchronize the state of every user by linking each message to its predecessor. With each message added to the channel, both subscribers and publishers advance along the message sequence.

• Multi branching: Adopts a non-linear sequencing model to link messages. In this approach, a sequencing branch acts as a reference point where publishers are assigned to one or more branches within the channel.

Branching delineates how participants should interpret data from channels to which they are subscribed. Authorized subscribers have the ability to decrypt masked payloads and to publish their own masked payloads. Subscribers are always aware of the branch configuration model they should adhere to, as it is specified within the announcement message upon channel creation. Both branching forms support either public or private configurations. In the former, all participants can access the information, while in the latter, access is controlled by the channel owner.

IOTA Streams architecture. Streams channels are built upon the DLT, enabling the transmission and security of messages across the network, thereby guaranteeing the authenticity of the data

Full size image

In our proposal, we have adopted a private single-branch configuration to provide the author with control over the shared information. This allows the author to restrict channel access by implementing policies when needed. Figure 9 illustrates our implementation of the private single-branch configuration within a Streams channel.

As the Tangle lacks the native capability to transport ordered asynchronous messages, data packetization and sequencing methods become necessary when using a channel over Streams. These processes of message preparation and packetization serve as a transport layer for the secure messaging protocol, which is built upon the Streams framework and utilizes the Tangle as its transportation layer. Consequently, messages must be accurately ordered following a sequencing process. This mechanism plays an important role in organizing large volumes of data within the DLT. Its definition encompasses packetization structure, message typing, and cryptographic processes, all of which are integral components of Streams implementation.

3.3Fully Homomorphic Encryption

Homomorphic encryption refers to an encryption mechanism proposed in 1978 by Rivest et al. [21], although the first implementation was not realized until recently by Gentry [22].

Homomorphic encryption enables various computations to be performed on previously encrypted data without requiring the involvement of the secret key. The output of such computations will remain encrypted, and only individuals possessing the secret key can unveil the encrypted information.

The main difference between homomorphic encryption and FHE lies in the fact that FHE allows a broader range of arbitrary operations to be computed, whereas homomorphic encryption supports only a limited number of operations. In this paper, homomorphic encryption is referenced as an encryption method, but in terms of implementation, FHE is used.

From the work of Munjal and Bhatia [23], the scheme illustrated in Fig. 4 demonstrates how homomorphic encryption can protect sensitive data when processed by service providers in an encrypted format. This prevents service providers from gaining any knowledge of the information, since only the owner of the private key is able to decrypt it. Thanks to homomorphic encryption, when the service provider calculates the result based on the encrypted data provided, it remains inaccessible for the entity responsible for the computation because it lacks the private key. Then, this encrypted result is transmitted to the client.

Utilization of public, private, and evaluation keys to encrypt and decrypt data within a homomorphic encryption scheme implemented by a service provider

Full size image

Homomorphic encryption can be implemented using different schemes. Fawaz et al. [24] provide a comparison between diverse homomorphic encryption schemes employed on the Microsoft SEAL [25] library. Additionally, there exist numerous libraries for implementing homomorphic encryption. Sathya et al. [26] conducted a review of homomorphic encryption libraries, analyzing their features. Their findings suggest that the libraries examined are not specifically designed to implement homomorphic encryption techniques across various use cases, particularly in domains such as healthcare and finance where precise results are essential. Hence, the Concrete library is selected for use in this research.

Concrete [27] is a framework that addresses the limitations of other homomorphic encryption schemes by combining the advantages of both leveled and bootstrapped approaches. Bootstrapping involves restoring encryption levels, which represent the depth of computational operations performed on ciphertexts, and reducing noise-perturbations introduced during homomorphic operations in ciphertexts, thus enabling continued homomorphic computations. It could be said that there is a tradeoff between the level and the noise in FHE. As more homomorphic operations are performed on ciphertexts, the level decreases and the noise increases. Therefore, an intrinsic tradeoff exists between maintaining a higher encryption level and minimizing the level of noise to ensure the security and accuracy of homomorphic computations.

Unlike schemes such as BGV [28] and CKKS [29], that only support additions and multiplications and require approximations for non-linear functions, Concrete, based on a variant of TFHE [30] developed by Zama [31], enables both fast bootstrapped operations and precise evaluation of arbitrary functions on booleans and integers. This capability is crucial for applications dealing with sensitive data, such as healthcare or financial services, while also enabling a broad spectrum of other applications.

On the one hand, homomorphic encryption schemes like CKKS or BGV rely on leveled computation to prevent noise from overflowing the data, which limits the number of fast operations that can be performed. On the other hand, TFHE employs bootstrapping, which allows for an unlimited number of slower operations by reducing noise. Concrete introduces programmable bootstrapping [32], which enables the computation of a univariate function during the bootstrapping operation itself. However, the tradeoff for these added features is the lower precision of the encoded data, currently limited to 16 bits.

Ultimately, the motivation to employ FHE in this research stems from the significant overhead inherent in these schemes compared to other existing encryption mechanisms, such as symmetric encryption or elliptic curve cryptography. Upon closer examination of TFHE [30], a notable limitation is the expansion ratio from plaintext to ciphertext, which refers to the increase in data size during encryption, resulting in an overhead of at least 10,000:1 for achieving 100 bits of security.

In this section, we delve into the methodology employed in our research. First and foremost, the aim is to elucidate the underlying reasons and contextual basis for our study, highlighting the gaps in existing literature that drive our investigation. Subsequently, a high-level, comprehensive overview of our approach to addressing the identified issues is provided.

4.1Motivation

The motivation behind this study is driven by several fundamental concerns outlined below. As highlighted in the related work section, there is a growing trend in using FHE schemes for sharing sensitive data between users and service providers via cloud infrastructures. Consequently, service providers, and even third parties, who receive user data can only process it to fulfill a user’s service request, guaranteeing that they gain no knowledge about the user in the process. These services are mainly focused on predictive analysis of medical data, although other services from different fields are also provided.

However, despite these architectures aiming to safeguard user data, they do not encompass all privacy measures required to protect user identity. This gap persists because, even though the information is properly protected during transit and storage, the user’s identity is always known to the service provider. In certain instances, even to third parties handling the data may also have access to this identity. This situation is partly attributed to information-sharing systems employed between the client and the provider, which entail direct communication through traditional architectures and often require the creation of user accounts within these service providers.

Moreover, most client-service provider architectures do not support interactive data sharing. Instead, it usually entails a single submission by the user through a system controlled by the service provider, often employing a conventional storage method, like a centralized database.

In view of the foregoing, we encounter a scenario where user data is protected by FHE schemes, but user identity remains exposed to both the service provider and third parties. In the event of a security breach, not only could the user’s identity be compromised but also become linked to the usage of a particular service, potentially raising unwarranted privacy concerns for service clients. Additionally, when sharing data through a system entirely controlled by the service provider, the user might lack mechanisms to limit the provider’s access to their data.

4.2Proposed Approach

To tackle the aforementioned issues, we present a framework that establishes a resilient transmission model for sharing encrypted sensitive data through data streams over DLT, ensuring user privacy and providing an enhanced level of anonymity when using computing services.

Initially, we advocate for the continued use of FHE encryption schemes due to their capability to perform computations directly on ciphertexts without the need for data decryption. For this reason, the raw data, typically collected from wearable devices and containing sensitive information, is encrypted using FHE.

Nevertheless, using these schemes raises a significant concern owing to the high overhead they entail compared to other encryption methods. This overhead may result in system performance degradation, but its adoption is justified by the proven benefits it provides in terms of privacy and security.

As an advanced data transmission mechanism, the use of data streams is suggested. Data streams are selected as the transmission method because of their efficiency in real-time information transfer, facilitating synchronization between the client and the service provider. This approach ensures data integrity, confidentiality, and authentication. While the data transmitted in our proposal is homomorphically encrypted, data streams themselves provide secure mechanisms to protect data in transit.

In addition to data streams, and to increase the accountability of our model, we propose the implementation of a system that enables the storage of evidence concerning data exchange among participants through public records. This is why the use of a DLT is adopted in our proposal. DLT not only fosters a public trustless ecosystem among participants but also offers means to ensure data integrity during transmission. Therefore, DLT is the selected technology for storing the encrypted data transmitted via data streams. This ensures that neither the client nor the service provider have additional privileges over the network, while evidence of data transmission is stored and verifiable even by third parties.

Considering the preceding factors, our research aims to facilitate the secure transmission of large encrypted data via data streams on a DLT, empowering users to selectively share their data with service providers and to revoke access as required.

In this section, every aspect regarding the transmission model of large ciphertexts through Streams over a specific underlying DLT network is explored. Moreover, each procedure and technique that aids in thoroughly comprehending our proposed architectural framework is explained.

5.1Preliminary Assumptions

Our starting point encompasses a scenario where a user seeks to execute a program whose implementation is unknown, offered by a particular service provider. This program comes with a specification outlining its purported effects and outputs. However, the user possesses the program’s signature, enabling data transmission to the program in the appropriate format. The following are the trust assumptions and requirements:

• The user trusts the provider, whose identity is typically public, often represented as a legal entity such as a company. This assumption is common in SaaS, where the provider is subject to legal responsibilities.

• There is no inherent trust in the network used for data transmission.

• Publicly accessible evidence of the information exchange between the user and the service provider, and vice versa, must be documented and made available to the public.

In this context, an asymmetry is introduced where the provider is publicly known and holds legal responsibilities, whereas the user remains anonymous.

5.2IOTA Chrysalis DLT Network

As previously stated, IOTA is selected as the designated DLT for this proposal. While IOTA and its primary features have been outlined in the preceding sections, the following part delves into the specifics of transmitting encrypted information over this DLT on resource-constrained devices.

Firstly, it is important to clarify that this work specifically utilizes version 1.5 of IOTA, also known as Chrysalis, among the various IOTA networks available. This choice is driven by the compatibility of IOTA Streams, which is exclusively supported on the Chrysalis network.

5.2.1Consensus

The Tangle allows an unlimited number of transactions to be concurrently attached to the DLT, with transaction issuers being obligated to perform PoW, a computational puzzle-solving process, as an anti-spam measure. In the current Chrysalis release, a coordinator node is still used for transaction authentication, as well as for managing the execution and issuing of milestones.

5.2.2Privacy

Privacy is achieved through common mechanisms found in other DLTs. Moreover, IOTA’s application layer allows for the implementation of supplementary privacy measures, such as secure messaging via cryptographic protocols, as employed in this study. However, it is crucial to note that IOTA does not inherently support private transactions.

5.2.3Scalability

Scalability in IOTA is achieved through the Tangle’s implementation, which is founded on principles derived from graph theory. This consensus mechanism enhances scalability, as the processing capacity scales in tandem with the volume of transactions.

5.2.4Interoperability

While it is true that IOTA supports cross-chain interoperability, it should be noted that the Chrysalis network currently does not facilitate any form of interoperability with other networks.

5.2.5Energy Efficiency

The energy efficiency of the Tangle was assessed by the IOTA Foundation [33]. Testing was performed on Raspberry Pi 3 and 4 devices running IOTA’s node software, demonstrating the lightweight and energy-efficient characteristics of the IOTA network.

While these features are fundamental to our proposal’s implementation, it is equally important to consider the intrinsic characteristics of a DLT, such as immutability and data integrity, which form the basis of the security and reliability of our approach. As previously mentioned, the use of a DLT in this project involves storing evidence demonstrating effective communication between the client and the service. This evidence is recorded in the form of a transaction on the DLT, with the associated data comprising the message sent through the established channel between the author and the subscriber. Specifically, the operation of a Streams channel is linked to the use of a DLT, ensuring that all shared information is recorded in the ledger, serving as storage for messages sent through the channels. To clarify, anyone capturing a transaction containing a message will be unable to access its content as long as it remains masked. The message must also have been sent under a configuration that allows access only to subscribers.

Furthermore, it is important to acknowledge that in our scenario, messages originate from encrypting raw data using FHE, producing ciphertexts too large to be directly transmitted through the DLT. Therefore, to manage the high overhead, messages will undergo a splitting process to comply with the size limits set by the DLT for message transmission.

5.3Message Structure: Splitting, Merging, and Serializing Data

This section defines the message structure transmitted through the IOTA network via IOTA Streams, containing the user’s encrypted information. To maintain a consistent record of the information sent, the timestamp associated with the message is included as a public payload, while the user’s fully homomorphically encrypted data is transmitted as a masked payload.

The distinction between public and masked payloads is based on their accessibility. Public payloads are presented in clear text to anyone capturing the message, whereas masked payloads can only be deciphered by subscribers specified by the sender. This limitation ensures that masked payloads are accessible only to those subscribed to the channel.

Figure 5 depicts the high-level composition of the message payload, comprising both public and masked payloads. This figure also illustrates how the client and the service provider generate their respective masked payloads by carrying out their respective processes related to FHE. The client first processes the raw data, which typically comes from a wearable device, and then applies FHE to it, as shown in Algorithm 1. Once encrypted, the data is ready for the next steps in generating the message payload. It is important to note that both the client and the server do not work together on the payload; rather, the process is analogous for each party. The data undergoes FHE, serialization, and division into fragments, which are subsequently encapsulated within the masked payload and transmitted as a message appended to the channel.

Message payload generation for each party. Public payload visible to all. Masked payload visible only to subscribers. Encrypted data is handled by both the client and the server, with the client directly generating it and the server acquiring it as a computation result

Full size image

Masked payload generation for Client and Service Provider

Full size image

Because of the high overhead associated with FHE encryption, serialized data must be split into byte chunks to enable transmission and adhere to the IOTA message size restrictions. Moreover, the larger the data to be serialized due to FHE encryption, the larger the size of the masked payload. Therefore, it is required to divide the payload into smaller fragments to transmit the encrypted data, as messages in IOTA cannot exceed a size of 32KB.

Since the encrypted data resulting from FHE computation is large and exceeds the IOTA message size limit, it is necessary to include both an init flag and an end flag alongside the encrypted data. These flags indicate the beginning and end of the messages that together form the complete masked payload. As shown in Fig.6, the init flag is set to ‘1’, while the end flag is set to ‘0’, both treated as masked payloads. In such cases, the service provider must wait for the end flag to signal the completion of the transmission. Subsequently, the service provider must reconstruct the masked payload from the received messages before performing homomorphic computations on it.

Data transmitted from the client to the service provider via the channel. Transmission of the init and end flags to indicate the start and conclusion of the series of messages that together form the complete masked payload

Full size image

To obtain an encrypted result, the same process applies to the client when the service provider transmits encrypted information that exceeds the allowed message size limit. In such situations, it is the client who must wait for the end flag to begin data reconstruction and subsequently decrypt the result.

5.4Experimental Software Architecture

To illustrate the model proposed in this research, the environment based on a peer-to-peer architecture, shown in Fig. 7, is configured. This section will provide details about the hardware and software components used in this configuration.

Proposed experimental setup. Channel participants utilize their respective node implementations to facilitate the transmission of encrypted information within a pre-established Streams channel. The client transmits encrypted data to the service provider, which subsequently returns the computed results for verification by the client. In light of the message size constraints in IOTA, the process of data splitting and merging is depicted, along with their corresponding flags indicating the start and end of the entire data

Full size image

5.4.1Client

Refers to an entity capable of gathering data from a wearable device and generating fragmented encrypted data from these measurements. Additionally, the client can establish an IOTA Streams channel and connect to it through node software linked to the IOTA Chrysalis network. This allows the client not only to transmit encrypted information to the service provider for processing but also to receive encrypted data from the provider, which can be decrypted later. In our case, we omit the collection of measurements and instead utilize the well-known Diagnostic Wisconsin Breast Cancer Dataset [34]. The specific hardware employed for testing from the client’s perspective was a Raspberry Pi 4 Model B.

5.4.2Service Provider

Entity that offers a specific computing service, such as the detection and notification of potential issues related to user activity. The service provider receives encrypted information from the client, computes it, and returns the encrypted result through the established IOTA Streams channel. Like the client, the service provider is connected to the IOTA Chrysalis network via node software, enabling the exchange of information. For our experiments, we used a dedicated server equipped with an AMD Ryzen 5 5600 G CPU, 16 GB of memory, and disabled GPU accelerator.

5.4.3Software

As mentioned earlier, both the client and the service provider use specific software to connect to the IOTA Chrysalis network, enabling data transmission through the channel. The software employed for this purpose is Hornet [35], an implementation developed by IOTA that offers full node capabilities, specifically designed for low-end devices.

In the context of DLT networks, there are various types of nodes, each with a specific function. Full nodes’ primary function involves the processing and validation of transactions, which are subsequently incorporated into the ledger and distributed across all nodes in the network. Furthermore, full nodes maintain synchronization of their database with other equivalent full nodes. Although some of these nodes are operated by the IOTA Foundation, there is also the option to employ a self-hosted node through Hornet instead of relying on third-party managed nodes.

Regarding data encryption, both the client and the service provider perform cryptographic operations using Concrete. The client is responsible for encrypting the raw data and decrypting the encrypted information, while the service provider focuses only on processing the encrypted data.

5.5Keys Management and Distribution

In this section, we delve into essential aspects regarding the establishment of channels in IOTA and the management of FHE keys within the context of this research. We examine the process of establishing a channel and the sharing of necessary keys to guarantee the privacy and security of encrypted data transmission.

5.5.1Channel Address

Due to the intrinsic characteristics of IOTA channels, it is impossible to ascertain the existence of a channel unless its announcement message, serving as the channel’s root, is already known. In this scenario, the author, who is also the creator of the channel, is responsible for transmitting this announcement message and making it publicly available. This ensures that potential subscribers become aware of the channel’s existence.

To accomplish this challenge, there are different methods for notifying the service provider about the existence of the channel. One approach is to use a public repository that the provider regularly checks to identify available channels for subscription. To guarantee user privacy during this process, it would be feasible to employ other DLTs in conjunction with publicly managed smart contracts owned by the service provider. These smart contracts would function as repositories for storing channel identifiers submitted by clients. Alternatively, a more invasive method, in terms of client privacy, involves establishing direct communication with the service provider before initiating the data exchange. This approach enables the client to directly share the root of their channel with the provider. In this work, as we propose a model for encrypted data transmission through Streams channels, we assume that the channel’s existence is known in advance through any of the aforementioned means.

5.5.2FHE Keys

Many architectures that analyze encrypted data often require access to the secret key for decryption and subsequent processing before re-encrypting the data. However, using this process in cloud services raises security concerns. To mitigate these concerns, a more secure approach involves conducting computations directly on homomorphically encrypted data, thereby avoiding any exposure of sensitive information during the analytical process. This concept is thoroughly discussed by Archer et al. [36].

In this work, to achieve an adequate level of privacy regarding user anonymity, the use of homomorphically encrypted data is proposed. Unlike other encryption schemes, FHE introduces an additional key known as the evaluation key. Employing an FHE scheme entails managing the public key, private key, and evaluation key. The public and private keys in FHE schemes function similarly to those in conventional encryption methods, with the client responsible for their generation and management in our proposal. However, the evaluation key, which is also public and typically derived from the private key, is instrumental in performing homomorphic operations. Considering that the server is tasked with conducting homomorphic operations on the encrypted data in this scenario, sharing the evaluation key with the server becomes necessary.

While the encryption and decryption processes, along with data processing via the evaluation key, are beyond the scope of this manuscript, we will provide a brief overview of the encryption process in the results and discussion section.

Sharing the evaluation key via IOTA Streams is practically unfeasible due to the large size of the evaluation key. In the conducted tests, this key was several megabytes in size.

Although sharing the evaluation key falls outside the general scope of this work and is specific to the FHE scheme, maintaining user privacy and anonymity requires the use of a distributed file system. The use of such distributed file systems is a common solution in DLT-based architectures when handling files that are too large to be transmitted through the DLT due to their size. InterPlanetary File System (IPFS) [37] stands out as an example of a distributed file system with privacy properties that could be employed to share the evaluation key.

5.6Streams Transmission Model

The proposed work in this research aims to develop a transmission model using the IOTA distributed ledger and its Streams communication protocol through channel implementation. This model seeks to protect user data privacy and anonymity, addressing confidentiality concerns while ensuring the data communicated through the Streams protocol remains secure and seamless.

As previously discussed, the model shown in Fig.1 presents potential inherent risks associated with solutions relying on such architectures. Thus, this paper introduces an enhanced model that integrates technologies such as encrypted personal data transmission over DLT networks, enhancing the privacy and security of the model.

Figure 7 illustrates a high-level implementation of the proposed approach, representing an advancement over commonly utilized architectures. Within the transmission model, we assume that the information is encrypted using FHE. Therefore, the different processes of encryption, decryption, and FHE computation are not explicitly addressed within the transmission model itself. A detailed explanation of the proposed architecture is provided below.

Communication between the service provider and client occurs through a channel employing a private single-branch configuration, as depicted in Fig. 8. This configuration facilitates the exchange of data between them. In the context of the channel setup, different types of messages are used to manage and secure communication within the channel.

• Announce: A message generated by the author to establish the channel and set its root address. This initial message marks the start of the channel and is always the first to be sent.

• Keyload: A message that includes a list of public keys for each authorized subscriber in the channel, along with a randomly generated key used for chaining. This message allows secure management of access to the channel.

• Subscribe: A message sent by the subscriber to indicate their intention to join and participate in a specific channel.

• Unsubscribe: A message sent by the subscriber to indicate their decision to leave or withdraw from a channel.

• Signed packet: Message from publisher signed using the publisher’s private key. It contains both public and masked payloads.

Preliminary steps are essential for creating and configuring the channel to ensure that only authorized subscribers designated by the author gain access to the information. These actions, including setting up the channel, handling subscriptions, and sharing the keyload, are detailed in Algorithm 2. Nonetheless, the detailed process of account generation for channel participants is omitted in this work. Also, it should be emphasized that in the model proposed in this research, the client can specify both the recipients of information and the duration of access, leveraging the intrinsic properties of IOTA Streams, as demonstrated in Fig. 9.

Client (Author) specific functions for channel setup and management

Full size image

Channel creation and configuration. Channel creation and configuration encompass participant generation, data exchange, and the process of subscribing participants

Full size image

Private single branch synchronization. Author generates a Streams channel with predefined user access. Sequencing state of each user will be updated to the same state unless an unsubscribe event occurs

Full size image

As the channel author, the client generates the announcement message, which serves as the channel’s initiation by designating its root address, acting as a link. From this initial message, service providers can then validate the signature against the corresponding public key embedded in the message, thereby verifying its authenticity and confirming its origin from the intended client.

In their role, the service provider acts as a channel subscriber. Subsequently, the provider receives the announcement message from the client. It is assumed that prior communication has occurred between the client and the service provider, enabling the subscriber to be informed of the channel’s existence. Various approaches, as mentioned earlier, can achieve this. One viable solution might entail periodically publishing the channel’s address in a public registry that the provider consults. This method maintains the model’s privacy, as an additional message is necessary to grant subscribers access to the information within the channel. Upon receiving the announcement message, the service provider sends a subscription request to the channel, which the client, as the channel’s author, receives. The procedures for subscribing to the channel and handling the keyload to access the encrypted data and participate in the communication process are detailed in Algorithm 3.

Service Provider (Subscriber) specific functions for channel setup and management

Full size image

Upon identifying the service provider, the client creates a keyload message and transmits it to the channel. This keyload message includes the provider as a subscriber, allowing the provider to send and receive messages within the channel. If the client chooses to cease sharing information with the provider, the client can issue a new keyload message that excludes the provider as a subscriber. This action guarantees that the provider will no longer have access to any new messages published within the channel. Moreover, the incorporation of masked payloads and channel subscriptions makes it infeasible for any external entity to gain unauthorized access to the messages published within the channel. If, at any point, the client opts to switch to a different service provider, it is advisable to establish a new channel to prevent the new supplier from accessing previous messages.

Ultimately, the client initiates the transmission of messages to the channel, which are then accessible to the service provider. The provider retrieves the messages attached to the channel, allowing the provider to conduct computations on the received data and provide results to the client. Subsequently, these results are dispatched back to the channel for the client’s retrieval. Both the client and the service provider maintain synchronized states for every message transmitted through the channel, thereby ensuring consistent communication between them. The process of sending and receiving messages over the channel, which is the same for both parties, is shown in Algorithm 4.

Functions for sending and receiving messages over the channel

Full size image

With a clear understanding of how the established channel operates logically, we now proceed to outline the transmission process.

The client must split the entire payload into smaller fragments to adhere to the limitations of the IOTA Streams protocol, which restricts message sizes at a maximum of 32KB. Additionally, two flags are used to denote the start and end of the message set containing the complete payload. These flags enable the service provider to identify the beginning of information reception and when it should commence reconstructing the payload upon the completion of reception. Once the client has transmitted the payload and signaled its completion with an end flag, it awaits the encrypted result from the service provider. During this interval, no further information is transmitted to the service provider until the client receives the response. Subsequently, the FHE computation is initiated, with the service provider generating an encrypted result.

When the service provider has received all the information from the client, it proceeds to process the encrypted data in order to obtain the computation result. It is important to highlight that before processing the information, the complete payload must be reconstructed on the server side. Then, after computing the result, it is transmitted as an encrypted message by the service provider. Similar to the client, the service provider may also need to split the payload into smaller messages. Although the size of the encrypted result may be smaller in this scenario, the same chunking process is applied. Consistent with previous steps, two flags are employed to indicate both the beginning and the end of the message set containing the complete payload. At this stage, the service provider awaits a new set of messages from the client unless the client has initiated an unsubscription process.

Thereafter, the client receives the encrypted result in the form of messages, each accompanied by its corresponding flag, indicating when to initiate the decryption process. Similarly, payload reconstruction is required before proceeding. Once the decrypted result is obtained, the client is ready to transmit a new set of messages (payload) to the service provider in order to acquire a new computation result. Consequently, the ongoing communication is facilitated through a continuous stream of data between the client and the service provider.

Reviewing the main contributions to the implementation carried out in this research, this section aims to verify the results and effectiveness of the proposed model. Metrics were obtained to evaluate the data sharing across the established channel between the client and the service provider, including transmission times and data transfer rates for sending encrypted data.

To comprehensively evaluate the system’s performance in transmitting encrypted data, the following key metrics have been identified, covering various aspects of the transmission process, including data volume, efficiency, and transfer rate. A description of these metrics is provided below.

• Message Size: Number of bytes transmitted in each message.

• Average Message Transmission: Average time, measured in seconds, taken to send a message of specific size from the publisher to the channel.

• Median Message Transmission: Similar to average message transmission time, but focused on the median value, which helps reduce the impact of outliers and provides a more robust view of the common channel behavior.

• Average Bytes per Second: Calculated as the average number of bytes transmitted per second. This value is obtained by dividing the message size by the average transmission time.

• Median Bytes per Second: Represents the middle value of the bytes per second rate, reducing the impact of outliers and providing a more typical measure of transmission performance.

• Messages Received: Refers to the percentage of messages successfully fetched by the subscriber from the channel out of the total transmitted.

• Average Message Reception Time: Average time, measured in seconds, required to fetch a message from the channel. The median was not calculated due to the exclusion of outliers.

For the performance evaluation of our proposal, homomorphically encrypted information is employed. In an effort to emulate a real-world use case, the encrypted data is obtained from 30 features of the Diagnostic Wisconsin Breast Cancer Dataset [34]. This dataset serves as an example input, from which a service provider is expected to compute a result that will later be transmitted to the client.

Before encryption, the 30 features collectively occupy a total size of 240 bytes, whereas in their encrypted state, this can expand significantly, reaching up to 2,458,850 bytes. This expansion results in the encrypted data being more than 10,000 times larger than the original raw data. Table 1 offers insights into the sizes of homomorphic encryption ciphertexts based on the employed quantization bits. Quantization involves mapping an input from a continuous set of values to a discrete set of values. This process inevitably leads to some loss of accuracy in the representation of these values, typically by discarding the least significant bits. In this context, the encrypted information consists of an array of features containing different client-related values. Therefore, following the guidelines of this study, the encrypted data must be serialized for subsequent fragmentation.

Depending on the raw data, the size of the encrypted information may vary. Hence, the size of the encrypted data directly influence the quantity of messages that need to be transmitted through the privately configured single-branch channel in our study.

To analyze the performance of data transmission through the channel, fragments of varying byte sizes were set up, comprising 1 byte for the flags and 100, 1,024, 8,192, and 16,384 bytes, respectively, for the encrypted data fragments. We selected these values to remain within the 32KB limitation defined by IOTA and to examine potential trade-offs between the quantity of messages sent and their size. Additionally, we employed different connection types and endpoints to establish a connection with the IOTA Chrysalis network. The evaluated connection types included wired Ethernet and Wi-Fi, while the endpoints used were the public load-balanced mainnet endpoint provided by the IOTA public infrastructure [38] and our locally implemented endpoint through Hornet.

The results presented in Table 2 reveal that the larger the message size, the longer the time required to propagate the message. To calculate both the average and median, 100 messages were transmitted between the client and the service provider through the established channel for each connection type, endpoint, and message size. This comprehensive approach generated a total of 2,000 measurements, allowing us to derive meaningful insights into transmission times.

Table 2 provides a summary of message transmission times and their corresponding bytes per second rates for different message sizes, connection types, and selected endpoints. All measurements in Table2 were acquired from the client, which uses a Raspberry Pi 4 Model B.

Alternatively, when evaluating the performance of the service provider, characterized by its higher specifications, Table 3 illustrates the potential improvements achievable with superior hardware for a specific setting. These results demonstrate a significant improvement over the client’s metrics under identical conditions. This highlights the possibility of achieving superior transmission outcomes through the use of hardware with higher specifications.

Considering the measurements from Table 2, we can estimate the time and number of messages required to transmit the 30 encrypted features for each fragment size, as shown in Table4. To determine the number of messages in Table 4, we accounted for the number of fragments needed to accommodate the FHE-encrypted data for each size. Regarding the estimated transmission time for these messages, we selected the best median message transmission time from Table2 for each message size, regardless of the connection type or endpoint used. It should be noted that the transmission time for flags, due to their brief duration, has minimal impact on these measurements. In conclusion, based on the findings in Table4, it is clear that the most efficient transmission time is achieved using fragments of 8,192 bytes to transmit the same amount of information

From the comprehensive results, a box and whisker plot has been generated, visualized in Fig. 10. To automatically identify anomalies, we calculated the interquartile range (IQR), establishing a threshold beyond which values are considered outliers. Although outliers are present upon computing the IQR, they are neither as frequent nor as extreme as those observed in the original distribution.

While disparities between the average and median values in Table 2 are apparent, these differences are mainly due to the presence of outliers. Outliers represent exceptional cases where message transmission times deviate significantly, either being very short or excessively long. Therefore, the median is a more appropriate reference measure in this context, as it is less influenced by extreme outliers and offers a more representative characterization of message transmission times.

In Fig. 10, we observe the distribution of bytes per second for each fragment size, categorized by connection type and endpoint. Noticeably, there are outliers corresponding to atypical data transmission times, as mentioned above, which directly impact the average values. In all scenarios, we encounter a positive skewness, indicating that higher bytes-per-second rates are less common than lower ones. However, contrary to the general trend, the rates for 8,192-byte fragments appear slightly better than those for 16,384-byte fragments. This deviation might be attributed to the difference in fragment sizes, with the latter using half the message size allowed in IOTA. Furthermore, there is a noticeable increase in transmission rate dispersion as the fragment size grows, although the dispersion tends to stabilize for larger fragments.

Distribution of transmission rates in bytes per second for different fragment sizes, connection types, and endpoints, based on 100 measurements per message size and connection type. Flags are omitted due to their small size

Full size image

To conclude, Table 5 presents metrics concerning the average message reception time based on fragment size, connection type, and endpoint. Notably, these reception times are significantly lower compared to transmission times. Additionally, Table 5 displays the ratio between transmitted and received messages, demonstrating that the configured channel serves as a reliable transmission system, preserving data integrity.

As the demand for applications employing data from wearables continues to grow, particularly cloud-based solutions serving a wide range of users, concerns regarding privacy and data security have become increasingly pronounced. Typically, such services handle raw or unencrypted data, posing potential privacy risks for users. In response to this challenge, our research introduces an enhanced architectural model aimed at improving user privacy during the transmission of encrypted data derived from wearables to service providers. This model allows service providers to continue offering their services while ensuring user privacy. Notably, in our proposed model, service providers do not gain access to any personal user information, thereby protecting user privacy.

Building on this foundation, the original research question, which aimed to determine the feasibility of transmitting large ciphertexts as data streams via a DLT network while maintaining the confidentiality and integrity of user information, is considered to have been successfully addressed through our proposed architecture and methodology. Our findings demonstrate that combining data streams with DLT networks is a feasible approach for securely transmitting high-overhead encrypted data to service providers for processing, while giving users greater control over their data and ensuring its integrity throughout the transmission and processing phases. The performance evaluation, validated with medical data, further confirmed that, despite the computational overhead introduced, the system remains viable for real-world applications.

The integration of the IOTA DLT network with the established channel via the Streams protocol addresses potential security breaches by ensuring data authenticity, immutability, and integrity during the transmission of data. In this research, we demonstrate the feasibility of using data streams to share FHE-encrypted information with computing services. In fact, the transmission of information occurs through a decentralized distributed network, enhancing the integrity and immutability of the model, as the data is not reliant on a single point of failure as in current cloud solutions. Moreover, the preservation of the client’s information on an immutable decentralized DLT network enables its utilization in future interactions. For instance, this could lead to a multi-subscriber approach, empowering the client to engage with another service provider and authorize access to their authenticated historical data.

Regarding the transmission of encrypted information via a DLT like IOTA, the metrics manifest that while Streams channels are engineered for transmitting small data segments, they also exhibit capability in handling larger volumes. In our study, the private single branch configuration enables organized information transmission between the client and service provider. Nonetheless, the proposed model has limitations, including the IOTA message size constraint and the limited specifications of client devices. The most significant limitation is the transmission delay. As indicated by the metrics in Table 2, sending large volumes of data results in a noticeable delay. Hence, further research aimed at optimizing data transmission is imperative to enhance transmission rates. As depicted in Table 4, using 8,192-byte fragments yields reasonable transmission times considering the data volume being transmitted. Additionally, factors beyond the technical specifications of hardware, such as network quality, available bandwidth, and the reliability of the nodes involved, can also affect message transmission times. Alternatively, it is worth noting that the influence of these factors is relatively minor compared to the impact of the hardware’s technical specifications, as evidenced by the significant improvements in transmission times and bytes per second rates achieved by the service provider in Table 3.

Future research endeavors will focus on conducting a more in-depth analysis of the proposed model and its seamless integration with the IOTA main network, which is under development. Similarly, as FHE libraries and data stream protocols advance, the feasibility of implementing the proposed architecture in real-world business scenarios will progressively improve. Furthermore, exploring mechanisms aimed at reducing FHE overhead, such as those proposed by Gentry et al. [39], holds promise for significant performance enhancements. Likewise, an area for potential improvement involves investigating methods that enable the sharing of the channel’s root between the author and the subscriber while maintaining client confidentiality. Exploring payment mechanisms for third parties or service providers, with a focus on ensuring user anonymity through cryptographic techniques like zero-knowledge proofs (ZKP), will be crucial for future investigations.