Zenoh Protocol Security Analysis

Zenoh is a communication protocol designed to efficiently facilitate data exchange, storage, and computation across diverse computing environments — from powerful servers in data centers to resource-constrained microcontrollers in IoT devices. Its primary objective is to enable seamless integration and operation of systems throughout the entire cloud-to-microcontroller continuum, overcoming limitations inherent to existing protocols that frequently create isolated "connectivity islands."
Given the critical nature of network protocols and technology infrastructures, it is essential to thoroughly analyze and comprehend Zenoh's security architecture. This article provides a security analysis of the Zenoh protocol, specifically within an automotive sector context, examining scenarios where data traverses nodes outside the direct control and trust boundaries of the OEM. The analysis leverages a lightweight threat modeling approach, accounting for adversaries with varying levels of access and capabilities. Additionally, the article includes a focused case study of a compromised router scenario, uncovering a security gap within Zenoh stemming from its current lack of support for End-to-End Encryption (E2EE).

What is Zenoh?

Zenoh — the Zero Overhead Network Protocol — is a Pub/Sub/Query protocol designed to unify data in motion, data at rest, and computational tasks across environments ranging from data centers to resource-constrained microcontrollers. It is specifically engineered to address the challenges posed by heterogeneous networks and diverse hardware ecosystems. It overcomes limitations commonly associated with related protocols such as Message Queuing Telemetry Transport (MQTT), Data Distribution Service (DDS), and Scalable service-Oriented MiddlewarE over IP (SOME/IP), notably their restrictions in network topology flexibility and inadequate support for resource-constrained devices. To achieve these objectives, Zenoh offers the following key features:

Feature	Description
Unified Abstractions	Integrates pub/sub and query mechanisms to handle data in motion, data at rest, and computational tasks seamlessly.
Minimal Wire Overhead	Achieves efficiency with wire overhead as low as 4 bytes, outperforming MQTT and DDS, and enabling its use in resource-constrained devices.
Flexible Communication Topologies	Supports various communication models including peer-to-peer, routed, and brokered architectures, adapting flexibly to diverse system requirements.
Cross-Platform Compatibility	Capable of operating across Data Link, Network, and Transport layers, supporting various communication protocols such as Serial Links, Bluetooth, TCP/IP, and CANbus.

The Zenoh protocol is designed by ZettaScale Technology and released as an open source project under an Apache 2.0 license.

Where can Zenoh be used?

Given its key features and design choices, Zenoh is particularly well-suited for environments requiring reliable, efficient communication across heterogeneous networks and diverse computing platforms, such as:

• Automotive communications, including Vehicle-to-Everything (V2X) and Software-Defined Vehicles (SDVs)
• Industrial Automation and Industrial IoT, such as Intelligent Transportation Systems (ITS)
• Robotics, specifically Robot-to-Everything (R2X) communications
• Edge computing and Multi-Access Edge Computing (MEC)
• Large-scale distributed systems with real-time communication requirements

Zenoh in the Automotive Sector

In the automotive industry, Zenoh excels in V2X communication scenarios, facilitating efficient data exchange within vehicles (in-vehicle), between vehicles (V2V), with infrastructure (V2I), and interactions with cloud-based systems (V2C). It offers a compelling alternative to traditional automotive communication protocols such as CAN bus, as well as protocols like MQTT or DDS, delivering significantly lower latency (as low as 13 µs in optimized scenarios) and higher throughput (up to 50 Gbps in peer-to-peer configurations).

Zenoh has also been recommended by the International Telecommunication Union (ITU) for standardization as a communication protocol for Intelligent Transport Systems (ITS). Additionally, its applicability in Robotics and Robot-to-Everything (R2X) aligns closely with Industry 4.0 trends, supporting innovation in automotive manufacturing and beyond.

Security Architecture

Security is a critical aspect of any communication protocol, especially one designed to operate across diverse, mixed-criticality environments that may include untrusted components. Zenoh’s security model aims to minimize the attack surface through robust authentication, encryption, and access control mechanisms. The following features underpin Zenoh's security guarantees:

• Authentication: Support of pluggable authentication mechanisms, including mutual TLS authentication, ensuring that only authorized entities can participate in the network.
• Secure Channels: Zenoh provides secure communication channels, such as those enabled by TLS, to protect data in transit between nodes.
• Session Establishment & State Management: Unlike protocols relying on complex, stateful interactions, Zenoh’s session management offloads state-tracking responsibilities to the initiating entity via encrypted cookies, reducing the protocol’s attack surface.
• Access Control: Enforcement of fine-grained access control using Access Control Lists (ACLs), restricting unauthorized data access.
• Memory Safety: Implemented in Rust, leveraging the language’s built-in memory safety features to protect against common vulnerabilities such as buffer overflows and dangling pointers.

These features demonstrate Zenoh’s commitment to establishing a robust and secure foundation for distributed systems. However, as demonstrated in the following sections, certain deployment scenarios may require additional security measures beyond Zenoh’s built-in capabilities.

Lightweight Threat Model

To assess the potential security risks and evaluate Zenoh’s security posture in the context of a deployment, we applied a lightweight threat model. The model considers threat actors with varying access levels, enumerates associated threats, and highlights relevant security mechanisms:

Actor	Threats	Security Controls
Man-in-the-Middle (MiTM)	Interception and eavesdropping on communications, tampering with existing data, or injecting malicious data.	Secure channels using TLS, ensuring data confidentiality, integrity, and authenticity.
Malicious Peer/Client	Unauthorized access or manipulation of data, potentially causing data leaks or operational disruptions.	Mutual authentication via mTLS combined with strict access control mechanisms.
Compromised Router	Interception or modification of data passing through the router, exposure of plaintext data, and manipulation of routing logic.	Hop-by-hop encrypted links between routers. Lack of built-in support for end-to-end encryption between publishers and subscribers.

For the remainder of this article, we focus on the compromised router scenario, as it highlights a critical security consideration when architecting Zenoh deployments.

Reference Automotive Zonal Architecture Case Study

In a Zenoh network, data may pass through multiple routers before reaching its final destination. While Zenoh supports secure channels between nodes using TLS with mutual authentication (mTLS), encryption is applied on a hop-by-hop basis rather than end-to-end. Consequently, data is decrypted and then re-encrypted at each intermediate router, leaving it vulnerable to inspection or modification if a router is compromised.

Consider a scenario where an attacker gains control of a router in a multi-router Zenoh configuration. Since data is decrypted at each router, the attacker could capture plaintext content from topics traversing through the compromised node or even manipulate these values before forwarding them. This lack of End-to-End Encryption (E2EE) poses a security risk, especially for sensitive data that requires confidentiality throughout its entire journey from publisher to subscriber.

To demonstrate this vulnerability, we developed a Proof of Concept (PoC) using Docker in a multi-router configuration representative of Zenoh's deployment in an automotive context. The PoC is based on a zonal automotive architecture, reflecting modern vehicle design trends, where the vehicle is partitioned into multiple zones (e.g., front left, front right, rear left, rear right). Each zone contains a dedicated zonal router that connects client sensors (e.g., cameras, LiDAR, speed sensors). A central router connects these zonal routers, facilitating data flow between the vehicle's internal systems and external interfaces, such as cloud services.

In the following PoC, we assume one of the zonal routers has been compromised. We demonstrate how an attacker could exploit this compromised router to view plaintext topic data passing through it, highlighting the security implications of Zenoh’s lack of E2EE.

PoC Network Topology

For the purposes of our PoC we consider a vehicle which uses Zenoh and employs a zonal architecture, logically dividing the vehicle into four zones. The main components in our setup are:

• Tire Sensors - Each zone includes tire sensor services (sensor_ws1 through sensor_ws4), connected as clients to their respective zonal router. The sensors act as Zenoh publishers, publishing real-time measurements for tire pressure, temperature, and wear. Tire data are generated randomly and published to their respective key expressions at 1-second intervals.
• Traction Control Systems (TCS) - Each zone has a dedicated Traction Control System (zone1_tcs through zone4_tcs), responsible for reading measurement data from the tire sensors. Each TCS subscribes to its zone’s sensor, but it can also subscribe to data from other zones to allow traction-related decisions that require data from the entire vehicle.
• Zonal Routers - Each zone has a Zenoh router which handles communication between the clients of the respective zone, and connects the zone with the central router to allow information exchanges between zones.
• Central Router - A central Zenoh router manages cross-zone communication, allowing controlled data flow between vehicle zones—similar to a vehicle's central gateway. This router enables each zone's TCS to access data from other zones when needed, supporting a holistic view of the vehicle's tire status.

PoC Implementation Details

The PoC utilizes Docker containers, assigning a dedicated, isolated container to each component. This approach mimics the isolated environments found in modern vehicles. Each router exposes only the necessary ports for TLS communication and optionally, REST APIs, realizing the network topology described above. Communication between components enforces mutual authentication over TLS (mTLS), ensuring only authenticated components can exchange data. Finally, Docker Compose is used to simplify the deployment, management, and testing of the multi-container PoC setup.

The system uses a hierarchical naming convention of car_tires/sensor_wsX, where X represents the zone number (1 - 4). Each sensor publishes a JSON-serialized payload containing three measurements: tire pressure, temperature, and wear level. To simulate realistic sensor data, random values are generated within the following specified ranges:

• Pressure: 30.0 - 35.0 PSI
• Temperature: 25.0 - 35.0 °C
• Wear: 0.0 - 100.0%

This is a sample of a JSON-serialized payload:

{
   "pressure": 32.45,     // Tire pressure in PSI
   "temperature": 28.73,  // Tire temperature in Celsius
   "wear": 42.18          // Tire tread wear percentage
 }

Optionally, we configure a storage plugin on each router, utilizing integrated memory to store sensor measurements in the respective router’s volatile storage. Additionally, a REST API is configured to enable querying current and historical data through HTTP requests. Data can be retrieved by specifying either the exact key expression (e.g., car_tires/sensor_ws2) or wildcard expressions (e.g., car_tires/**) to simultaneously access data from all zones.

The complete data flow is reflected from the following pattern:

1. Sensors generate randomized tire measurements.
2. Measurement data is serialized to JSON.
3. Publishers send data to their respective zone routers.
4. Zone routers store the data and forward them to the central router.
5. The central router makes the data available to all subscribed TCS systems.
6. TCS subscribers decode and process the received data.

Attack Scenario: Data Leak via a Compromised Router

In this PoC attack scenario, we simulate an attacker who has successfully compromised the Zenoh router in Zone 4. Such a compromise could occur through various means, including physical access, exploitation of vulnerabilities in the component hosting the Zenoh router (e.g., the zonal ECU), or through a supply-chain attack.

As expected, network traffic captured at the network interface of the compromised Zone 4 router is protected by TLS, given that mutual TLS (mTLS) is enforced throughout our Zenoh deployment. An example of this encrypted communication is shown in the following packet capture:

However, as previously mentioned, Zenoh employs hop-by-hop data encryption, meaning TLS connections terminate at each router. If the compromised router exposes a REST API, an attacker can directly access plaintext values of published data.

The following commands, executed locally on the compromised Zone 4 router, demonstrate retrieval of plaintext sensor data published by a sensor within the same zone (sensor_ws4):

• Command:

$ curl -s 'http://localhost:8004/car_tires/sensor_ws4'

• Output:

[
 {
   "key": "car_tires/sensor_ws4",
   "value": "eyJwcmVzc3VyZSI6IDMwLjE0NTA2MzQxMzkyNjA0NiwgInRlbXBlcmF0dXJlIjogMjYuMzE5NDM4NjEzNjM0MjkzLCAid2VhciI6IDc3LjE2NDM2NDAzMTY2OTd9"
 }
]

In the output above, the measurement value is base64-encoded. The plaintext measurement values are retrieved by decoding this base64 value:

$ base64 -D
eyJwcmVzc3VyZSI6IDMwLjE0NTA2MzQxMzkyNjA0NiwgInRlbXBlcmF0dXJlIjogMjYuMzE5NDM4NjEzNjM0MjkzLCAid2VhciI6IDc3LjE2NDM2NDAzMTY2OTd9

{
 "pressure": 30.145063413926046,
 "temperature": 26.319438613634293,
 "wear": 77.1643640316697
}

The extracted measurements received via the REST API match the values published by the publisher and received by the subscriber shown below:

[...]
sensor_ws4-1            | Publishing back right tire data (Zone 4): {'pressure': 30.145063413926046, 'temperature': 26.319438613634293, 'wear': 77.1643640316697}
zone4_tcs-1             | Received data for Zone 4: {'pressure': 30.145063413926046, 'temperature': 26.319438613634293, 'wear': 77.1643640316697}
[...]

Even if the REST API is not configured to be in use in the compromised router, the attacker can instrument the zenohd router or manipulate its memory to retrieve, or tamper, with measurements passing through the router.

In the following commands, the attacker located on the Zenoh router component dumps the memory zenohd process with gdb:

$ gcore -o /tmp/dump 1 # PID for zenohd: 1

The memory dump contains measurement values in plaintext residing in the router’s memory, as seen below running the  strings command on the generated core dump:

$ strings /tmp/dump
[...]
car_tires/sensor_ws4
x9]{"pressure": 30.145063413926046, "temperature": 26.319438613634293, "wear": 77.1643640316697}
car_tires/sensor_ws4
x9]{"pressure": 30.145063413926046, "temperature": 26.319438613634293, "wear": 77.1643640316697}
car_tires/sensor_ws4
x9]{"pressure": 30.145063413926046, "temperature": 26.319438613634293, "wear": 77.1643640316697}
zenoh-router-zone4
RootCA
[...]

Even though TLS sessions protect data against adversaries in a network-based Man-in-the-Middle (MiTM) position, an adversary who has compromised a Zenoh router can access plaintext measurement data flowing through it. Our PoC demonstrates the potential risks inherent in Zenoh deployments requiring E2EE. Zenoh's lack of built-in E2EE support can impact the confidentiality and integrity of sensitive automotive data—such as vehicle location or critical control signals—if any segment of the routing infrastructure is compromised before the data reaches its intended destination.

Recommendations for Achieving E2EE

For systems that require End-to-End Encryption (E2EE) to guarantee the confidentiality and integrity of sensitive data, additional security measures must be employed when using Zenoh, as it does not currently offer native E2EE support. Practical recommendations for addressing this limitation include:

1. Application-Level Encryption:
   Clients can encrypt data at the application layer before publishing it to Zenoh, decrypting the data upon receipt. This ensures that only intended recipients with the appropriate cryptographic keys can access plaintext data, even if intermediate routers become compromised. However, implementing this approach requires robust key management, secure key distribution, and lifecycle management.
2. Custom Security Plugins:
   Zenoh’s pluggable architecture supports the integration of custom security plugins. Organizations can leverage this capability to develop or integrate plugins specifically designed to enforce E2EE for sensitive data streams. Such plugins would facilitate automated encryption and decryption within the Zenoh ecosystem, but developers must ensure these plugins are thoroughly tested, securely implemented, and regularly maintained.

These measures can effectively mitigate the security gaps stemming from Zenoh’s current lack of built-in E2EE capabilities. However, their successful implementation necessitates careful planning, thorough evaluation of cryptographic algorithms, secure and efficient key management practices, and comprehensive security assessments to ensure they deliver the desired effectiveness.

Concluding Remarks

Zenoh effectively addresses many of the challenges faced by modern distributed systems, providing a unified framework for managing data and computation across diverse and heterogeneous environments. Its efficiency, flexibility, and compatibility with resource-constrained hardware position it as an attractive solution for various applications, particularly within the automotive sector and robotics domains.

However, Zenoh's current lack of built-in End-to-End Encryption (E2EE) support presents security concerns for deployments in scenarios where data:

• Traverses nodes belonging to different security domains.
• Is routed through potentially untrusted nodes beyond the direct control of the data owner (e.g., subsystems managed by another OEM).
• Is transmitted across external or public network boundaries.

This security analysis of the Zenoh protocol equips system architects and developers with the insights needed to appropriately balance Zenoh’s advantages against its security limitations. Platforms and use cases requiring stringent E2EE or adopting a Zero Trust architecture must implement additional security measures to safeguard data confidentiality and integrity across their network.

To ensure robust protection for automotive systems utilizing Zenoh, system integrators and OEMs can leverage from CENSUS’s specialized cybersecurity engineering services, which are tailored specifically to automotive ecosystems.

References

• Zenoh official website and documentation, https://zenoh.io/
• A. Corsaro et al., "Zenoh: Unifying Communication, Storage and Computation from the Cloud to the Microcontroller," 2023 26th Euromicro Conference on Digital System Design (DSD), Golem, Albania, 2023, pp. 422-428, doi: 10.1109/DSD60849.2023.00065
• Eclipse Zenoh source code and GitHub repository, https://github.com/eclipse-zenoh/zenoh

• Tags: automotive , Zenoh , E2EE