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

1 Introduction

• The Internet’s usage model has limitations as data exchange and services have grown beyond the modest applications and point-to-point communication patterns for which its core ideas were developed.NDN is one of several research efforts pursuing a next-generation architecture, but its suitability for less content-centric domains such as building automation remains unclear.Source: §1 · p. 1

1.1 Building Automation and Lighting Control

• Lighting is the initial BAS test platform because it represents a broad actuator class with limited safety concerns, existing IP deployments, and available IP- and serial-system comparisons.The design goals include low latency, identity- or function-based NDN names, public-key identities, authorization with strong authentication, and mechanisms suitable for low-power systems.Source: §1.1 · pp. 1–2

1.2 Securing Lighting Control

• Increasing Internet integration and cross-boundary applications make network separation alone an increasingly difficult basis for lighting-control security.Public networks can offer existing infrastructure, distributed access, and standardized security features instead of separate networks and proprietary measures.Source: §1.2 · p. 2

1.3 Focus

• Lighting control has stricter latency needs than general BAS: commands may need to execute within a few hundred milliseconds, or updates approach DMX’s 44Hz refresh rate for smooth fades.The paper targets a hybrid design space for heterogeneous BAS through a secure, low-latency framework with a meaningful namespace.Source: §1.3 · p. 2

2 Overview of NDN

• NDN identifies content by names made of variable-length components, rather than by content location.Large content can be split into fragments with predictable names.Source: §2 · p. 2
• Consumers request content with interests, and routers forward matching content objects only after an interest, using Pending Interests Table state to return content along incoming interfaces.Interests carry no source address, and routers may satisfy requests from caches rather than the original producer.Source: §2 · p. 2
• NDN requires digitally signed content to bind content to its name and provide origin authentication; applications manage trust, and publishers encrypt private or restricted content.Source: §2 · pp. 2–3

3.1 Base-Line Protocol

• The baseline sends a signed command through an interest exchange, then the fixture checks authorization, verifies the signature, executes the command, and returns a signed acknowledgment.The four-round, four-message exchange is a poor match for delay-sensitive lighting.Source: §3.1 · p. 3
• A fixture could solicit commands continuously, but one interest per authorized application and fixture creates O(mn) overhead and prevents rapid command bursts.The fixture operates in lock-step because an application must wait for its next interest.Source: §3.1 · p. 3

3.2 Whither Authenticated Interests?

• MACs perform better but cannot attribute a command to one party, so signatures are preferred for auditable actuators when timing permits and MACs for sensors.Authentication tags must be randomized, which inhibits aggregation because distinct tags make names distinct with overwhelming probability.Source: §3.2 · pp. 3–4
• Authenticated interests place a signature or MAC in the NDN name, alongside the fixture namespace, command, and a nonce or timestamp randomizer.The fixture verifies the tag, executes the command, and returns a signed acknowledgment.Source: §3.2 · pp. 3–4
• With multiple applications using the same command class and authentication type, a fixture may need repeated tag verification unless the name identifies the requesting application.Real-time signing of the acknowledgment may also delay execution on a resource-limited fixture.Source: §3.2 · p. 4
• Authenticated interests operate in 2 messages/2 rounds and allow successive commands without waiting for an acknowledgment, though closely spaced interests may arrive out of order.The baseline requires four rounds and four messages.Source: §3.1 · p. 3, §3.2 · p. 4

3.3 Secure Lighting Control Framework

• The framework targets reasonable performance while adhering to NDN principles, following the preceding discussion of secure lighting-control approaches.Source: §3.3 · p. 4
• The framework combines namespace-linked public-key trust, key attributes and access-control policies, and protocols for fixture initialization and authenticated command handling.It is motivated by the need for reasonable performance while adhering to NDN principles.Source: §3.3 · p. 4
• The threat model gives an adversary control of the App–Fix channel, including the ability to record, drop, modify, inject, delay, or replay packets.The stated goals include unauthorized command execution, undetectable delay or replay of legitimate commands, and false acknowledgments for unexecuted commands.Source: §3.3 · p. 4

3.4 Trust Model

• A producer may publish only in its namespace or a child namespace, and content must be signed by a key associated with that namespace or an ancestor.A namespace is a child when its name has the parent namespace as a prefix.Source: §3.4 · p. 4
• A trusted third party generates and distributes a root public key, then publishes each producer’s public key under that producer’s namespace key name.A signature made with the root secret key is always accepted.Source: §3.4 · p. 4
• A producer can delegate signing authority for a sub-namespace by publishing a corresponding public key there, and can prove key ownership through a fresh-nonce challenge response.Source: §3.4 · p. 4
• HIBS offers namespace strings as public keys and permits deriving signing keys for descendant names, but current NDN code cannot verify HIBS signatures.The lighting-control prototype therefore uses RSA signatures.Source: §3.4 · p. 4

• Each key attribute is encoded as two consecutive namespaces: an attribute name followed by its value.Source: §3.5 · p. 4
• The framework defines a set of attributes that applications can extend with new attributes.Source: §3.5 · p. 4
• A key name can bind a public key to an application, full-access permission, and an expiration date.The example key is considered invalid after December 31, 2015.Source: §3.5 · pp. 4–5
• Repeated instances of an attribute are combined by intersecting their values.Source: §3.5 · p. 5

• The protocol has three sub-protocols: bootstrapping, application authorization, and control.Source: §3.6 · p. 5
• Bootstrap pairs and initializes a fixture, establishing its NDN identity, trusted domain key, optional ACL references, and long-term secret.The fixture responds with the current time and a hash of the bootstrap information.Source: §3.6 · p. 5
• The authority grants an application permissions by signing its public key and publishing it under a name containing the permissions.Source: §3.6 · p. 5
• Commands carry an auth-token containing state information and a signature or MAC over the fixture, application, command, and state.The state includes a sequence number, timestamp, and estimated round-trip time.Source: §3.6 · p. 5
• A fixture checks command format, application permissions, command freshness and sequence number, and the signature or MAC before execution.It retains sequence-number state only for active applications and can use a local or remote ACL specified during bootstrap.Source: §3.6 · p. 5
• For symmetric authentication, a fixture derives an application-specific key from its long-term secret and encrypts that key to the application.The fixture can recompute the key when needed, so stored symmetric-key state does not grow with the number of authorized applications.Source: §3.6 · p. 5

• Applications encrypt commands before placing them in an interest; the encryption key derives from the MAC key or uses the fixture’s public key.The paper uses NDN’s content-encryption framework for acknowledgement privacy.Source: §3.7 · p. 6
• Command and acknowledgement sizes remain visible, potentially revealing command types, and the design implements no countermeasure for more sophisticated side channels.Padding is possible but incurs costs; timing and other observable feedback are harder to address.Source: §3.7 · p. 6

• Authenticated acknowledgements are needed for feedback after commands, but per-command public-key signatures are costly for resource-constrained fixtures.The proposed NDN extension aims to let fixtures produce authenticated acknowledgements efficiently.Source: §3.8 · p. 6
• Encryption-based acknowledgement authentication lets routers verify that an acknowledgement matches a pending interest by checking whether H(x) equals z.The fixture recovers x from the encrypted challenge and returns it in an empty content object.Source: §3.8 · p. 6
• The encryption-based method is publicly verifiable but cannot prove to a third party that the application actually interacted with the fixture.An application can generate challenge/response pairs without fixture interaction.Source: §3.8 · p. 6
• Hash-chain authentication makes fixture interactions auditable, but its lock-step operation prevents issuing a new command before the prior acknowledgement arrives.The method is designed for infrequent use and suits resource-constrained fixtures where public-key operations are too costly.Source: §3.8 · pp. 6–7
• If an acknowledgement is lost, the application retransmits the same interest for a set period, then aborts and falls back to public-key signatures.A retransmission of an already acknowledged command can be answered without additional computation.Source: §3.8 · p. 7

4 Prototype Evaluation

• The prototype was deployed in an actual theatrical lighting installation where three applications controlled eleven lights through five embedded devices.Experiments used a commodity laptop and an Overo embedded platform representative of a lighting fixture or low-power fixture controller.Source: §4 · p. 7, §4.2 · p. 7

4.1 Implementation

• NameCrypt implements the protocol over CCNx in C with OpenSSL, using RSA and SHA-256 for signatures and HMAC-SHA-256 for symmetric authenticated interests.The implementation also includes AES-128/SHA-256 encrypted challenges and SHA-256 hash-chain acknowledgments; the Overo target has a 600 MHz ARM Cortex-A8 and 256 MB RAM.Source: §4.1 · p. 7

4.2 Performance Evaluation

• On low-power devices, real-time command signatures are ill-suited, while signature verification is below typical network latency on both platforms.Intel signing time is comparable to typical LAN latency; the authors recommend HMAC for command generation on low-power devices.Source: §4.2 · p. 7
• Symmetric authentication has negligible performance impact, and fixtures generate each application's symmetric key in far less than a millisecond on the test devices.The key is generated from the fixture's secret.Source: §4.2 · p. 7
• When public verifiability is required and standard signatures are too expensive, encrypted challenges are an appealing acknowledgment-authentication option.RSA signatures add no significant delay on Intel, while signature generation is relatively expensive on ARM; HMAC performs adequately when viable.Source: §4.2 · p. 7
• With an efficient hash-chain representation, challenge-response takes less than a millisecond, and other operations incur very low overhead on both platforms.The authors advise against representations that require fixtures to regenerate a large portion of the chain from its secret seed.Source: §4.2 · p. 7

Trust model and access control

• The trust model represents signed content and key locators as graph edges; well-formed ownership paths bind namespace prefixes and constrain applications to delegating more restrictive attributes.An application cannot own a namespace with a mismatched prefix without additional namespace ownership from the TTP or another application.Source: §5 · pp. 7–8

Symmetric authentication mechanism

• The symmetric-interest analysis argues that an application cannot forge a new authenticated command for an unqueried namespace if the PRF and MAC are secure.The simulator answers namespace-key queries consistently with random values and forwards target-namespace command queries to the MAC challenger.Source: §5 · p. 8

Encryption-based Ack Authentication

• The encryption-based acknowledgment protocol aims to prevent acknowledgments without fixture assistance, assuming an invertible-hard hash and a secure block cipher.The analysis models an adversary controlling the App–Fix channel and seeking to forge an acknowledgment for a command not yet acknowledged by the fixture.Source: §5 · pp. 8–9
• For the modeled challenge involving pairs of encrypted and hashed values, a successful acknowledgment forgery with non-negligible probability would imply breaking the block cipher or hash one-wayness.The argument concludes that the adversary can forge authenticated acknowledgments only with negligible probability; it also permits CPA-secure encryption with efficiently sampleable ciphertext space.Source: §5 · p. 8

Hash-chain-based Ack Authentication

• For hash-chain acknowledgments, the application must not issue another command before receiving the prior acknowledgment; otherwise a reused challenge can let an adversary acknowledge later commands.With unique challenges, an adversary can acknowledge only commands successfully executed by the fixture, because the fixture reveals a preimage only for an authenticated, unaltered command.Source: §5 · p. 9
• A hash-chain acknowledgment and anchor can prove interaction with a fixture, but the preimage alone does not identify the acknowledged command.An application cannot produce the preimage without interacting with the fixture except with negligible probability; it identifies the command when authorization permits only a command with no parameters.Source: §5 · p. 9

6 Related Work

• Legacy lighting protocols relied on separate communication infrastructure, while transitions to IP often omitted added security and instead relied on network isolation or VPNs.Physical segregation can be difficult over RF, and some such protocols have been shown insecure.Source: §6 · p. 9
• DMX512 underlies many lighting systems, while Art-Net transports DMX over UDP without authentication or encryption and ACN standardizes media-agnostic control over UDP.ACN does not address security and assumes transport over a secure network.Source: §6 · p. 9
• Proprietary lighting systems include Dynalite, which spans lighting and other building systems, and KiNET, for which the authors report no known device authentication or encryption.KiNET uses Ethernet; Dynalite uses multidrop serial over twisted pair, while KiNET is associated with the Philips Color Kinetics platform.Source: §6 · p. 9

6.1 Common BAS protocols

• BACnet supports encryption and authentication but has reported weaknesses, including DES-only encryption and susceptibility to man-in-the-middle, interleaving, and replay attacks.BACnet is an open backbone standard intended to interoperate with other BAS and supports multiple underlying media.Source: §6.1 · p. 10
• KNX provides no data security, while LonTalk offers origin authentication but uses short shared keys, lacks key distribution, and requires a four-round challenge-response per message.A proposed KNX extension uses Diffie-Hellman key exchange and AES, but its security model and protocol details are insufficient for evaluation.Source: §6.1 · p. 10
• Fieldbus implementations often rely on network isolation, with rudimentary access control and cleartext passwords; proposed protections include SSL/TLS and IPSec.Fieldbus is an open architecture with published IEC standards and was adapted from industrial automation to building control.Source: §6.1 · p. 10

7 Summary and Future Work

• The paper identifies lighting-control security requirements, constructs an NDN-based architecture, analyzes its security, and reports a prototype implementation and experiments.The work addresses instrumented environments increasingly connected with enterprise networks and the Internet.Source: §7 · p. 10
• The evaluation is an initial step toward assessing NDN beyond content distribution, and the design's limited feedback model may not cover BAS with more expressive acknowledgments.The authors state that lighting control is in some ways simpler than other BAS and that further secure adaptation work is needed.Source: §7 · p. 10
• The current design does not support multicast; synchronously commanding a fixture group requires separate fixture interests issued at roughly the same time.The application could then send a command to all interested fixtures.Source: §7 · p. 10
• The authors identify long-lived interests as a direction to explore, allowing fixtures to solicit commands from controlling applications.Fixtures would need to refresh interests periodically as they expire and are flushed by routers.Source: §7 · p. 10
• NDN can provide access to sensing and actuation points through application-assigned names without specifying gateway IP addresses and ports.The paper notes this as a potential benefit for BAS applications.Source: §7 · p. 10