We had a great second meeting for the folks in other time zones. In attendance were people from Amazon, RTI, Alias Robotics, UCSD, and Acutronic Robotics. Unfortunately I completely forgot to record the meeting so the only artifact is the summary below.
I’m tentatively going to schedule the next meeting for October 30th @ 08:00 AM PDT. Please let me know in the next couple of days if this is not a convenient time, otherwise I will post here with the meeting details.
Summary
-
Alias
- Current in assessment phase for ROS2
- General check for vulnerabilities
- Interest in collaborating on threat model
-
RTI
- Not working specifically on security for ROS2
- Should parts of DDS need augmentation, happy to collaborate on them
-
Threat model
- Collaborate via a wiki on SROS2 repo
- Want to start with a less complex, publicly available system to model as an example
- Could use the Turtlebot3
- Victor @ Acutronic offered to use https://acutronicrobotics.com/modularity/mara/ as a possible alternative
-
Should security be exclusive with performance?
- Need to balance security and performance
- May want to have subset of nodes secure
- May only sign or could be sensitive data
- Publicly known data not very sensitive
- High performance, high through put topics may not tolerate problem
-
Does the sensitivity of the data merit the performance hit (tf or odometry)
- Someone could reconstruct sensitive information from non-sensitive data
- Reconstruct context based on partial information
- Default should be total security
- Model how does partial disclosure affect the system
- There is a paper in the SROS2 tutorial about security, latency, throughput
-
Realtime systems
- Security on realtime systems could impact the realtime aspects
- Various security related functions that will need to happen
- Handshake could cause some non-deterministic elements which would be detrimental to realtime
- Are there other non-deterministic security related functions that could affect realtime systems?
-
How do we deal with security failures?
- Extend lifecycle state related to safety of the component
- Allow system to recover by fixing the issue
- Could have mediator that fixes the issue
- This could have problems if nodes begin requesting permissions not needed before
- Nodes/messages could be marked as critical and cause an error if those messages are not able to be processed due to permission errors
- Would require the CA to live close to the system
- Have specific error modes when permission
-
SROS2 tutorial has a walkthrough on securing Turtlebot3
- Compilation has problems since there’s not a 32-bit build of ROS2
- Use QEMU to cross-compile
- Problems getting the XRCE agent with security enabled, could not communicate with the XRCE node
- Ended up with insecure XRCE nodes and using the RTI router to connect it to the rest of the secure graph
- Need agent to be able to relay the XRCE traffic under it’s own GUID potentially?
Thanks for everyone for attending!