ROS 2 Robotic Systems Threat Model

Authors: Thomas Moulard, Juan Hortala Xabi Perez Gorka Olalde Borja Erice Odei Olalde David Mayoral

Date Written: 2019-03

Last Modified: 2021-01

This is a DRAFT DOCUMENT.

Table of Contents

• ROS 2 Robotic Systems Threat Model
  • Table of Contents
  • Document Scope
  • Robotic Systems Threats Overview
    • Defining Robotic Systems Threats
    • Robot Application Actors, Assets, and Entry Points
      • Robot Application Actors
      • Assets
      • Entry Points
    • Robot Application Components and Trust Boundaries
    • Threat Analysis and Modeling
    • Including a new robot into the threat model
  • Threat Analysis for the TurtleBot 3 Robotic Platform
    • System description
    • Architecture Dataflow diagram
      • Assets
        • Hardware
        • Processes
        • Software Dependencies
        • External Actors
        • Robot Data Assets
      • Entry points
      • Use case scenarios
      • Threat model
      • Threat Diagram: An attacker deploys a malicious node on the robot
      • Attack Tree
    • Threat Model Validation Strategy
  • Threat Analysis for the MARA Robotic Platform
    • System description
    • Architecture Dataflow diagram
      • Assets
        • Hardware
        • Network
        • Software processes
        • Software dependencies
        • External Actors
        • Robot Data assets
      • Use case scenarios
      • Entry points
      • Trust Boundaries for MARA in pick & place application
    • Threat Model
      • Attack Trees
      • Physical vector attack tree
      • ROS 2 API vector attack tree
      • H-ROS API vector attack tree
      • Code repository compromise vector attack tree
    • Threat Model Validation Strategy
    • Security Assessment preliminary results
      • Introduction
      • Results
        • Findings
  • References

Document Scope

This document describes potential threats for ROS 2 robotic systems. The document is divided into two parts:

1. Robotic Systems Threats Overview
2. Threat Analysis for the TurtleBot 3 Robotic Platform
3. Threat Analysis for the MARA Robotic Platform

The first section lists and describes threats from a theoretical point of view. Explanations in this section should hold for any robot built using a component-oriented architecture. The second section instantiates those threats on a widely-available reference platform, the TurtleBot 3. Mitigating threats on this platform enables us to demonstrate the viability of our recommendations.

Robotic Systems Threats Overview

Defining Robotic Systems Threats

We will consider as a robotic system one or more general-purpose computers connected to one or more actuators or sensors. An actuator is defined as any device producing physical motion. A sensor is defined as any device capturing or recording a physical property.

Robot Application Actors, Assets, and Entry Points

This section defines actors, assets, and entry points for this threat model.

Actors are humans or external systems interacting with the robot. Considering which actors interact with the robot is helpful to determine how the system can be compromised. For instance, actors may be able to give commands to the robot which may be abused to attack the system.

Assets represent any user, resource (e.g. disk space), or property (e.g. physical safety of users) of the system that should be defended against attackers. Properties of assets can be related to achieving the business goals of the robot. For example, sensor data is a resource/asset of the system and the privacy of that data is a system property and a business goal.

Entry points represent how the system is interacting with the world (communication channels, API, sensors, etc.).

Robot Application Actors

Actors are divided into multiple categories based on whether or not they are physically present next to the robot (could the robot harm them?), are they human or not and are they a “power user” or not. A power user is defined as someone who is knowledgeable and executes tasks which are normally not done by end-users (build and debug new software, deploy code, etc.).

Assets

Assets are categorized in privacy (robot private data should not be accessible by attackers), integrity (robot behavior should not be modified by attacks) and availability (robot should continue to operate even under attack).

Entry Points

Entry points describe the system attack surface area (how do actors interact with the system?).

Robot Application Components and Trust Boundaries

The system is divided into hardware (embedded general-purpose computer, sensors, actuators), multiple components (usually processes) running on multiple computers (trusted or non-trusted components) and data stores (embedded or in the cloud).

While the computers may run well-controlled, trusted software (trusted components), other off-the-shelf robotics components (non-trusted) nodes may be included in the application. Third-party components may be malicious (extract private data, install a root-kit, etc.) or their QA validation process may not be as extensive as in-house software. Third-party components releasing process create additional security threats (third-party component may be compromised during their distribution).

A trusted robotic component is defined as a node developed, built, tested and deployed by the robotic application owner or vetted partners. As the process is owned end-to-end by a single organization, we can assume that the node will respect its specifications and will not, for instance, try to extract and leak private information. While carefully controlled engineering processes can reduce the risk of malicious behavior (accidentally or voluntarily), it cannot completely eliminate it. Trusted nodes can still leak private data, etc.

Trusted nodes should not trust non-trusted nodes. It is likely that more than one non-trusted component is embedded in any given robotic application. It is important for non-trusted components to not trust each other as one malicious non-trusted node may try to compromise another non-trusted node.

An example of a trusted component could be an in-house (or carefully vetted) IMU driver node. This component may communicate through unsafe channels with other driver nodes to reduce sensor data fusion latency. Trusting components is never ideal but it may be acceptable if the software is well-controlled.

On the opposite, a non-trusted node can be a third-party object tracker. Deploying this node without adequate sandboxing could impact:

• User privacy: the node is streaming back user video without their consent
• User safety: the robot is following the object detected by the tracker and its speed is proportional to the object distance. The malicious tracker estimates the object position very far away on purpose to trick the robot into suddenly accelerating and hurting the user.
• System availability: the node may try to consume all available computing resources (CPU, memory, disk) and prevent the robot from performing correctly.
• System Integrity: the robot is following the object detected by the tracker. The attacker can tele-operate the robot by controlling the estimated position of the tracked object (detect an object on the left to make the robot move to the left, etc.).

Nodes may also communicate with the local filesystem, cloud services or data stores. Those services or data stores can be compromised and should not be automatically trusted. For instance, URDF robot models are usually stored in the robot file system. This model stores robot joint limits. If the robot file system is compromised, those limits could be removed which would enable an attacker to destroy the robot.

Finally, users may try to rely on sensors to inject malicious data into the system (Akhtar, Naveed, and Ajmal Mian. “Threat of Adversarial Attacks on Deep Learning in Computer Vision: A Survey.”).

The diagram below illustrates an example application with different trust zones (trust boundaries showed with dashed green lines). The number and scope of trust zones is depending on the application.

Diagram Source (edited with Threat Dragon)

Threat Analysis and Modeling

The table below lists all generic threats which may impact a robotic application.

Threat categorization is based on the STRIDE (Spoofing / Tampering / Repudiation / Integrity / Denial of service / Elevation of privileges) model. Risk assessment relies on DREAD (Damage / Reproducibility / Exploitability / Affected users / Discoverability).

In the following table, the “Threat Category (STRIDE)” columns indicate the categories to which a threat belongs. If the “Spoofing” column is marked with a check sign (✓), it means that this threat can be used to spoof a component of the system. If it cannot be used to spoof a component, a cross sign will be present instead (✘).

The “Threat Risk Assessment (DREAD)” columns contain a score indicating how easy or likely it is for a particular threat to be exploited. The allowed score values are 1 (not at risk), 2 (may be at risk) or 3 (at risk, needs to be mitigated). For instance, in the damage column a 1 would mean “exploitation of the threat would cause minimum damages”, 2 “exploitation of the threat would cause significant damages” and 3 “exploitation of the threat would cause massive damages”. The “total score” is computed by adding the score of each column. The higher the score, the more critical the threat.

Impacted assets, entry points and business goals columns indicate whether an asset, entry point or business goal is impacted by a given threat. A check sign (✓) means impacted, a cross sign (✘) means not impacted. A triangle (▲) means “impacted indirectly or under certain conditions”. For instance, compromising the robot kernel may not be enough to steal user data but it makes stealing data much easier.

Including a new robot into the threat model

The following steps are recommended in order to extend this document with additional threat models:

1. Determine the robot evaluation scenario. This will include:
   • System description and specifications
   • Data assets
2. Define the robot environment:
   • External actors
   • Entry points
   • Use cases
3. Design security boundary and architectural schemas for the robotic application.
4. Evaluate and prioritize entry points
   • Make use of the RSFrsf to find applicable weaknesses on the robot.
   • Take existing documentation as help for finding applicable entry points.
5. Evaluate existing threats based on general threat table and add new ones to the specific threat table.
   • Evaluate new threats with DREADwikipedia_dread and STRIDEwikipedia_stride methodologies.
6. Design hypothetical attack trees for each of the entry points, detailing the affected resources on the process.
7. Create a Pull Request and submit the changes to the ros2/design repository.

Threat Analysis for the TurtleBot 3 Robotic Platform

System description

The application considered in this section is tele-operation of a Turtlebot 3 robot using an Xbox controller.

The robot considered in this section is a TurtleBot 3 Burger. It is a small educational robot embedding an IMU and a Lidar, two motors / wheels, and a chassis that hosts a battery, a Pi Raspberry Pi 3 Model B+ Single Board Computer, and a OpenCR 1.0 Arduino compatible board that interacts with the sensors. The robot computer runs two nodes:

• turtlebot3_node forwarding sensor data and actuator control commands,
• raspicam2_node which is forwarding camera data

We also make the assumption that the robot is running a ROS 2 port of the AWS CloudWatch sample application). A ROS 2 version of this component is not yet available, but it will help us demonstrate the threats related to connecting a robot to a cloud service.

For the purpose of demonstrating the threats associated with distributing a ROS graph among multiple hosts, an Xbox controller is connected to a secondary computer (“remote host”). The secondary computer runs two additional nodes:

• joy_node is forwarding joystick input as ROS 2 messages,
• teleop_twist_joy is converting ROS 2 joystick messages to control commands.

Finally, the robot data is accessed by a test engineer through a “field testing” computer.

Architecture Dataflow diagram

Diagram Source (draw.io)

Assets

Hardware

• TurtleBot 3 Burger is a small, ROS-enabled robot for education purposes.
  • Compute resources
    • Raspberry PI 3 host: OS Raspbian Stretch with ROS 2 Crystal running natively (without Docker), running as root.
    • OpenCR board: using ROS 2 firmware as described in the TurtleBot3 ROS 2 setup instructions.
  • Hardware components) include:
    • The Lidar is connected to the Raspberry PI through USB.
    • A Raspberry PI camera module is connected to the Raspberry PI 3 through its Camera Serial Interface (CSI).
• Field testing host: conventional laptop running OS Ubuntu 18.04, no ROS installed. Running as a sudoer user.
• Remote Host: any conventional server running OS Ubuntu 18.04 with ROS 2 Crystal.

• CI host: any conventional server running OS Ubuntu 18.04.

• WLAN: a wifi local area network without security enabled, open for anyone to connect
• Corporate private network: a secure corporate wide-area network, that spans multiple cities. Only authenticated user with suitable credentials can connect to the network, and good security practices like password rotation are in place.

Processes

• Onboard TurtleBot3 Raspberry Pi
  • turtlebot3_node
  • CloudWatch nodes (hypothetical as it has not been yet ported to ROS 2)
    • cloudwatch_metrics_collector: subscribes to a the /metrics topic where other nodes publish MetricList messages that specify CloudWatch metrics data, and sends the corresponding metric data to CloudWatch metrics using the PutMetricsData API.
    • cloudwatch_logger: subscribes to a configured list of topics, and publishes all messages found in that topic to a configured log group and log stream, using the CloudWatch metrics API.
  • Monitoring Nodes
    • monitor_speed: subscribes to the topic /odom, and for each received odometry message, extract the linear and angular speed, build a MetricList message with those values, and publishes that message to data to the /metrics topic.
    • health_metric_collector: collects system metrics (free RAM, total RAM, total CPU usage, per core CPU usage, uptime, number of processes) and publishes it as a MetricList message to the /metrics topic.
  • raspicam2_node a node publishing Raspberry Pi Camera Module data to ROS 2.
• An XRCE Agent runs on the Raspberry, and is used by a DDS-XRCE client running on the OpenCR 1.0 board, that publishes IMU sensor data to ROS topics, and controls the wheels of the TurtleBot based on the teleoperation messages published as ROS topics. This channel uses serial communication.
• A Lidar driver process running on the Raspberry interfaces with the Lidar, and uses a DDS-XRCE client to publish data over UDP to an XRCE agent also running on the Raspberry Pi. The agent sends the sensor data to several ROS topics.
• An SSH client process is running in the field testing host, connecting to the Raspberry PI for diagnostic and debugging.
• A software update agent process is running on the Raspberry PI, OpenCR board, and navigation hosts. The agent polls for updates a code deployment service process running on the CI host, that responds with a list of packages and versions, and a new version of each package when an update is required.
• The CI pipeline process on the CI host is a Jenkins instance that is polling a code repository for new revisions of a number of ROS packages. Each time a new revision is detected it rebuilds all the affected packages, packs the binary artifacts into several deployment packages, and eventually sends the package updates to the update agent when polled.

Software Dependencies

• OS / Kernel
  • Ubuntu 18.04
• Software
  • ROS 2 Core Libraries
  • ROS 2 Nodes: joy_node, turtlebot3_node, rospicam2_node, teleop_twist_joy
  • ROS 2 system dependencies as defined by rosdep:
    • RMW implementation: we assume the RMW implementation is rmw_fastrtps.
    • The threat model describes attack with the security enabled or disabled. If the security is enabled, the security plugins are assumed to be configured and enabled.

See TurtleBot3 ROS 2 setup instructions for details about TurtleBot3 software dependencies.

External Actors

• A test engineer is testing the robot.
• A user operates the robot with the joystick.
• A business analyst periodically checks dashboards with performance information for the robot in the AWS Cloudwatch web console.

Robot Data Assets

• Topic Message
  • Private Data
    • Camera image messages
    • Logging messages (might describe camera data)
    • CloudWatch metrics and logs messages (could contain Intellectual Property such as which algorithms are implemented in a particular node).
      • Restricted Data
    • Robot Speed and Orientation. Some understanding of the current robot task may be reconstructed from those messages..
• AWS CloudWatch data
  • Metrics, logs, and aggregated dashboard are all private data, as they are different serializations of the corresponding topics.
• Raspberry Pi System and ROS logs on Raspberry PI
  • Private data just like CloudWatch logs.
• AWS credentials on all hosts
  • Secret data, provide access to APIs and other compute assets on the AWS cloud.
• SSH credentials on all hosts
  • Secret data, provide access to other hosts.
• Robot embedded algorithm (e.g. teleop_twist_joy)
  • Secret data. Intellectual Property (IP) theft is a critical issue for nodes which are either easy to decompile or written in an interpreted language.

Robot Compute Assets

• AWS CloudWatch APIs and all other AWS resources accessible from the AWS credentials present in all the hosts.
• Robot Topics
  • /cmd_vel could be abused to damage the robot or hurt users.

Entry points

• Communication Channels
  • DDS / ROS Topics
    • Topics can be listened or written to by any actor:
      1. Connected to a network where DDS packets are routed to,
      2. Have necessary permissions (read / write) if SROS is enabled.
    • When SROS is enabled, attackers may try to compromise the CA authority or the private keys to generate or intercept private keys as well as emitting malicious certificates to allow spoofing.
    • USB connection is used for communication between Raspberry Pi and OpenCR board and LIDAR sensor.
  • SSH
    • SSH access is possible to anyone on the same LAN or WAN (if port-forwarding is enabled). Many images are setup with a default username and password with administrative capabilities (e.g. sudoer).
    • SSH access can be compromised by modifying the robot
• Deployed Software
  • ROS nodes are compiled either by a third-party (OSRF build-farm) or by the application developer. It can be compiled directly on the robot or copied from a developer workstation using scp or rsync.
  • An attacker compromising the build-farm or the developer workstation could introduce a vulnerability in a binary which would then be deployed to the robot.
• Data Store (local filesystem)
  • Robot Data
    • System and ROS logs are stored on the Raspberry Pi filesystem.
    • Robot system is subject to physical attack (physically removing the disk from the robot to read its data).
  • Remote Host Data
    • Machines running additional ROS nodes will also contain log files.
    • Remote hosts is subject to physical attack. Additionally, this host may not be as secured as the robot host.
  • Cloud Data
    • AWS CloudWatch data is accessible from public AWS API endpoints, if credentials are available for the corresponding AWS account.
    • AWS CloudWatch can be credentials can allow attackers to access other cloud resources depending on how the account has been configured.
  • Secret Management
    • DDS / ROS Topics
      • If SROS is enabled, private keys are stored on the local filesystem.
    • SSH
      • SSH credentials are stored on the robot filesystem.
      • Private SSH keys are stored in any computer allowed to log into the robot where public/private keys are relied on for authentication purposes.
    • AWS Credentials
      • AWS credentials are stored on the robot file system.

Use case scenarios

• Development, Testing and Validation
  • An engineer develops code or runs tests on the robot. They may:
    • Restart the robot
    • Restart the ROS graph
    • Physically interact with the robot
    • Log into the robot using SSH
    • Check AWS console for metrics and log
• End-User
  • A user tele-operates the robot. They may:
    • Start the robot.
    • Control the joystick.
  • A business analyst may access AWS CloudWatch data on the console to assess the robot performance.

Threat model

Each generic threat described in the previous section can be instantiated on the TurtleBot 3.

This table indicates which TurtleBot particular assets and entry points are impacted by each threat. A check sign (✓) means impacted while a cross sign (✘) means not impacted. The “SROS Enabled?” column explicitly states out whether using SROS would mitigate the threat or not. A check sign (✓) means that the threat could be exploited while SROS is enabled while a cross sign (✘) means that the threat requires SROS to be disabled to be applicable.

Threat Diagram: An attacker deploys a malicious node on the robot

This diagram details how code is built and deployed for the “An attacker deploys a malicious node on the robot” attack.

Diagram Source (draw.io)

Attack Tree

Threats can be organized in the following attack tree.

Diagram Source (draw.io)

Threat Model Validation Strategy

1. Setup a TurtleBot with the exact software described in the TurtleBot3 section of this document.
2. Penetration Testing
   • Attacks described in the spreadsheet should be implemented. For instance, a malicious joy_node could be implemented to try to disrupt the robot operations.
   • Once the vulnerability has been exploited, the exploit should be released to the community so that the results can be reproduced.
   • Whether the attack has been successful or not, this document should be updated accordingly.
   • If the attack was successful, a mitigation strategy should be implemented. It can either be done through improving ROS 2 core packages or it can be a platform-specific solution. In the second case, the mitigation will serve as an example to publish best practices for the development of secure robotic applications.

Over time, new reference platforms may be introduced in addition to the TurtleBot 3 to define new attacks and allow other types of mitigations to be evaluated.

Threat Analysis for the MARA Robotic Platform

System description

The application considered in this section is a MARA modular robot operating on an industrial environment while performing a pick & place activity. MARA is the first robot to run ROS 2 natively. It is an industrial-grade collaborative robotic arm which runs ROS 2 on each joint, end-effector, external sensor or even on its industrial controller. Throughout the H-ROS communication bus, MARA is empowered with new possibilities in the professional landscape of robotics. It offers millisecond-level distributed bounded latencies for usual payloads and submicrosecond-level synchronization capabilities across ROS 2 components.

Built out of individual modules that natively run on ROS 2, MARA can be physically extended in a seamless manner. However, this also moves towards more networked robots and production environments which brings new challenges, especially in terms of security and safety.

The robot considered is a MARA, a 6 Degrees of Freedom (6DoF) modular and collaborative robotic arm with 3 kg of payload and repeatibility below 0.1 mm. The robot can reach angular speeds up to 90º/second and has a reach of 656 mm. The robot contains a variety of sensors on each joint and can be controlled from any industrial controller that supports ROS 2 and uses the HRIM information model. Each of the modules contains the H-ROS communication bus for robots enabled by the H-ROS SoM, which delivers real-time, security and safety capabilities for ROS 2 at the module level.

No information is provided about how ROS 2 nodes are distributed on each module. Each joint offers the following ROS 2 API capabilities as described in their documentation (MARA joint):

• Topics
  • GoalRotaryServo.msg model allows to control the position, velocity or/and effort (generated from models/actuator/servo/topics/goal.xml, see HRIM for more).
  • StateRotaryServo.msg publishes the status of the motor.
  • Power.msg publishes the power consumption.
  • Status.msg informs about the resources that are consumed by the H-ROS SoM,
  • StateCommunication.msg is created to inform about the state of the device network.
• Services
  • ID.srv publishes the general identity of the component.
  • Simulation3D.srv and SimulationURDF.srv send the URDF and the 3D model of the modular component.
  • SpecsCommunication.srv is a HRIM service which reports the specs of the device network.
  • SpecsRotaryServo.srv is a HRIM message which reports the main features of the device.
  • EnableDisable.srv disables or enables the servo motor.
  • ClearFault.srv sends a request to clear any fault in the servo motor.
  • Stop.srv requests to stop any ongoing movement.
  • OpenCloseBrake.srv opens or closes the servo motor brake.
• Actions:
  • GoalJointTrajectory allows to move the joint using a trajectory msg.

Such API gets translated into the following abstractions:

Topic	Name
goal	/hrim_actuation_servomotor_XXXXXXXXXXXX/goal_axis1
goal	/hrim_actuation_servomotor_XXXXXXXXXXXX/goal_axis2
state	/hrim_actuation_servomotor_XXXXXXXXXXXX/state_axis1
state	/hrim_actuation_servomotor_XXXXXXXXXXXX/state_axis2

Service	Name
specs	/hrim_actuation_servomotor_XXXXXXXXXXXX/specs
enable servo	/hrim_actuation_servomotor_XXXXXXXXXXXX/enable
disable servo	/hrim_actuation_servomotor_XXXXXXXXXXXX/disable
clear fault	/hrim_actuation_servomotor_XXXXXXXXXXXX/clear_fault
stop	/hrim_actuation_servomotor_XXXXXXXXXXXX/stop_axis1
stop	/hrim_actuation_servomotor_XXXXXXXXXXXX/stop_axis2
close brake	/hrim_actuation_servomotor_XXXXXXXXXXXX/close_brake_axis1
close brake	/hrim_actuation_servomotor_XXXXXXXXXXXX/close_brake_axis2
open brake	/hrim_actuation_servomotor_XXXXXXXXXXXX/open_brake_axis1
open brake	/hrim_actuation_servomotor_XXXXXXXXXXXX/open_brake_axis2

Action	Name
goal joint trajectory	/hrim_actuation_servomotor_XXXXXXXXXXXX/trajectory_axis1
goal joint trajectory	/hrim_actuation_servomotor_XXXXXXXXXXXX/trajectory_axis2

Parameters	Name
ecat_interface	Ethercat interface
reduction_ratio	Factor to calculate the position of the motor
position_factor	Factor to calculate the position of the motor
torque_factor	Factor to calculate the torque of the motor
count_zeros_axis1	Axis 1 absolute value of the encoder for the zero position
count_zeros_axis2	Axis 2 absolute value of the encoder for the zero position
enable_logging	Enable/Disable logging
axis1_min_position	Axis 1 minimum position in radians
axis1_max_position	Axis 1 maximum position in radians
axis1_max_velocity	Axis 1 maximum velocity in radians/s
axis1_max_acceleration	Axis 1 maximum acceleration in radians/s^2
axis2_min_position	Axis 2 minimum position in radians
axis2_max_position	Axis 2 maximum position in radians
axis2_max_velocity	Axis 2 maximum velocity in radians/s
axis2_max_acceleration	Axis 2 maximum acceleration in radians/s^2

The controller used in the application is a ROS 2-enabled industrial PC, specifically, an ORC. This PC also features the H-ROS communication bus for robots which commands MARA in a deterministic manner. This controller makes direct use of the aforementioned communication abstractions (topics, services and actions).

Architecture Dataflow diagram

Diagram Source (draw.io)

Assets

This section aims for describing the components and specifications within the MARA robot environment. Below the different aspects of the robot are listed and detailed in Hardware, Software and Network. The external actors and Data assests are described independently.

Hardware

• 1x MARA modular robot is a modular manipulator, ROS 2 enabled robot for industrial automation purposes.
  • Robot modules
    • 3 x Han’s Robot Modular Joints: 2 DoF electrical motors that include precise encoders and an electro-mechanical breaking system for safety purposes. Available in a variety of different torque and size combinations, going from 2.8 kg to 17 kg weight and from 9.4 Nm to 156 Nm rated torque.
      • Mechanical connector: H-ROS connector A
      • Power input: 48 Vdc
      • Communication: H-ROS robot communication bus
        • Link layer: 2 x Gigabit (1 Gbps) TSN Ethernet network interface
        • Middleware: Data Distribution Service (DDS)
      • On-board computation: Dual core ARM® Cortex-A9
      • Operating System: Real-Time Linux
      • ROS 2 version: Crystal Clemmys
      • Information model: HRIM Coliza
      • Security:
        • DDS crypto, authentication and access control plugins
    • 1 x Robotiq Modular Grippers: ROS 2 enabled industrial end-of-arm-tooling.
      • Mechanical connector: H-ROS connector A
      • Power input: 48 Vdc
      • Communication: H-ROS robot communication bus
        • Link layer: 2 x Gigabit (1 Gbps) TSN Ethernet network interface
        • Middleware: Data Distribution Service (DDS)
      • On-board computation: Dual core ARM® Cortex-A9
      • Operating System: Real-Time Linux
      • ROS 2 version: Crystal Clemmys
      • Information model: HRIM Coliza
      • Security:
        • DDS crypto, authentication and access control plugins
• 1 x Industrial PC: ORC include:
  • CPU: Intel i7 @ 3.70GHz (6 cores)
  • RAM: Physical 16 GB DDR4 2133 MHz
  • Storage: 256 GB M.2 SSD interface PCIExpress 3.0
  • Communication: H-ROS robot communication bus
    • Link layer: 2 x Gigabit (1 Gbps) TSN Ethernet network interface
    • Middleware: Data Distribution Service (DDS)
  • Operating System: Real-Time Linux
  • ROS 2 version: Crystal Clemmys
  • Information model: HRIM Coliza
  • Security:
    • DDS crypto, authentication and access control plugins
• 1 x Update Server: OTA
  • Virtual Machine running on AWS EC2
    • Operating System: Ubuntu 18.04.2 LTS
    • Software: Mender OTA server

Network

1. Ethernet time sensitive (TSN) internal network: Interconnection of modular joints in the MARA Robot is performed over a daisy chained Ethernet TSN channel. Each module acts as a switch, forming the internal network of the robot.
2. Manufacturer (Acutronic Robotics) corporate private network: A secure corporate wide-area network, that spans multiple cities. Only authenticated user with suitable credentials can connect to the network, and good security practices like password rotation are in place. This network is used to develop and deploy updates in the robotic systems. Managed by the original manufacturer.
3. End-user corporate private network: A secure corporate wide-area network, that spans multiple cities. Only authenticated user with suitable credentials can connect to the network, and good security practices like password rotation are in place.
4. Cloud network: A VPC network residing in a public cloud platform, containing multiple servers. The network follows good security practices, like implementation of security applicances, user password rotation and multi-factor authentication. Only allowed users can access the network. The OTA service is open to the internet. Uses of the cloud network:
   • Manufacturer (Acutronic Robotics) uploads OTA artifacts from their Manufacturer corporate private network to the Cloud Network.
   • Robotic Systems on the End-user corporate private network fetch those artifacts from the Cloud Network.
   • Robotic Systems on the End-user corporate private network send telemetry data for predictive maintenance to Cloud Network.

Software processes

In this section all the processes running on the robotic system in scope are detailed.

• Onboard Modular Joints
  • hros_servomotor_hans_lifecyle_node this node is in charge of controlling the motors inside the H-ROS SoM. This nodes exposes some services, actions and topics described below. This node publishes joint states, joint velocities and joint efforts. It provides a topic for servoing the modular joint and an action that will be waiting for a trajectory.
  • hros_servomotor_hans_generic_node a node which contains several generic services and topics with information about the modular joint, such as power measurement readings: voltage and current, status about the H-ROS SoM like cpu load or network stats, specifications about communication and cpu, the URDF or even the mesh file of the modular joint.
  • Mender (OTA client) runs inside the H-ROS SoM. When an update is launched, the client downloads this version and it gets installed and available when the device is rebooted.
• Onboard Modular Gripper: Undisclosed.
• Onboard Industrial PC:
  • MoveIt! motion planning framework.
  • Manufacturing process control applications.
  • Robot teleoperation utilities.
  • ROS 1 / ROS 2 bridges: These bridges are needed to be able to run MoveIT! which is not yet ported to ROS 2. Right now there is an effort in the community to port this tool to ROS 2.

Software dependencies

In this section all the relevant third party software dependencies used within the different components among the scope of this threat model are listed.

• Linux OS / Kernel
• ROS 2 core libraries
• H-ROS core libraries and packages
• ROS 2 system dependencies as defined by rosdep:
  • RMW implementation: In the H-ROS API there is the chance to choose the DDS implementation.
  • The threat model describes attacks with the security enabled and disabled. If the security is enabled, the security plugins are assumed to be configured and enabled.

See Mara ROS 2 Tutorials to find more details about software dependencies.

External Actors

All the actors interacting with the robotic system are here gathered.

• End users
  • Robotics user: Interacts with the robot for performing work labour tasks.
  • Robotics operator: Performs maintenance tasks on the robot and integrates the robot with the industrial network.
  • Robotics researcher: Develops new applications and algorithms for the robot.
• Manufacturer
  • Robotics engineer: Develops new updates and features for the robot itself. Performs in-site robot setup and maintainance tasks.

Robot Data assets

In this section all the assets storing information within the system are displayed.

• ROS 2 network (topic, actions, services information)
  • Private Data
    • Logging messages
      • Restricted Data
    • Robot Speed and Orientation. Some understanding of the current robot task may be reconstructed from those messages.
• H-ROS API
  • Configuration and status data of hardware.
• Modules (joints and gripper)
  • ROS logs on each module. Private data, metrics and configuration information that could lead to GDPR issues or disclosure of current robot tasks.
  • Module embedded software (drivers, operating system, configuration, etc.)
    • Secret data. Intellectual Property (IP) theft is a critical issue here.
  • Credentials. CI/CD, enterprise assets, SROS certificates.
• ORC Industrial PC
  • Public information. Motion planning algorithms for driving the robot (MoveIt! motion planning framework).
  • Configuration data. Private information with safety implications. Includes configuration for managing the robot.
  • Programmed routines. Private information with safety implications.
  • Credentials. CI/CD, enterprise assets, SROS certificates.
• CI/CD and OTA subsystem
  • Configuration data.
  • Credentials
  • Firmware files and source code. Intellectual property, both end-user and manufacturer.
• Robot Data
  • System and ROS logs are stored on each joint module’s filesystem.
  • Robot system is subject to physical attacks (physically removing the disk from the robot to read its data).
• Cloud Data
  • Different versions of the software are stored on the OTA server.
• Secret Management
  • DDS / ROS Topics
    • If SROS is enabled, private keys are stored on the local filesystem of each module.
• Mender OTA
  • Mender OTA client certificates are stored on the robot file system.

Use case scenarios

As described above, the application considered is a MARA modular robot operating on an industrial environment while performing a pick & place activity. For this use case all possible external actor have been included. The actions they can perform on the robotic system have been limited to the following ones:

• End-Users: From the End-user perspective, the functions considered are the ones needed for a factory line to work. Among this functions, there are the ones keeping the robot working and being productive. On an industrial environment, this group of external actors are the ones making use of the robot on their facilities.
  • Robotics Researcher: Development, testing and validation
    • A research engineer develops a pick and place task with the robot. They may:
      • Restart the robot
      • Restart the ROS graph
      • Physically interact with the robot
      • Receive software updates from OTA
      • Check for updates
      • Configure ORC control functionalities
  • Robotic User: Collaborative tasks
    • Start the robot
    • Control the robot
    • Work alongside the robot
  • Robotics Operator: Automation of industrial tasks
    • An industrial operator uses the robot in a factory. They may:
      • Start the robot
      • Control the robot
      • Configure the robot
      • Include the robot into the industrial network
      • Check for updates
      • Configure and interact with the ORC
• Manufacturer: From the manufacturer perspective, the application considered is the development of the MARA robotic platform, using an automated system for deployment of updates, following a CI/CD system. These are the actors who create and maintain the robotic system itself.
  • Robotics Engineer: Development, testing and validation
    • Development of new functionality and improvements for the MARA robot.
      • Develop new software for the H-ROS SoM
      • Update OS and system libraries
      • Update ROS 2 subsystem and control nodes
      • Deployment of new updates to the robots and management of the fleet
      • In-Place robot maintenance

Entry points

The following section outlines the possible entry points an attacker could use as attack vectors to render the MARA vulnerable.

• Physical Channels
  • Exposed debug ports.
  • Internal field bus.
  • Hidden development test points.
• Communication Channels
  • DDS / ROS 2 Topics
    • Topics can be listened or written to by any actor:
      1. Connected to a network where DDS packets are routed to.
      2. Have necessary permissions (read / write) if SROS is enabled.
    • When SROS is enabled, attackers may try to compromise the CA authority or the private keys to generate or intercept private keys as well as emitting malicious certificates to allow spoofing.
  • H-ROS API
    • H-ROS API access is possible to anyone on the same LAN or WAN (if port forwarding is enabled).
    • When authentication (in the H-ROS API) is enabled, attackers may try to vulnerate it.
  • Mender OTA
    • Updates are pushed from the server.
    • Updates could be intercepted and modified before reaching the robot.
• Deployed Software
  • ROS nodes running on hardware are compiled by the manufacturer and deployed directly. An attacker may tamper the software running in the hardware by compromising the OTA services.
  • An attacker compromising the developer workstation could introduce a vulnerability in a binary which would then be deployed to the robot.
  • MoveIt! motion planning library may contain exploitable vulnerabilities.

Trust Boundaries for MARA in pick & place application

The following content will apply the threat model to an industrial robot on its environment. The objective on this threat analysis is to identify the attack vectors for the MARA robotic platform. Those attack vectors will be identified and clasified depending on the risk and services implied. On the next sections MARA’s components and risks will be detailed thoroughly using the threat model above, based on STRIDE and DREAD.

The diagram below illustrates MARA’s application with different trust zones (trust boundaries showed with dashed green lines). The number and scope of trust zones is depending on the infrastructure behind.

Diagram Source (edited with Draw.io)

The trust zones ilustrated above are the following:

• Firmware Updates: This zone is where the manufacturer develops the different firmware versions for each robot.
• OTA System: This zone is where the firmwares are stored for the robots to download.
• MARA Robot: All the robots’ componentents and internal comunications are gathered in this zone.
• Industrial PC (ORC): The industrial PC itself is been considered a zone itself because it manages the software the end-user develops and sends it to the robot.
• Software control: This zone is where the end user develops software for the robot where the tasks to be performed are defined.

Threat Model

Each generic threat described in the main threat table can be instantiated on the MARA.

This table indicates which of MARA’s particular assets and entry points are impacted by each threat. A check sign (✓) means impacted while a cross sign (✘) means not impacted. The “SROS Enabled?” column explicitly states out whether using SROS would mitigate the threat or not. A check sign (✓) means that the threat could be exploited while SROS is enabled while a cross sign (✘) means that the threat requires SROS to be disabled to be applicable.

Attack Trees

In an atempt to analyze the different possible attacks before even happening, attack trees are created. This diagrams speculate about the possible attacks against the system in order to be able to counter them. Threats can be organized in the following attack trees. Attacks are ordered starting from the physical attack vector, continuing with network based attacks, and finishing with the support infrastructure for the robot.

Physical vector attack tree

The following attack tree describes the possible paths to be followed by an attacker for compromising the system.

Diagram Source (draw.io)

The next diagram shows the infrastructure affected on a possible attack based on a compromise of a physical communication port.

ROS 2 API vector attack tree

The following attack tree describes the possible paths to be followed by an attacker for physically compromising the system.

Diagram Source (draw.io)

The following diagram shows the infrastructure affected on a possible attack based on exploitation of the ROS 2 API.

H-ROS API vector attack tree

The following attack tree describes the possible paths to be followed by an attacker for compromising the system.

Diagram Source (draw.io)

The diagram below shows the infrastructure affected on a possible attack against MARA’s H-ROS API.

Code repository compromise vector attack tree

The following attack tree describes the possible paths to be followed by an attacker for compromising the system.

Diagram Source (draw.io)

The following diagram shows the infrastructure affected on a possible attack against the manufacturer code repository, showing its potential implications and consequences.

Threat Model Validation Strategy

1. Setup a MARA with the exact software described in the Components MARA section of this document.
2. Penetration Testing
   • Attacks described in the spreadsheet should be implemented. For instance, a malicious hros_actuator_servomotor_XXXXXXXXXXXX could be implemented to try to disrupt the robot operations.
   • Once the vulnerability has been exploited, the exploit should be released to the community so that the results can be reproduced.
   • Whether the attack has been successful or not, this document should be updated accordingly.
   • If the attack was successful, a mitigation strategy should be implemented. It can either be done through improving ROS 2 core packages or it can be a platform-specific solution. In the second case, the mitigation will serve as an example to publish best practices for the development of secure robotic applications.
   • For trainning purposes, an online playground (RCTF) exists to challenge roboticists to learn and discover robot vulnerabilities.
   • For an overall evaluation of the robots’ security measures, the Robot Security Framework (RSF) will be used. This validation has to be don e after the assessment is completed in order to have a realistic results.

Security Assessment preliminary results

Due to the iterative nature of this process, the results shown on this section may differ depending on the threat model’s version.

The results here presented are a summary of the discoveries made during the Acutronic Robotics’ MARA assessment. Prior to the assessment, in order to be time-effective, a threat analysis was done over the system and the most likely attack vectors were identified.

Introduction

Based on the threat model performed over MARA, an assessment has been performed in order to discover the vulnerabilities within. The content below is directly related to that threat model using all the attack vectors identified as starting points for the exercise.

This Security Assessment Report for Acutronic Robotics’ MARA components has been performed by Alias Robotics S.L. The targeted system for the assessment is the H-ROS powered MARA. H-ROS, the Hardware Robot Operating System, is a collection of hardware and software specifications and implementations that allows creating modular and distributed robot parts. H-ROS heavily relies on the use of ROS 2 as a robotic development framework.

This document presents an overview of the results obtained in the assessment. In it, we introduce a report focused on identifying security issues or vulnerabilities detected during the exercise.

Results

This assessment has evaluated the security measures present in the H-ROS SoM components. The evaluation has been done through a vulnerability and risk assessment, and the following sections are a summary of the findings.

The vulnerabilities are rated on a severity scale according to the guidelines stated in the Robot Vulnerability Scoring System (RVSS), resulting in a score between 0 and 10, according to the severity of the vulnerability. The RVSS follows the same principles as the Common Vulnerability Scoring System (CVSS), yet adding aspects related to robotics systems that are required to capture the complexity of robot vulnerabilities. Every evaluated aspect is defined in a vector, having its weight at the final score.

All assessment findings from the MARA are classified by technical severity. The following list explains how Alias Robotics rates vulnerabilities by their severity.

• Critical: Scores between 9 and 10
• High: Scores between 7 and 8.9
• Medium: Scores between 4 and 6.9
• Low: Scores between 0.1 and 3.9
• Informational: Scores 0.0

In the course of a first funded vulnerability assessment, 2 critical, 6 high, 13 medium and 6 low vulnerabilities have been found. The ones fixed by Acutronic Robotics are disclosed below using the following format:

Findings

References

1. Abera, Tigist, N. Asokan, Lucas Davi, Jan-Erik Ekberg, Thomas Nyman, Andrew Paverd, Ahmad-Reza Sadeghi, and Gene Tsudik. “C-FLAT: Control-FLow ATtestation for Embedded Systems Software.” ArXiv:1605.07763 [Cs], May 25, 2016. http://arxiv.org/abs/1605.07763.
2. Ahmad Yousef, Khalil, Anas AlMajali, Salah Ghalyon, Waleed Dweik, and Bassam Mohd. “Analyzing Cyber-Physical Threats on Robotic Platforms.” Sensors 18, no. 5 (May 21, 2018): 1643. https://doi.org/10.3390/s18051643.
3. Bonaci, Tamara, Jeffrey Herron, Tariq Yusuf, Junjie Yan, Tadayoshi Kohno, and Howard Jay Chizeck. “To Make a Robot Secure: An Experimental Analysis of Cyber Security Threats Against Teleoperated Surgical Robots.” ArXiv:1504.04339 [Cs], April 16, 2015. http://arxiv.org/abs/1504.04339.
4. Checkoway, Stephen, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, Stefan Savage, Karl Koscher, Alexei Czeskis, Franziska Roesner, and Tadayoshi Kohno. “Comprehensive Experimental Analyses of Automotive Attack Surfaces.” In Proceedings of the 20th USENIX Conference on Security, 6–6. SEC’11. Berkeley, CA, USA: USENIX Association, 2011. http://dl.acm.org/citation.cfm?id=2028067.2028073.
5. Clark, George W., Michael V. Doran, and Todd R. Andel. “Cybersecurity Issues in Robotics.” In 2017 IEEE Conference on Cognitive and Computational Aspects of Situation Management (CogSIMA), 1–5. Savannah, GA, USA: IEEE, 2017. https://doi.org/10.1109/COGSIMA.2017.7929597.
6. Denning, Tamara, Cynthia Matuszek, Karl Koscher, Joshua R. Smith, and Tadayoshi Kohno. “A Spotlight on Security and Privacy Risks with Future Household Robots: Attacks and Lessons.” In Proceedings of the 11th International Conference on Ubiquitous Computing - Ubicomp ’09, 105. Orlando, Florida, USA: ACM Press, 2009. https://doi.org/10.1145/1620545.1620564.
7. Dessiatnikoff, Anthony, Yves Deswarte, Eric Alata, and Vincent Nicomette. “Potential Attacks on Onboard Aerospace Systems.” IEEE Security & Privacy 10, no. 4 (July 2012): 71–74. https://doi.org/10.1109/MSP.2012.104.
8. Dzung, D., M. Naedele, T.P. Von Hoff, and M. Crevatin. “Security for Industrial Communication Systems.” Proceedings of the IEEE 93, no. 6 (June 2005): 1152–77. https://doi.org/10.1109/JPROC.2005.849714.
9. Elmiligi, Haytham, Fayez Gebali, and M. Watheq El-Kharashi. “Multi-Dimensional Analysis of Embedded Systems Security.” Microprocessors and Microsystems 41 (March 2016): 29–36. https://doi.org/10.1016/j.micpro.2015.12.005.
10. Groza, Bogdan, and Toma-Leonida Dragomir. “Using a Cryptographic Authentication Protocol for the Secure Control of a Robot over TCP/IP.” In 2008 IEEE International Conference on Automation, Quality and Testing, Robotics, 184–89. Cluj-Napoca, Romania: IEEE, 2008.https://doi.org/10.1109/AQTR.2008.4588731.
11. Javaid, Ahmad Y., Weiqing Sun, Vijay K. Devabhaktuni, and Mansoor Alam. “Cyber Security Threat Analysis and Modeling of an Unmanned Aerial Vehicle System.” In 2012 IEEE Conference on Technologies for Homeland Security (HST), 585–90. Waltham, MA, USA: IEEE, 2012.https://doi.org/10.1109/THS.2012.6459914.
12. Kleidermacher, David, and Mike Kleidermacher. Embedded Systems Security: Practical Methods for Safe and Secure Software and Systems Development. Amsterdam: Elsevier/Newnes, 2012.
13. Klein, Gerwin, June Andronick, Matthew Fernandez, Ihor Kuz, Toby Murray, and Gernot Heiser. “Formally Verified Software in the Real World.” Communications of the ACM 61, no. 10 (September 26, 2018): 68–77.https://doi.org/10.1145/3230627.
14. Lee, Gregory S., and Bhavani Thuraisingham. “Cyberphysical Systems Security Applied to Telesurgical Robotics.” Computer Standards & Interfaces 34, no. 1 (January 2012): 225–29. https://doi.org/10.1016/j.csi.2011.09.001.
15. Lera, Francisco J. Rodríguez, Camino Fernández Llamas, Ángel Manuel Guerrero, and Vicente Matellán Olivera. “Cybersecurity of Robotics and Autonomous Systems: Privacy and Safety.” In Robotics - Legal, Ethical and Socioeconomic Impacts, edited by George Dekoulis. InTech, 2017.https://doi.org/10.5772/intechopen.69796.
16. McClean, Jarrod, Christopher Stull, Charles Farrar, and David Mascareñas. “A Preliminary Cyber-Physical Security Assessment of the Robot Operating System (ROS).” edited by Robert E. Karlsen, Douglas W. Gage, Charles M. Shoemaker, and Grant R. Gerhart, 874110. Baltimore, Maryland, USA, 2013.https://doi.org/10.1117/12.2016189.
17. Morante, Santiago, Juan G. Victores, and Carlos Balaguer. “Cryptobotics: Why Robots Need Cyber Safety.” Frontiers in Robotics and AI 2 (September 29, 2015). https://doi.org/10.3389/frobt.2015.00023.
18. Papp, Dorottya, Zhendong Ma, and Levente Buttyan. “Embedded Systems Security: Threats, Vulnerabilities, and Attack Taxonomy.” In 2015 13th Annual Conference on Privacy, Security and Trust (PST), 145–52. Izmir, Turkey: IEEE, 2015. https://doi.org/10.1109/PST.2015.7232966.
19. Pike, Lee, Pat Hickey, Trevor Elliott, Eric Mertens, and Aaron Tomb. “TrackOS: A Security-Aware Real-Time Operating System.” In Runtime Verification, edited by Yliès Falcone and César Sánchez, 10012:302–17. Cham: Springer International Publishing, 2016.https://doi.org/10.1007/978-3-319-46982-9_19.
20. Ravi, Srivaths, Paul Kocher, Ruby Lee, Gary McGraw, and Anand Raghunathan. “Security as a New Dimension in Embedded System Design.” In Proceedings of the 41st Annual Conference on Design Automation  - DAC ’04, 753. San Diego, CA, USA: ACM Press, 2004. https://doi.org/10.1145/996566.996771.
21. Serpanos, Dimitrios N., and Artemios G. Voyiatzis. “Security Challenges in Embedded Systems.” ACM Transactions on Embedded Computing Systems 12, no. 1s (March 29, 2013): 1–10. https://doi.org/10.1145/2435227.2435262.
22. Vilches, Víctor Mayoral, Laura Alzola Kirschgens, Asier Bilbao Calvo, Alejandro Hernández Cordero, Rodrigo Izquierdo Pisón, David Mayoral Vilches, Aday Muñiz Rosas, et al. “Introducing the Robot Security Framework (RSF), a Standardized Methodology to Perform Security Assessments in Robotics.” ArXiv:1806.04042 [Cs], June 11, 2018. http://arxiv.org/abs/1806.04042.
23. Zubairi, Junaid Ahmed, and Athar Mahboob, eds. Cyber Security Standards, Practices and Industrial Applications: Systems and Methodologies. IGI Global, 2012. https://doi.org/10.4018/978-1-60960-851-4.
24. Akhtar, Naveed, and Ajmal Mian. “Threat of Adversarial Attacks on Deep Learning in Computer Vision: A Survey.” ArXiv:1801.00553 [Cs], January 2, 2018. http://arxiv.org/abs/1801.00553.
25. V. Mayoral Vilches, E. Gil-Uriarte, I. Zamalloa Ugarte, G. Olalde Mendia, R. Izquierdo Pisón, L. Alzola Kirschgens, A. Bilbao Calvo, A. Hernández Cordero, L. Apa, and C. Cerrudo, “Towards an open standard for assessing the severity of robot security vulnerabilities, the Robot Vulnerability Scoring System (RVSS),” ArXiv:807.10357 [Cs], Jul. 2018. https://arxiv.org/abs/1807.10357
26. G. Olalde Mendia, L. Usategui San Juan, X. Perez Bascaran, A. Bilbao Calvo, A. Hernández Cordero, I. Zamalloa Ugarte, A. Muñiz Rosas, D. Mayoral Vilches, U. Ayucar Carbajo, L. Alzola Kirschgens, V. Mayoral Vilches, and E. Gil-Uriarte, “Robotics CTF (RCTF), a playground for robot hacking,” ArXiv:810.02690 [Cs], Oct. 2018. https://arxiv.org/abs/1810.02690
27. L. Alzola Kirschgens, I. Zamalloa Ugarte, E. Gil Uriarte, A. Muñiz Rosas, and V. Mayoral Vilches, “Robot hazards: from safety to security,” ArXiv:1806.06681 [Cs], Jun. 2018. https://arxiv.org/abs/1806.06681
28. Víctor Mayoral Vilches, Gorka Olalde Mendia, Xabier Perez Baskaran, Alejandro Hernández Cordero, Lander Usategui San Juan, Endika Gil-Uriarte, Odei Olalde Saez de Urabain, Laura Alzola Kirschgens, “Aztarna, a footprinting tool for robots,” ArXiv:1806.06681 [Cs], December 22, 2018. https://arxiv.org/abs/1812.09490