ROS 2 Security (SROS 2)

All data transmitted between authenticated ROS 2 nodes is encrypted to ensure confidentiality. This protects sensitive sensor data, control commands, and system state from eavesdropping. SROS 2 leverages the DDS Security: Crypto plugin to perform transparent encryption and decryption of messages on topics and services. Common algorithms like AES-GCM are used, providing both encryption and integrity verification for the payload, securing data in transit across potentially untrusted networks.

Fine-grained access control policies govern what actions an authenticated identity is allowed to perform. These policies are defined in XML files and specify permissions such as:

• Publish/Subscribe to specific topics
• Call/Provide specific services
• Read/Write specific parameters For example, a navigation node may be permitted to subscribe to /odometry but not to /camera/image_raw. This principle of least privilege minimizes the impact of a compromised node by restricting its capabilities within the system.

Security configuration is defined by two key XML documents. The Governance Document sets high-level security rules for an entire DDS Domain, specifying allowed security plugins and encryption algorithms. The Permissions Document is identity-specific, mapping a node's certificate to its exact set of allowed actions (topics, services). During startup, the DDS Security plugin validates the node's certificate and loads its corresponding permissions, enforcing the defined policy.

The sros2 utilities automate the complex process of generating and managing the security artifacts. Key commands include:

• sros2 key generate: Creates a Certificate Authority (CA) and private keys.
• sros2 key create: Issues identity certificates for nodes.
• sros2 policy generate: Automatically generates permission policies by introspecting a running ROS 2 system. These tools abstract the underlying PKI (Public Key Infrastructure) complexity, making it practical to deploy security in real robotic systems.

A fundamental, non-cryptographic security mechanism is network segmentation using the ROS_DOMAIN_ID. Nodes with different domain IDs (0-232) operate in completely isolated communication graphs. This simple integer acts as a virtual network partition, preventing accidental or malicious cross-talk between independent robotic systems sharing the same physical network. It is a critical first layer of defense, often used in conjunction with cryptographic security for multi-robot or multi-tenant deployments.

ROS 2 Security is built directly on the Data Distribution Service (DDS) Security specification (v1.1). This provides a standardized, middleware-level security model. The SROS 2 tools generate the necessary configuration files and credentials that enable DDS Security plugins (like RTI Connext DDS Secure or eProsima Fast DDS Secure) to enforce:

• Authentication: Verifying the identity of nodes using X.509 certificates.
• Encryption: Securing data in transit with cryptographic algorithms (e.g., AES-GCM).
• Access Control: Governing which nodes can publish/subscribe to specific topics or call services based on permissions files.

SROS 2 establishes a Public Key Infrastructure (PKI) for the ROS 2 graph. A central Certificate Authority (CA) is created to sign certificates for all participants. Each ROS 2 node receives a unique identity comprising:

• A private key (kept secure).
• A signed identity certificate (proving its identity).
• A permissions certificate (defining its allowed actions). This model allows for fine-grained identity-based security, where trust is rooted in the CA, and compromised nodes can be revoked by invalidating their certificates.

Security policies are defined in two XML documents:

• Governance File: Sets the global security rules for the domain, including the list of enabled security plugins (Authentication, Encryption, Access Control) and their properties (e.g., allowed cipher suites).
• Permissions File: A node-specific rulebook that grants fine-grained access. It uses subject names from certificates to specify exact allowances, such as:
  • Publish to /cmd_vel
  • Subscribe to /scan
  • Call the /compute_path service SROS 2 utilities auto-generate these files from a high-level policy description, simplifying management.

SROS 2 supports two primary models for defining node permissions:

• Topic-Based Access Control: Permissions are granted based on ROS communication constructs (topics, services, actions). This is the most common model, mapping directly to the ROS graph.
• Partition-Based Access Control: Permissions are granted based on DDS partitions—logical groups within a domain. This offers an alternative, DDS-native grouping mechanism that can be useful for certain architectural patterns. Permissions can specify allow or deny rules, enabling the implementation of least-privilege security principles where nodes only have the minimum access required for their function.

The sros2 package provides command-line tools to manage the security lifecycle:

• sros2 keys create: Generates the root CA and key pairs.
• sros2 keys generate: Creates identity and permission keys/certificates for a specific node or enclave.
• sros2 distribution: Securely distributes keys and certificates to remote machines.
• sros2 policy: Generates governance and permissions XML files from a YAML policy template. These utilities abstract the complexity of the underlying DDS Security configuration, making it operable for robotics engineers without deep PKI expertise.

An enclave is a security context within a ROS 2 process. A single Linux process can host multiple nodes, each in its own enclave with distinct security credentials. This enables:

• Secure composition: Multiple nodes with different security postures can run in one process, isolated by enclave boundaries.
• Performance: Avoids the overhead of inter-process communication (IPC) for tightly coupled, trusted nodes.
• Resource efficiency: Reduces memory and launch complexity compared to one-process-per-node. Enclaves are a key feature for balancing security granularity with system performance.

DDS Security is the underlying Object Management Group (OMG) standard that provides the pluggable security framework for ROS 2. It defines the cryptographic protocols and Quality of Service (QoS) policies that SROS 2 configures and manages. Its core plugins handle:

• Authentication: Verifying the identity of nodes using X.509 certificates.
• Cryptography: Encrypting and signing all data in transit.
• Access Control: Enforcing permissions defined in governance and permission files.
• Logging: Generating auditable security event logs. ROS 2 leverages a DDS Security-compliant middleware implementation (e.g., Cyclone DDS, RTI Connext) to activate these protections.

An X.509 certificate is a digital identity credential used in public key infrastructure (PKI) to authenticate participants in a ROS 2 graph. In SROS 2, each node, and often each domain, requires a unique certificate. Key attributes include:

• Subject Name: A unique identifier for the node (e.g., /talker_node).
• Public Key: Used to verify digital signatures and for key exchange.
• Issuer Signature: A cryptographic signature from a Certificate Authority (CA) that validates the certificate's authenticity.
• Validity Period: A defined timeframe during which the certificate is active. The SROS 2 utilities (ros2 security) automate the creation and management of these certificates, forming a chain of trust from a root CA down to individual node certificates.

A Governance file is an XML document that defines the high-level security policies for an entire ROS 2 domain. It acts as a rulebook that all participants must follow. Its primary functions are:

• Enabling Security Plugins: Specifies which DDS Security plugins (Authentication, Cryptography, Access Control) are required.
• Domain Rule Set: Defines default rules for topics and services, such as whether communication is allowed, encrypted, or signed.
• Topic Access Rules: Can specify granular permissions for specific topic names or use wildcards (e.g., rt/*). The governance file is signed by a domain CA and distributed to all nodes, ensuring a consistent security baseline across the system.

A Permissions file is an XML document that grants specific access rights to a single node or a group of nodes, as identified by their X.509 certificates. It is the node's "keycard" that defines what it is allowed to do. It contains:

• Grants: Sections tied to a specific node's subject name.
• Allow/Deny Rules: Explicit permissions for publishing, subscribing, or making service requests on specific topics and services.
• Validity Period: A timeframe matching the node's certificate validity. Each node loads its own signed permissions file. The Access Control plugin cross-references a node's requests against this file and the domain's governance file to enforce fine-grained access control.

A Secure ROS 2 Domain is a logical network partition (defined by a ROS_DOMAIN_ID) where all communication is protected by DDS Security policies. It is the operational environment created by deploying SROS 2. Key characteristics include:

• Cryptographic Isolation: Nodes without valid, trusted credentials cannot join or discover the domain.
• End-to-End Protection: Data is encrypted between publisher and subscriber, even if routed through intermediate processes.
• Policy Enforcement: All communication adheres to the rules in the signed governance and permissions files. This contrasts with an unsecured domain, where nodes can freely discover and communicate, which is suitable only for trusted, isolated development networks.

A Security Enclave is a logical grouping of ROS 2 nodes that share a common set of security artifacts (certificates, keys, permissions). It is a conceptual container for managing trust boundaries within a larger system.

• Purpose: To simplify security administration by applying identical policies to a related set of nodes (e.g., all nodes on a single robot, or all navigation-related nodes).
• Management: Nodes within an enclave typically share a common intermediate CA, making certificate revocation and policy updates more efficient.
• Segmentation: Different enclaves can be established for different subsystems (perception, control, fleet management) to enforce the principle of least privilege and limit the impact of a potential compromise.