We at Canonical care deeply about robotics. We firmly believe that robots based on Linux are cheaper to develop, more flexible, more secure, and faster to market. One of the contributing factors to this being the case is the Robot Operating System (ROS). ROS is by far the most popular middleware for creating Linux-powered robots. It provides all sorts of open source tools and libraries and pre-made components that solve common problems encountered during robot development. This allows roboticists to avoid needing to reinvent the wheel and instead focus on what really makes their robot unique. Of course, another reason we care about ROS is that most of the ROS community use Ubuntu. We love our users, and we want to make sure the experience they have on Ubuntu is consistently stellar!
We also care deeply about security, and that permeates everything we do. We’ve all seen how the IoT wave has been going in this regard: badly. IoT devices are low-margin, and no one has any incentive to keep them up to date or ensure that they’re secure in the first place. Manufacturers want to drive costs down, and users don’t consider the devices computers and don’t give a second thought to connecting them to the internet. It’s an unfortunate set of circumstances.
We think that the best way out of this situation is to make security and maintenance so easy that it becomes the obvious choice. If it was suddenly easier and cheaper for device manufacturers to create secure devices that can be automatically updated, why wouldn’t they do it? That’s the premise behind snaps and Ubuntu Core: by making complex topics like security and updates transparent and straightforward, we can make the entire ecosystem better for everyone.
Now, we aren’t quite that naive. A secure and robust operating system and packaging and update process are only pieces of a puzzle. If the software running on the devices has security holes, the picture is incomplete. Which brings us back to robotics and ROS.
Robotics is a realm of experimentation: evaluating different hardware and software, pushing ahead with what works, and culling what doesn’t. ROS 1, the version used by most production robots, was designed to be flexible to enable this experimentation. The flexibility of allowing existing components to be easily combined with new ones or swapped with others was valued above all else, at the cost of security.
We haven’t quite seen a wave of robots like we’ve seen with IoT, but we’re pretty sure it’s coming, and we want to make sure it doesn’t suffer the same fate. Just like IoT, the best way to make sure a production robot is secure is to make security as easy and transparent as possible. This is why we’re so interested in ROS 2.
ROS 2 is undergoing active development and is being built with the flexibility of ROS 1 while also supporting the technology necessary to secure it at its very core. A while ago, we joined the effort of fleshing out the ROS 2 security story; we’ve been helping with the design as well as software implementation. In order to effectively coordinate this work as well as show our commitment to it, we’re pleased to announce that we have become a member of the ROS 2 Technical Steering Committee.
We’re genuinely excited to be a part of such an open source powerhouse, and look forward to bringing our security expertise to bear as ROS 2 matures. With the right push during its development, we’re convinced ROS 2 will develop into an ecosystem where security comes naturally.
This article originally appeared on Kyle Fazzari’s blog.