Secure IoT Communication: Implementing a One-Time Pad Protocol with True Random Numbers and Secure Multiparty Sums

Abstract

We introduce an innovative approach for secure communication in the Internet of Things (IoT) environment using a one-time pad (OTP) protocol. This protocol is augmented by incorporating a secure multiparty sum protocol to produce OTP keys from genuine random numbers obtained from the physical phenomena observed in each device. We have implemented our method using ZeroC-Ice v.3.7, dependable middleware for distributed computing, demonstrating its practicality in various hybrid IoT scenarios, particularly in devices with limited processing capabilities. The security features of our protocol are evaluated under the Dolev–Yao threat model, providing a thorough assessment of its defense against potential cyber threats.

1. Introduction

The increasing prevalence of the IoT in our daily lives opens a wealth of opportunities to create new services, many of them personalized and customized for individuals, provided that the privacy of individual and sensible data are maintained in the process of constructing digests that can be used for public benefits, such as planning, policy making [1], smart agriculture [2], and healthcare [3], among others.

However, as the IoT becomes more integrated into our daily routines, the critical issue of data privacy grows. IoT devices and their associated data are prone to significant vulnerabilities from a modern information security perspective [4]. The issue arises when raw data are collected and transmitted without sufficient privacy safeguards. This situation can result in dangers such as unauthorized virtual profiling, which poses serious threats to essential privacy needs and the confidence of the public [5]. To counter these risks, ensuring the privacy of data collected from IoT devices while using them for social profit and the common good can be effectively achieved through secure multiparty computation (SMPC), secret-sharing protocols, and masking through one-time pads (OTPs).

Secure multiparty computation is a robust method that allows multiple parties to jointly compute a function over their private inputs without revealing them to each other. This security is a significant advancement over traditional lightweight key management systems, which, while less resource intensive, may not offer comparable security levels; see, for example, Ref. [6]. SMPC ensures that each participant’s data remain concealed throughout the computation process, significantly improving privacy and security. SMPC can also be used in distributed scenarios with other security-preserving techniques, such as secret sharing and oblivious transfer, enabling joint computation without compromising individual data privacy. Secret-sharing schemes allocate a secret to several participants, requiring a specific minimum number of shares to be gathered for reconstruction. These protocols are crucial for cryptographic applications, starting with the pioneering contributions of Diffie and Hellman in 1976 [7].

An example of a protocol that uses secure multiparty computation and secret sharing in a distributed environment that maintains user privacy while decreasing communication and computation expenses is discussed in Patel’s work [8]. On the other hand, oblivious transfer (OT) allows a party to send one of many pieces of information to another without revealing which piece was sent; see, for example, ref. [9].

Furthermore, employing masking via one-time pads involves encrypting data through XOR operations with a key known exclusively to the communicating parties, ensuring a robust level of security given that the key is utilized only once. When integrated with SMPC, this approach creates an effective framework for protecting sensitive information, as is the case in policy formulation and healthcare applications, where protecting sensitive personal data during analysis and decision-making processes is mandatory.

The combination of these techniques ensures that, even if part of the system is compromised, it would be difficult for third parties to deduce confidential information as it would require considerable computational resources or processing times for full disclosure of protected data, thus supporting the ethical and secure use of IoT data for public benefit.

Numerous proposals for collaborative machine learning (ML) models exist where parties want to keep their data private, for example, in text classification for speech detection [10] and machine learning with sensitive medical data [11], in ensuring privacy in training deep networks on decentralized data [12], and in the use of blockchain technology to enhance the security of distributed systems [13]. In such cases, one-time pad (OTP) encryption presents a viable solution, providing exceptional secrecy, low computational overhead, immunity to quantum attacks, independence from trusted centralized systems, and ease of implementation. These attributes fulfill the lightweight computational requirements essential for resource-constrained IoT devices.

Our approach is to substitute the key agreement process with an approach that uses true random numbers, a dummy third party, and a modified classical three-party computation protocol. This modified protocol can be applied in real time to mask communications. True randomness ensures that the generated key is used only once, thus maintaining confidentiality. The details of the protocol are explained in Section 2, and we implement it in a distributed environment based on ZeroC-Ice v.3.7., and the Python language v.3.12, as described in Section 3 and Section 4. Furthermore, an analysis of the security properties is presented in Section 5, and our findings are discussed in Section 6.

2. A One-Time Pad with True Randomness

Section 2 considers the first building block for secure multiparty computation (SMPC) among two parties using a third dummy party in a procedure inspired by [14]. Although the procedure generally applies to any set of numbers, we consider, in particular, the numbers in $\mathbb{Z}$ or ${\mathbb{Z}}_p$, in which p is an appropriate prime. This decision does not introduce additional limitations as all messages, textual or otherwise, must be transformed into a number (or series of numbers) for encryption purposes.

Think of two parties, $P_1$ and $P_2$, who wish to agree on a shared key using multiparty computation that involves the sum of their private inputs $x_1$, $x_2$ in ${\mathbb{Z}}_p$, but without disclosing them to each other. The procedure needs, of course, a third party, which will be $P_3$, which is used as an auxiliary server that only receives inputs and transmits the resulting sum of the inputs.

• Share generation:
  Each party $P_i$, $i=1,2$, generates two random shares $r_{i,1}$ and $r_{i,2}$ in ${\mathbb{Z}}_p$ and computes a third share $r_{i,3}$ as the difference between their private input $x_i$ and the sum of the two random shares, modulo p, as described by the following equations:

  $$\begin{array}{ccc}\hfill (r_{i,1},r_{i,2})& \stackrel{\$}{\leftarrow }& {\mathbb{Z}}_p\times {\mathbb{Z}}_p,\hfill \end{array}$$

  (1)

  $$\begin{array}{ccc}\hfill r_{i,3}& =& x_i-(r_{i,1}+r_{i,2})modp,i=1,2.\hfill \end{array}$$

  (2)
  Party $P_3$ generates three random numbers, $r_{3,j}\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$, $j=1,2,3$.
• Standard share distribution (as in [14]):
  Each party $P_i$ sends two of its three shares to the other parties according to a specific rule to ensure that no one party receives all shares from another party. Quote: Each $P_i$ sends privately $r_{i,2}$, $r_{i,3}$ to $P_1$, $r_{i,1}$, $r_{i,3}$ to $P_2,$ and $r_{i,1}$, $r_{i,2}$ to $P_3$. Hence, the distribution pattern is as follows:

  $$\begin{array}{cccc}{P}_1:\hfill & ---& \begin{array}{|c|}\hline r_{1,1}\left|\right|r_{1,3}\stackrel{}{\to }{P}_2\\ \hline\end{array}& \begin{array}{|c|}\hline r_{1,1}\left|\right|r_{1,2}\stackrel{}{\to }{P}_3\\ \hline\end{array}\\ P_2:\hfill & \begin{array}{|c|}\hline r_{2,2}\left|\right|r_{2,3}\stackrel{}{\to }{P}_1\\ \hline\end{array}& ---& \begin{array}{|c|}\hline r_{2,1}\left|\right|r_{2,2}\stackrel{}{\to }{P}_3\\ \hline\end{array}\\ P_3:\hfill & \begin{array}{|c|}\hline r_{3,2}\left|\right|r_{3,3}\stackrel{}{\to }{P}_1\\ \hline\end{array}& \begin{array}{|c|}\hline r_{3,1}\left|\right|r_{3,3}\stackrel{}{\to }{P}_2\\ \hline\end{array}& ---\end{array}$$

  (3)
• Modified share distribution:
  Each $P_i$ sends privately $r_{i,j}$ to $P_j$, $i\ne j$, $i,j=1,2,3$. Hence, the distribution pattern is as follows:

  $$\begin{array}{cccc}{P}_1:\hfill & ---& \begin{array}{|c|}\hline r_{1,2}\stackrel{}{\to }{P}_2\\ \hline\end{array}& \begin{array}{|c|}\hline r_{1,3}\stackrel{}{\to }{P}_3\\ \hline\end{array}\\ P_2:\hfill & \begin{array}{|c|}\hline r_{2,1}\stackrel{}{\to }{P}_1\\ \hline\end{array}& ---& \begin{array}{|c|}\hline r_{2,3}\stackrel{}{\to }{P}_3\\ \hline\end{array}\\ P_3:\hfill & \begin{array}{|c|}\hline r_{3,1}\stackrel{}{\to }{P}_1\\ \hline\end{array}& \begin{array}{|c|}\hline r_{3,2}\stackrel{}{\to }{P}_2\\ \hline\end{array}& ---\end{array}$$

  (4)
• Partial sum determination:
  In the standard procedure, each party $P_j$ adds the corresponding shares as $s_l=r_{1,l}+r_{2,l}+r_{3,l}$, $l\ne j$, $j=1,2,3$. In the modified share distribution, each party $P_j$ computes the (single) sum of the shares received according to the following:

  $$s_j=r_{1,j}+r_{2,j}+r_{3,j},j=1,2,3.$$

  (5)
  For instance, $P_2$ is aware of his own generated shares, $r_{2,1}$, $r_{2,2}$, and $r_{2,3}$. Additionally, he has obtained $r_{1,2}$ from $P_1$ and $r_{3,2}$ from $P_3$. Therefore, $P_2$ can calculate $s_2$, which is expressed as $s_2=r_{1,2}+r_{2,2}+r_{3,2}$.
• Partial sum distribution:
  In the standard procedure, each party computes and announces (broadcasts) two values. In our proposed modification, $P_1$ sends $s_1$ to $P_2$, $P_2$ sends $s_2$ to $P_1$, and $P_3$ broadcasts $s_3$ to $P_1$ and $P_2$:

  $$\begin{array}{cccc}{P}_1:\hfill & ---& \begin{array}{|c|}\hline s_1\stackrel{}{\to }{P}_2\\ \hline\end{array}& ---\\ P_2:\hfill & \begin{array}{|c|}\hline s_2\stackrel{}{\to }{P}_1\\ \hline\end{array}& ---& ---\\ P_3:\hfill & \begin{array}{|c|}\hline s_3\stackrel{}{\to }{P}_1\\ \hline\end{array}& \begin{array}{|c|}\hline s_3\stackrel{}{\to }{P}_2\\ \hline\end{array}& ---\end{array}$$

  (6)
• Final sum calculation:
  In the standard procedure, all parties compute the result $s_1+s_2+s_{3}modp$. In our modified procedure, $P_1$ and $P_2$ calculate both the sum $K=s_1+s_2+s_3$, while $P_3$ learns nothing. Therefore, K will be known only for $P_1$ and $P_2$, while all private inputs remain private and cannot be deduced from the output.

Figure 1 graphically shows our proposal, highlighting communication between parties.

Observe that, for $P_3$, the role of randomness guarantees that $x_3$ is never disclosed during communication between parties. In fact, for the first part, only $r_{3,1}$ and $r_{3,2}$ travel to $P_1$ and $P_2$, respectively. The third component, $r_{3,3}$, travels masked in the sum $s_3$ when transmitted. Therefore, even in the case where a malicious eavesdropper is following the interchange between $P_1$ and $P_2$ towards $P_3$, it is improbable that the output $s_3$ can be correlated with the secure multiparty sum protocol, or with the random component $x_3$. Therefore, since the final computation of the key K takes place privately for $P_1$ and $P_2$, the conclusion is that $P_1$ and $P_2$ have effectively shared a common key K, which can be used to mask communication between them.

In a usual SMPC summation for three parties, as in [14], the transmission of the shares is different (10 rounds compared to 12) and allows cross-checking of the partial sums to detect a potential dishonest one out of two parties. In addition, the key is shared between the three intervening parties. In our procedure, instead, communication can be sequentially arranged so that the total number of rounds can be reduced to eight, which is a reduction of the order of 30% from the standard multiparty summation protocol; see the Section 3.

Now it should be clear that, at this point, the space in which the sums are taken can be a ${\mathbb{Z}}_2^N$ for a suitable N, which means that there is no restriction a priori about whether the sums are binary sums or not. This means that the procedure between parties can be performed bit by bit or by blocks of bits of size N. The summation can be executed using the well-known XOR operator as a classical implementation of the one-time pad protocol.

It is worth noting that it is not necessary to limit the quality of the random shares; they can be pseudo but also true random bits. These true random bits can be obtained from any source, such as physical true random numbers commonly found in IoT devices (by capturing states from sensors, accelerometers, channel noise, etc.).

True random number generators (TRNGs) produce numbers based on physical processes, such as thermal noise, radioactive decay, or quantum phenomena, making these numbers inherently unpredictable. This unpredictability is theoretically ideal for cryptographic applications where randomness is crucial for security. However, it has been pointed out that using TRNGs in practical cryptographic systems presents several challenges, some of which we detail below (see [15]):

• In cryptographic protocols, particularly those involving multiple parties, it is essential that all parties agree on the cryptographic keys to be used. If every participant uses their TRNG, reaching a consensus on a common key is challenging since each participant will produce distinct, autonomous values. Coordinating these values among varied systems and across different regions increases complexity and may lead to security risks;
• TRNGs may exhibit slow performance, and their output rates might not meet the demands of high-throughput environments. Furthermore, the dependability of TRNGs can be compromised due to environmental factors and the deterioration of hardware;
• Ensuring the randomness and lack of bias in numbers generated by TRNGs is non-trivial. Continuous testing and monitoring are required to ensure the integrity of randomness, which can be resource intensive.

Our newly developed protocol employs a blend of secure multiparty computation (SMPC) and one-time pads (OTPs), effectively tackling the challenges of key agreement and the demand for cryptographically effective TRNGs. Instead of solely relying on TRNGs, employing cryptographically strong pseudorandom number generators (CSPRNGs) is a feasible substitute. An upcoming paper will detail a hybrid method where CSPRNGs, known for their faster and more dependable random number generation than TRNGs, are incorporated into an SMPC setting. This integration ensures that our protocol achieves the necessary randomness for cryptographic security and the practicality for application in real scenarios. This comprehensive method resolves the critical issue of key agreement in multiparty systems, guaranteeing secure, efficient, and dependable cryptographic processes.

3. On-the-Fly KeyGen and Encryption

It is crucial to recognize that, although the protocol shown in Figure 1 adheres to the principles of a secure multiparty sum involving three parties, as outlined in [14], we diverge from this method by ensuring that the dummy third party remains unaware of the final (secure) sum. Furthermore, the performance of the actual protocol is improved if the sequence (ordering) in which transactions are executed is taken into account.

Clearly, since any consideration about the messages to be exchanged includes parsimony and duplication avoidance, the protocol can be modified as follows (Algorithm 1):

Algorithm 1 SMP-OTF4IOT: On-the-Fly KeyGen and Encryption

Require:  Users $U_1,U_2$, which will be called Client and Server, respectively Ensure:  Peer to Peer Key sharing and Encryption. Initialization:  - $U_1$ generates a dummy third party $U_3$ and shares the connection details with the server $U_2$.  - $U_i$ reads three (true) random numbers from the devices attached to it: $r_{i,1},r_{i,2}$ and $r_{i,3}$, $i=1,2,3$. Procedure:  1.  First Round: - $U_1\stackrel{r_{1,2}}{\to }{U}_2\stackrel{r_{2,3}}{\to }{U}_3\stackrel{r_{3,2}}{\to }{U}_2\stackrel{r_{2,1}\left|\right|s_2}{\to }{U}_1$, with $s_2:=r_{1,2}+r_{2,2}+r_{3,2}$. - $U_1\stackrel{r_{1,3}}{\to }{U}_3\stackrel{s_3}{\to }{U}_2$, with $s_3:=r_{1,3}+r_{2,3}+r_{3,3}$. - $U_3\stackrel{r_{3,1}\left|\right|s_3}{\to }{U}_1$.  2.  Key determination: - $U_1$ computes $K_1:=s_1+s_2+s_3$, with $s_1:=r_{1,1}+r_{2,1}+r_{3,1}$. - $U_2$ computes $K_2:=s_2+s_3$ Encryption and decryption:  - $U_1\stackrel{s_1\left|\right|c:=K_1\oplus m}{\to }{U}_2$  - $U_2$ decrypts the message as $m=(s_1+K_2)\oplus c$

We implement the SMP-OTF4IOT protocol described above to establish a common key K between any two IoT devices that can be used as an OTP to secure communication between two parties $P_1$ and $P_2$ that requires a third (dummy) server $P_3$, whose job is to receive inputs and broadcast the sum of the inputs.

The procedure described above is visualized in Figure 2.

4. Methodology and Implementation

We present the essential elements required for an IoT set-up where our method can be applied. A practical pilot implementation is described in an actual environment using ZeroC-Ice v.3.7., with Python v.3.12.

4.1. System Model

• IoT Environment: The system operates within an IoT framework consisting of various sensors and devices distributed across multiple locations. These devices are interconnected through a network and can collect, process, and transmit data;
• Sensors and Data Sources: Various types of sensors (e.g., temperature, humidity, motion, or light sensors) are employed. These sensors capture environmental data that exhibit inherent randomness and can be extracted to generate true random numbers;
• Data Processing Units: These are either embedded within the IoT devices or are standalone units (like edge computing devices) that perform initial data processing, including filtering, normalization, and preliminary randomness extraction from sensor data;
• Randomness Extraction Module: A dedicated module that applies statistical tests and extraction algorithms (e.g., hash functions) to raw sensor data to refine and ensure the quality of randomness;
• Communication Network: Connects IoT devices with each other and with central servers or cloud services. This network facilitates the transmission of sensor data, processed random numbers, and cryptographic keys/messages;
• Central Server/Cloud: Hosts higher-level data processing, storage, and management services. It may also perform additional security checks, distribute software updates, and manage cryptographic keys.

4.2. Client–Server Configuration

In Figure 3, a client application transmits the encrypted message ‘Hello secret world!’ one character at a time, and, as each character arrives at the server, it is decrypted. The server processes each character to rebuild the initial message. This process is facilitated by the SMP-OTF4IOT protocol (Algorithm 1), implemented in Python v.3.12.

The realization of this process requires the simultaneous functioning of three programs: (1) smpc_dummy.py, which acts as an intermediary for generating random numbers; (2) smpc_server.py, responsible for establishing communication with the “dummy” service where synchronization begins; and, finally, (3) smpc_client.py, which initializes communication coordination and initiates the sending of encrypted data to the server, synchronously generating keys in real time to transmit each character. Each of these programs uses ZeroC-Ice for network data transfer.

The complete implementation is available for perusal in the GitLab repository at https://gitlab.com/smpc-ufro/smpc.

4.3. ZeroC-Ice Implementation on SMP-OTF4IOT

We implement the protocol in ZeroC-Ice v.3.7, (Internet Communication Engine developed by ZeroC), as described in [16], using Pyhton 3.12, as the implementation language. The advantage of using this approach lies in the possibility of connecting three devices from three different platforms and architectures, for example, a single-board computer (Raspberry Pi), a mobile device, and a cloud application. Each platform runs the corresponding script according to the current role in the protocol, i.e., client, server, and dummy, according to Listing 1.

Listing 1. ZeroC-Ice SMPC implementation.

It is essential to mention that the server can retrieve the key and the message in a single call. Similarly, when making a remote call, it is possible for the call to return multiple values. For example, the server can return their share and partial sum as a tuple of integers.

By adopting this method, the number of messaging instances for communication is reduced from 11 to 8, including the transmission of the encrypted message (approximately 30% reduction in bandwidth). Notice that the roles described above (Client, Server, Dummy) are used ‘as a whole’ to secretly communicate between two parties by using (true) random number acquisition and a dummy third party that is not granted access to the shared encrypted message. However, these roles can be continuously and dynamically changed so that, in principle, the protocol extends naturally to peer-to-peer secure communication between any number of IoT agents in a real-life application. Note that, if a message m of size $\left|m\right|$ must be transmitted while encrypted according to our algorithm, then the total communication cost for key generation and transmission of an encrypted message would be approximately twice the size of the message simply because, in our setting, the communication time between parties $U_1$ and $U_2$ is bounded above by

$$time(U_1,U_2,K\oplus m)\sim \sum _{i,j=1}^3|r_{i,j}| + \sum _{k=1}^3|s_k|+|K\oplus m|\le 2\left|m\right|.$$

5. Security Analysis

The security aspects of the SMP-OTP4IOT protocol can be rigorously examined and verified by formal analysis using, say, Tamarin Prover [17] or ProVerif [18] (see [19] for an extended review of formal modeling and security analysis of security protocols). However, an accurate description of the formalism required for our protocol lies beyond the scope of this investigation. Instead, we focus on the inherent security properties of the protocol as implemented in ZeroC-Ice.

Under the Dolev–Yao threat model [20,21,22], we assume a semi-honest adversary that has access to all messages exchanged between parties $U_1$, $U_2$, and $U_3$ and tries to gain some knowledge of the messages being transmitted, without tampering with the transmitted data, or a dishonest adversary, which also actively modifies the messages in transaction.

In the context of the semi-honest participant scenario, all the information being transmitted consists of random numbers and additions. Observing the communication between $U_2$ and $U_1$ as well as between $U_3$ and $U_1$ in the first round, it is possible to deduce the partial sums $s_2$ and $s_3$. Subsequently, by monitoring communication between $U_1$ and $U_2$ during encryption and decryption, it is possible to deduce $s_1$, and, consequently, the adversary could potentially compute $K_1=s_1+s_2+s_3$, as well as $K_2=s_2+s_3$. We argue that, since $K_1$ and $K_2$ differ by $s_1$, the eavesdropper would need to know precisely the computations that are being performed privately by each of the involved parties, which is conveniently masked by the use of ZeroC-Ice to achieve decryption with the OTP. On the other hand, in the case of a dishonest attacker, any alteration or substitution of the random numbers being transferred can potentially result in a different key for $U_1$ and $U_2$, thus making it impossible to decrypt the original message, indicating a potential unauthorized interception.

We examine our protocol along the lines of [8,23].

5.1. Privacy, Computation, and Communication Costs

As stated by Patel et al. [8], the protocol must demonstrate the following characteristics: privacy, costs related to communication, and computation. As for privacy, we have noted that the transmitted data consist of random numbers and partial sums. There is nothing different from that which flows sequentially during the protocol. Therefore, it is necessary for any attacker, regardless of their level of honesty, to have prior knowledge of the protocol being used. This knowledge, even if the middleware conceals it, would still require the attacker to impersonate the parties involved in the connection. A side-channel attack could be avoided by adequate formatting of the transmitted data. Only sums are needed for computational aspects, so we neglect this overload. A technique known as RJID (Random Code Injection to Mask Power-Analysis-Based Side-Channel Attacks) can protect parties from the exposure of simple and differential power analysis; see [24]. Finally, as mentioned above, communication costs are approximately equal to 70% of a typical three-party sum, as in [14].

5.2. Error Correction and Privacy Amplification

It is known that IoT devices can calculate hash functions, which are used to improve security by integrating them into the KeyGen protocol. However, the specific functions they can compute depend on the device’s processing power, memory, and energy constraints. They typically have limited resources compared to more powerful devices such as computers and servers. For this reason, one of the commonly used approaches to improve security in the IoT setting is the use of hash functions. Among them, BLAKE2 appears to be a good choice since it has versions optimized for 64-bit architectures (BLAKE2b) and optimized for 8- to 32-bit platforms (BLAKE2s) [25]. With this at hand, one possible procedure for error correction and privacy amplification that can be applied to ensure that the OTP key obtained by the SMP-OTP4IOT procedure is as follows (Algorithm 2):

Algorithm 2 KeyGen Security Check: Error Correction and Privacy Amplification

Require:  SMP-OTP4IOT derived Key $K_1$ for user $U_1$ and $s_1+K_2$ for user $U_2$ & agreed hash function h. Ensure:  $K_1=s_1+K_2$   Initialization:   $U_1$ generates a random position $b\in \{1,2,\cdots n\}$ such that $K_1=[k_1,k_2,\cdots k_{b-1}]\left|\right|[k_b,k_{b+1},\cdots k_n]$, with $n=|K_1|$.   Procedure:   $U_2$ computes $h_b=h(s_2+K_2[b,b+1,\cdots n])$ and sends it to $U_1$   $U_1$ verifies if $h\left([k_b,k_{b+1},\cdots k_n]\right)=h_b$. If so, return True, otherwise return False.

Algorithm 2 enables the user $U_1$ to verify that $U_2$ has the same OTP key, which can be used by $U_2$ in the same way. It should be noted that this concept is not novel and has been applied in a different context, such as in IoT with a quantum security layer, as illustrated in [26]. Observe also that the final steps in the KeyGen security check (Algorithm 2) might seem unnecessary since comparing the hash of the entire key should suffice, which is the case. However, selecting a random subset based on position b introduces a variable workload to the processor each time the procedure is executed, making it easier to prevent a side-channel attack by monitoring processor energy consumption, as in [27].

The multiparty protocol outlined thus far enables user $U_1$ to collaboratively generate and share a key with user $U_2$, utilizing the dummy server $U_3$ as a third party. This ensures the privacy of the inputs, which, in our scenario, are the private registers of the data involved in the computation. It is reasonable to assume that these inputs reside on different devices or architectures. To further bolster security in this context, a (2,3) secret-sharing scheme, as described in [28] or [29], can be considered. This scheme can be integrated into our algorithm at its conclusion, thereby eliminating the necessity for $U_1$ to send $s_1$ to $U_2$ in plaintext. This makes our approach particularly well suited for IoT devices as it mitigates the risk of data breaches by ensuring that no single device possesses sufficient information to compromise the entire system.

5.3. Abstract Requirements for Secure Multiparty Computation

We examine the properties of validity, agreement, termination, and privacy to postulate the security of our protocol, as depicted in [23], Definition 1.0. Since the key is produced employing (true) random numbers obtained individually by each party $P_i$, $i=1,2,3$. Individual contributions to the key are never transmitted, and individual inputs remain secret to other processes (apart from the shares given away). Malicious processes cannot prevent the computation from taking place or influence the computation in favorable ways (paragraph adapted from [23]). Therefore, validity is ensured in the sense that the final result is obtained with at least all the correct inputs in the chain of computation as the party currently working will utilize its data and the value received from the previous party to perform the calculation, which can only be achieved if accurate values are supplied. In contrast, agreement is achieved directly during the first half of the protocol, even in the presence of a dishonest attacker, since replacing randoms with other numbers indistinguishable from random will produce the same key agreement. Therefore, only in the second half of the procedure is it possible that the distribution of $s_1$ and $s_2$ to $P_2$ and $P_1$, respectively, if intercepted by a dishonest party, will produce a discrepancy in the OTP key K calculated by $P_1$ and derived by $P_2$, see Figure 2, with the result that, in this case, the message will not be recovered. This can be avoided using Algorithm 2, the KeyGen security check, as depicted above.

Finally, termination and privacy are inherent in the process. Termination means that every correct process eventually computes the result intended by the protocol, and privacy means that the specific inputs of the individual parties are never transmitted, calculated, or potentially revealed.

6. Discussion

Our developed system model exploits the environmental noise and physical phenomena IoT sensors detect. This strategy differs from approaches that depend on deterministic hardware or data from human interactions, providing the benefit of smooth integration with current IoT set-ups, thus lowering expenses and simplifying operations. Moreover, while the natural unpredictability of the environmental sources our method employs might result in variations in the quality of randomness, it still serves as a viable option for extensive IoT deployments because of its affordability and straightforward incorporation.

From a security standpoint, our proposal utilizes a blend of secure multiparty computation (SMPC) and one-time pads to boost cryptographic security, eliminating the need for intricate key agreement protocols. This proves especially beneficial in a distributed IoT setting, where handling key distribution can be problematic and insecure. Compared to methods dependent on conventional cryptographic protocols or sophisticated approaches like quantum key distribution (QKD), which may provide greater security but often sacrifice scalability and incur higher costs, our strategy aims to balance security and usability. It offers a scalable and sturdy framework that effectively manages cyber and physical threats, making it appropriate for the varied and frequently adverse environments in which IoT devices function.

The SMP-OTF4IOT protocol is introduced and implemented using ZeroC-Ice. The proposed procedure establishes a common key between IoT devices for secure communication. Two primary parties ($P_1$ and $P_2$) and a dummy server ($P_3$) sequentially agree on a key K using true random numbers and a modified (but standard) multiparty security sum procedure, which is applied for encrypted communication with a single pad.

The main contributions of this research include the innovative use of a dummy third party ($P_3$), whose role is crucial to facilitating the establishment of the key but does not have access to the shared encrypted message. This design enhances the security framework by reducing the number of entities accessing sensitive information, minimizing the potential for unauthorized data interception. The protocol exhibits a reduction in communication of a factor of approximately 30%.

Furthermore, implementing our protocol in ZeroC-Ice offers significant advantages in connecting devices across different platforms and architectures with reduced complexity. This versatility is essential for the widespread adoption of secure communication protocols within heterogeneous IoT environments.

A notable benefit of our approach is the marked efficiency in message transmission, where multiple parameters can be included in a single function call, thereby reducing bandwidth requirements and enhancing communication efficiency. The protocol exhibits a reduction in communication overhead of approximately 30%, a significant improvement that addresses one of the critical challenges in IoT environments: bandwidth conservation.

In terms of security, although a formal security analysis of the protocol is deferred to a forthcoming article, we focus on its inherent security properties as implemented. Our protocol is evaluated using the Dolev–Yao threat model against semi-honest or dishonest adversaries. In the semi-honest scenario, the random numbers and their sums transmitted make it challenging for an adversary to deduce the key without knowledge of the exact computations performed by each party. For a dishonest attacker, any alteration in the transmitted random numbers could result in a different key, potentially flagging an interception attempt simply because the encrypted text will not be recovered.

This research also addresses potential threats, such as side-channel attacks, which are mitigated through techniques such as random code injection, appropriate data formatting, and dynamic role changes. These measures ensure that robust defense mechanisms are in place and adaptable for peer-to-peer communication between multiple IoT agents.

Lastly, the communication cost of our protocol is estimated at 70% of the usual three-party sum, significantly reducing overhead and contributing to the system’s overall efficiency. By addressing these specific security concerns and efficiency challenges, the SMP-OTF4IOT protocol advances the field of IoT security. It sets a new standard for implementing secure multiparty computation protocols in real-world applications.

In terms of future work, we plan to propose a formal analysis of the protocol using tools such as Tamarin Prover or Proverif, as well as explore the scalability of the protocol to federated n-party key agreement and encryption to provide a more comprehensive understanding of the security properties of the protocol and highlight potential advantages or disadvantages, particularly in the IoT domain.