# Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases
## 1 Introduction
[7] evaluated MQTT over TLS using server nodes that host virtual machines (VMs). Within these VMs, they deployed MQTT entities: the broker, coordinating message exchange; the publisher, publishing messages to specific topics; and the subscriber, receiving messages from subscribed topics. Their objective was to measure resource consumption on different TLS cipher suites offering 128-bit security. Inspired by their study, our current work moves beyond virtualization to implement TLS-based MQTT communication and evaluate its performance on physical IoT hardware. Testing with real IoT devices is motivated by the recognition that simulation and analytical modeling are inherently limited in capturing real-world physical characteristics and network dynamics [8]. Recent works highlight that the deployment of experimental IoT setups using actual devices and real data traffic not only increases the realism of the testing environment but also enhances the credibility and repeatability of results, making it a widely accepted research practice to validate IoT protocols and systems [8; 9]. In particular, in our experimental setup, all the main MQTT entities i.e., the broker, the publisher, and the subscriber, are deployed on quad-core Cortex-A72 ARMv8 boards, specifically the Raspberry Pi 4\(B\) platform, as illustrated in Figure 1. The Raspberry Pi 4\(B\) is a lightweight, low-cost IoT platform whose processing capabilities have been shown to be representative of the hardware commonly used in real-world On-Board Units (OBUs) and Road-Side Units (RSUs) for V2X deployment. Indicatively, recent work by [PERSON] et al. [10] demonstrates that Raspberry Pi devices can effectively serve as the computational core for Cooperative-Intelligent Transport System (C-ITS) stations, validating their suitability for both prototyping and operational use in real vehicular environments. However, their constrained resources necessitate a careful examination of how TLS-enhanced protocols perform on them. Regarding TLS cipher suites, we employ Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) using curve 25519 for key exchange and the Edwards Digital Signature Algorithm _Ed25519_ for server-client authentication i.e., the TLS authentication mechanism over the MQTT protocol. For encryption, we use the symmetric ciphers AES_256_GCM and Chacha20_Poly1305, chosen for their strong security guarantees, performance efficiency, and quantum-resistant properties [11], laying the groundwork for future all-quantum-resistant MQTT deployment. Along these lines, we advocate that such an architecture can support V2X use cases such as road hazard alerting, platooning control, and secure dissemination of traffic information. Our objective is to address three main research questions: Feasibility of Secure MQTT (RQ 1): Can constrained IoT devices, such as Raspberry Pi 4\(B\) boards, running MQTT with QoS 1, effectively support TLS 1.3 security without compromising performance under realistic V2X message workloads? Resource--Payload Trade-Offs (RQ 2): How do different message packaging strategies (e.g., number and size of messages) and network interfaces (Ethernet and WiFi) affect resource requirements including CPU cycles, latency, energy consumption, and goodput during TLS-secured MQTT communication? Cipher Suite Performance (RQ 3): What are the real-world performance differences between ChaCha20_Poly1305 and AES_256_GCM on ARMv8-based IoT hardware, and which cipher is better suited for resource-constrained V2X and IoT environments in terms of end-to-end latency, execution time, and energy efficiency? The contribution of this paper can be summarized as follows:  
1. End-to-end implementation and evaluation on physical IoT hardware: We deploy all MQTT roles, i.e., broker, publisher, and subscriber, on separate Raspberry Pi 4\(B\)  
Figure 1: Our three–layered architecture. boards, leveraging Paho-MQTT, Mosquito, and OpenSSL for TLS 1.3.