Earlier this year, the UK government put forward a strong series of arguments why security can’t be ignored in IoT devices, both by manufacturers as well as service providers and consumers.
Recognizing the benefits and opportunities of the IoT, the “Secure by Design, Improving the cyber security of consumer Internet of Things Report” said many internet-connected devices lack even basic cyber-security provisions, especially in the consumer market. It said there are two main risks:
The report said protecting consumers requires a fundamental shift in industry’s approach to managing cyber risks. There is a need to move away from placing the burden on consumers to securely configure their devices and instead ensure that strong security is built in by design.
In doing so, it put forward a draft code of practice. For device manufacturers, this is what it said:
All companies that provide internet-connected devices and services must provide a public point of contact as part of a vulnerability disclosure policy in order that security researchers and others are able to report issues. Disclosed vulnerabilities should be acted on in a timely manner.
Knowing about a security vulnerability allows companies to respond. Companies should also continually monitor for, identify and rectify security vulnerabilities within their own products and services as part of the product security lifecycle. Companies are encouraged to share information with competent industry bodies.
All software components in internet-connected devices should be securely updateable. Updates must be timely and not impact on the functioning of the device. An end-of-life policy must be published for end-point devices which explicitly states the minimum length of time for which a device will receive software updates and the reasons why. For constrained devices that cannot physically be updated, the product should be isolatable and replaceable.
Any credentials must be stored securely within services and on devices. Hard-coded credentials in device software are not acceptable.
Reverse engineering of devices and applications can easily discover credentials such as hard-coded usernames and passwords in software. Simple obfuscation methods also used to obscure or encrypt this hard-coded information can be trivially broken. Security-sensitive data that should be stored securely includes, for example, cryptographic keys and initialization vectors. Secure, trusted storage mechanisms should be used such as those provided by a Trusted Execution Environment and associated trusted, secure storage. Stored credentials in services should follow best practices.
Security-sensitive data, including any remote management and control, should be encrypted when transiting the internet, appropriate to the properties of the technology and usage. All keys should be managed securely.
All devices and services should operate on the ‘principle of least privilege’; unused ports must be closed, hardware should not unnecessarily expose access, services should not be available if they are not used and code should be minimized to the functionality necessary for the service to operate. Software should run with appropriate privileges, taking account of both security and functionality.
Software on IoT devices must be verified using secure boot mechanisms. If an unauthorized change is detected, the device should alert the consumer/administrator to an issue and should not connect to wider networks than those necessary to perform the alerting function.
Resilience must be built into IoT services where required by the usage or other relying systems, such that the IoT services remain operating and functional.
If collected, all telemetry such as usage and measurement data from IoT devices and services should be monitored for security anomalies within it.
Implementing a root of trust for secure design
Essentially the key message here is that security really needs to be built into devices from the ground up. It’s easier to build an entire supply chain of trust if an IoT device is secure by design. The foundation of such an approach is to start by establishing a root of trust in the device right at the beginning – which means:
This can then be carried through the entire development, manufacturing and lifetime of a product, say through a secure microcontroller execution environment and an immutable boot path to a root of trust boot manager that verifies subsequent software before execution.
By integrating this embedded trust, it’s possible to manage keys and certificate structures for a product, providing protection from development to production manufacturing, and enable sure software updates through the life of a product.
The fact that governments are publishing documents advising on how to improve security is a clear message that cyber-security has become a key part of national agendas.
It’s also a message to industry to indicate that it needs to take security seriously. With hacking incidents becoming more prevalent in the news, these issues are now more in the public domain.
The result is the emergence of technologies enabling not just the design of secure semiconductors and elements, but also techniques to enable secure manufacturing of products that contain these devices. Companies such as Secure Thingz with its Secure Deploy technology are at the forefront of this drive to provide manufacturers with the capability to ensure secure programming and secure software updating, with a “zero trust” approach to ensure the highest levels of security.