Security and usability are often paradoxically portrayed as a zero-sum trade off, particularly in traditional computing; where favor of one is assumed to the detriment of the other. Yet the truth is often more nuance; especially so for cyber physical systems. In many regards, security and usability in robotics are intertwined, and should instead be thought of as a positive-sum game; where the deficiency of one aspect may deprive potential from the other. This talk will focus on how to improve the security for robotic systems by improving the usability of SROS2 tooling, and by extension the development and verification processes adopted by ROS users.

1. Security and Usability:
Designing Security Tooling
That Roboticists Can Use
By: Ruffin White

2. Overview
● Repeatability and Reproducibility
○ Improving Development Progress
● Security and Usability
○ Improving Technology Transfer
● Proceduralized Access Control
○ Removing Human Factors
● Composable Policy Profiles
○ Simplify Access Control Language
● Formal Verification of Setup
○ Checking Data Flow Reachability
● Modeling for System Integration
○ Validating Non-functional Properties

3. Jorge Cham
Repeatability and Reproducibility
A major challenge for both
robotic software and research
● exacerbates maintenance
● impaires Code Quality
● limits stability & longevity
● impeades scientific progress
● waist engineering resources
● dissuades from participation
Code reuse among the primary
motivations for ROS; countering
siloing of robotic development and
fragmentation of software efforts
Quigley, Morgan, et al. "ROS: an open-source
Robot Operating System." ICRA workshop on
open source software. Vol. 3. No. 3.2. 2009.
F. Bonsignorio and A. P. del Pobil, “Toward
Replicable and Measurable Robotics
Research” IEEE R&A Magazine, no. 3, Sep
E. Guglielmelli, “Research Reproducibility
and Performance Evaluation For Dependable
Robots” IEEE R&A Magazine, no. 3, Sep.
“On Research Reproducibility:
An interview with Gianluca
Setti [Turning Point],” IEEE
R&A Magazine, no. 3, Sep.

4. R&D
Repeatability and Reproducibility
Adopt linux container technologies used in web
development to self-document or disseminate
dependencies and build/runtime configurations
● Affix build/run environments for debugging
● Consistency between dev and deployment
● Publish scientific code alongside literature
● Replicate experimental setup and results
● Archive binaries/environments for posterity
● Prolong support and migration grace period
● Lowering barriers in external collaboration
● Simplify/share cross compilation tool chain
● Facilitate faster Continuous Integration
Official ROS images [1, A] used in research and
industry, including nightly build tracking the latest
ROS2 devel. E.g. Navigation2
Using CircleCI and Docker
i386 amd64 armhf amd64
Field Robot
Deployments

5. Security and Usability
Tech transfer between Research and Industry is essential
for accelerating the field of robotics. Exchange barriers for
algorithms or infrastructure only impair robot development
● Security contributes to the privacy, availability, and
integrity of robotic Cyber Physical Systems (CPS),
furthering their practicality and commercial value
● Security shortcomings of robotic frameworks used
in research remains a limiting factor for industry
adoption, given real world requirements and risks
● Security in middleware frameworks adds additional
complexity; if left unchecked, this may deteriorate
overall usability, and ultimately avoided by users

6. Security and Usability
SROS1 was developed as a retrofit to the ROS1 API and ecosystem
to support modern cryptography and security measures [2-5,B,C].
● Pros: Among the most thorough security effort for ROS1
○ Encryption, Authentication, Authorization
○ API compatible over all IPC
○ No additional SPoF
● Cons: Restricted client library support limited usability
○ Lack of QoS options given TLS/TCP limitations
○ Unruly master-slave API complexified permissions
○ Tight coupling to limited transport abstraction
SROS2 builds upon Secure DDS for transport security, while focusing
on usability; e.g. extending ideas and patterns gained from SROS1 [D]
● PKI keystores and CA management
● Compilation of ROS2 IPC rules to DDS Permissions
● Profiling and modeling permission requirements
Master API
Key Server API
Parameter API
Slave API
XMLRPC
(HTTPS)
Node
Master
Params
Key
Serv
er

7. Proceduralized Access Control
Procedurally Provision Access Control for Robotic
Systems via development of meta build systems to
compile cryptographic artifacts for using SROS2, DDS
middlewares via ComArmor and Keymint [6,D].
● Remove human factors via automation tooling
● Use high level Intermediate Representations (IR)
● Remain agnostic to the transport specifics
● Verify compiled artifacts match IR semantics
Provide SROS2 users a similar workspace build
environment for generating and testing cryptographic
artifacts, similar in respect to Ament or Catkin.
Used in tracing erroneous access control events in
ROS2 Ardent; both False Negatives - minimal complete
ness permissions is unsatisfied, and False Positives -
principle of least privilege is unmaintained.

8. Composable Policy Profiles
A Mandatory Access Control (MAC) language is defined
to profile fine grained permissions for distributed
computational graphs while abstract of transport. [6, D]
● Policy: collection of Profiles for Access Control
● Profile: composed of Rules or nested profiles
● Rule: specifies permission Type, Scope, Qualifier
● Scope: globbing expression matching Namespace
● Type: ROS IPCs, e.g. topic, service, action
● Qualifier: defines permission as Allow or Deny
● Deny: supersedes any alternate allows rules
A markup schema is used to facilitate importing and
modularization of larger and complex policies, enabling
the abstraction of common profile primitives for ROS
nodes, while also the reuse of rules between policy files.
<policy version="0.1.0"
xmlns:xi="http://www.w3.org/2001/XInclude">
<profiles>
<profile ns="/" node="talker">
<xi:include href="common/node.xml"
xpointer="xpointer(/profile/*)"/>
<topics publish="ALLOW" >
<topic>chatter</topic>
</topics>
</profile>
<profile ns="/" node="listener">
<xi:include href="common/node.xml"
xpointer="xpointer(/profile/*)"/>
<topics subscribe="ALLOW" >
<topic>chatter</topic>
</topics>
</profile>
</profiles>
</policy>
Profile.
Rule.
Import.
Permission.
common/
├─ node/
│ ├─ logging.xml
│ ├─ parameters.xml
│ └─ time.xml
└─ node.xml
<profile>
<topics publish="ALLOW" subscribe="ALLOW" >
<topic>parameter_events</topic>
</topics>
<services reply="ALLOW" request="ALLOW" >
<service>~describe_parameters</service>
<service>~get_parameter_types</service>
<service>~get_parameters</service>
<service>~list_parameters</service>
<service>~set_parameters</service>
<service>~set_parameters_atomically</servic
...

9. Formal Verification of Setup
Assessing connectivity and data flow reachability
within CPSs and for Network Reconnaissance and
Vulnerability Excavation of Secure DDS Systems [7]
Passive
● System discovery and Identification
○ What is the system for/doing?
● Profiling connectivity and dependencies
○ What are the critical components?
● Determining internal state of the system
○ How does/would the system behave?
Active
● Prioritizing attack vectors
○ Maximize effect and minimize effort
● Selective denial of service
○ Content aware data flow disruption
● Indirectly control the system
○ Isolate without direct intervention
Server
?
?
?
??
Know
External
Network
Unknown
Black Box
Device
Known
Local
Device
Unknown
External
Network
Robot
Knowledge
Threshold
Statistical estimation of resources
as in the German tank problem.
E.g. introspecting topic names to
infer hidden internal state, model
info, or topology of CPS structure.
?
?
?

10. Formal Verification of Setup
Network Reconnaissance via sniffing packet
traffic of DDS Security crypto handshakes that
exchange digitally signed permission tokens.
Cleartext Exchange of Permission Tokens:
1. Following Simple Discovery Protocol
Node A sends handshake request to B
2. Node A’s handshake request includes:
A’s signed x509 cert and permission token
+ Diffie-Hellman params and challenge
3. Node B responds with a handshake reply
4. Node B’s handshake reply includes:
B’s signed x509 cert and perm token
+ DH response, signed digest of request
5. A/B check token signature (included CA’s)
and use token to govern remote access
Data QoS Negotiation
Simple Discovery
Protocol
c.id
c.perm
`c.pdata
c.dsign_algo
c.kagree_algo
hash_c2
dh2
hash_c1
dh1
challenge1
A B
c.id
c.perm
c.pdata
c.dsign_algo
c.kagree_algo
hash_c1
dh1
challenge1
ocsp_status
OK
Example wireshark capture of participant
handshake exchange highlighting
permission token serialized in c.perm

11. Formal Verification of Setup
Publicly observed permission tokens used to formalise partially
observable model for reachability exploit potential, such as
affecting a target CPS functionality by proxied permissions [7]
● Validate permissions
○ Match grant: subject name, validity
○ Match rule: domain, criteria
○ Check criteria: topics, partitions, data tags
● Reason about reachability
○ Given permission file sets, find their entire intersect
○ Matching publisher with subscriber
○ Formal verification and Imandra + OCaml
permissions.p7s
<grant=...
<subject>
Signature
permissions.p7s
<grant=...
<subject>
Signature
permissions.p7s
<grant=...
<subject>
Signature
?

12. Formal Verification of Setup
<?xml version="1.0" encoding="UTF-8"?>
<dds>
<permissions>
<grant name="/talker">
<subject_name>CN=/talker</subject_name>
<validity>
<not_before>2013-10-26T00:00:00</not_before>
<not_after>2018-10-26T22:45:30</not_after>
</validity>
<allow_rule> <!-- multi and/or <deny_rule> -->
<domains>
<id_range> <!-- multi and/or <id> -->
<min>10</min>
<max>42</max>
</id_range>
</domains>
<publish> <!-- multi and/or pub/sub -->
<partitions> <!-- multi and/or <tags> -->
<partition>food</partition>
</partitions>
<topics>
<topic>foo/bar/pudding</topic>
<topic>foo/bar/test</topic>
<topic>foo/bar/*</topic>
</topics>
</publish>
</allow_rule>
<default>DENY</default> <!-- or >ALLOW< -->
</grant>
</permissions>
</dds>
<?xml version="1.0" encoding="UTF-8"?>
<dds>
<permissions>
<grant name="/listener">
<subject_name>CN=/listener</subject_name>
<validity>
<not_before>2014-10-26T00:00:00</not_before>
<not_after>2019-10-26T22:45:30</not_after>
</validity>
<allow_rule> <!-- multi and/or <deny_rule> -->
<domains>
<id_range> <!-- multi and/or <id> -->
<min>20</min>
<max>50</max>
</id_range>
</domains>
<subscribe> <!-- multi and/or pub/sub -->
<partitions> <!-- multi and/or <tags> -->
<partition>food</partition>
<partition>spam/*</partition>
</partitions>
<topics>
<topic>foo/bar/pudding</topic>
<topic>foo/baz/test</topic>
</topics>
</subscribe>
</allow_rule>
<default>DENY</default> <!-- or >ALLOW< -->
</grant>
</permissions>
</dds>
matching
topics

13. Formal Verification of Setup
Testbed for experimental simulation using software
defined networks and reconsence as-a-services using
containerized inference engines for attack pipeline [7].
● Passive Reconnaissance
a. Sniff packets via tshark
to obtain permission files
b. Generate heuristic graph
with admissible connectivity
c. Compute application layer topology
to infer network reachability
● Active Attack
a. Live network packet capture
b. Single out participant with data of interest
c. Cut off information flow to or from participant DDS
Model
XML
tokens
DDS
Perms
Siff
Capt.
publisher
publisher &
subscriber
subscriber
SAT
Solver
Recon
Attacker
Simulation
Controller

14. Modeling for System Integration
Future Work: Static Analysis of Non-functional
Properties for ROS systems at Design-time
● CI linters for checking:
○ Launch-file remapping
○ Dangling Topics
○ Unset Parameters
○ Incompatible QoS
○ Matching Message Types
● Secure Access Control
○ Enforced least privilege
○ Minimally complete permissions
○ Subsystem dataflow quarantine
● Resource Allocation
○ Inferencing runtime dependencies
○ Time scheduling limited resources
Similar idea to HAROS [8], but instead
for Non-functional Properties and ROS2

15. Acknowledgements
Ruffin White @ruffsl
UC San Diego
About Me: about.me/ruffin
Tully Foote
@tfoote
OSRF
Morgan Quigley
@codebot
OSRF
Mikael
Arguedas
@mikael
arguedas
Dr. Henrik I.
Christensen
UC San Diego
Dr. Gerardo
Pardo-
Castellote
RTI
Gianluca Caiazza
@ZJohnny
UNIVE
Dr. Bernhard
Dieber
JOANNEUM
Dr. Agostino
Cortesi
UNIVE

16. References
Cited Talks
A. R. White, “ROS + Docker: Enabling repeatable,
reproducible, and deployable robotic software via linux
containers,” 2015, ROSCon, Hamburg, Germany.
B. R. White, M. Quigley, “{,S}ROS: Securing ROS over the
wire, in the graph, and through the kernel,” 2016,
ROSCon, Seoul, South Korea.
C. R. White, G. Caiazza, “SROS: Current Progress and
Developments” 2017, ROSCon, Vancouver, Canada.
D. G. Pardo-Castellote, R. White, “Leveraging DDS
Security in ROS2” 2018, ROSCon, Madrid, Spain.
Cited Publications
1. R. White and H. Christensen, ROS and Docker. In: Robot Operating
System (ROS). Studies in Computational Intelligence, vol 707.
Springer, Cham, 2017, pp. 285–307.
2. R. White, M. Quigley, and H. Christensen, “SROS: Securing ROS
over the wire, in the graph, and through the kernel,” in Humanoids
Workshop: Towards Humanoid Robots OS. Cancun, Mexico, 2016.
3. G. Caiazza, R. White, and A. Cortesi, “Enhancing security in ROS,” in
Advances in Intelligent Systems and Computing, ser. International
Doctoral Symposium on Applied Computation and Security Systems,
vol. 5. Kolkata, India: Springer, 2017.
4. R. White, G. Caiazza, H. Christensen, and A. Cortesi, SROS1: Using
and Developing Secure ROS1 System. Robot Operating System
(ROS). Studies in Computational Intelligence. Springer, Cham, 2018.
5. B. Dieber, R.White, S. Taurer, B. Breiling, G. Caiazza, H. Christensen,
A. Cortesi, "Penetration testing ROS", Robot Operating System
(ROS). Studies in Computational Intelligence. Springer, Cham, 2019
6. R. White, G. Caiazza, H. Christensen, and A. Cortesi, “Procedurally
provisioned access control for robotic systems,” Intelligent Robots and
Systems (IROS), IEEE/RSJ International Conference, 2018.
7. R. White, G. Caiazza, C Jiang, X Ou, Z Yang, H. Christensen, and A.
Cortesi, “Network Reconnaissance and Vulnerability Excavation of
Secure DDS Systems” in IEEE EuroS&P Workshop: Software
Security for Internet of Things (SSIoT). Stockholm, Sweden, 2019
8. Santos, André, et al. "A framework for quality assessment of ROS
repositories." 2016 IEEE/RSJ International Conference on Intelligent
Robots and Systems (IROS). IEEE, 2016.
● SROS2 Github Repo
○ github.com/ros2/sros2
● SROS2 Tutorial | IROS 2019
○ ruffsl.github.io/IROS2018_SROS2_Tutorial
● SSIoT Workshop | IEEE EuroS&P 2019
○ www.cse.chalmers.se/~russo/ssiot19