Skip to main content

BTI for CPS

Problem

Multi-robot systems are becoming increasingly important in factories, warehouses, transportation, and rugged environments ranging from jungles to outer space. Each robot has its own controller, sensors, actuators, and radio, and the robots often coordinate over a time-varying wireless network. This makes multi-robot systems prime targets for adversarial attacks.

The distributed software systems community has been exploring fault tolerance for decades, but several of its assumptions break when we move from servers on a wired network to robots that can directly affect the physical world. A Byzantine robot can report false positions or obstacles, equivocate with different neighbors, and use its own actuators to block paths or crash into other robots. Because the rest of the group makes decisions from information supplied by individual robots, one compromised robot can influence many correct robots.

RoboRebound considers how to protect multi-robot systems against this fully Byzantine threat model. In a similar vein to the BTR project, it also strives to provide a bounded-time guarantee: a compromised robot will be put into a safe state, and the remaining robots will resume correct behavior after a brief interlude in which the compromised robot may still affect the system.

In a flocking simulation with 125 robots, 10 compromised robots spoof the positions of other robots and lead correct robots away from the destination.

Why not use something else

Traditional Byzantine Fault Tolerance (BFT) is a poor fit for multi-robot systems. Replicas placed on the same robot could be compromised together, while replicas placed on other robots would have to communicate over an intermittent, limited-range wireless network without disrupting tight control-loop deadlines. Protocols such as PBFT also require 3f+1 replicas to mask f faults, which is expensive for a fleet of resource-constrained robots.

Existing multi-robot defenses tend to focus on a particular attack, such as Sybil attacks or physical masquerading, or on a particular coordination protocol. BTR can detect and isolate faulty nodes quickly, but it assumes that other nodes can determine what a node's inputs were and that isolating the node's messages is enough. Neither assumption holds here: other robots cannot directly verify a compromised robot's sensor readings, and a robot can cause physical harm through its own actuators even if the other robots stop listening to it.

Approach

RoboRebound uses bounded-time interaction (BTI), a slightly weaker but practical alternative to perfect fault masking (as one might get with Byzatine fault tolerance). A compromised robot may briefly influence the system, but after a bounded interval its ability to interact with the other robots and the physical world is removed. Whether this guarantee is sufficient depends on the application and the amount of time needed to reach a safe state.

Each robot has a normal, complex control node and two small trusted components. The sensor node (s-node) sits between the sensors and the control node, while the actuator node (a-node) sits between the control node, the actuators, and the radio. The control node can run mission-specific software and is not trusted; the s-node and a-node run small immutable protocols on separate MCUs. This requires custom circuitry: the trusted nodes are wired into the robot's sensor, actuator, and radio paths, preferably through a small PCB or interposer, so the control node cannot simply bypass them without lugging around a soldering iron.

RoboRebound places trusted sensor and actuator nodes between the untrusted control node and the rest of the robot. The actuator node can also enforce Safe Mode by disconnecting the robot from its actuators.

The trusted nodes make the control node auditable. Sensor inputs, actuator commands, and wireless messages are recorded in a local log and committed to hash chains maintained by the s-node and a-node. Other robots periodically audit a recent log segment by replaying the control node deterministically and checking that the recorded outputs match the replayed outputs. The hash-chain authenticators make omitted or modified inputs and outputs detectable.

Successful audits produce tokens. The actuator node requires each robot to maintain fresh tokens from at least f+1 other robots; if too few valid tokens remain, it expires the robot's authorization and triggers Safe Mode. This makes the audit timeout the bound on how long a misbehaving robot can interact with the rest of the system.

The authors implemented RoboRebound both in an ns-3 simulator and on SecBot, a wheeled mobile-robot platform. The SecBot prototype adds the custom trusted-node circuitry to an existing robot, using inexpensive PIC32 MCUs and keeping the trusted code small enough to audit carefully.

Three SecBot robots used to prototype RoboRebound's trusted sensor and actuator nodes.

Sample Result

The evaluation uses Olfati-Saber flocking as a representative multi-robot application. In a 100m x 100m arena, 25 robots move toward a common destination while avoiding collisions. The attack begins at t = 15 seconds: a compromised robot spoofs messages so that correct robots believe their path is blocked.

Top: execution with one compromised robot and RoboRebound disabled, where the spoofed robot diverts the correct robots. Bottom: RoboRebound-enabled execution, where failed audits cause the compromised robot's tokens to expire and the robot to be disabled. The correct robots continue toward approximately the same final state as in the fault-free case.

The protected system briefly experiences a disturbance, but the compromised robot's audits begin failing immediately and its Safe Mode is triggered quickly. The trusted sensor and actuator implementations contain roughly 106 and 145 lines of C, respectively. The tiny MCUs cost about €3 each; in the evaluated configuration, the s-node uses only a low single-digit percentage of the CPU, while the more active a-node remains within the capabilities of the inexpensive processor.

Publications