Smart home devices fail security tests

To gain insight into just how well smart home devices conform 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.

In their study on the security of smart home devices, Riscure researchers observed that Zigbee and BLE implementations suffered most from misconfiguration and weak implementation strategies.

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.

The IX20 rugged, secure LTE router is a great choice for applications from basic connectivity to industrial-class and security solutions. Its high-performance architecture gives primary and backup WWAN over software selectable multi-carrier LTE.

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, the 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.

By:  Karen Field

From:  https://www.fierceelectronics.com/embedded/study-smart-home-devices-finds-security-shortcomings-all