A Network Performance Analysis of MQTT Security Protocols with Constrained Hardware in the Dark Net for DMS

Abstract

In the context of the internet of things, and particularly within distributed measurement systems that are subject to high privacy risks, it is essential to emphasize the need for increasingly effective privacy protections. The idea presented in this work involves managing critical traffic through an architectural proposal aimed at solving the problem of communications between nodes by optimizing both the confidentiality to be guaranteed to the payload and the transmission speed. Specifically, data such as a typical sensor on/off signal could be sent via a standard encrypted channel, while a sensitive aggregate could be transmitted through a dedicated private channel. Additionally, this work emphasizes the critical importance of optimizing message sizes to 5 k-bytes (small payload messages) for transmission over the reserve channel, enhancing both privacy and system responsiveness, a mandatory requirement in distributed measurement systems. By focusing on small, encrypted payloads, the study facilitates secure, timely updates and summaries of network conditions, maintaining the integrity and privacy of communications in even the most challenging and privacy-sensitive environments. This study provides a comprehensive performance analysis of IoT networks using Dark Net technologies and MQTT protocols, with a focus on privacy and anonymity. It highlights the trade-offs between enhanced security and performance, noting increased latency, reduced bandwidth, and network instability when using TOR, particularly with cipher suites like AES256-GCM-SHA384 and DHE-RSA-CHACHA20-POLY1305. The research emphasizes the need for further exploration of alternative protocols like LWM2M in secure IoT environments and calls for optimization to balance privacy with performance in Dark-Net-based IoT deployments.

1. Introduction

The proliferation of internet of things (IoT) devices highlights the crucial importance of protecting sensitive information. These devices primarily collect measurements, effectively functioning as modern distributed measurement systems (DMSs), employed in diverse sectors such as wellness, home and industrial automation, education, power generation, smart agriculture, and safety applications. According to Check Point Research, IoT devices have faced a surge in cyber attacks this year. Early in 2023, the number of weekly attacks per organization rose by 41% over the same period the year before, with the education and research sectors experiencing the greatest increase in attack frequency. On average, organizations experienced nearly 60 attacks per week targeting IoT devices, marking a significant rise from 2022 and more than triple the attacks recorded two years ago.

In the realm of IoT communication, developers have access to a variety of protocols for designing and deploying bidirectional communication channels, including message queuing telemetry transport (MQTT), hypertext transfer protocol (HTTP), constrained application protocol (CoAP), and WebSockets. The choice of protocol depends on hardware constraints and specific application requirements. This study focuses on MQTT due to its lightweight nature and publish-subscribe model, which aligns well with many IoT communication patterns, particularly in resource-constrained environments. However, we acknowledge that MQTT, like any protocol, has its limitations and may not be the optimal choice for all IoT scenarios.

The surge in cyberattacks can be largely attributed to the widespread adoption of internet-connected IoT devices, especially those used in home automation systems and smart building technologies. Additional significant factors include users’ limited understanding of cybersecurity risks, the race for a first-mover advantage in the market, the swift expansion of connected devices, and constrained security investments due to slim profit margins. Various techniques are employed to maintain service quality and ensure safety, but these often come at the cost of reduced network efficiency. This reduction can lead to delays in measurement data transmission, potentially compromising evaluation accuracy and introducing vulnerabilities or system failures. This study explores a security-centric virtual local area network (VLAN) strategy and the limitations of IoT hardware, given the varied landscape of IoT devices and their connectivity. The research implements local MQTT brokers and employs transport layer security (TLS) tunnels for sensor data at the local level. A secure sockets layer (SSL) tunnel is utilized to transmit TLS-encrypted information to a centralized cloud broker. The findings are extrapolated from an analysis of a worst-case scenario, providing broadly applicable insights.

This focused attention stems from multiple factors. The rapid proliferation of internet-connected IoT devices enables remote control capabilities. The tight economic margins in the home automation sector restrict investments in security measures. The importance of swift market entry drives companies to compete for early adopter advantages. Additionally, limited cybersecurity knowledge among end-users often leads to cost considerations taking precedence over security precautions.

When considering MQTT for IoT deployments, scalability becomes a crucial factor. Two key considerations are: (1) whether MQTT is the right protocol for the scale of the deployment, and (2) what infrastructure and network capabilities are necessary to handle increased traffic over MQTT. While MQTT is widely used and suitable for many IoT applications, alternatives like lightweight machine-to-machine (LWM2M) may be more appropriate for certain large-scale, long-term enterprise deployments.

To address these security concerns while maintaining compatibility with MQTT brokers, we have tested and identified secure open secure sockets layer (OpenSSL) cipher suites. These suites, listed in

Table 1. OpenSSL Cipher Suites for MQTT Testbeds.

TLS Version 1.2	TLS Version 1.3
ECDHE_ECDSA_AES128_GCM_SHA256	TLS-AES-128-GCM-SHA256
ECDHE_RSA_AES128_GCM_SHA256	TLS-AES-256-GCM-SHA384
ECDHE_ECDSA_AES256_GCM_SHA384	TLS-CHACHA20-POLY1305-SHA256
ECDHE_RSA_AES256_GCM_SHA384	-
ECDHE_ECDSA_CHACHA20_POLY1305	-
ECDHE_RSA_CHACHA20_POLY1305	-
DHE_RSA_AES128_GCM_SHA256	-
DHE_RSA_AES256_GCM_SHA384	-

, are compatible with MQTT brokers and are recommended by the Agency for Digital Italy (AGID) guide for security protocols and cipher suites. Our analysis focuses on these cipher suites to ensure a balance between security and performance in IoT communications.

This work aims to perform these analyses in the onion router (TOR) environment. We want to verify how much the loss of network performance, typical of this technology, can affect the choice of use, given the undoubted advantage in terms of privacy and ease of access guaranteed by the TOR network despite the classic traffic-blocking mechanisms of the perimeter companies unless the perimeter firewall filters TOR traffic exactly. Our MQTT benchmarking architecture over the TOR network is depicted in Figure 1.

This study aims to provide a comprehensive performance analysis of MQTT security protocols in the context of Dark Net and IoT applications. While we do not propose a new theoretical model, our approach aligns with numerous respected works in the field that focus on empirical analysis and practical insights. Our goal is to explore the potential of Dark Net technologies in specific IoT scenarios where anonymity and privacy are crucial, providing valuable data on the trade-offs between security, privacy, and performance.

Our research approach differentiates itself from existing studies in several key aspects. Firstly, we innovatively combine MQTT with TOR network technology, offering enhanced anonymity and privacy crucial for sensitive IoT applications. Secondly, we provide a comprehensive performance analysis of this combined approach across different network types (IEEE 802.3ab [1] IEEE 802.11n/ac [2] and 3GPP-4G [3]), offering insights into its practicality in diverse real-world scenarios. Thirdly, we focus on the impact of various cipher suites and quality of service (QoS) levels in the context of Dark Net communications, an area that has received limited attention in existing MQTT security research. Lastly, our work emphasizes the optimization of small payload messages (up to 5 kbytes) for Dark Net transmissions, a specific consideration not typically addressed in conventional MQTT security studies. These distinctive features provide novel insights into securing IoT communications in highly privacy-sensitive environments, extending beyond the scope of traditional MQTT security protocols.

Through our analysis, we offer practical insights into the trade-offs between privacy, performance, and complexity in IoT deployments. These contributions aim to advance the field of IoT security and privacy, particularly in scenarios requiring high levels of anonymity.

While this study focuses primarily on the integration of MQTT with the TOR network, there are several areas that present opportunities for future research. A comparative analysis of MQTT with other IoT protocols in Dark Net environments, for instance, could provide valuable insights into the relative strengths and weaknesses of different approaches. Additionally, our current work introduces increased latency due to TOR routing, presenting a trade-off between enhanced privacy and system performance. Future studies could explore innovative methods to mitigate this latency while maintaining the privacy benefits. These aspects, while beyond the scope of the current paper, represent promising directions for extending this research and further advancing the field of secure IoT communications in privacy-sensitive contexts.

The remainder of this paper is organized as follows: Section 2 provides an overview of the TOR network and its relevance to IoT communications. Section 3 discusses legitimate use cases for Dark Net in IoT. Section 4 reviews related works in the field of MQTT security and Dark Net applications. Section 5 presents our proposed architecture and its deployment. Section 6 details our throughput assessment methodology and benchmarking approach. Section 7 presents and analyzes our experimental results. Section 8 discusses the implications of our findings and compares our approach with existing methods. Finally, Section 9 concludes the paper and outlines directions for future research.

2. The Onion Router Network

TOR is a network of virtual tunnels that enhances online privacy and security by routing traffic through three randomly selected servers, known as relays. It aims to prevent websites from tracking user locations and protect against local traffic observation. TOR employs various encryption keys for data privacy and authentication. The first relay in a TOR circuit, the “entry guard”, remains constant for 2–3 months to protect against anonymity attacks. TOR Browser utilizes the TOR network to safeguard privacy and anonymity, preventing ISPs and local observers from tracking online activities.

TOR’s operation involves thousands of nodes worldwide, managed by volunteers, acting as intermediaries for internet traffic. Traffic is routed through layers of encryption like an onion, ensuring user privacy by routing traffic through intermediary nodes that only know the previous and next node in the chain. Exiting the network occurs through an exit node, which communicates directly with the destination website. End-to-end encryption protects user privacy, allowing only the exit node to read data sent to the destination site. TOR maintains user anonymity by routing traffic through intermediary nodes, making it difficult for observers to identify the traffic’s source. However, traffic speed may be slower than conventional internet connections due to redirection through multiple nodes. TOR’s association with illegal activities may also lead to authorities’ surveillance.

The TOR network is a solution for anonymizing internet communications. It uses onion routing, where encrypted communications travel through a network of relay nodes. Each node decrypts one layer of the data before sending it along to the subsequent node in the sequence. The TOR network includes three types of nodes: entry nodes (guard nodes), relay nodes, and exit nodes. Entry nodes encrypt user traffic and route it through the TOR network, with each TOR user randomly selecting an entry node and remaining with it for a period to reduce the chances of traffic-related attacks. Relay nodes are intermediary nodes in the routing chain between the entry and exit nodes, receiving encrypted traffic from the entry one and routing it to the next without knowing its origin or final destination. Exit Nodes receive encrypted traffic from other TOR nodes and send it to the final recipient on the internet, with exit nodes being the last nodes in the routing chain. The TOR network enhances anonymity and privacy by obscuring the complete route of data transmission. It limits each relay’s information about the overall path, complicating attempts by observers—such as governments, internet service providers, and hackers—to trace the traffic’s origin or destination. However, the TOR network has limitations, such as slower traffic speed due to redirection through numerous nodes and potential surveillance by authorities due to its association with illegal activities.

The TOR network’s operation revolves around the onion relay, utilizing advanced encryption techniques to route traffic through intermediary nodes while preserving user anonymity. The process involves circuit creation, layered encryption, traffic routing, decryption at the exit node, and data flow response. This intricate system safeguards user privacy by hindering external monitoring and analysis of online activities, thanks to layered encryption and routing through intermediary nodes.

TOR network traffic slowdown can result from several technical factors within the open systems interconnection (OSI) model. These factors include physical connectivity issues, congestion, latency, routing delays, transport protocol delays, session negotiation delays, encryption and decryption issues, and application performance issues. Slowdowns can be attributed to combining these factors at different OSI layers. The inherent nature of TOR, involving multiple intermediary nodes and encryption layers, can introduce delays compared to direct internet connections.

Using TOR with MQTT can add anonymity and security to your communications. Here is how TOR can help protect MQTT secure connections from attacks:

• Anonymity: TOR routes your MQTT traffic through a network of volunteer-operated servers, making it difficult for adversaries to trace the origin of your MQTT messages. This anonymity can be beneficial in scenarios where you want to protect the identity of MQTT clients or servers.
• Traffic Encryption: MQTT itself supports encryption through TLS. When combined with TOR, your MQTT traffic is encrypted by TLS as it travels through the TOR network. This double-layered encryption enhances the security of your MQTT communications.
• Bypassing Network Restrictions: Accessing MQTT brokers directly may be challenging in some environments, such as restrictive networks or regions with censorship. TOR can help bypass these restrictions by allowing you to access MQTT brokers through its network, even in environments where direct access is blocked.
• Protecting Against Network Analysis: TOR’s onion routing mechanism ensures that your MQTT traffic is routed through multiple relays, obscuring the connection between the sender and the receiver. This makes it harder for adversaries to analyze traffic and gain insights into your MQTT communication patterns.

However, it is essential to consider some limitations and challenges when using TOR with MQTT:

• Latency: TOR introduces additional latency due to the extra hops your MQTT messages traverse through the TOR network. While this latency might not be significant for many applications, it could impact real-time or latency-sensitive MQTT communications.
• Reliability: TOR’s reliability can vary based on factors such as network congestion and the availability of TOR relays. While TOR aims to provide robust anonymity and security, occasional network disruptions or slowdowns may occur.
• Configuration Complexity: Configuring MQTT clients or brokers to work with TOR can be more complex than traditional network configurations. You may need to adjust network settings and ensure compatibility between TOR and your MQTT implementation.

In summary, while TOR can enhance the anonymity and security of MQTT communications, it is essential to weigh the benefits against potential challenges and consider whether TOR aligns with your specific use case and security requirements.

3. Dark Net and IoT Integration: Use Cases, Legal Considerations, and Ethical Frameworks

Recent research has highlighted the importance of integrating technologies like the onion router (TOR) into IoT systems, especially for applications requiring high levels of privacy. In IoT, this is particularly relevant in fields such as healthcare and industrial automation, where sensitive data is transmitted.

Singh et al. [4] emphasize the vulnerability of IoT devices to cyberattacks due to the lack of encryption in many communication protocols. They propose that combining IoT with TOR can enhance the security of personal and industrial data by anonymizing communications, thereby preventing surveillance and data breaches in critical environments like healthcare and smart cities.

In the context of IoT, one significant application is in the field of wearable health devices. As noted by Alharbi et al. [5], the anonymity provided by networks like TOR can be crucial for protecting sensitive medical data transmitted by IoT devices. This is particularly relevant for wearable health applications, where the privacy of personal health data is of utmost importance.

Jha et al. [6] explore how blockchain technology can be combined with TOR to improve security in IoT networks. They suggest that blockchain-based access control can ensure both data integrity and privacy, which is crucial for industries managing large amounts of sensitive data, such as energy and manufacturing.

In the industrial IoT (IIoT) domain, secure communication protocols such as MQTT, when used in conjunction with TOR, have been recognized as effective in protecting critical infrastructure. Although TOR can introduce latency due to its layered encryption, Dingledine et al. [7] argue that the privacy benefits outweigh the performance drawbacks, especially in sensitive sectors like manufacturing and energy.

From a legal perspective, the use of TOR in IoT must comply with regulations such as GDPR, which govern the handling of personal data. Ziegeldorf et al. [8] highlight the challenges of ensuring compliance with these frameworks when using privacy-enhancing technologies, particularly concerning the processing of metadata and device interactions.

Ethically, while TOR offers strong privacy protections, it also presents risks of misuse. Ling et al. [9] discuss how the anonymity provided by TOR can be exploited for malicious purposes, but they emphasize that with proper legal frameworks and oversight, the advantages for protecting privacy-sensitive IoT applications outweigh these risks.

4. Related Works

Several recent studies have followed a similar structure and methodology, focusing on performance analysis in IoT and network contexts. For instance, Banno et al. [10] evaluated the performance of MQTT v5.0 brokers using the MQTTLoader tool, offering insights into the broker’s efficiency under high load scenarios. Similarly, Gheorghe-Pop et al. [11] developed a benchmarking methodology for MQTT brokers, providing stress test data to compare different implementations. Mishra et al. [12] conducted a comparative analysis of performance measurements by stress-testing MQTT brokers, while Longo et al. [13] introduced the BORDER framework to assess the scalability and fault tolerance of distributed MQTT systems. Additionally, Gentile et al. [14] presented an analysis of security protocols for distributed measurement systems (DMS) based on IoT, focusing on performance with constrained hardware and open-source infrastructures. These studies, like our own, focus on providing empirical data and practical insights, demonstrating the effectiveness of MQTT in various IoT settings.

In the context of large-scale IoT deployments, it is worth comparing MQTT with other protocols such as lightweight machine-to-machine (LWM2M). While MQTT excels in quickly launching IoT projects with minimal effort, LWM2M offers features more suited for long-term universal infrastructure. LWM2M provides superior device management tools, including connection monitoring, firmware updates, and remote actions on devices. For enterprises managing large numbers of devices sending substantial volumes of data to a central platform, LWM2M might be the preferable choice. However, MQTT’s widespread adoption and broader support make it more than adequate for most IoT deployments.

Ford et al. [15] conducted a performance assessment of MQTT on Raspberry Pi, analyzing throughput and data transfer times across different devices and evaluating the impact of Denial of Service (DoS) attacks on various brokers. This research extends the findings of Hmissi et al. [16], who investigated MQTT protocols in a mist computing environment and assessed service quality metrics including power usage and response times. Khan et al. [17] further explored the security requirements and threats in IoT, noting the significant impact of DoS attacks on QoS parameters.

Mishra et al. [12] examined MQTT broker behavior under high-load conditions, revealing Mosquito’s superiority across multiple performance indicators. Tripathi et al. [18] and Pawar et al. [19] further investigated MQTT brokers, focusing on node clustering and comprehensive monitoring through dynamic dashboards that provide real-time statistics for cluster nodes and connections.

Comparative studies have highlighted MQTT’s performance advantages in certain scenarios. For example, Bansal and Priya [20] compared MQTT with CoAP, demonstrating that MQTT performs better in real-time data exchange scenarios due to its lower overhead. Similarly, Govindan and Azad [21] found that MQTT outperformed HTTP in terms of bandwidth usage and response time in IoT applications. However, it is important to note that these advantages are context-dependent and may not apply uniformly across all IoT use cases.

In terms of protocol comparison, Al Enany [22] provided an analysis of MQTT against other IoT protocols, highlighting its reliability in high-traffic networks but also pointing out limitations like higher latency and bandwidth consumption. Mishra and Kertesz [23] extended this by offering a survey of MQTT’s use in machine-to-machine and IoT systems, comparing it with other protocols.

Spohn [24] examined scalability challenges within MQTT, identifying potential bottlenecks in the publish/subscribe model and suggesting strategies such as clustering and broker federation to enhance reliability. Shuichi et al. [25] proposed a distributed broker architecture using a ring topology for reliable, low-latency communication, particularly suitable for real-time services in smart cities. Kawaguchi et al. [26] introduced an edge-based architecture specifically designed for geographical IoT applications, which reduces latency and improves system availability through hierarchical topics and broker clusters.

Security remains a critical focus. Azzedin et al. [27] proposed a secure data distribution architecture using MQTT, incorporating discovery and authentication services to enhance scalability and security, while Doshi et al. [28] introduced a Redis-based distributed broker architecture that improves scalability and fault tolerance through load balancing and shared memory systems.

Network performance in distributed systems is emphasized by Flammini et al. [29], who discussed the potential of low-power wide-area networks for large-scale systems. Along the same lines, the study by Kotak et al. [30] performs a cross-examination of various MQTT brokers, with particular emphasis on their potential security weaknesses, such as susceptibility to denial-of-service attacks and reconnaissance vulnerabilities. Their study identifies the least vulnerable brokers for secure communication in IoT environments, particularly smart cities. Opačin [31] explored MQTT integration into industrial control systems, demonstrating its applicability across various deployment scenarios.

To address security vulnerabilities, Hadded et al. [32] presented a platform for evaluating the impact of cybersecurity attacks on MQTT using a security information and event management system, highlighting the need for improved detection mechanisms against DoS attacks. Longo et al. [13] introduced BORDER, a benchmarking framework for distributed MQTT brokers, offering insights into the efficiency of clustering versus bridging approaches in resource-constrained environments. Further exploration into DMS security in IoT environments is presented by Gentile [33], suggesting a VLAN approach using MQTT, TLS, and SSL, with a similar approach to work [34]. This is validated by considerations of Fedullo’s work [35] on the VLAN approach in DMS that provides an in-depth analysis of time-sensitive networks (TSN), highlighting their potential use in intelligent and distributed industrial measurement systems. It discusses how TSN networks can ensure deterministic and reliable communications in industrial environments, with a special focus on synchronization, latency, and quality of service. The review also explores the challenges and requirements for implementing TSN networks in these contexts. Tripathi et al. [18], Pawar et al. [19], and Pawar [36] emphasized the significance of QoS in critical applications, showcasing MQTT’s adaptability in ensuring secure and efficient data transmission across diverse IoT domains.

Koziolek et al. [37] conducted a comparative analysis of distributed brokers, revealing Erlang MQTT Broker’s superior performance in cluster-based tests, while other studies [38] explored MQTT’s security, addressing emerging vulnerabilities and defense mechanisms.

Additionally, related network security topics are explored by Snader and Borisov [39], who proposed an opportunistic bandwidth measurement algorithm to improve TOR network performance, and Jansen and Hopper [40], who introduced the Sniper attack, a method for executing DoS attacks on TOR by exploiting legitimate protocol messages.

Dolliver’s research [41] aimed to gauge activity levels on Silk Road 2.0, while Manolache et al. [42] introduced VeriDark, a tool for authorship verification in cybercrime prevention. Abu et al. [43,44,45,46,47] explored the integration of machine learning within blockchain technology, enhancing security and performance in industrial applications. The research conducted by Alharbi et al. [5] examined the underlying network topology of the TOR dark web, uncovering parallels with the bow-tie configuration observed in the conventional internet.

Finally, additional research highlights the importance of conducting targeted studies to optimize resource utilization in IoT environments, as noted by [48], and examines the emerging vulnerabilities and defenses against MQTT attacks, as seen in the work of [38].

To comprehensively compare our approach with existing state-of-the-art methods, we have conducted a detailed analysis considering key aspects of IoT security and performance. This comparison, presented in the Section 8, evaluates our method against five recent and relevant approaches in secure IoT communications, MQTT protocols, and standard MQTT implementations. The analysis covers privacy/anonymity, security, latency, throughput, scalability, implementation complexity, IoT compatibility, attack resistance, and energy efficiency, providing a thorough context for our contribution to the field.

5. Proposal Architecture and Its Deployment

Our choice of MQTT for this study is based on its suitability for IoT applications requiring efficient, lightweight communication. MQTT’s publish-subscribe model aligns well with many IoT communication patterns, and its low overhead is beneficial in resource-constrained environments often encountered in IoT deployments. However, we recognize that the optimal protocol choice can vary depending on specific application requirements and hardware constraints. In the context of this study, we focus on evaluating MQTT’s performance specifically in Dark Net communications for IoT applications where privacy and anonymity are crucial considerations.

Figure 2 provides a high-level overview of our proposed architecture, integrating MQTT with the TOR network for secure IoT communications. This diagram illustrates the flow of data from IoT devices through MQTT clients, the TOR network, and finally to the MQTT broker configured as a TOR hidden service. The following sections will elaborate on each component of this architecture, detailing our objectives, design considerations, implementation process, and the challenges we addressed to create a secure, efficient, and scalable solution for IoT communications in privacy-sensitive environments.

5.1. Objectives and Design Considerations

The primary objectives of our proposed architecture are:

• To enhance privacy and anonymity in IoT communications using Dark Net technologies.
• To maintain efficient and reliable data transmission despite the additional security layers.
• To ensure compatibility with existing IoT infrastructures and protocols.
• To provide a scalable solution that can be applied in various IoT scenarios.

The idea aims to extend the results of a worst-case scenario for wide practical applicability by combining a hardware limitation solution with a security-focused VLAN technique.

The research assesses how well various OpenSSL encryption protocols integrate with the Mosquitto server, focusing on key performance indicators across different quality of service tiers. These metrics include overall efficiency ratio, cumulative processing time, mean execution duration, message transmission interval, average data throughput, and aggregate bandwidth consumption for each cryptographic algorithm set.

The study aims to pinpoint encryption methods that optimize both information protection and efficient data transfer, particularly for MQTT systems operating in areas with limited resources, such as suburban or rural environments. This approach seeks to enhance adaptability across diverse MQTT network configurations.

To improve IoT device interoperability and contribute to a secure communication architecture, the project also investigates the implementation of open firmware on restricted devices. Together, these goals, which are examined in a TOR environment, seek to improve safe and effective IoT communication protocols while tackling hardware limitations and various network settings, taking into account the effect of the normal TOR network performance loss.

5.2. Detailed Architecture Description

Our architecture integrates MQTT with the TOR network to provide enhanced privacy and anonymity. The key components of our system are:

• MQTT Clients: IoT devices or applications that publish or subscribe to MQTT topics.
• TOR Network: Provides anonymity by routing traffic through multiple relays.
• MQTT Broker: Handles message routing between publishers and subscribers, now accessible as a TOR hidden service.
• VLANs: Used to segment and secure local network traffic before it enters the TOR network.

The communication flow in our architecture is as follows:

• MQTT clients connect to the TOR network using a TOR proxy.
• The MQTT broker is set up as a TOR hidden service.
• MQTT messages are encrypted and routed through the TOR network.
• The MQTT broker receives messages via its hidden service address.
• Messages are then distributed to appropriate subscribers, maintaining end-to-end encryption and anonymity.

The following architecture, which is based on free software, is integrated with the necessary parts and protocols according to the proposal.

TOR allows one to deploy onion services, accessible only through TOR, combining HTTPS security with the TOR browser’s privacy advantages. They offer numerous privacy and security benefits, shielding IP addresses and preventing impersonation. Traffic to onion services is encrypted from client to host, akin to robust SSL/HTTPS protection. Additionally, they bypass firewall restrictions by punching through NAT, eliminating the need for open ports. The protocol for onion services employs the TOR network to facilitate client introduction to the service and establish rendezvous points, ensuring anonymity and security. This involves the service setting up introduction points, publishing descriptors, and clients verifying onion address signatures. Finally, clients establish rendezvous points, allowing end-to-end encrypted communication between client and service, with the entire connection routed through a series of relays for location hiding.

5.3. Implementation Process

The implementation of our architecture involves the following key steps:

1.

Setting up the MQTT broker as a TOR hidden service.

2.

Configuring MQTT clients to connect through the TOR network.

3.

Implementing VLANs for local network segmentation.

4.

Configuring and optimizing the various cipher suites and QoS levels.

5.

Setting up monitoring and logging systems for performance analysis.

5.4. Challenges and Solutions

During the implementation, we encountered several challenges:

• Increased latency due to TOR routing: Mitigated by optimizing message sizes and implementing efficient QoS strategies.
• Compatibility issues between MQTT clients and TOR: Resolved by developing custom adapters and thoroughly testing various client configurations.
• Maintaining performance under varying network conditions: Addressed through adaptive QoS mechanisms and robust error handling.

5.5. Scalability Considerations

To ensure our architecture can scale effectively, we have:

• Implemented a distributed broker architecture to handle increased load.
• Designed the system to allow for easy addition of new IoT devices and MQTT clients.
• Incorporated load balancing mechanisms to distribute traffic across multiple TOR circuits.
• Developed monitoring tools to track system performance and identify bottlenecks.

The deployment adheres to the same concepts described in the previous work [14], particularly for VLAN usage as detailed in [49]. The extracted data from the campaigns are real, focusing on total ratio, total runtime, and message time metrics, and the installation spans both the clear web and the dark web.

Figure 3 illustrates our MQTT Benchmarking Architecture deployment, which includes the Raspberry Pi devices in which the encryption routines are implemented. Moreover, to measure the time intervals necessary for the benchmark estimation the synchronization procedure based on network time protocol (NTP) is also included in the architecture.

The tests are conducted on various channel technologies using a utility for the bandwidth and different loss probability measurements.

6. Throughput Assessment and Benchmarking Deploy

Our experimental setup consists of two Raspberry Pi 4 units, each equipped with 8 GB of memory. One unit functions as a performance-testing MQTT client, while the other operates as the MQTT server. We used the latest stable Raspberry OS “bookworm” 12.0 on raspberry nodes. Specific versions of tools are mosquitto and mosquitto_pub/mosquitto_sub 2.0.11, mqtt-benchmarker 0.2.0, mqttx 1.10.1, mqtt-cli 4.32.0, OpenSSL 3.0.14, and TOR 0.4.7.16 for testing. The network configurations tested include IEEE 802.3ab (1 Gbps Ethernet), IEEE 802.11n/ac (Wi-Fi), and 3GPP-4G (cellular) connections. All experiments were conducted using OpenSSL version 3.0.14 for encryption and TOR version 0.4.7.16 for anonymization. This setup allows us to evaluate our proposed MQTT over TOR approach across various network conditions and compare it with standard implementations.

Several factors must be taken into account to measure network throughput completely. It is necessary to determine which OpenSSL cipher suites are compatible with the MQTT server to prevent data encryption from impeding communication between brokers and IoT devices. The phases of the suggested measuring method are shown in Figure 4, which assesses throughput between any two network nodes. The OpenWRT router is synchronized with Italian time servers to ensure consistent device time sources. It acts as a local NTP server and an NTP client over an MQTT-BRIDGE link with certificates and login credentials.

For performance analysis, we used the Mosquitto-clients package, which allowed a more thorough evaluation compared to other tools (mqtt-benchmarker [50]; mqttx [51]; mqtt-cli [52]), and compared results of 1000 message communications varying QoS type, encryption algorithm, and TLS version, as shown in Figure 5 for 3GPP-4G, IEEE 802.3ab, and IEEE 802.11n/ac testbeds.

In the first run, we use a 5 k-byte payload, and after that, we send a 1 M-byte payload for each message. These metrics include the total ratio, which measures the number of messages sent compared to those received, the average runtime, the total runtime, and the message time metrics, which show the minimum, maximum, mean, and standard deviation of message transit times. We also evaluate total bandwidth (messages per second during benchmarking) and average bandwidth (messages per second). The investigation examines cryptographic methods, authorization protocols, and adherence to legal standards as key components of information protection. It also explores network response times, data transmission reliability, and accuracy of information transfer. The study underscores the importance of safeguarding sensitive information, particularly in critical sectors such as medical services, banking systems, and essential infrastructure surveillance.

Our study evaluates information accuracy, transmission reliability, and communication delays to ensure the fidelity and robustness of data collected from sensing devices. Data confidentiality must be emphasized, particularly in delicate industries like healthcare, finance, and vital infrastructure monitoring. To preserve data security, we go over encryption techniques, access limits, and adherence to data protection laws. Ensuring the implementation of these measures ensures the integrity and confidentiality of the gathered measurements.

7. Experimental Results

The use of the Dark Net in IoT contexts, particularly for applications like wearable health devices, presents a complex trade-off between enhanced privacy and potential performance limitations. As discussed by Jardine [53], while the Dark Net offers significant privacy benefits, it also introduces challenges in terms of standardization and performance. Our study aims to quantify these trade-offs, providing insights that can inform decision-making for IoT deployments in privacy-sensitive contexts. It is crucial to emphasize that the use of Dark Net technologies in IoT should be considered on a case-by-case basis, weighing the privacy benefits against potential drawbacks in performance and ease of use. Traditional secure networking protocols may be more appropriate for many IoT applications, particularly in smart home or industrial contexts. However, for scenarios where anonymity is critical, such as in certain medical or human rights applications, the benefits of Dark Net technologies may outweigh the drawbacks.

While the Dark Net offers enhanced privacy and anonymity, it is important to acknowledge the potential trade-offs in terms of performance and usability. As Dingledine et al. [7] noted, using TOR can introduce additional latency and potentially reduce throughput due to the multiple relay hops involved in routing traffic. These performance impacts must be carefully considered in the context of IoT devices, which often have limited computational resources and power constraints. Our study quantifies these trade-offs, providing empirical data on the performance implications of using Dark Net technologies for MQTT communications in IoT contexts. We observed that while there is a measurable impact on latency and throughput, the degree of this impact varies depending on the specific cipher suite and QoS level used. These trade-offs may be acceptable for applications where the privacy benefits outweigh the performance costs, such as in sensitive health monitoring scenarios. However, alternative security measures may be more appropriate for time-critical or high-bandwidth IoT applications. It is crucial for IoT system designers to carefully evaluate these trade-offs based on their specific use case, considering factors such as data sensitivity, required response times, and the potential consequences of privacy breaches. Our findings provide a foundation for making informed decisions in this complex landscape of security, privacy, and performance in IoT communications.

Our focus on MQTT in this study is justified by its widespread adoption and suitability for a wide range of IoT applications. However, we acknowledge that for certain large-scale enterprise deployments, especially those requiring advanced device management features, alternatives like LWM2M might be more appropriate. The choice between MQTT and other protocols depends on the specific requirements of the IoT deployment, including scale, management needs, and long-term infrastructure plans.

To assess the efficacy of our suggested measuring technique in an operational context, we created a specific test configuration, which is illustrated in Figure 3 and Figure 4.

The experimental configuration utilizes a pair of Raspberry Pi 4 units, each equipped with 8 GB of memory. In the MQTT Benchmarking framework illustrated in Figure 3, one unit (the white-cased model) functions as a performance-testing MQTT client, while the other (the exposed black board) operates as the MQTT server.

Figure 5 outlines the algorithm steps executed by these Raspberry Pis, using functions like “mqtt_pub_base-qosX-vY-tlsZ” to invoke tools such as mosquitto_pub/mosquitto_sub, mqtt-benchmarker, mqttx, and mqtt-cli for testing.

The algorithm, as shown in the flowchart of Figure 4, comprises four main parts: preparation of the benchmarking environment, initiation of remote MQTT over TLS instances on the broker with TLS dumps, execution of the client for data transmission, and summary of data collection at session conclusion.

During the message relay process, the “mqtt_pub_base-qos” routine captures sending and receiving statistics using the measurement utility. Simultaneously, it establishes a connection as a distant log monitor to access the Mosquitto event records stored on the broker system.

The process is divided into four primary stages: initial setup of the performance evaluation environment, remote activation of MQTT over TLS on the broker with TLS activity monitoring, client execution for data transmission, and final compilation of gathered information upon session completion. The mqtt_pub_base-qos routine establishes a link as a distant log observer to the broker’s Mosquitto event records. It employs a metric collection utility to record sending and receiving statistics throughout the message relay process. The client initiates the remote broker on the server via SSH commands, cycling through each supported encryption protocol in OpenSSL 1.x libraries. The server monitors a designated port (1866/TCP in this instance) for one encryption protocol at a time while the client creates connections and verifies server responsiveness.

It is interesting to see the statistical distribution of delays illustrated in Figure 6 using a boxplot representation.

The results presented in the figure exclude the IEEE 802.3ab channel, but similar trends were observed in the IEEE 802.11n/ac and 3GPP-4G configurations. In each boxplot, the 25th and 75th percentiles are represented visually by the box boundaries, the 5th and 95th percentiles by the whiskers, and the median is indicated by an ‘X’. Outlier values beyond these percentiles are included to augment the previously reported average values and show the range of delay variance. The ordinate axis is scaled to properly represent the boxplot’s general range while improving the visibility of outlier values. As seen in Figure 6, the majority of delay samples fall into a constant range, with a few studies above the 95th percentile in delay time and outliers offering insights into observed variances in average delay.

Figure 7 depicts the comparative bandwidth utilization between standard internet and TOR network communications using TLSv1.2 encryption protocols. The analysis covers all quality of service tiers on an IEEE 802.3ab connection, employing MQTT V3.11 with a constant payload of 1 Mb.

The figure reveals that in the case of the DHE-RSA-AES128-SHA cipher suite, the measured bandwidth percentage difference is the highest at around 13%, while in all other cases, a percentage difference of around 4% is measured. This graph helps us understand the overhead introduced into communication measured in terms of bandwidth loss.

We conducted another relevant analysis comparing the percentage difference in bandwidth between messages of 1 MB and 500 KB in size. This analysis helps us understand how message length affects bandwidth utilization. The results, as shown in Figure 8, indicate that doubling the message length results in a bandwidth reduction of approximately 6 percentage points.

This analysis helps us understand how the length of a message affects bandwidth. From the graph, it can be seen that doubling the length of the message results in a loss in terms of send width equal to 6 percentage points.

The mean data throughput observed during performance evaluation trials is illustrated in Figure 9 and Figure 10. These graphics contrast the efficiency of various TLSv1.2 encryption protocols across MQTT iterations 3.x and 5.0, utilizing IEEE 802.3ab network links. The data highlight performance discrepancies between the protocol versions, with newer features in MQTT 5.0 sometimes introducing additional overhead that can reduce bandwidth efficiency compared to MQTT 3.x. Actual performance also varies depending on how MQTT protocols are implemented by clients and brokers, with some implementations optimizing bandwidth use more effectively than others. For instance, while AES128-GCM-SHA256 in MQTT version 3.11 shows subpar performance, MQTT 5.0 generally exhibits improved performance metrics.

Figure 11 and Figure 12 illustrate trends in IEEE 802.11n/ac connections, while Figure 13 and Figure 14 depict average bandwidth usage over 3GPP-4G links, comparing TLSv1.2 cipher suites and MQTT versions 3.x and 5.0.

Notably, certain cipher suites, particularly those ranked lower in performance on the left side of Figure 13, show improved performance transitioning from MQTT 3.x to 5.0, as evident in Figure 14. Similar observations regarding performance enhancements with MQTT 5.0 can be seen in the results for both IEEE 802.11n/ac and 3GPP-4G connections, especially for cipher suites initially demonstrating poorer performance. Bandwidth performance is influenced by various network conditions such as latency, available bandwidth, and network congestion, which can significantly impact MQTT performance, particularly in 3GPP-4G environments.

The delay distribution for TLS v1.2 cipher suites at QoS0 level on a 3GPP-4G network with MQTT V3 is shown in Figure 15. The boxplot illustrates the latency distribution for various cipher suites over a 4G network. Notable variability is observed with suites like ECDHE-RSA-AES256-GCM-SHA384 and DHE-RSA-CHACHA20-POLY1305, which show larger boxes and longer whiskers, indicating a wider range of latency values. Outliers, particularly visible for these suites, suggest occasional extreme latency spikes. Conversely, suites such as AES128-SHA and ECDHE-ECDSA-AES128-SHA exhibit more stable performance with smaller boxes and fewer outliers, indicating more consistent latency. Overall, the cipher suite chosen significantly impacts the latency performance, with some suites being more prone to variability than others.

By comparison, the average bandwidth used for benchmarks with TLSv1.3 cipher suites and MQTT versions 3.x and 5.0 over IEEE 802.11n/ac connections is shown in Figure 16 and Figure 17.

Figure 18 and Figure 19 display the average bandwidth utilization during benchmarks using TLSv1.3 cipher suites and MQTT versions 3.x and 5.0 over 3GPP-4G connections. When transitioning from TLSv1.2 to TLSv1.3 cipher suites, changes in MQTT protocol versions do not significantly affect performance, contrasting with observations from TLSv1.2 suites.

Figure 20 and Figure 21 present the delay distribution for TLS v1.3 cipher suites at QoS0 level on 3GPP-4G links and MQTT V5.

The analysis of the boxplot in Figure 22 reveals that certain cipher suites, such as ECDHE-RSA-AES256-GCM-SHA384 and DHE-RSA-CHACHA20-POLY1305, show the highest variability in latency, suggesting significant fluctuations under certain network conditions, potentially due to encryption complexity or network congestion. In contrast, suites like AES128-SHA256 and ECDHE-ECDSA-AES128-SHA demonstrate more stable and consistent performance with fewer deviations in latency. The presence of outliers, particularly for more variable suites, indicates occasional instances of high latency, likely caused by external factors such as network interference or congestion. Overall, the choice of cipher suite has a noticeable impact on latency performance, with some suites exhibiting less predictable behavior, which may affect their suitability for certain applications.

8. Discussion

Implementing VLAN-based protection measures for IoT systems operating through TOR networks ensures strong information safeguarding and optimal operational efficiency. While customized data confidentiality techniques address the security requirements of sensitive situations, extensive examination and benchmarking of cipher suites and QoS levels yield insights for enhancing IoT installations.

When it comes to managing encrypted connections among various sensor networks, wireless solutions are important. They also present major advantages in cases where access is limited, such as rural or hilly places. Integrating routers as active network participants requires dedicated equipment and custom software configurations. This integration often involves protocols such as Zigbee, typically accessed through Raspberry Pi-based intermediary devices or Lora/Lorawan systems interfaced with 3GPP-4G/5G infrastructure.

Even with inexpensive devices, this firmware solution offers a safe basis for building internet of things networks. Our main goal is to find the best combinations (QoS, CipherSuite, TLS Version) to improve data transmission efficiency on limited devices. Performance tests carried out on Raspberry Pi 4s, and TP-LINK OpenWRT routers highlight the most effective algorithms and are compiled in

Table 2. Results: The table presents the bandwidth extremes (in messages per second) observed during testing, with QoS0 measurements serving as the reference point.

Communication Media	Cypher Suite	MQTT Version	TLS Version	WORST	BEST
IEEE 802.3ab	AES128-GCM-SHA256	3.11	1.2		21,124
IEEE 802.3ab	AES128-SHA	3.11	1.2	16,830
IEEE 802.3ab	DHE-RSA-AES128-SHA	5.0	1.2		21,018
IEEE 802.3ab	AES128-SHA	5.0	1.2	16,888
IEEE 802.3ab	TLS-CHACHA20-POLY1305-SHA256	3.11	1.3		21,145
IEEE 802.3ab	TLS-AES-128-GCM-SHA256	3.11	1.3	20,881
IEEE 802.3ab	TLS-AES-128-GCM-SHA256	5.0	1.3		20,896
IEEE 802.3ab	TLS-CHACHA20-POLY1305-SHA256	5.0	1.3	20,632
IEEE 802.11n/ac	ECDHE-RSA-AES128-SHA256	5.0	1.2		20,831
IEEE 802.11n/ac	DHE-RSA-CHACHA20-POLY1305	5.0	1.2	17,487
IEEE 802.11n/ac	ECDHE-ECDSA-AES128-GCM-SHA256	3.11	1.2		21,169
IEEE 802.11n/ac	DHE-RSA-CHACHA20-POLY1305	3.11	1.2	15,137
IEEE 802.11n/ac	TLS-CHACHA20-POLY1305-SHA256	5.0	1.3		20,619
IEEE 802.11n/ac	TLS-AES-128-GCM-SHA256	5.0	1.3	19,548
IEEE 802.11n/ac	TLS-AES-256-GCM-SHA384	3.11	1.3		20,803
IEEE 802.11n/ac	TLS-CHACHA20-POLY1305-SHA256	3.11	1.3	20,608
3GPP-4G	DHE-RSA-AES256-SHA	3.11	1.2		21,118
3GPP-4G	ECDHE-RSA-AES256-SHA384	3.11	1.2	12,751
3GPP-4G	ECDHE-ECDSA-AES128-SHA256	5.0	1.2		20,786
3GPP-4G	AES128-SHA	5.0	1.2	17,491
3GPP-4G	TLS-AES-128-GCM-SHA256	3.11	1.3		20,918
3GPP-4G	TLS-AES-256-GCM-SHA384	3.11	1.3	20,321
3GPP-4G	TLS-AES-128-GCM-SHA256	5.0	1.3		20,682
3GPP-4G	TLS-AES-256-GCM-SHA384	5.0	1.3	20,425

.

From our experiments, it’s evident that certain cipher suites perform notably better than others across different network types. For instance, on 1 Gb IEEE 802.3ab connections, ECDHE-RSA-CHACHA20-POLY1305 excels, whereas AES128-SHA with MQTT 5.0 and TLSv1.2 shows optimal performance on 3GPP-4G connections. Evaluating MQTT versions across 3GPP-4G connections reveals varying performance levels, particularly in less controllable communication environments provided by ICT providers.

Regarding our second objective, TLSv1.2 cipher suites demonstrate broad compatibility with current devices, whereas TLSv1.3 is natively supported by specific clients like mqttx and hive-mqtt-cli. The third objective emphasizes client capabilities: while mosquitto clients support TLSv1.2 and TLSv1.3 but lack WebSocket communication, mqttx and mqtt-cli offer comprehensive support for various cipher suites, TLS families, and MQTT versions.

This study underscores the significance of optimizing message sizes on the TOR network, particularly “small payload messages” up to 5 k-bytes, to enhance responsiveness for critical updates and periodic network condition summaries.

The advantages of our approach are particularly evident in high-sensitivity environments. Consider the following use cases:

• Healthcare IoT: In a scenario where wearable devices are monitoring patients with stigmatized conditions, our approach ensures that the data transmission remains not only encrypted but also anonymous. This prevents potential discrimination based on data interception or metadata analysis.
• Industrial IoT in Restrictive Regions: For multinational corporations operating in regions with strict government surveillance, our method allows for secure and anonymous communication between IoT devices and central servers, protecting sensitive industrial data from unauthorized access or monitoring.
• Smart City Applications: In smart city deployments where citizen privacy is a concern, our approach can be used for anonymous data collection, ensuring that individual data points cannot be traced back to specific households or individuals.

While our method introduces some latency due to the routing through the TOR network, the enhanced privacy and security make it an ideal choice for applications where data sensitivity outweighs the need for real-time communication.

The degraded performance of AES256-GCM-SHA384 and DHE-RSA-CHACHA20-POLY1305 can be attributed to several factors. For AES256-GCM-SHA384, the high computational overhead associated with 256-bit key encryption and SHA384 hashing increases the processing load, particularly on devices with limited hardware optimization. This suite also requires significant computational resources, which can result in increased latency, especially under conditions of high data load or multiple concurrent connections. Furthermore, strict TLS configurations aimed at enhancing security may also impact performance, compounded by potential inefficiencies in software or firmware implementations. Similarly, DHE-RSA-CHACHA20-POLY1305 suffers from significant overhead due to the Diffie-Hellman key exchange process, which adds complexity to the encryption procedure. Additionally, the CHACHA20 cipher, while effective, may not be fully optimized on all hardware platforms, contributing to slower performance. The integration of POLY1305 further complicates the encryption process, affecting speed. As with AES256-GCM-SHA384, network conditions and high workloads exacerbate the latency, indicating the need for optimization in both software implementation and configuration. Numerical tests have revealed significant findings. With an IEEE 802.3ab connection, the use of the dark web increases communication delay by 11% for QoS0, 12% for QoS1, and 13% for QoS2. This increase is likely due to the additional negotiations required to establish hidden connections in the TOR network. These results highlight the trade-offs between enhanced privacy and dark web-based IoT communications performance. Our methodology proves crucial for evaluating potential network throughput under specific privacy and QoS requirements. It enables a more accurate determination of sampling frequencies and characteristics for DMS nodes. This approach allows for the extension of DMS services to contemporary applications that demand high levels of privacy. The analysis shows that using the TOR Network for broker/customer MQTT communication offers significant privacy benefits, including IP address anonymization, enhanced security through multilevel encryption, and access to censored regions. However, it also introduces challenges such as higher latency, reduced bandwidth, less reliable connections, and increased complexity in setup and maintenance. While our study does not explicitly model all aspects of the peer-to-peer nature of the Dark Net, our results do reflect some of its implications, including the effects of decentralized routing, network resilience, and scalability challenges. These observations open up avenues for future research to more directly quantify and analyze these peer-to-peer characteristics in the context of IoT communications.

In this section, we compare the strengths and weaknesses of various approaches to privacy and security in IoT systems, including both our proposed method and several key works from the literature. The comparison focuses on qualitative aspects such as privacy, security, scalability, and ease of implementation without delving into specific performance metrics that require empirical validation.

The

Table 3. A qualitative comparison of various approaches.

Approach	Strengths	Weaknesses
Our Approach	High privacy and anonymity, high security, medium scalability for sensitive IoT applications	Medium implementation complexity, slightly higher latency compared to less secure solutions
Singh et al. [4]	High privacy and security, optimized for IoT environments	High implementation complexity, requires sophisticated infrastructure
Jha et al. [6]	High scalability, good integration with blockchain for security	Medium latency, lower throughput compared to other approaches
Ziegeldorf et al. [8]	Good security, easy implementation	Less robust privacy, reduced performance in high-latency environments
Ling et al. [9]	Easy to implement, good compatibility with existing systems	Limited privacy and security, lower resistance to attacks
Dingledine et al. [7]	High privacy and anonymity due to the use of TOR, excellent security	High latency, high implementation complexity

highlights the differences between our approach and other state-of-the-art methods.

Our method provides strong privacy and anonymity features, with high security and medium scalability for IoT applications that require sensitive data handling. However, this comes with moderate implementation complexity and slightly higher latency compared to approaches that prioritize performance over security. The works of Singh et al. [4] and Jha et al. [6] emphasize privacy and security, but they differ in terms of implementation complexity and throughput. Singh et al. focus on optimized security for IoT environments, which comes at the cost of high implementation complexity. Jha et al. integrate blockchain technology for enhanced security, offering high scalability but with medium latency and reduced throughput. Other works, such as Ziegeldorf et al. [8] and Ling et al. [9], present easier-to-implement solutions with good compatibility for existing systems, but they trade off some level of privacy and security. Finally, Dingledine et al. [7] offer an approach with excellent privacy and security through the use of TOR, though it introduces higher latency and greater implementation complexity due to the additional layers of anonymity. This comparative analysis provides a clear overview of the advantages and trade-offs associated with each approach, helping to contextualize our work within the broader landscape of IoT security and privacy solutions.

9. Conclusions

This study contributes to the growing body of literature on IoT and network protocols by providing a comprehensive performance analysis in the specific context of Dark Net technologies and MQTT applications. Our research offers valuable empirical insights into the practical implications of using these technologies in IoT applications, particularly in scenarios where privacy and anonymity are paramount.

We present a refined experimental methodology for evaluating dark web network performance in the context of distributed measurement systems based on IoT. This approach builds upon existing methods, adapting them to the unique challenges posed by Dark Net environments. Our methodology encompasses the analysis of throughput, quality of service, privacy, and security, allowing for a holistic assessment of the system’s capabilities and limitations. Our experimental results capture several key features of Dark Net communications, including increased latency due to multiple relay hops, bandwidth limitations from encryption and routing overhead, and the impact of network instability characteristic of TOR circuits. While we do not directly quantify anonymity, our performance measurements implicitly reflect the trade-offs associated with enhanced privacy in Dark Net communications.

While this study focuses on MQTT, future research could explore the performance and security implications of using other protocols like LWM2M in Dark Net environments. Such studies would provide valuable insights into the scalability and manageability of different protocols in secure, privacy-focused IoT deployments. Future work should investigate the scalability of MQTT and compare it with protocols like LWM2M in large-scale IoT deployments over Dark Net environments. This could include assessing the infrastructure requirements for handling increased traffic and evaluating the effectiveness of different protocols in managing large numbers of devices in secure, anonymized networks. In conclusion, our study provides empirical data and practical insights that can guide decision-making in IoT deployments where privacy and security are critical concerns. While TOR offers substantial anonymity and security benefits for MQTT broker communication, it also introduces performance, reliability, and complexity challenges. Future research should focus on optimizing these trade-offs, developing strategies to mitigate the identified limitations, and more explicitly investigating the peer-to-peer aspects of Dark Net communications in IoT contexts. Additionally, exploring alternative protocols and their performance in Dark Net environments will be crucial for advancing the field of secure and scalable IoT communication.