WebAssembly Based Portable and Secure Sensor Interface for Internet of Things

This paper presents a novel WebAssembly System Interface (WASI) extension built on Zephyr RTOS that provides a secure, portable, and low-overhead sandbox for multi-tenant IoT sensor access, achieving only a 6% latency and 5% memory footprint increase compared to native execution while enabling in-network access control via MQTT-SN.

The Gist

Imagine the Internet of Things (IoT) as a giant, bustling city where millions of tiny devices (like smart thermostats, health monitors, and factory sensors) are constantly talking to each other. While this makes life easier, it also creates a security nightmare. These devices are often small, cheap, and lack the "bouncers" (security guards) needed to keep bad actors out. If a hacker gets in, they can steal private data or take control of the devices.

This paper introduces a new solution called WASI-SN. Think of it as a secure, portable, and unbreakable glass booth that you can drop onto any of these tiny devices, no matter what kind of device it is.

Here is how it works, broken down into simple concepts:

1. The Glass Booth: WebAssembly (Wasm)

Traditionally, if you wanted to write a program for a specific smart sensor, you had to build it from scratch for that exact device. It was like building a custom car engine for every single model of car on the road.

The authors use WebAssembly, which is like a universal "translation booth."

• The Analogy: Imagine you have a master chef (your code) who knows how to cook a perfect meal. Usually, this chef can only cook in one specific kitchen. WebAssembly puts the chef inside a portable, self-contained kitchen unit. Now, the chef can walk into any kitchen (any device, whether it's a smart watch or a factory robot), set up their unit, and start cooking immediately without needing to know the specific layout of that kitchen.
• The Security: This booth has thick glass walls. The chef can only touch the ingredients inside the booth. If the chef tries to reach out and grab a tool from the main kitchen (the device's core system), the glass stops them. This prevents the program from accidentally (or maliciously) breaking the device.

2. The Universal Remote: The Sensor Interface

Once the booth is set up, the program needs to talk to the device's sensors (like a thermometer or a motion detector).

• The Problem: Before this, every sensor spoke a different language. One said "Turn on," another said "Start," and a third said "Activate."
• The Solution: The paper creates a Universal Remote Control (called a "Sensor Interface"). Instead of learning a new language for every sensor, the program just presses buttons like "Turn On," "Read Temperature," or "Change Settings." The system translates these standard buttons into the specific language the sensor understands.
• The Benefit: This means you can write one program that works on a sensor in a hospital in New York and a sensor in a farm in Texas, without rewriting the code.

3. The Secure Messenger: MQTT-SN

These devices need to send data over the internet, but standard internet protocols are too heavy and slow for tiny batteries. They use a lightweight protocol called MQTT-SN.

• The Analogy: Think of MQTT-SN as a postcard system instead of a heavy registered letter. It's fast and uses very little energy.
• The Security Upgrade: The paper adds a special encryption layer to this postcard system. Usually, the "Post Office" (the server or broker) could read your postcards. In this new system, the postcards are written in a secret code that only the intended recipient can read. Even if the Post Office is hacked, the messages remain safe because the Post Office doesn't have the key to the code.

4. The VIP List: Access Control

How do we know who is allowed to read the temperature or change the settings?

• The Analogy: Imagine a club with a dynamic VIP list. Instead of giving everyone a master key, the club manager (the device) issues keys based on a pattern.
• How it works: The system uses a method called Wildcard Identity-Based Encryption.
  • Imagine the key for "Alice in the New York office" is a special pattern.
  • If Alice needs to share access with her team, she doesn't need to ask the manager for new keys for everyone. She can issue a "Wildcard Key" that says "Anyone with the pattern NewYork/Alice/* can enter."
  • If Alice leaves the company, the manager can instantly revoke that specific pattern, and suddenly, no one with that pattern can enter anymore. This happens instantly, without needing to change the locks on the whole building.

5. The Results: Fast and Light

The authors tested this system on real hardware (a small development board).

• Speed: They found that running programs inside this "glass booth" was only 6% slower than running them directly on the device. That's like a runner wearing slightly heavier shoes; they are still fast enough to win the race.
• Size: The extra space needed for this security system was only 5% of the device's memory.
• Network: When sending messages over the network, the security system added almost no delay (less than 1%) because the network traffic itself was the slowest part, not the security check.

Summary

The paper presents a way to make tiny, insecure IoT devices much safer and easier to program. By wrapping them in a universal, secure glass booth (WebAssembly) and giving them a standard remote control (Sensor Interface) and a secret postcard system (MQTT-SN with encryption), developers can build applications that work anywhere, are hard to hack, and don't slow the devices down.

Technical Summary

Technical Summary: WebAssembly Based Portable and Secure Sensor Interface for Internet of Things

Problem Statement
The rapid expansion of Internet of Things (IoT) deployments introduces significant privacy and security challenges, particularly regarding the management of shared and protected access to sensors on resource-constrained embedded devices. Current Real-Time Operating Systems (RTOS) often lack robust security mechanisms (such as AppArmor or Seccomp) to mitigate software-based and network-based attacks due to memory and latency constraints. This places the burden of security on application developers, who must possess deep embedded systems knowledge to prevent vulnerabilities. Furthermore, the lack of a standardized interface for sensor access leads to platform-specific implementations that hinder portability across heterogeneous devices. Additionally, existing network protocols like MQTT-SN often rely on trusted brokers, creating a single point of failure where a compromised broker can leak sensitive data, and they lack fine-grained, end-to-end access control for multi-tenant scenarios.

Methodology
The authors propose WASI-SN, a WebAssembly System Interface (WASI) extension designed to provide a secure, portable, and low-footprint sandbox for accessing on-board sensors and managing network communication via MQTT-SN. The system is implemented atop the Zephyr RTOS using the Wasm-micro-runtime (WAMR) for Cortex-M processors.

The methodology consists of three primary components:

1. Sensor Interface Primitives:
   The paper defines a capability-based sensor interface inspired by SmartThings but adapted for local Wasm applications. Instead of relying on cloud proxies, the interface exposes device peripherals directly. It includes primitives such as getSensors, turnOn/Off, config, read, and state. These functions allow Wasm modules to query sensor capabilities, initialize devices, configure attributes (e.g., sampling rates), and retrieve data. The runtime intercepts these calls to enforce memory isolation and validate that the executing module possesses the necessary privileges for specific sensor accesses.

2. Network Interface and MQTT-SN Integration:
   To facilitate communication, the authors integrate an MQTT-SN library into the Wasm runtime. This exposes standard MQTT-SN operations (e.g., searchGW, connect, register, publish, subscribe) to Wasm modules. The implementation utilizes a hybrid architecture where resource-constrained devices communicate with a gateway via UDP (to minimize energy consumption), and the gateway interfaces with the broker via TCP. This design supports sleep modes and decouples publishers from subscribers.

3. Access Control and Encryption (WKD-IBE):
   To address the lack of end-to-end security and the risk of untrusted brokers, the paper introduces a Wildcarded Identity-Based Encryption (WKD-IBE) scheme.

   • Hierarchical Identity: Resources (sensors) and requesters are mapped to hierarchical Uniform Identity Identifiers (UIIs).
   • Pattern Matching: Encryption keys are bound to patterns (e.g., /entity/Location1/*/BME280/temperature). A key derived for a specific pattern can decrypt messages encrypted for that pattern or any matching sub-pattern.
   • Key Establishment: A TLS-like key exchange occurs over MQTT-SN topics. Requesters publish encrypted authorization requests containing their identity and public key. The device decrypts these, verifies permissions, and derives specific decryption keys for authorized users without the broker acting as a trust anchor.
   • Revocation: The system employs a Complete Subtree (CS) broadcast encryption scheme (based on JEDI) to support immediate key revocation and key expiry, allowing the device to invalidate access for specific users or subgroups dynamically.

Key Contributions

• WASI-SN Extension: The first implementation of a WASI extension providing secure, multi-tenant access to on-board sensors for embedded devices.
• Formal Sensor Capability Definition: A standardized, capability-based API that constrains sensor interfaces to necessary and valid accesses, improving portability across heterogeneous devices.
• Open-Source Runtime: The first open-source implementation of a WebAssembly runtime with sensor interface extensions supporting Cortex-M processors (specifically on Zephyr RTOS).
• Integrated MQTT-SN Library: A library built into the Wasm runtime that exposes network interfaces to Wasm modules, enabling in-network access control.
• Secure Access Control Scheme: An access control mechanism over MQTT-SN utilizing WKD-IBE, enabling flexible key delegation, immediate revocation, and end-to-end encryption without relying on the broker as a trust anchor.

Results and Evaluation
The system was evaluated on an NRF52840-DK board (Cortex-M4F, 64 MHz, 256KB SRAM) communicating via IEEE 802.15.4 and OpenThread.

• Memory Footprint: The WASI-SN implementation introduced a 5% memory overhead during compilation compared to native execution. At runtime, the dynamic memory footprint was approximately 10KB, with the MQTT-SN library adding negligible runtime overhead for modules not utilizing it.
• Latency: Sensor access via the Wasm interface incurred a 6% latency overhead compared to native execution. This overhead is primarily attributed to the fixed startup time required to boot the runtime; as modules are executed repeatedly, the overhead stabilizes.
• Network Latency: For MQTT-SN operations, the WASI-SN implementation introduced less than 1% additional latency compared to native execution. The authors note that network delays dominate the total latency, making the WebAssembly overhead negligible in this context.
• Code Size: Wasm modules were significantly more compact than their native counterparts (e.g., 357 bytes vs. 893 bytes for a 10-line sensor access program), highlighting the benefits of offloading functionality to the runtime.

Significance
The paper claims that WASI-SN offers a viable path toward secure and portable embedded applications without sacrificing performance. By leveraging WebAssembly's inherent sandboxing and portability, the framework reduces the security burden on application developers and enables a unified interface for heterogeneous devices. The integration of WKD-IBE provides a robust solution for multi-tenant data privacy and access control in IoT networks, addressing the vulnerabilities of trusted-broker models. The authors posit that this approach represents a significant step toward running secure, portable applications across diverse edge computing platforms, potentially establishing WebAssembly as a dominant binary format in the embedded IoT future.