wolfSSL and wolfCrypt for ROS

General
1

Hi!

We’re thinking about porting the wolfSSL suite of security tools over to ROS, and would like some feedback.

  1. We think that the order of priority is: 1. wolfCrypt Cryptography library, 2. wolfBoot secure boot, 3. wolfSSL TLS.

  2. We think the wolfSSL products are a pretty good fit for ROS because we support some useful things for the industry verticals that ROS supports. For example, we support FIPS 140 crypto for government use, MISRA-C for automotive, DO-178 DAL A for things that fly.

  3. We also support a lot of the hardware cryptography and secure elements that we think should and will be used in deployments. Hardware cryptography is especially important for real time performance requirements.

Those are our thoughts, but we’re not experts on ROS! As such, we could use your help as we prioritize what parts of our product line we bring over to your environment. Please let us know what you think!

LS

3 Likes
2

Where do you see this work fitting in with the existing SROS/SROS2 stuff?

Do you have any usage with DDS Security?

1 Like
3

Hi! I don’t have a good enough handle on SROS/SROS2 to answer that with specificity. That said, we expect wolfCrypt could be consumed by SROS/SROS2 as needed, especially where FIPS, MISRA, or DO-178 are required. The same is true with DDS Security. I understand that RTI’s implementation of DDS Security is currently consuming OpenSSL cryptographic primitives, but it can consume ours as well.

The alternative to DDS Security for data in motion that we’ve implemented and released in the market is DTLS or TLS over DDS, as we are transport agnostic. We’ve also implemented a key server for DTLS over DDS that has a fair bit of fault tolerance built in.

LS

4

Hey there @Stefonic, welcome to the community! It’ll take a little while to get a handle on the interplay between DDS and ROS 2’s security features, we’ve all been there :stuck_out_tongue: . This design doc should help to bootstrap you somewhat.

The challenge I see in this with regards to ROS 2’s security features is that the DDS features we’re relying on right now are the built-in plugins from DDS-Security. As such they’re a bit prescriptive in the cryptography department (see section 9.5 of the DDS-Security spec), for example:

DDS:Crypto:AES-GCM-GMAC provides authenticated encryption using Advanced Encryption Standard (AES) in Galois Counter Mode ( AES-GCM). It supports two AES key sizes: 128 bitsand 256 bits. It may also provide additional reader-specific message authentication codes (MACs) using Galois MAC ( AES-GMAC).

In order to do anything else, I think we’ll need new plugins that don’t follow the built-in spec, but still abide by the overall interface (section 8.5 of the DDS-Security spec). That’s probably not an insignificant amount of work, particularly considering that this is on a per-DDS-implementation basis.

Regarding just swapping wolfSSL for whatever library may or may not be used, that will again be down at the DDS implementation level. The ROS security features build on top of that.

1 Like