advertisement

In our previous post, we configured the firewall and gave $PROGRAMMER_LAPTOP_IP access to the robot via SSH. But controlling a robot involves more than just external connections: a robot is a complex ecosystem of internal components, including a base controller, cameras, scanners, and motion modules. These components (ROS2 nodes) must communicate securely with each other. So how do we ensure internal communication between ROS2 nodes? 📚 Table of contents - Why node-to-node security is important - What is SROS2? - SROS2 configuration script overview - Step by step: sros2_setup() Bash function: security context summary - Next steps: Intrusion detection with Suricata Why node-to-node security is important In robotic systems powered by ROS2, nodes constantly exchange data, some of it sensitive, such as motion commands or camera feeds. Without encryption or access control, this data is vulnerable to tampering or eavesdropping, especially in networked environments such as factories or research laboratories. That's where SROS2 comes into play. What is SROS2? SROS2 (Secure ROS2) extends ROS2 with security mechanisms based on the DDS-Security standard. It uses OpenSSL to encrypt node communication and restrict access based on signed permissions. When configured, SROS2 creates a keystore directory that contains: - A Certification Authority (CA) - Each node: - Public certificate - Private key - Signed permissions file This configuration ensures that only authorized nodes can participate in the ROS2 ecosystem. SROS2 Configuration Script Overview To simplify the configuration, we create a script: sros2_setup() . This Bash function initializes a keystore and configures a node (base_controler ) for secure communication. It is assumed: - A working ROS2 installation - ROS2 user and workspace configured in an external script ( common.sh ) Step by step: sros2_setup() knock function 1. Install OpenSSL proper installation -y openssl 🔧 Ensures necessary cryptographic tools are available for SROS2 key generation. 2. Switch to ROS2 user sudo -u "$ROS_USER" bash -c '...' 🏃 Run the configuration in the context of the non-root ROS2 user. Inside the block: a. Get the ROS2 environment source /opt/ros/$ROS_DISTRO/setup.bash 🔗 Load the ROS2 environment variables. b. Create the keystore directory mkdir -p $ROS_WS/sros2_keystore c. Initialize the keystore and create keys security ros2 create_keystore $ROS_WS/sros2_keystore security ros2 create_key $ROS_WS/sros2_keystore base_controler 🔐 Generate a secure identity for base_controler node. 4. Define node permissions Create a file with the following XML content: 2025-01-01T00:00:00 2027-01-01T00:00:00 0 * * 📜 This permission file grants base_controler node access to all topics on domain ID 0. 5. Generate signed permissions file security ros2 create_permission $ROS_WS/sros2_keystore base_controler ✍️ Sign the permissions file using the CA to make it valid and executable. Security Context Summary With this function we now have: ✅ An initialized keystore for SROS2 ✅ A certificate and key pair for base_controler node ✅ A signed permission file that allows communication ✅ End-to-end encryption for internal robot node communication In combination with the previous security steps (AppArmor, Auditd, and firewall configuration), we are creating a layered security model for our robot. See code here Next Steps: Intrusion Detection with Suricata Now that encrypted communication is configured within the robot's internal architecture, the next step is to detect anomalies or intrusions in the network.

advertisement

advertisement