Remember The Jetsons? This 1960s-era cartoon depicts space-age life, complete with flying cars and watches that let you call people. The Jetson household used home automation in everything from cooking to carpooling, with Rosey, the sassy robot housekeeper, making sure everything worked as it should.

We are quickly moving in a Jetsons direction with home automation and robotics. Over the last decade, home robotics such as smart thermostats, lighting controls and door cams — all of which may be controlled by an app on your phone — have become commonplace. Even my 80-something parents have a smart doorbell!

And this revolution doesn’t stop there. Amazon currently sells more than 1,000 different types of robotic vacuums to clean your floors and several dozen robotic lawnmowers to cut your grass. At Best Buy, you can buy smart refrigerators that automatically order milk when you run low, along with surveillance drones that patrol the perimeters of your home.

About the only thing you can’t find is a Rosey equivalent who can cook your meals, comfort your children — and oversee the software and firmware powering your other robots so that they’re not hacked or bricked. For this last item, you need software trust.

Why software trust is essential for home automation and robotics

There are already more than 7 billion home robotics and automation devices in use, a number that’s expected to grow dramatically over the next several years. And these devices are a hacker’s dream. In 2020, for example, more than 50,000 smart home cameras were hacked, with footage posted online for sale on adult websites. In another example, the Electronic Frontier Foundation advocates for safety and privacy regulations for smart door locks so that tenants are protected from being tracked or locked out of their apartments due to software breaches.

Now consider the damage that could take place if a robotic lawnmower or smart thermostat were hacked. Bad actors could override safety limits, causing temperature spikes in the HVAC that a smart thermostat is controlling, or program the lawnmower to injure people. In addition, inadequate security practices can prevent home robotics from functioning. A lost private key associated with a firmware update could cause an updated device to be bricked.

Software trust is not just about protecting attack surfaces, but also ensuring that products can function in the way that customers expect. Consumer loss of trust due to software breaches can be devastating to manufacturers. According to a 2022 survey sponsored by DigiCert, 47% of consumers have stopped doing business with a company that lost their trust, while 84% say they would consider switching companies that lost their trust.

The onus is on manufacturers to ensure that the software installed on their devices is safe and reliable and that any updates pushed out to improve safety and usability are equally safe and reliable. Not only do manufacturers need to think about how to keep their products secure once they’re in use, they also need to secure the code at its source: the developers that build and iterate it.

Product security is a developer responsibility

Software developers are under a great deal of pressure to deliver innovation. Their code must deliver competitive feature sets, while also fixing bugs that could cripple product functionality and customer satisfaction. And they must do this in increasingly faster cycles where new software releases may be measured in days or weeks instead of months or years. Because of this, security concerns may be secondary for them.

Added to these pressures, home automation and robotic devices utilize a complex system architecture with software in the device itself, software in a cloud infrastructure that controls and communicates with all the devices, and software in the back-office infrastructure which controls critical activities such as provisioning, software updates and billing, among other things.

A security vulnerability in the software of any of these creates a security vulnerability for everything. Moreover, there are additional security considerations to consider, including the communications between devices and the cloud, as well as between the cloud and on-premise servers.

Figure 1: Home automation and robotics systems require distributed software in three primary areas: the device itself, the cloud infrastructure that communicates with the device and the back-office system used for things like provisioning and billing.

Traditional enterprise security groups can provide guidance to product teams, but the fundamental responsibility of security should lie within the product and software teams. After all, they know a product’s software design, its overall system architecture, and the tools and processes used to create it better than anyone else.

In industries that utilize cloud infrastructure, product teams create specific roles on the product/software team for product security architects who ensure that security is built in every step of the way, across all components of the architecture. Home automation and robotics companies must do the same.

Best practices for software and product teams

There are a number of best practices that home automation and robotic vendors should embrace:

1. Deploy zero trust architectures: Assume zero trust for EVERYTHING hosted on premises, in the cloud and in the device. Employ security techniques to ensure this.
2. Implement principle of least privilege: Grant minimal access to the software and product team to accomplish their jobs — and no more.
3. Utilize code signing often and on everything: Sign everything at all stages of the software development process. This includes source code, build scripts and third-party libraries used during software development, testing and deployment.
4. Leverage Infrastructure as a Service (IaaS): Configuration files for containers and cloud environments, as well as build environments and everything throughout the CI/CD pipeline, should be treated as code — secured with signatures and version controlled.
5. Scan everything: Use threat, malware and tampering check tools to scan everything including code that you develop and any third-party code and open source software that you use. Do it often throughout the product lifecycle.
6. Secure secrets: Secrets come in many flavors, but code signing private keys are especially vulnerable. Do not store them on build machines or public webservers. As of June 1, 2023, the CA/Browser (CA/B) Forum requires that all code signing private keys must be secured in FIPS 140-2 compliant hardware.

How DigiCert is helping home robotics companies deliver software trust

DigiCert has helped multiple home automation and robotics companies deliver software trust, from devices ranging from robotic lawnmowers to home security devices. Some of the challenges our customers wished to solve included:

• standardizing private key storage practices,
• securing access and control to signing keys,
• securing firmware through centralized code signing practices, and
• securing over-the-air software updates from factory to device.

Software trust can mean the difference between delivering an innovation enabled by connected technology that is secure and can be trusted and one that can be potentially compromised and cause harm. And it can be the difference between a customer being delighted in their robot — or jettisoning it for the competition. This is where digital trust meets the real world.

Learn more about DigiCert® Software Trust Manager at https://www.digicert.com/software-trust-manager.