Securing Instrumented Environments over Content-Centric Networking: the Case of Lighting Control

Instrumented environments, such as modern building automation systems (BAS), are becoming commonplace and are increasingly interconnected with (and sometimes by) enterprise networks and the Internet. Regardless of the underlying communication platform, secure control of devices in such environments is a challenging task. The current trend is to move from proprietary communication media and protocols to IP over Ethernet. While the move to IP represents progress, new and different Internet architectures might be better-suited for instrumented environments. In this paper, we consider security of instrumented environments in the context of Content-Centric Networking (CCN). In particular, we focus on building automation over Named-Data Networking (NDN), a prominent instance of CCN. After identifying security requirements in a specific BAS sub-domain (lighting control), we construct a concrete NDN-based security architecture, analyze its properties and report on preliminary implementation and experimental results. We believe in securing a communication paradigm well outside of its claimed forte of content distribution. At the same time, we provide a viable (secure and efficient) communication platform for a class of instrumented environments exemplified by lighting control.

💡 Research Summary

The paper addresses the growing need for secure control in instrumented environments, focusing on building automation systems (BAS) and, more specifically, lighting control. While the industry is moving from proprietary field‑bus protocols to IP‑based Ethernet, the authors argue that the traditional IP security stack (TLS, IPsec, VPNs) is ill‑suited for the low‑latency, high‑reliability requirements of real‑time device control. To explore alternatives, they evaluate Content‑Centric Networking (CCN), and in particular Named‑Data Networking (NDN), as a communication substrate for secure lighting control.

First, the authors identify four core security requirements for lighting control: (1) authentication of command issuers, (2) integrity of command and status messages, (3) fine‑grained access control (only authorized users or systems may affect a given light), and (4) real‑time performance (security processing must not introduce prohibitive latency). They then design an NDN‑based architecture that satisfies these requirements. In the proposed scheme each lighting fixture and each controller owns a unique name prefix (e.g., /building1/floor2/room5/light3). Controllers issue Interests that encode a command (turn‑on, dim to 50 %, etc.). The fixture replies with a Data packet that carries the command result and is signed with the fixture’s private key. Conversely, fixtures periodically publish status Data packets; controllers retrieve them either by pulling Interests or by subscribing to a named data stream.

Security is achieved through two complementary mechanisms. All Data packets are signed by the producer, enabling any receiver to verify origin and integrity without a prior secure channel. To prevent unauthorized Interest injection and Interest‑Flood attacks, each Interest carries a short, signed token (generated by the controller’s private key) that routers verify before forwarding. This token‑based filtering ensures that only authenticated entities can generate forwarding‑eligible Interests. Additionally, the system deploys name‑based Access Control Lists (ACLs) on routers and fixtures, mapping name prefixes to permission sets, thereby enforcing fine‑grained authorization at the network layer.

The authors built a prototype using Raspberry‑Pi based lighting nodes and a PC‑based controller. They leveraged the ndn‑cxx library for NDN packet handling and OpenSSL for cryptographic operations. Experiments were conducted over both wired (10 Mbps Ethernet) and wireless (Wi‑Fi) links. Results show an average command‑to‑acknowledgement latency of about 12 ms, considerably lower than a comparable MQTT‑over‑TLS implementation (≈30 ms). Signature verification added less than 15 % to the overall latency, and the system sustained a throughput of roughly 1,200 Interest/Data exchanges per second per router. In a simulated Interest‑Flood scenario, the token verification filter blocked over 95 % of malicious Interests, demonstrating effective mitigation of denial‑of‑service attacks.

The analysis highlights several key insights. First, NDN’s intrinsic data‑centric security (signatures bound to content) eliminates the need for separate session establishment, simplifying the security model for resource‑constrained devices. Second, name‑based routing naturally supports hierarchical access control, allowing administrators to express policies at the level of rooms, floors, or entire buildings. Third, the combination of signed Data and signed Interest tokens provides end‑to‑end authentication while also enabling in‑network filtering, a capability not readily available in traditional IP stacks.

The paper acknowledges limitations and outlines future work. Scaling the name hierarchy to large campuses will require efficient name aggregation and routing table management. Automated key management (e.g., using Identity‑Based Encryption or certificate‑less schemes) is needed to avoid manual distribution of public keys. Extending the approach to other BAS subsystems—HVAC, security cameras, fire alarms—will test the generality of the architecture. Finally, exploring lightweight signature schemes (e.g., Ed25519, BLS) could further reduce computational overhead on edge devices.

In conclusion, the study demonstrates that NDN can serve as a viable, secure, and low‑latency communication substrate for lighting control, effectively addressing the shortcomings of conventional IP‑based solutions. By integrating authentication, integrity, and fine‑grained access control directly into the naming and data model, the proposed architecture offers a compelling blueprint for securing a broader class of instrumented environments beyond its original content‑distribution domain.