As awareness grows among non-technical audiences of the perils of hacking resulting from more and more things in their lives and businesses becoming connected, government involvement in attempting to regulate is also increasing.
This is evident as the Australian government just recently published a draft ‘IoT Security Code’ as it looks at initiatives to address security in the internet of things (IoT) as part of its 2020 Cyber Security Strategy. The principles are fundamentally similar to that published by the IoT Security Foundation and recently updated in release 2 of its IoT Security Best Practice Guideline. These freely available guidelines help IoT products and services developers address the varied security issues that must be addressed to deliver a safe, secure, trusted and mature end product.
The IoT Security Foundation says the pressure is mounting upon creators of IoT products and services to ensure what they deliver is truly compliant and can be trusted by their customers.
The guidelines cover everything from secure device boot, operating system, credential management and encryption to secure software and software updates policy. In the latest release 2 of its guidelines, in addition to reviewing and updating its existing 11 guides, it added three topics:
Secure boot process guidelines
The new secure boot assessment guide helps ensure the boot process is designed to be secure, complemented by software created using secure development techniques, and resistant to malicious attack, both for normal operation, and for debug, development or analysis. Under the key requirements it recommends that all code loaded as part of the boot process, unless it runs directly from ROM, is verified to ensure:
This code then needs to be verified after it has been loaded into RAM, and the boot sequence starts running from ROM, using an immutable root key to verify the first code to be loaded. Multiple immutable root keys could be considered for verifying different boot stages, for generating derived keys, or even for redundancy in case of subsequent compromise.
Modules of code are loaded progressively, but only after each previous stage has been successfully verified and booted. Any existing data currently installed on the device that will be used as part of the boot configuration is checked for length, type, range etc. prior to use within the boot process. At each stage of the boot process, wherever possible, the boot software checks that the hardware configuration matches the expected configuration parameters for that stage.
The boot process ensures that if an error occurs during any stage of the process, the device “fails gracefully” into a secure state in which RAM has been cleared of residual code. Graceful failure must also ensure the device is not ‘bricked’ and no unauthorised access can be made to underlying systems, code or data (e.g. via a U-Boot prompt).
The manufacturer implements a secure process for generating keys and certificates. The provisioning, storage and usage of keys and certificates on devices is secure. Device end-of-life management ensures the security of keys and certificates is maintained.
These secure boot process guidelines are just one element of the guidelines but, as with all the sections, vital parts of ensuring development of secure connected devices for the IoT. Secure Thingz, with its Security from Inception Suite of products, provides developers with a direct way of building the appropriate levels of security for their needs throughout the development, manufacturing, and product management process, and in line with the security guidelines.
Its unique set of tools and services for implementing and customizing security in embedded applications provides a security development environment in the form of Embedded Trust, and a complete development toolchain using IAR Embedded Workbench, which includes the security development tool C-Trust and static analysis tool C-STAT.