Introduction

Healthcare has evolved significantly in recent years primarily due to the advancements in and increasing adoption of technology in healthcare processes such as data collection, storage, diagnostics, and treatment. Computing infrastructure is omnipresent within healthcare facilities. More recently, the industrial internet of things (IIoT) has emerged as a disruptive computing paradigm with applications across various domains such as smart cities [1,2,3], manufacturing [4, 5], and healthcare [6, 7]. In particular, the emergence of IIoT has further evolved e-Health by facilitating the development of connected healthcare systems which can significantly improve data connectivity, visibility, and interoperability leading to improved quality of service delivered to patients. Consequently, sharing of healthcare data, in the life of patients and users, has become ubiquitous [8, 9] transforming healthcare from digital to intelligent [10]. E-health is the term often used exchangeably with telemedicine and telehealth. The term “telemedicine” mostly refers to clinical services from a distance, while the term “telehealth” covers a wide scope of health administration and health education. Both “e-Health” and “telehealth” can be considered as an evolutionary term for “telemedicine” [11].

However, such technological advancements come with their own perils—there are growing concerns with regards to security and privacy of healthcare data especially when collected, shared, and processed using cutting-edge connected sensor devices affecting the adoption of next generation e-healthcare systems. For instance, the use of wearable and embedded devices to aid diagnostic and treatment procedures is increasingly common [12, 13] leading to concerns about privacy and security of patient data.

Although use of IoT to enhance diagnostic and treatment procedures has remarkably improved the quality of healthcare service; however, these data are also an attractive target for cyber attacks [14]. Generally, the data sent by IoT devices do not follow any end-to-end encryption and decryption scheme. Furthermore, as patient data are shared across different tiers of the healthcare system, achieving security and privacy of such data is a challenge [12, 13]. Any disruption in transfer, update or sharing of data can lead to exposition of vulnerable patient data [15, 16].

Also, healthcare sector is more prone to cyber security breaches as health data is considered more lucrative than credit cards on the illegal market [14, 17]. Furthermore, regulations such as General Data Protection Regulation (GDPR) [18] has made regulations to protect individual’s data, which makes data sharing onerous. In this research, GDPR is considered as it is one of the most recent, generic, and comprehensive frameworks that has been established to date. Additionally, it covers broader domains regarding user privacy and access to data. GDPR is mentioned here as an example. In comparison, other policies such as HIPAA, PCI DSS, SOX, and CCPA are domain-specific.

Distributed ledger technologies (DLT) exemplified by Bitcoin have evolved as a major technological advancement of recent times facilitating decentralized data collection and processing in a tamper-proof manner [19,20,21]. In this paper, we investigate the use of DLT to address security concerns for emerging healthcare systems. In particular, we use masked authenticated messaging (MAM) over the Tangle to achieve secure data sharing within a healthcare system and provide a proof-of-concept of applying the proposed approach for securing healthcare data in a connected IIoT environment. We present the design and development of a proof-of-concept for a smart healthcare system to enhance the trustworthiness of the system by facilitating secure data sharing across them.

In the previous studies such as [22,23,24], similar healthcare models on distributed ledger technology have been proposed. However, this paper emphasizes secure sharing of health data in the digital healthcare system [14, 19, 25, 26] by exploring the potential of a DLT, IOTA Tangle [27], and its ability to cope with the limitations of blockchain technology. The objective of the research is to provide a decentralized framework that enables sharing and transport of health data in a secure and private environment by integrating the Tangle [28] which could support secure, fee-less, highly-scalable and granular medical data exchange. It primarily focuses on the transport of medical data to the Tangle. Masked authenticated messaging (MAM) is also employed to broadcast data to the Tangle.

Thus, there is a need for such a digital healthcare system that can meet the above-mentioned challenges and provides an immutable, secure, fee-less, highly scalable, and verifiable system that could gain the trust of medical entities. By implementing the healthcare system with distributed ledger technologies, the gap between healthcare systems and their challenges might be bridged. To address this, the designed framework offers a fee-less, and scalable system for the healthcare industry. It also deals with the security concerns such as confidentiality, accessibility and accuracy. The proposed framework keeps the data confidential by providing an extra encryption layer using MAM. It also enables the healthcare user to have access control over their data and share the data on their own accord. The data on IOTA Tangle is tamper-proof which maintains the credibility of the data.

This study brings contributions to the field of medical and healthcare industry. The demand for secure, private, and reliable digital healthcare has been around for a long time. Thus, by implementing this framework, the healthcare industry will be able to have a secure and scalable architecture for the communication of health data. Not only the users will have access control over the data, but the provided data will also be kept confidential. For medical professionals, this study will help them uncover patient’s diagnostics with the help of shared medical history.

Contributions

The main contributions of the paper include:

  1. (1)

    Discussion and demonstration on how the Tangle Version 1 (before Coordicide) provides improved security and privacy to the data sent by IoT devices.

  2. (2)

    Design of a scheme for secure transmission of medical or health data based transferred through IoT sensors to the Tangle using masked authenticated messaging (MAM) communication protocol.

  3. (3)

    Working “Proof-of-Concept” for transport of health data to a distributed ledger using masked authenticated messaging (MAM). MAM provides extra layer of security with its cryptographic functionality, thereby maintaining the integrity, authenticity, and confidentiality of the data.

  4. (4)

    Evaluation of the current performance of the Tangle with and without masked authenticated messaging (MAM).

Paper organization

The rest of the paper is organized as follows. Section “Design goals” summarizes the use of technology within healthcare and outlines security requirements and design goals for an e-health system. Section “Related work” provides insights into the historical background and research in the area of blockchain for the IoT-based healthcare systems. The next section, Section “Background”, of the research presents necessary background information and theoretical concepts related to distributed ledger technologies with an emphasis on Tangle and masked authenticated messaging (MAM). Section “Implementation” provides the information regarding the setup to collect performance data about the Tangle, its evaluation, and results. Sections “Methods” and “Evaluation” explains the implementation fragment and also discusses how the results are achieved. The last section concludes the paper. It also sets directions for future research work and recommends how this framework can be extended.

Design goals

The use of e-terminology began in the 1990 s with the advancement in Information and Communication Technology (ICT) [29]. The term e-Health was coined in the year 2000, but since then it has been used widely [30]. The World Health Organization (WHO) [31] has described e-Health as “the use of ICT for health” [32]. E-Health is defined as an amalgamation of information and communication of that information in terms of sharing and storage of healthcare data. The distribution of electronic health records (EHRs) is an important application of healthcare information technology (HIT) [33].

The idea of EHRs has been around for more than a decade [34]. Recent technological advancements have also revolutionized and reshaped the storage, processing, and access control of the health data [33]. With the shift in status quo, digital health information is prone to misinterpreted health information and unreliable data that could put a patient’s life to risk [35]. Furthermore, unauthorized third-party access to health data generated from smart devices and wearable devices might put sensitive information at risk [36]. In addition to that, quality medical devices, smartphones, and sensors [37] are required to provide accurate health data and the validation of these devices is also necessary [38].

EHR has numerous benefits, but there are several challenges associated with the establishment of such a system [33]. The possible challenges that are faced in the development of e-Health are security and privacy [39] which have hampered the deployment of existing e-health systems [40]. The reason is that these systems collect sensitive information that may influence a patient’s life and social status [41]. Furthermore, with the advancement in e-Health solutions, more focus has been positioned on accomplishing the security and privacy of the health data as digitizing them will lead to an array of attacks such as denial of service, insider attacks, and information leak [42]. Thus, several organizations have set up guidelines for the administration of healthcare information for achieving the desired level of security and privacy [40]. The first act that was put forward by the US Congress in 1996 as federal law was Health Insurance Portability and Accountability Act (HIPAA) [43]. Another such act is the General Data Protection Regulation act which was put forward by EU law in 2018 [18].

There are several requirements of the e-health system. In this section, security and privacy requirements are discussed for a healthcare system, which includes authorization, accuracy, confidentiality, integrity, and availability of data.

Security

Security can be described as an extent to which shared personal information is authorized [39]. It deals with the protection of data in terms of authorized access to the health information [44]. The security of data emphasizes confidentiality, integrity, and availability of medical data which is managed by e-health system [45]. Confidentiality of data is also a prime factor in e-health. Medical data contains much sensitive information like medical history, behavior problems, and various issues that should be kept confidential. Illegal access to such data can be dangerous for the mental and physical health of a patient [39]. Accuracy in e-health deals with the exactness and correctness of data and confirms that the data is free from faults [44]. For a secure healthcare network, this paper focuses on confidentiality and authorization of medical data.

Confidentiality Confidentiality means that the data is kept hidden. Since health-related data contains sensitive information of a patient, such as the history of illness, general information, diagnostic information, treatment information, etc, hence, it should remain confidential.

Authorization Another critical factor in a e-health system is the authorization of the data. The patient has the access to their health data and they have complete authority over it. This authority also includes the right to share their data, and the right to revoke the access that is granted previously.

Privacy

Privacy can be described as a right of a person to communicate their data [39]. With the rise of cyber-fraud in the digital era, the health data of the user is at risk. The privacy guidelines are formulated with the idea of defining the related factors: patients’ privacy limits and rights. Moreover, it defines the importance of the protection of any part of the data that exposes the identification of a person not bounded to name, address, contact number, etc. because that health data are directly related to the patient’s privacy. Whereas, liberty is given to any data that is unable to be linked to a person and no limits have been placed upon the disclosure of such information. There is also a factor of consent exception that enables the service provider to use the medical data of a certain person during a health crisis such as when a patient is in a coma or any other life-threatening scenarios [43].

Cloud computing notably contributes to the success of e-health as it can provide a framework to overcome the problems regarding the management of health data taking into account that the cloud infrastructures maintained by third parties may have some curious users that might be interested in the data is being stored. Hence, the issues regarding confidentiality, integrity, and privacy concerns have been heightened on the stored data [46, 47]. Furthermore, the flexibility of e-Health schema orbits is around the capability of efficient and selective sharing of medical data amongst related entities.

In the framework of e-health, blockchain appears to be a secure and decentralized platform. Blockchain has changed the trend of storing and sharing health data. It controls the security and accuracy of the data whilst reducing maintenance cost [48]. The primary advantage of blockchain in healthcare organizations is the administration of (electronic medical records) EMRs. The patient medical data are stored in a distributed manner, without full access to that medical data [49]. These factors make the blockchain a platform that reduces cost and increases security [50]. However, there are certain limitations to blockchain technology as well, as discussed in Section “Limitations” which makes the Tangle a better choice for IoT-based e-health solutions.

There is a requirement for a framework that can deal with existing security and privacy challenges, growth in the number of users as well as reduced cost to administer processing needs and control capabilities.

Related work

Blockchain has been able to address prime concerns of privacy and security in digital health care systems. Private information in healthcare is highly sensitive, but it needs to be shared among required personnel as well. Blockchain technology provides fast, secure, accountable and transparent ledger for secure and trustable electronic medical records (EMR) systems. In this paper, the authors, in collaboration with Stony Brook University Hospital, have proposed a framework on management of EMR of cancer patients. They have used the permissioned blockchain to manage the health data. Since it is strenuous for patients to provide continuous treatment data, a model was designed to provide consent management system that could ensure availability of data to concerned entities. This permissioned model with verification also ensures that only concerned entities enter the system while providing scalability and integrity of the data [51].

With the shift in technology, the focus is shifting from electronic medical records (EMRs) to sharing of health data real-time generated from different sensors. In this type of scenario, privacy and confidentiality are of paramount importance. However, scalability and interoperability of data can not be compromised either. To handle this dilemma, the authors in this research have taken a dynamic outlook on EMRs and EHRs. They have proposed a system which not only highlights a secure solution, but also guarantees scalability. They have implemented the Ethereum client on blockchain technology [52].

Similar blockchain architecture for storing health record was proposed by the authors in [53], in which they have discussed the dilemma between privacy and accessibility of patients’ records. They have implemented a framework of blockchain technology integrated with smart contracts. The patient will have the ownership of their data, while the physicians can read it. Furthermore, this whole scenario is controlled by a discovery system, which also keeps an eye on the events of the blockchain. The proposed architecture to access electronic health records (EHRs) ensures data privacy and accessibility [53].

Research by Dias et al. also focuses on the issue of access control of patients’ records in blockchain technology. The crucial part of system security—access control - determines what data is available for whom. The authors discus that current systems that share access do not guarantee integrity of data. The authors have proposed a framework that employed consortium blockchain and enables interested parties to access e-Health whilst maintaining integrity. They have designed a state machine for storing the states of access control. The three states are: Access Policy, Individual Authorization State and Record Life Cycle [54].

As the increase in data generated by IoT devices and sensors, logging of transactions is facing a threat. The Griggs et al. have taken a more advanced perspective on patient data by analyzing security concerns of IoT devices used in health data. They have used Ethereum blockchain based protocol, in which IoT sensors communicate with smart contract implemented smart device. That device is responsible for maintaining records of transactions on the blockchain. The proposed design, according to authors would handle security vulnerabilities that were occurring previously [55].

From the previous discussion on existing work done on maintenance of electronic health records (EHRs), electronic medical records (EMRs) and personal health records (PHRs) on distributed ledger technology, it can be seen that many experts have presented their solutions, protocols, frameworks and architecture to tackle two prime concerns, i.e, privacy and security of stored data. However, as discussed in Section “Background”, blockchain technology does not provide feasible solution for scalability. With the advancement in internet of things (IoT), hundreds and thousands of devices are becoming a part of this system. Similar is the scenario in IoT for medical and health related data. For this purpose, the authors, in this research, have proposed a framework in which IOTA Tangle is used as a ledger for storing medical data. They have also used masked authenticated messaging (MAM), a communication protocol. This extension of IOTA tangle enables users to send and receive encrypted data from a wearable device [22].

Similar framework was proposed by Zheng et al.. In this framework, they aim to develop a secure, fee-less, scalable and tamper-resistant health data sharing system over IOTA Tangle. They have also introduced Raspberry Pi as the gateway to share data from sensors in IoT system. They have concluded that this design could solve several of the problems that blockchain-based technologies have faced [56].

An extended framework of [22] was proposed in [23], in which the authors have extended their research. In this research, they have developed a General Data Protection Regulation (GDPR) compliant “Proof-of-Concept” system for health data exchange. They have proposed two designs: one is solely based on public IOTA Tangle, while the other design is based on the combination of public IOTA ledger with InterPlanetary File System (IPFS) cluster. They have done the analysis of both the designs and compared them in terms of data reversal, data linkability, processing time, file size compatibility and overall system complexity. Also, they have taken blood glucose data as the test data for the system [23].

However, the IOTA-based solutions did not consider the security aspects of IoT applications. Furthermore, the calculation of latency while integrating IoT devices with the Tangle. Hence, our proposed technology is built on top of the classical IOTA protocols, and majorly focuses on two aspects: latency while Integration of IOTA with IoT devices, and the achievement of security by Setting up a secure communication medium using the masked authenticated messaging protocol.

Background

Blockchain

Blockchain, a type of distributed ledger technology (DLT), has been trending recently since its popular emergence after 2015. Blockchain is a technology that enables moving digital coins or assets from one individual to another. The first application of DLT appeared in 2008 with the development of Bitcoin [57]. It was first proposed by Nakamoto in 2008 and implemented in 2009 [58]. As represented by Fig. 1, a blockchain is a public chain of digital data or blocks [59], usually consisting of transactions. The records are added in chain one after another, and the nodes in the network have their copy of the transactions [60]. There is no central controller and the data on blockchain is tamper-proof [22].

Fig. 1
figure 1

Simplified blockchain

Full size image

Table 1 illustrates the differences between traditional databases and distributed ledger technologies.

Table 1 Centralised Database to distributed ledger
Full size table

While blockchain does not allow any malicious interference from outside the network, any node, that is present in the network can be suspected to cause malicious changes to previous, historical transactions. This issue of an adverse node is tackled by cryptographic primitives, or one-way hash functions [61].

Transaction

Identical to any distributed or online transaction processing (OLTP) [62] transaction that acts on some data, blockchain transactions are the same. In the blockchain, a transaction represents an exchange of money or assets [63] between two users, and that transaction is stored in a block [64].

Blocks

Figure 2 illustrates the structure of a block in a blockchain network. There are two parts of a block: block header and block body. The block header consists of:

  1. (1)

    Block version: it indicates which block validation rule to follow

  2. (2)

    Merkle tree hash: it consists of the hash value of all the transactions in the block

  3. (3)

    Timestamp: it stores current time in seconds

  4. (4)

    nBits: target threshold of a valid block hash

  5. (5)

    nonce: nonce is a 4-byte field. It starts with 0 and increases as the hash increases

  6. (6)

    Parent block hash: it is a hash value that points to the previous block in the chain

The block body consists of transaction counter and transactions. Block size and size of each transaction determine the maximum number of transactions that a block may contain [65]. The authentication of the transaction is validated using asymmetric cryptography mechanism [66].

Fig. 2
figure 2

Block structure

Full size image

Limitations of blockchain

The technological needs of IoT cannot be met by blockchain [67] as it has some limitations which intercept it from being used as a common platform for IoT data.

Transparency The first challenge found in blockchain is transparency. Since everything is visible to everyone on blockchain [68,69,70], open data are considered blockchain’s limitation. This becomes very critical in the digital healthcare scenario, where personal medical records are highly sensitive. Although updates made on blockchain are immediately available across the network to all the concerned parties, it raises the following questions: Can all the involved stakeholders in the healthcare scenario be considered controllers of data? How does Article 22 of GDPR, which grants the users protection against automated processing of their information can affect the blockchain?

Scalability and speed The second challenge is scalability and speed [19]. Transaction times in Blockchain are often long, which in turn affects the size of the blockchain [71]. For a transaction to be final on the blockchain, it has to wait for 6 blocks to be added to the longest chain [72,73,74,75]. This issue of speed and scalability is not suitable for scenarios of medical data in the IoT domain. As the data is generated rapidly in the IoT health domain, using blockchain technology might cause a delay in the processing of that generated data as it is harder to scale due to its consensus method. An optimal blockchain that could balance the scalability is yet to be found.

Transaction fees The third challenge is transaction fees. This concept in blockchain that a node needs to pay some fees for the transaction is also a notable drawback. The transaction fees could be financial or it could be toke based. For instance, the transaction could be in the form of a bitcoin, or it could be a gas price. For such a large scenario, a model with high fees will not suffice as. It is certainly not a wise decision to pay higher fees than the data itself. Since the transaction fees are an incentive for the block creators, getting rid of the transaction fees in blockchain structure would not be a suitable decision [28].

Hashgraph

Hashgraph is a decentralized ledger by Hedera Hashgraph Council [76]. Hashgraph attempts to solve the obstacles of blockchain, such as security, scalability, and performance. Hashgraph is like a blockchain, but it permits the growth of new nodes that link back to the chain of nodes.

This DAG uses the probing technique. It is based on the human mechanism of sharing information: gossip. One network node shares the complete information with other randomly selected nodes in the network. These nodes combine all the information received from several other nodes and add it to the transaction. However, it has only been implemented in a private ledger. Hashgraph uses the BFT algorithm and discards proof-of-work which has increased the overall efficiency. A BFT or Byzantine Fault Tolerance algorithm is a feature of distributed ledgers to reach the consensus on some value. The gossip mechanism of Hashgraph is much faster than blockchain’s proof-of-work mechanism and reduces communication barrier [77].

Fig. 3
figure 3

An example of Hashgraph

Full size image

The user has to perform two roles in the Hashgraph. The first role is to submit a new transaction. The second role is to randomly select other users or nodes to whom they will share the information [78] Fig. 3 is an example of Hashgraph.

The Tangle

After the development of blockchain as the most widely used distributed ledger technology, two major problems appeared. The first one was miners, and the second and most important problem was scalability [28]. To overcome this problem, another distributed technology, known as the Tangle, was introduced by Popov [28]. It was created with an intent to solve the problems of post-quantum security, scalability and centralization as well as to focus on the Internet of Things (IoT) [24].

The Tangle is a distributed ledger similar to blockchain. It is based on the mathematical concept of Directed Acyclic Graph, or DAG [79]. So the Tangle is a graph (the ledger for storing transactions) formed of transactions in a directionally significant way (pointed in one direction). And those transactions can not be cyclic. The tangle is a zero-fee, zero-miner, zero-block [27] technology that has distributed consensus mechanism and uses an algorithm called Markov Chain Monte Carlo (MCMC) as its Proof of Work (PoW) mechanism [28]. Zero-fee means that no monetary transaction fee is required to process the transactions. Zero-miner means that there are no powerful machines like miners in the Tangle that would mine the transaction. Instead, it distributes transaction confirmation among all users. Additionally. zero-block implies that it does not have transaction blocks like blockchain. The Tangle has transaction bundles that validate the other two transactions which makes it scalable.

Table 2 Comparison of DLTs
Full size table
Fig. 4
figure 4

Transactions in the tangle

Full size image

Architecture of the Tangle platform

The Tangle architecture consists of several layers and components such as the transaction, client nodes, APIs, and network types. The Comnet is the most widely used network that is used for the purpose of testing and development. It is also used in this proposed framework [80].

Another component is the Tangle transaction bundle. The basic building block of one transaction comprises a transaction hash, value, confirmation status, tag, address, bundle, nonce, signature message fragment, and address of parent transaction. Additionally, the Tangle also has an API that developers can use to test the transactions and for building applications [80].

Components of the Tangle

Figure 4 shows how the Tangle transaction works. In the above figure, node A is Genesis. Genesis is the first transaction in the ledger. Unconfirmed transactions at the edge of the graph are called tips. In the above case, node E and node F are the tips.

A node is any computer that propagates transactions, also known as a site. The next transaction creates an edge that validates two previous transactions. The edges are created as the new transactions are added. Every new transaction is linked to the first transaction. Every site gets a personal weight [28]. The node must validate two transactions by solving a puzzle. That puzzle is similar to hashcash [81]. The central node in the Tangle is called Coordinator. This node is responsible for electing the tips to approve. The approved tips are called “Confirmed” transactions. The resultant transaction of the process of approving tips is called “Milestone”. This new transaction can now approve two other transactions [24].

In the Tangle, the transactions are also capable of carrying the message. They consist of 2673 trytes and can transfer both the message and IOTA tokens [82]. However, since all the transactions are visible to everybody, it is not feasible to share content that requires confidentiality [24].

The Tangle is still in “Beta” status. Hence, the rules of tip selection have not been released yet for the public as users with malicious intents and adequate computational power might perform a malicious activity such as double-spending [83].

Table 2 shows the comparison among blockchain, hashgraph and the Tangle. From this table, it can be seen that DAG-based DLTs are appropriate for IoT-based mechanisms especially with their lower transaction fees and consensus mechanisms [84]. Furthermore, from the two DAG-based mechanisms. the Tangle is more suitable for healthcare scenarios as it offers an extra layer of encryption with the help of its MAM protocol, which is discussed in the next subsection. It is specially designed for IoT scenarios and is immune [28] to quantum attacks. Thus, the Tangle is more suitable for e-health implementation as it allows scalability, quantum security, and offline capabilities [85].

Trits and trytes

The Tangle system utilizes ternary system (a system with three values) instead of binary system (a system with two values). The ternanry system can be balanced \((-1,0,1)\) or unbalanced (0, 1, 2). The tangle utilizes balanced ternary system with trits instead of bits. Hence, according to numeral system [86]:

$$\begin{aligned}&1 Byte = 2^8 = 256 combinations \\&1 Tryte = 3^3 = 27 combinations \end{aligned}$$

The maximum value that a tryte can have is 13 with 27 different combinations. The tryte alphabets in the Tangle uses ASCII sequence ranging from A to Z, and starting with number 9. Hence, it is strictly recommended not to use the same address for sending value once it has been used for the transaction [86].

Seeds and addresses

IOTA seeds, addresses, and hashes are trytes that use tryte alphabets. IOTA seed consist of 81 trytes and each tryte has 27 combinations, so IOTA seed has \((27^{81} \approx 8.71 \times 10^{115})\) combinations, while bitcoin has only \((2256 \approx 1.15 \times 10^{77})\) combinations [86]. With this unique seed, IOTA addresses are generated where the first address has 0 key index number, the second address has 1 key index number, and so on [86].

After the address has been created, the security levels ranging from 1 to 3 are assigned. This indicates how long the private key would be in terms of trytes. Security level 1 has 2187 trytes, security level 2 has 4374 trytes and security level 3 has 6561 trytes of private key and signature length. By default, level 2 security is used.

Masked authenticated messaging

Masked authenticated messaging (MAM), a second layer data communication protocol and an experimenting module, enables a node to publish or fetch data over the Tangle [87, 88]. It was developed by IOTA foundation [24]. The data in MAM is in encrypted forms, as an RSS feed. Messages can be sent anytime over IOTA using MAM. Whenever the message is published using MAM, a channel is created [56]. The message will be received by the node that is subscribed to that MAM channel [87]. Since MAM transactions are stored in the Tangle, it contributes to the hashing power in the ledger and maintains data integrity. MAM adds an extra layer of encryption onto the Tangle, which enables only the subscribers to decode the encrypted message [24]. Furthermore, MAM provides the possibility for sensors and other IoT Devices to encrypt and data streams before sending it to IOTA Tangle.

Since the data in IOTA are decentralized (any node can send a message to any address), there is a risk that a message transaction might contain malicious data sent by any node to hijack the channel. This is where message signing comes in which encrypts the data. The encryption system used by Masked Authenticated Messaging is based on a Merkle Hash Tree (MHT) based signature scheme [56]. The ID of the MAM channel is determined by its root of the Merkle Tree. The next root is referenced by the message in the existing Merkle Tree [87]. It is a type of tree in which the tree is generated bottom-up [89]. The leaves of the Merkle Trees are hashes of the amalgamation of the seed and index number of each leaf, which starts from i = 0 [90].

Fig. 5
figure 5

Merkle hash tree

Full size image

Figure 5 shows the formation of the Merkle tree for transactions A, B, C, and D. Hash is the cryptographic hash function. The last node in the tree is called a leaf. A One-Time Signature (OTS) scheme is used to enable faster signing. Each leaf in the Merkle tree is an OTS scheme.

MAM stores its data in the form of a bundle. Figure 6 shows the structure of the MAM bundle, which consists of two sections: Signature and MAM. The signature section is concerned with validity checking. MAM section contains the actual message [90]. In this figure, the security level is 2. Hence, the first two transactions, transaction 0 and transaction 1 contain the Merkle Tree signature. Transaction 1 contains the actual message.

Fig. 6
figure 6

MAM bundle

Full size image

Figure 6 shows MAM bundle with two transactions in detail. As it can be seen from the figure the MAM bundle consists of information about siblings of the leaf as well as branch index.

MAM has three different privacy and encryption modes [90]. They are:

Public In this mode, the address transaction is the Merkle tree’s root [56] and that address serves as both the channel ID and channel key [22]. Any node can fetch this message and decode it using the transaction’s address. This type of mode can be used for public announcements mostly [87].

Table 3 MAM privacy modes. A hash function is used to generate private key from user’s seed
Full size table

Private In this mode, the address of the transaction is the channel ID. It is encrypted and not meant for the public, i.e, it can not be decrypted by any node. A node must be provided with root to encrypt the stream [87].

Restricted In this mode, an authorization key, also known as side key [56], is concatenated with the channel key [22]. It is like a private MAM with an authorization key on top of it [87]. It allows the publisher of MAM message to revoke the access anytime [56]. The message broadcaster has the authority to revoke access anytime by altering the authorization key, which disables the subscriber from receiving future broadcasts [22].

Table 3 [22] shows three modes of privacy in MAM. It also shows the control visibility and access to channels. CH stands for channel key and AK stands for authentication key.

Fig. 7
figure 7

MAM bundle with two transactions

Full size image

MAM works on two main functions: publish and fetch. To publish the data on MAM stream, first, the root of the tree needs to be generated. In public mode, the address of the tree is the hash of its root, i.e address = hash(root). After that, the message that is to be posted is converted into trytes and stored as a message. It also contains the address to the next generation, known as next root. Branch index and Siblings are also calculated. The combination of message, nextRoot, branch_index and Siblings is then encrypted with root (in Public mode) or sideKey (in Restricted mode). To fetch the data from MAM, root (in Public mode), or root and sideKey (in Restricted mode) is required. The address is calculated from root. After that, the MAM section is decrypted. From decrypted data, message, nextRoot, branch_index, Siblings is received [90].

Thus, masked authenticated messaging provides a fine layer of data integrity and access control management which could be beneficial in many IOTA use cases.

The next section elaborates the setup and evaluation process carried out to test several key performance parameters of the Tangle and discusses the obtained results.

The proposed scheme

Discussion

The proposed framework is a “Proof-of-Concept” of the research objectives. This framework stores medical data on IOTA Tangle in encrypted form, which provides complete privacy and security to the stored data. The sharing of data over IOTA Tangle is done using Masked Authenticated Messaging (MAM) which also provides different modes with different levels of security. Sample health data are collected using a simple android application, which has been designed using Google Fit API [91]. A web interface has also been designed to enable concerned entities to view health data. The android phone is used because Google Fit API can be utilized easily for the purpose of health data. The implementation could also work for a phone with any other OS, provided that the health apps allow utilization of their APIs.

Fig. 8
figure 8

Proposed architecture

Full size image

The proposed framework is a simple design at the initial level to demonstrate the deployment of IOTA Tangle and MAM while collecting real-time health data from the application. This has been done for the basic understanding of research.

Two main roles are designated in the system. The roles are publisher and fetcher. The publisher can be any individual who wishes to publish their health data from their smart device. The fetcher is any healthcare personnel that intends to view the published data. A user can be a publisher and fetcher at the same time.

The implementation of the proposed framework presents a proof of concept of sending data securely from a smart device to IOTA Tangle, which is done via gateway. However, for publishing the data to IOTA Tangle from smart devices such as smartphones, smart watches and smart fitness monitoring devices the proposed setting has to be adapted as per the technical requirements of these devices. For this purpose, a computer or Raspberry Pi [92] can be used as a gateway layer.

Research questions The system was designed with the following questions in mind:

  1. (1)

    Do the users have control of their health data in the existing healthcare systems?

  2. (2)

    Do the existing healthcare systems provide GDPR compliance over the health data?

  3. (3)

    What are the optimal solutions for providing privacy and security in medical and e-Health applications

  4. (4)

    Is the health data that is shared over secure and private?

  5. (5)

    Can the concerned entities view the health data with a user’s permission?

Identification of software requirements Before the development of the framework, thorough research was carried out and several IOTA libraries were tested. Several different libraries were existing on the IOTA Foundation’s website for the implementation of IOTA like C library, Go library, Java library, JavaScript library, and Python library. However, the MAM package was included in the JavaScript library. For this purpose, the JavaScript library was chosen for the implementation of MAM on IOTA Tangle. Out of three modes of MAM, the restricted mode was chosen as it enables the user to revoke access anytime they want to.

After the identification of the language, the next important step was to identify the code editor. VS Code editor was found to be a suitable choice. Another important step was to decide the choice of the operating system for mobile applications. For this step, the android operating system was chosen which has to work in conjunction with Google Fit [93] and Google Fit API.

The web API was designed using Node.js running on a machine with Windows 10, having Intel Core i3, a 3.76 GHz processor, and 4 GB RAM.

Proposed design

The proposed framework addresses the research question. The model was designed by keeping those questions in mind. Figure 9 shows the working of the “Proof-of-Concept”.

Fig. 9
figure 9

Proposed framework

Full size image
Fig. 10
figure 10

Steps for the remote key exchange in the proposed system

Full size image

Detailed architecture and prototype of the proposed framework is shown in Figs. 8 and 9.

The application was designed for the android smartphone which fetches data from the Google Fit application using Google Fit API. This customized application for smartphones allows the user to send their health data such as calories, heart points, and the number of steps to a remote server. In this case, Firebase [94] serves as a remote server. The data is then fetched from a remote server and published to IOTA Tangle.

In this framework, the android smartphone is a part of the sensing layer. The computer system (running the web interfaces) plays the role of a gateway. For security, the user’s health data is published using MAM restricted mode.

To subscribe to that published data, the concerned entity only needs to know the address of the channel and an authentication key (also known as a secret key). This is shared by the user using QR code [95]. The QR code is generated consisting of the user’s channel’s address and authentication key. The advantage of using restricted mode is that user has an authority to revoke access anytime they want to.

Extended scheme

An extended scheme was designed to refine the experiment and evaluate the results. Few changes were made to the existing scheme which includes the addition of Raspberry Pi 3B+ to the architecture as a master node. Additionally, the latency tests were carried out on the latest Comnet.

The IoT device (Raspberry Pi 3B+), in this scenario, sends data to the Tangle. Since Raspberry Pi is capable of processing data from the sensors attached to them and then sending this data to the Hornet node or Comnet Node WiFi for attaching it to the Tangle, it acts as a master node. However, other IoT devices such as sensors are not capable of doing the same. Hence, they can forward the data to the gateway layer via Bluetooth or WiFi, or Arduino serial communication protocol.

Setup and arrangement of hardware

Fig. 11
figure 11

Extended framework

Full size image

The setup and arrangement of extended scheme was refined on the basis of existing framework. The modified scheme can be seen in the Fig. 11. For the purpose of experimentation, a Raspberry Pi has also been added to the architecture. It is not only capable of sending data to the Tangle, it can also server as a gateway layer for the devices that are not capable of performing transactions on Hornet.

System and Software Specifications For the extended experiments, some modifications were made to the current architecture. Two new nodes were setup. One was connected to Comnet, and the other one was Hornet running in a Docker container. Table 4 shows the system specifications of the revised architecture.

Table 4 System and software specifications
Full size table

Method

In the feasibility study of this proposed framework, the data was broadcasted using MAM protocol in restricted mode. This test was carried out on 5 android smartphones with different android versions. However, all of the versions were above android 5.0. This test was carried out for approximately 10 days.

Fig. 12
figure 12

Device information stored by device Id

Full size image

Consider the scenario where users or patients intend to share their health data with physicians or any other medical entity. For this, they will have to publish the data to Firebase first.

Fig. 13
figure 13

Stored data in JSON format

Full size image

Figure 12 shows the storage of health data by device number. The data is stored in JSON format in Firebase, unlike relational databases, where data is stored in tabular form.

Fig. 14
figure 14

Only the data that is shared by the user is fetched from Google Fit using Google Fit API and stored in Firebase

Full size image

Figure 13 shows the JSON string. From Fig. 14, it can be seen that the user had control over what data they intend to share. The first device (device number: 3811ddba387d93a0) has shared its calories, number of steps as well as heart points.

But, the second device (device number: 909d9bab2c894b45) has only shared calories.

This also highlights the right of access (mentioned in GDPR) of the person to whom the data relates. This data is then published to IOTA Tangle using a Web API. OpenSSL protocol is used to ensure the safety of the seed. To check whether the data has been published to IOTA Tangle or not, IOTA MAM Explorer is used.

Fig. 15
figure 15

Address and secret key shared using QR code

Full size image

After publishing the data, a QR code is generated consisting of address and side key as shown in Fig. 15. Now, that patient can share the QR code with their physician to give them access to view their data.

Similarly, published data can be fetched from IOTA tangle using the developed web API.

IOTA Devnet [96] was used to publish and fetch data from IOTA Tangle. At the beginning of the research, IOTA Devnet was supported by IOTA Foundation. However, it no longer supports Devnet and has switched to Comnet, so the system was also switched to Comnet. The Node.js [97] scripts for publishing and fetching data from IOTA Tangle using MAM are available [98, 99].

Evaluation

This section describes the setup used to append the transaction to the Tangle. It also describes the preliminary results of this experiment. This study will provide the basis to discuss the practicability of implementing healthcare applications on IOTA.

Setup

A basic setup consisting of a public node was created to evaluate the transaction time in the Tangle. The public node at https://nodes.thetangle.org:443 (Node A), was hosted in Ashburn, USA. And a private node (Node B) was hosted in North Virginia, USA.

The hardware employed to test the trials of the public node is a 2 core i3 CPU running at 2.40 GHz, with a 4 GB RAM and 500 GB SSD disk for storage. The private node has been set up as an E2 instance using Amazon AWS [100].

The official IOTA Python API PyOTA [101] is used to add transactions with a payload of different lengths and their transaction writing time is assessed. An IOTA transaction has a payload length of 2187 trytes. If the payload size in a transaction exceeds 2187 trytes, then the transaction is segmented into two and then added to the Tangle. For this research, two payloads of different lengths were considered: m with 1399 trytes and n with 2373 trytes.

Two different scenarios, appending transactions and appending masked authenticated messages, have been considered. Their details are given below:

  1. (1)

    Append transactions to the Tangle: For this scenario, the tests were conducted in two phases. First, the overall delay of adding these transactions to the Tangle was calculated with 100 trials. After that, again for a set of 100 trials, the delay measurement was partitioned into “tip selection”, “attach to tangle” and “broadcast” operations.

  2. (2)

    Append MAMs to the Tangle: The test was conducted for a set of 100 trials measuring the delay of appending MAMs to the Tangle partitioned in terms of “encoding”, “broadcast” and “get message” operations.

Results

In this section, the results are arranged according to the above-discussed scenarios: append transactions and append MAMs.

Fig. 16
figure 16

Time distribution for attaching message m and n and of sizes 1399 and 2373 trytes respectively for node A and node B

Full size image
Fig. 17
figure 17

CDF of the latency taken when appending message m of size 1399 trytes to the Tangle using public node A and private node B

Full size image

Append transactions to the tangle

Figure 16 is a box-and-whisker plot to show the global delay in attaching the transaction to the Tangle. It can be seen that message of size n has a higher median delay for both nodes (A and B) probably because the message has been segmented into two transactions. For the same reason, i.e the size of trytes, there is less median delay for the message of size m.

Fig. 18
figure 18

CDF of the latency taken when appending message n of size 2373 trytes to the Tangle using public node A and private node B

Full size image

It can be seen that the private node, node B, has exhibited a clear improved performance timing for both the messages, m and n. This is probably due to the reduced load in transaction requests that the private node, node B, experiences.

There are some transaction maximum outliers in Fig. 16. The attachment delay can have multiple causes. The most likely cause is the highly challenging “proof-of-work”.

To get a deeper understanding of the delay in attaching transactions to the Tangle, this procedure is divided into three operations: “tip selection”, “attach to tangle” and “broadcast”. The first step decides which two transactions are to be approved. It is done by running the tip selection algorithm twice. The second operation carries out some “proof-of-work”. This operation has a high variance because the randomness of finding a suitable nonce requires time. In the last operation, the transaction is broadcasted to the network. The cumulative distribution functions (CDF)of the latency experienced in these operations for messages m and n is demonstrated in Figs. 17 and 18.

It can be seen that the major delay caused when appending transaction to the Tangle is due to the “attach to tangle” operation corresponding to the “proof of work” which is carried out in each transaction. The second reason for the delay is the “tip selection”. The broadcast operation is approximately 1 s and thus insignificant as compared to other delay contributions.

While comparing Figs. 17 and 18, an expected behaviour is revealed: the “proof of work” for messages of size n exhibit delay as compared to messages of size m. For example, 80% of the transactions of size m for private node B experience the “attach-to-tangle” delay below 10 ms, while the same is true for 25% of the transactions of size n for the same node.

Append MAMs to the tangle

Fig. 19
figure 19

CDF of the latency taken when appending transaction using masked authenticated messaging protocol

Full size image

MAM transactions are different from normal transactions on the Tangle. In a MAM transaction, the data is encrypted before attaching it to the Tangle. So, attaching a MAM transaction includes three stages: “encoding”, “broadcast” and “get message”. The first stage is the encryption of the message with its secret key. The second stage is attaching the message to the tangle and broadcasting it. The last stage corresponds to fetching a MAM message.

The latency CDF for all three stages can be seen in Fig. 19. As the graph suggests, the “broadcast” stage is the prime contributor to the overall delay. This behavior is expected as a small amount of proof-of-work is included in this stage and it is a random process. The second contributor is the “get message” stage. The “encoding” stage has a negligible jitter and exhibits delays of 0.8 to 1 s.

Extended evaluations

The evaluation setup has been extended for 500 transactions instead of 100 transactions. Furthermore, two nodes are used to test transactions. However, the payload has been kept same for both the nodes i.e. 1399 trytes. Additionally, the similar operation of appending transactions to the Tangle was carried out with the set of new nodes.

Fig. 20
figure 20

CDF of the latency taken when appending transaction using message m on the Tangle using Hornet and Comnet nodes

Full size image

Figure 20 shows the latency of attaching the transaction on IOTA Tangle using the latest nodes, each performing 500 transactions on the Tangle.

Discussion

The above-observed data shows that the transmission of a transaction in the Tangle can be achieved with a relatively low delay as compared to blockchain technologies. The above-observed implementation leverages medical applications with the benefits of IOTA technology.

At the current stage of the Tangle, many of the transactions were not immediately confirmed by the Coordinator. Many of them took a long time to get confirmed, which might represent a security risk, such as double-spending. This risk can be evaded using MAM.

MAM is an extension module that allows the storage, retrieval, and sharing of authenticated and encrypted data on-demand. It relies on distributed nodes and the data is distributed. Due to this reason, there is no central target for data leaks or cyber-attacks. Another important point is that this is the implementation of MAM in restricted mode, which gives users authority and agency to define the level of control over their data. The user can change the authorization key and disable future transactions for the past subscribers.

The tests were carried out on the current MAM library and it was observed that the overall delay of attaching the transaction is probably influenced by a small amount of “proof-of-work”, which has randomness associated with it. This current library is not optimized for healthcare scenarios and it needs to be improved. The “proof-of-work” implementation can be made further efficient to run more effectively. Another important factor to delay is network latency, but this issue is out of the scope for this research.

MAM channels were found to be more efficient in storing, managing and sharing IoT data due to scalability which makes it a suitable protocol for healthcare IoT as well as industrial IoT.

Security analysis

The Tangle, similar to the blockchain network, is secure, scalable, resilient, and robust as its foundation is laid upon the cryptographic fundamentals. To further improve the security and encryption mechanism, MAM [87] protocol is used to encrypt the data stream on the Tangle. The restricted mode in this protocol allows the data to be decrypted only if the private key is shared by the sender with the receiver.

The Tangle is known for its security features, hence making it suitable for several applications. It offers tamper-proof solutions and helps in attaining the security requirements such as confidentiality, authorization, availability, and integrity. This section discusses the security requirements and how these requirements are achieved by the Tangle.

Confidentiality Confidentiality is one of the most important requirements of security. The Tangle offers confidentiality by providing encryption to the data. All the information that is stored on the ledger, or communicated between nodes is encrypted. An extra layer of encryption is also provided using the MAM protocol. For the current scenario of the proposed framework, MAM protocol is used in restricted mode, thus only enabling the authorized users to communicate with the data. Therefore, data confidentiality is well maintained using the Tangle.

Authorization Another critical factor in an e-health system is the authorization of the data. The patient has the access to their health data and they have complete authority over it. For example, in the proposed healthcare system, only the user must share the data with the required medical person.

Availability Availability is another important security requirement. This requirement is facilitated by the Tangle. The nodes are always available and the transaction can take place at any time. The significant feature of the Tangle is decentralization which eradicates the single point of failure from the system.

Integrity The Tangle also offers this security feature in addition to the features mentioned above. The ledger has built-in integrity as it is immutable and tamper-proof. The information that has been stored there can not be changed or deleted. Hence, the integrity of the system is maintained using this distributed ledger.

Conclusion and future work

In this study, a distinctive model with zero-fee, zero-miner, and zero-block was proposed for the storage and sharing of health-related information securely and privately. This research has evaluated and discussed the chief performance parameters of the transaction on the Tangle as well as masked authenticated messaging (MAM) Protocol. Another main factor of this research is masked authenticated messaging (MAM) protocol which allows for smooth and secure transactions over the Tangle. This will aid in privacy and security support for medical data with minor latency overhead. MAM module has also enabled the user to exercise authority over access control of data. However, it has room for further improvements. The research can also be seen as a possible solution to overcome the many challenges of blockchain technologies for the healthcare sector, enable remote monitoring, and pilot healthcare into the digital age.

The research does not end here. Another version of this healthcare system can be implemented using random access authenticated Messaging (RAAM) [102] which allows for random access in the channel stream, rather than sequential access as in MAM.

One more similar work that can be carried out is addressing the patients in emergency and critical conditions where patients are not in a position to share their QR Code or publish their recent data to the Tangle. They may either be unconscious or unable to access their data at a given time. For this purpose, other facets of biometric identity solutions, such as retina and voice scans, can be explored. This idea was also proposed for future work by [22, 103].

The proposed framework can be further modified to adjust with wearable devices and sensors and can be used in other health and fitness domains such as sports and rehabilitation. Environmental sensors can also be included to monitor the environment around patients. These different data can be published to the Tangle with different MAM modes. It could be a new direction for the future work [56]. Future work can also be focused on extending the trial count from 100 to a larger set to verify, authenticate and endorse the performance parameters of the Tangle [24].