News about another major security breach is all too common today. To gain insight into just how well smart home devices confirm to requirements for secure storage, secure communications, and reduced attack surface categories, the global security lab Riscure reverse engineered a dozen devices and published its findings.
FierceElectronics interviewed Managing Director Maarten Bron to learn more about the deficiencies they identified and what companies and embedded developers can do to reach a higher level of security robustness.
FE: How did you conduct this research and in a nutshell, what was the key conclusion?
Bron: We were curious about the “state of security,” and so we took a dozen or so webcams, door locks, routers, wifi gateways etc. and analyzed them by reverse engineering the firmware and studying the internals that way. In the cases that the device had a mobile app, we also looked at the app. As a benchmark we took the ETSI cybersecurity spec for consumer IoT and mapped the findings accordingly. You can see the results in our whitepaper, yet there are certain categories in which none of the devices met the requirements.
FE: Can you point to one of the worst examples of an insecure smart home device?
Bron: Without going into the specifics of a single device, we oftentimes see things related to bootloaders, outdated versions of operating systems, improper configuration of communication protocol stacks. In itself these can all lead to exploits.
FE: With all the things that product developers need to worry about, is security something of an afterthought in products like smart home devices?
Bron: Security is something that needs to be baked in from the beginning, as opposed to being “sprinkled on” at the end. So yes, unless security is part of the design it really is an afterthought. Developers have a lot of things to worry about such as compliance, features, time to market, and the avoidance of mass-brick-events / warranty claims. In a world where security awareness amongst the general public is still growing, there are situations where other things besides security are higher on the priority list.
FE: Are security standards lagging or leading?
Bron: That’s an interesting question. In case a device undergoes security evaluation, the standard for security is implicitly defined by the requirements it is supposed to satisfy. This is often expressed as “attack resistance” of a certain level, against an attacker with a certain “attack potential.” The attack potential of hackers increase over time, so in its very essence the standard is never lagging. In practice though, where security standards are lagging is in the area of alignment, and the white paper contains only a few of a long list of security evaluation schemes / standards. All aimed at more or less the same security and privacy objectives, yet through different categories and rating schemes. This makes it hard for IoT developers to implement a proverbial single “security stack.”
FE: To build the right level of security into connected devices, developers must consider a multitude of vulnerabilities including runtime control, firmware updates, password issues, and more. With so much to consider, what are the areas to focus on that will give them the “biggest bang for the buck,” so to speak?
Bron: To start with secure boot, hands down. There’s a lot of silicon available nowadays that have the building blocks that allow for a good secure boot implementation. Process separation is also a good thing to have. The Arm Platform Security Architecture (PSA) program for instance gives IoT developers the assurance that PSA-certified chips function as full-fledged hardware Root of Trust, and that’s a solid foundation to build the rest of your IoT device on.
FE: Is security just the engineer’s job, or do others need to be involved (and if so who are they?).
Bron: At Riscure, our vision is one of Security at Scale. Only if security scales, it will make an impact. As per Gartner, there’s going to be more than 20 billion IoT devices online by the year 2025, that’s a lot of security engineers to make that happen. Automation could be an attractive way to achieve scale, and at Riscure we are working on solutions for developers to aid them in making embedded security an integral part of their workflow. Tooling will be able to analyse and optimize code for security, and to inject countermeasures. Keep in mind though that security knows several dimensions, and supply chain security is also an important factor. ‘Perceived security’ by consumer can also be an issue. If a de-facto secure product is perceived as being unsecure, consumers may be less likely to buy and use it.
FE: What words of advice do you have for an embedded developer working on smart home devices today when it comes to building a secure product?
Bron: You will often find yourself in the situation where your next project is an iteration of previous work (hardware designs, software libraries etc.), i.e. not an empty canvas situation. That is in itself a nice starting point to incrementally increase the level of security provided by your system. The ETSI technical specification referenced in the whitepaper is a good starting point of things to consider. Implement those security features related to hardware first. Followed by firmware, realtime OS, and application. In some situations, the developer will be in control of the application layer only, but there’s often a lot to gain on that level too related to security telemetry and “logical” security.
Editor's Note: Maarten Bron will be speaking on strategies for embedded developers to build more secure IoT devices at our first online Embedded Innovation Week, a digital event series taking place Sept 28-Oct 1 with a focus on IoT, AI, security and more. For more information and to register for your free pass, click here https://www.fiercedigitaltechevents.com/embedded-innovation-week.
RELATED: