Decentralized Information-Flow Control for ROS2

Decentralized Information-Flow Control for ROS2

Speakers: Nishit V. Pandya, Researcher, Indian Institute of Science

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=_TsV2OWqSw0

Overview

This article delves into Picaros, a novel system for Decentralized Information-Flow Control (DIFC) specifically designed for ROS2 (Robot Operating System 2). Presented by Nishit V. Pandya from the Indian Institute of Science, the talk highlights a critical security gap in existing ROS2 deployments, even those utilizing SROS2 (Secure ROS2). While SROS2 provides foundational security features like encryption, integrity, and authentication, it lacks the ability for data owners to control how their data is consumed or re-published downstream by other applications. This absence of fine-grained control exposes robotics systems to data exfiltration risks and unauthorized data usage.

Picaros addresses this fundamental limitation by introducing a robust DIFC framework tailored for ROS2's inherently distributed and dynamic architecture. The system innovatively leverages Attribute-Based Encryption (ABE) to enforce information flow policies, allowing data owners to associate labels (sets of tags) with their data. These labels dictate which applications are authorized to access and process the data, thereby preventing unauthorized information leakage. A key aspect of Picaros is its commitment to ROS2's decentralized philosophy, meticulously avoiding any centralized components that could introduce single points of failure or violate the platform's core design principles.

The significance of Picaros lies in its potential to elevate the security posture of ROS2-based robotics applications. As ROS2 becomes increasingly prevalent in critical domains ranging from industrial automation to autonomous vehicles, ensuring strict control over data flow is paramount. Picaros empowers developers and system integrators to build more secure and compliant robotic systems, where sensitive data can be created and processed with confidence, knowing that its downstream usage adheres to predefined policies. This work represents a crucial step forward in securing the complex, interconnected ecosystems of modern robotics.

Background

▶ Watch: Introduction to ROS2 security gaps and DIFC (0:00)

ROS2 is a widely adopted middleware framework for developing distributed robotics applications. It operates on a publish/subscribe model, where applications communicate by publishing messages to named topics and subscribing to topics of interest. This decentralized architecture, built atop the Data Distribution Service (DDS), facilitates dynamic discovery and direct, pairwise communication between applications, typically over UDP sockets.

SROS2 enhances the core ROS2 framework with essential security features. It uses manifests to declare topics, cryptographically binds applications to their manifests, and sandboxes them. All communication is encrypted end-to-end using TLS (Transport Layer Security), ensuring confidentiality, integrity, and sender authentication. For the purpose of the Picaros work, SROS2 is assumed to be a default and functioning part of the ROS2 stack.

Despite SROS2's foundational security, a significant vulnerability remains: the lack of fine-grained control over data consumption and propagation. For instance, if a Camera application publishes an image to an Image topic, an ObjectDetector application might subscribe to it, process the image, and then be free to publish the original image or derived information under a completely different topic. The original data owner (the Camera) has no mechanism to control this downstream usage. This can lead to data exfiltration attacks or unauthorized data re-distribution, which is unacceptable for sensitive information.

This problem is precisely what Decentralized Information-Flow Control (DIFC) aims to solve. In a DIFC system, each data owner associates a label—a set of tags of its choosing—with the data objects it creates. DIFC enforcement then controls data consumption by checking that the consumer's label includes all the tags present in the data object's label. This is known as the no-reads-up rule. Dually, the no-writes-down rule ensures that data published by an application inherits the tags of that publisher. These concepts date back to classic Mandatory Access Control (MAC) models like Bell-LaPadula, but DIFC, as introduced by Myers and Liskov, makes label assignment egalitarian, allowing data owners to define policies. DIFC systems also support mutable labels, where applications can request to add or remove tags, and declassification, a critical mechanism allowing trusted entities to remove tags from data objects to prevent "label creep."

Applying DIFC to ROS2 presents unique challenges due to its decentralized, distributed, and dynamic nature. Traditional DIFC systems often rely on a centralized Trusted Computing Base (TCB), such as an operating system kernel or language runtime, to store labels and enforce policies. In ROS2, applications are spread across multiple physical devices, requiring the TCB to span machines. Securely binding labels to data objects across a network (Goal G1) and enforcing flow policies (Goal G2) without invasive changes to ROS2's communication model is complex. Prior distributed DIFC systems, like DStar, often employ a dedicated data exporter process per machine, which centralizes network access and label binding. This approach fundamentally alters ROS2's direct communication path and violates its core decentralized design philosophy. Furthermore, ROS2's software architecture, where libraries are loaded into application address spaces and communication is opaque to the underlying OS, makes OS-level enforcement difficult. Enforcing access control at the receiver is often too late, as plaintext data is already in the application's address space. Sender-side enforcement requires the publisher to know the receiver's label, which is problematic in a dynamic, distributed environment due to centralized state management issues and Time-of-Check-to-Time-of-Use (TOCTTOU) vulnerabilities.

Picaros builds upon SROS2's security guarantees but is the first system to specifically address information-flow control for ROS2, tackling these challenges head-on by adopting a novel, decentralized approach.

Key Findings

▶ Watch: Challenges of DIFC for ROS2 and Picaros introduction (2:00)

Picaros introduces several significant contributions to the field of robotics security and decentralized information-flow control:

• First DIFC System for ROS2: Picaros is the pioneering system to implement decentralized information-flow control specifically tailored for the unique distributed and dynamic characteristics of the ROS2 environment. It fills a critical security gap not addressed by SROS2.
• Novel ABE-based Approach: The system innovatively casts the DIFC access control problem within the framework of Attribute-Based Encryption (ABE). This provides a robust cryptographic primitive for enforcing fine-grained data access policies in a decentralized manner.
• Adherence to ROS2's Decentralized Ethos: Crucially, Picaros leverages a decentralized multi-authority ABE scheme, meticulously avoiding any centralized components. This design choice fully respects and integrates with ROS2's inherent distributed architecture, ensuring scalability and resilience.
• Enhanced Usability through Topic-Derived Labels: Picaros significantly reduces developer effort by automatically bootstrapping DIFC labels directly from existing ROS2 topic names. For example, a message published to ImageRaw by a Camera application might automatically receive a CAMERA:IMAGERAW tag, intuitively reflecting its provenance and semantic relevance.
• Strong Security Guarantees: Picaros securely binds labels to data objects, rigorously enforces both the no-reads-up and no-writes-down rules, and provides a mechanism for controlled declassification. It defends against unauthorized DIFC label modification and certain collusion attacks by integrating with SROS2's Public Key Infrastructure (PKI), TLS, and secure kernel-level storage.
• Practical Implementation and Feasibility: The Picaros team developed a working prototype seamlessly integrated into the ROS2 Humble Hawksbill and SROS2 stack. This implementation demonstrates the practical feasibility of their approach with real-world robotics applications.
• Comprehensive Performance Characterization: The research provides a detailed evaluation of Picaros's performance overhead on both microbenchmarks and complex iRobot application pipelines. This quantifies the impact on latency, memory, and power consumption, offering valuable insights for future optimization and deployment considerations.

Technical Deep Dive

▶ Watch: DIFC principles and Picaros' topic-based label generation (4:00)

Picaros's core technical innovation lies in its use of Attribute-Based Encryption (ABE) to implement DIFC. ABE is a cryptographic primitive where plaintext messages are encrypted under an access structure (a Boolean expression over a set of attributes), and a user's decryption key is associated with a set of attributes. A user can decrypt the ciphertext only if their attributes satisfy the access structure. Picaros utilizes simple Boolean conjunctions for access structures, which are sufficient for expressing DIFC policies.

A critical aspect of ABE for distributed systems is collusion resistance, ensuring that multiple users with partial attribute sets cannot combine their keys to decrypt unauthorized data. Picaros leverages the Lewko-Waters fully collusion-resistant, decentralized multi-authority ABE scheme, which eliminates the need for a centralized master key server after an initial global setup and supports dynamic participation.

The Lewko-Waters ABE API maps directly to DIFC requirements:

1. GlobalSetup($\lambda$) GP: This function is called once with a security parameter $\lambda$ to establish global parameters (GP) shared by all participants.
2. AuthSetup(GP, a) (PrivK$_a$, PubK$_a$): Each authority, which "owns" an attribute a, generates a private key (PrivK$_a$) and publishes a public key (PubK$_a$) for that attribute. In Picaros, a ROS2 application that is the first to add a specific tag to data objects it creates becomes an ABE authority for that tag. For example, the Camera application might be the authority for the CAMERA:IMAGERAW tag.
3. Encrypt(M, GP, PubK$_A$, A) C: A user encrypts a plaintext message M by providing an access structure A (a conjunction of attributes) and the public keys of the relevant authorities. In Picaros, when an application publishes a data object, it encrypts the object with an access structure A that is a conjunction of all tags in the data object's DIFC label. This directly enforces the no-writes-down rule, as the published data inherits all the publisher's tags.
4. Keygen(GID, GP, a, PrivK$_a$) K(a,GID): When a user with a globally-unique identifier (GID) needs to decrypt data associated with attribute a, it contacts the authority a. The authority uses its PrivK$_a$ to generate a decryption key K(a,GID) tailored for that specific user and attribute.
5. Decrypt(C, GP, K(a,GID)) M: The user decrypts the ciphertext C using the collected decryption keys. Decryption succeeds only if the user's attributes satisfy the access structure A. This directly enforces the no-reads-up rule: a consumer can decrypt data only if its label (attributes) includes all tags in the data object's label (access structure).

Key observations about this ABE mapping for DIFC:

• Decryption keys K(a,GID) are customized by GID, preventing collusion by combining keys from different users. They are also customized by attribute a.
• A user needs decryption keys from all authorities whose attributes appear in the access structure A.
• Mutable labels and capability sets are implemented by providing decryption keys. An application requesting to add a tag to its label is effectively requesting the corresponding decryption key from the tag owner.
• Declassification is handled by a trusted declassifier receiving the decryption key for a tag but not the corresponding encryption key. This allows the declassifier to decrypt data with that tag but publish its output without that specific tag in its label, effectively removing the sensitivity.

System Design and Architecture

Picaros is designed as a set of components that integrate seamlessly with the ROS2 software stack. The prototype is built atop ROS2 Humble Hawksbill with SROS2 patches, running on Ubuntu 20.04 with a Linux 5.11.0-46 kernel. Picaros's Trusted Computing Base (TCB) includes three main components:

1. Picaros-rclcpp: This is a modified ROS2 client library (specifically for C++ applications, with plans for Python's rclpy). It implements the ABE Encrypt and Decrypt functions. For cryptographic primitives, it uses the mcl library, which provides BN-254 elliptic curve group operations and optimal Ate pairing. Picaros-rclcpp reads encryption keys from a secure state-save area to encrypt outgoing messages and uses metadata in incoming ciphertexts to locate decryption keys for Decrypt.
2. Picaros-LKM: A loadable kernel module that securely stores artifacts related to an application's DIFC labels, including encryption and decryption keys, and its globally-unique identifier (GID). This is crucial for secure attribute storage and unforgeable identity. Picaros-LKM allocates and protects a user-space state-save area, making it readable and modifiable by Picaros-rclcpp but not by untrusted application code. This protection can be achieved using hardware memory domains like Intel MPK or ARM memory domains, or software-fault isolation.
3. Picaros-verif: A user-space ROS2 server that runs on each participating physical machine. It acts as an intermediary for key generation requests. When an application requests a decryption key from an authority, Picaros-verif authenticates the requestor's identity (using TLS and digital signatures) and verifies the source GID. It then instructs Picaros-LKM to add the received encryption and decryption keys to the application's secure storage. Crucially, Picaros-verif is only involved during initial key acquisition, not in the data path, ensuring decentralization.

Workflow for Tag Addition and Declassification

Consider the example of FormatConvertor needing to consume data from Camera and preserve its tag:

• When FormatConvertor receives an encrypted message from Camera (labeled CAMERA:IMAGERAW), its Picaros-rclcpp detects it lacks the necessary decryption key.
• FormatConvertor initiates a request to Camera for the K(CAMERA:IMAGERAW,FC) key, sending its GID (obtained from Picaros-LKM) over a TLS-secured ROS2 channel.
• Camera authenticates FormatConvertor via TLS and applies its domain-specific logic to decide if permission should be granted.
• If granted, Camera's Picaros-rclcpp invokes Keygen to generate K(CAMERA:IMAGERAW,FC) and sends it, along with PubK$_{CAMERA:IMAGERAW}$, back to FormatConvertor over TLS.
• FormatConvertor's Picaros-verif authenticates this response and instructs Picaros-LKM to add both keys to FormatConvertor's kernel keystore and state-save area.
• Now, FormatConvertor can decrypt Camera's messages and encrypt its own outgoing messages with PubK$_{CAMERA:IMAGERAW}$, effectively adding the CAMERA:IMAGERAW tag to its DIFC label.

For declassification, as with an ImgScrubber application:

• RealsenseCamera designates ImgScrubber as a trusted declassifier.
• RealsenseCamera grants ImgScrubber the decryption key K(CAMERA:IMAGERAW,ImgScrubber) but omits the encryption key PubK$_{CAMERA:IMAGERAW}$.
• This allows ImgScrubber to decrypt Camera's images but publish its sanitized output without the CAMERA:IMAGERAW tag, effectively declassifying the data. The output is then published in the clear or with a new, less restrictive label.

Implementation Details and Threat Analysis

Picaros is built on ROS2 release 8 (Humble Hawksbill) and leverages SROS2 patches, along with eProsima's Fast-RTPS 1.6.0 DDS implementation. The underlying ABE cryptography uses the mcl library 48, providing an implementation of the BN-254 elliptic curve group and optimal Ate pairing function.

The TCB for Picaros includes Picaros-rclcpp, Picaros-LKM, Picaros-verif, the OS kernel, and supporting libraries. It assumes hardware-based attestation at boot time to ensure the integrity of the OS kernel and Picaros-LKM. Standard process-level isolation and protection mechanisms are assumed for Picaros-verif and Picaros-rclcpp. The secure state-save area for keys is protected using memory domains (Intel MPK or ARM memory domains) or software-fault isolation.

Picaros operates under the same threat model assumptions as SROS2, considering runtime exploits that subvert the OS kernel or Picaros-LKM, or memory-error attacks in C++ applications (e.g., control-flow hijacking, ROP) to be out-of-scope. Picaros's goal is to provide information-flow control on top of SROS2's existing security guarantees.

Regarding specific threat analysis:

• Unauthorized DIFC label modification: Picaros prevents malicious applications from arbitrarily adding or deleting tags. Any request to add or delete ABE keys must be authenticated by Picaros-verif using TLS and digital signatures, and securely stored by Picaros-LKM in kernel space and the protected state-save area.
• Collusion attacks: The Lewko-Waters ABE construction inherently prevents users with different GIDs from combining decryption keys. Picaros further strengthens this by read-protecting decryption keys within the Picaros-LKM and state-save area. However, a limitation is that if a malicious user legitimately obtains a decryption key for a single attribute (e.g., K(CAMERA:IMAGERAW,FC)), they could potentially decrypt messages offline that are encrypted with that attribute, even if not authorized to receive them. The secure channel helps prevent the transmission of keys to unauthorized parties, but not their misuse if legitimately obtained.

Demo / Proof of Concept

▶ Watch: Difficulties of decentralized DIFC enforcement in ROS2 (5:00)

To demonstrate Picaros's end-to-end functionality and security guarantees, a real-life ROS2 application pipeline from NVidia's Isaac ROS platform demos was used as a case study. The pipeline illustrates a common scenario in robotics vision systems:

1. RealsenseCamera (A) publishes raw images to camera/color/image_raw (T1).
2. These images are processed by isaac_ros_dnn_encoders (B) and isaac_ros_tensor_rt (C), transforming them into tensors published to tensor_sub (T3).
3. Yolov5DecoderNode (D) performs object detection on the tensors, publishing results to object_detections (T4).
4. VisualizationNode (E) subscribes to both object_detections and camera/color/image_raw, then publishes an overlaid image (showing detected objects on the original image) to yolo5_processed_image (T5).
5. Finally, FoxGlove (F), a monitoring application, subscribes to yolo5_processed_image for visualization.

The Problem without DIFC: In a standard SROS2 setup, RealsenseCamera has no control over which downstream applications, like FoxGlove, can ultimately access its images. FoxGlove could directly obtain images from VisualizationNode, even if the RealsenseCamera owner considers the raw image data sensitive and wants to restrict its final recipients.

Picaros Solution:

1. Tag Definition: RealsenseCamera (A) is designated as an authority, owning the tag REALSENSECAMERA:CAMERA/COLOR/IMAGE_RAW (abbreviated as RscIMG).
2. Initial Encryption: Messages published by RealsenseCamera to camera/color/image_raw are encrypted with PubK_RscIMG.
3. Permission Granting (No-Writes-Down Enforcement): RealsenseCamera explicitly grants permissions to B, C, D, and E to consume its data by providing them with the necessary decryption keys, K(RscIMG,GID). These intermediate applications (B, C, D, E) preserve the RscIMG label. This means when they re-encrypt their outputs, they include PubK_RscIMG in the access structure, ensuring the data remains associated with its original provenance.
4. Access Denial (No-Reads-Up Enforcement): FoxGlove (F) is not granted the decryption key K(RscIMG,FoxGlove). Consequently, when FoxGlove subscribes to yolo5_processed_image from VisualizationNode, it receives encrypted messages that it cannot decrypt, effectively enforcing the no-reads-up rule and preventing unauthorized access to the RscIMG-tagged data.
5. Declassification Mechanism: To allow controlled external access, RealsenseCamera designates a Sanitizer (S) application as a trusted declassifier. Sanitizer subscribes to yolo5_processed_image (T5). RealsenseCamera grants Sanitizer the decryption key K(RscIMG,Sanitizer).
6. Sanitized Output: Sanitizer processes and sanitizes the image (e.g., blurring faces, redacting sensitive information). Crucially, when Sanitizer publishes its output to yolo5_processed_image, RealsenseCamera omitted PubK_RscIMG when granting declassifier privileges to Sanitizer. This allows Sanitizer to publish its output in the clear (or with a new, less restrictive label) under yolo5_processed_image, effectively declassifying the data.
7. Final Result: FoxGlove subscribes to yolo5_processed_image. It receives encrypted messages from VisualizationNode (which it cannot decrypt) and cleartext, sanitized messages from Sanitizer. This demonstrates Picaros's ability to enforce end-to-end DIFC, allowing the original data owner (RealsenseCamera) to control data flow, ensure sensitive content is scrubbed, and permit external consumption only of the declassified version.

This case study effectively illustrates how Picaros provides granular control over information flow, preventing unauthorized data exfiltration while still enabling necessary data processing and controlled release of sanitized information within complex ROS2 pipelines.

Defensive Implications

▶ Watch: Picaros' core innovation: Attribute-Based Encryption (ABE) (6:00)

Picaros provides a powerful framework for defenders seeking to enhance the security of ROS2-based robotic systems, particularly against data exfiltration and unauthorized data propagation. Here's how defenders can leverage this information:

1. Implement Fine-Grained Data Governance: Picaros allows data owners (applications like Camera) to define and enforce explicit policies on how their data is consumed and re-published downstream. Defenders should identify sensitive data sources within their ROS2 applications and use Picaros to associate appropriate DIFC labels. This shifts control from network-level access to data-centric policies.
2. Leverage Topic-Derived Labels for Usability: The automatic derivation of DIFC labels from ROS2 topics (e.g., CAMERA:IMAGERAW) significantly reduces the burden on developers. Defenders should encourage the use of semantically meaningful topic names that can naturally translate into effective security labels, minimizing the overhead of security policy definition.
3. Strategically Deploy Declassifiers: The declassification mechanism is crucial for preventing label creep and enabling practical data sharing. Defenders must carefully identify trusted applications that can act as declassifiers. These applications should be thoroughly vetted for security, as they represent a critical point where sensitive tags are removed. Their role is to sanitize or transform data before it's exposed to less trusted or external entities.
4. Strengthen the Trusted Computing Base (TCB): Picaros relies on a TCB comprising Picaros-rclcpp, Picaros-LKM, and Picaros-verif, along with the OS kernel. Defenders must ensure the integrity of these components. This includes implementing hardware-based attestation at boot time for the OS kernel and Picaros-LKM, and utilizing hardware memory domains (Intel MPK, ARM memory domains) or software-fault isolation to protect the secure state-save area for ABE keys. Regular security audits and patching of these TCB components are paramount.
5. Understand Performance Trade-offs: The evaluation reveals that Picaros introduces latency overhead (tens to hundreds of milliseconds) and increased resource consumption (up to 61.9% memory, 11% power). Defenders must benchmark Picaros in their specific deployments to understand the impact on real-time performance and system resources. This is particularly important for critical, time-sensitive robotics applications. Strategic use of declassifiers can mitigate the quadratic latency increase in long pipelines with many authorities.
6. Be Aware of Collusion Limitations: While Picaros's ABE scheme prevents collusion by combining keys from different users, the risk of offline decryption by a malicious user who legitimately obtains a single decryption key for an attribute remains. Defenders should implement strong access controls around key distribution and storage, and monitor for any unauthorized key acquisition, even if legitimate for a single attribute.
7. Integrate with Existing SROS2 Guarantees: Picaros builds upon SROS2's TLS-based confidentiality, integrity, and authentication. Defenders should ensure SROS2 is correctly configured and functioning, as Picaros assumes these underlying security guarantees. The combination of SROS2 and Picaros offers a more comprehensive security posture.
8. Plan for Delegation and Revocation: While not fully implemented in the current prototype, the underlying ABE schemes support delegation and revocation. Defenders should consider how these features, once integrated, can be used to manage dynamic access rights for applications that join or leave the ROS2 ecosystem, ensuring that permissions can be granted and revoked efficiently.

By strategically adopting and configuring Picaros, defenders can move beyond basic communication security to establish robust, data-centric information-flow policies, significantly reducing the attack surface for data exfiltration and ensuring the integrity and confidentiality of sensitive robotic data.

Key Takeaways

• SROS2 Lacks Fine-Grained DIFC: Despite providing foundational security, SROS2 does not offer mechanisms for data owners to control how their data is used or re-published by downstream applications, creating a critical data exfiltration vulnerability.
• Picaros Introduces Decentralized DIFC for ROS2: Picaros is the first system to implement information-flow control specifically for ROS2's distributed architecture, leveraging Attribute-Based Encryption (ABE) to enforce data usage policies without centralized components.
• ABE Enables Robust Policy Enforcement: Picaros maps DIFC rules (no-reads-up, no-writes-down) directly to ABE's encryption under access structures and decryption with attribute keys, providing strong cryptographic guarantees against unauthorized data access and propagation.
• Usability Enhanced by Topic-Derived Labels: Picaros reduces developer overhead by automatically generating DIFC tags from ROS2 topic names, making it easier to integrate security policies with existing application logic.
• Declassification is Essential for Practicality: The system supports declassification, allowing trusted applications to remove sensitive tags from data after processing, which is crucial for preventing "label creep" and enabling controlled sharing of sanitized information.
• Performance Overhead is a Consideration: While providing strong security, Picaros introduces significant latency (tens to hundreds of milliseconds) and resource consumption overhead, especially in pipelines with many accumulating tags, requiring careful performance evaluation in real-world deployments.

About the Speaker(s)

Nishit V. Pandya is a researcher affiliated with the Indian Institute of Science. His work, as presented in the talk on Picaros, focuses on advancing the security of distributed robotics systems, particularly within the ROS2 framework, by applying advanced cryptographic techniques to address challenges in information-flow control.