Whether it is the remote hacking of cars or the rise of the IoT botnet we have all read the scary headlines: IoT security is a growing issue. But how exactly do you stop your company and your product appearing on the front page, associated with the latest security hacking story? Here are six tips to get you started…
If you design an IoT product and ship it with default credentials (username = admin, password = admin), then your connected product is likely to be part of the next IoT botnet and making headlines across the globe. IoT products need unique identities, which cannot be guessed, they also need keys that help them connect securely to cloud based services.
Deciding on a keys and trust architecture sounds complicated, but it can be simplified by adopting a platform approach. For example, Arm® provides Arm Mbed OS and Mbed Cloud, to help even the lowest cost microcontrollers connect securely to the cloud. Whilst GlobalPlatform provides standards for the remote management of security domains on applications processors. Alternatively, new protocols such as Open Trust Protocol (OTrP) combine a PKI and Certificate Authority based trust architecture, with a simple OTA management protocol.
Action #1: Ask your design team if any shared credentials or shared private keys have been used - if the answer is yes - investigate how they can be removed or protected in hardware key stores.
As the amount of software grows in your product, so does the number of security vulnerabilities. Critical code, data and hardware can be protected by using hardware mechanisms such as Arm TrustZone. TrustZone was first adopted in mobile markets on application processors but is available on the latest Armv8-M MCUs (which will be entering the market in 2017). If you are using an applications processor you can make use of a TrustZone based GlobalPlatform Trusted Execution Environment (TEE). There are both open source and commercial offerings available on the market, from organisations such as Linaro and Trustonic.
Action #2: Ask your silicon provider if they support TrustZone and what software is available for you to use (e.g. key store, hardware attestation, GlobalPlatform TEE etc).
TrustZone enables defence in depth and the creation of multiple isolated security domains, for your critical code and data. The code that runs there might be from different sources and it is a useful feature, as it allows you to isolate code that might be distrusted from other parts of the system. TrustZone extends beyond the processor across the whole chip enabling secure peripherals, secure interrupts and secure memory – it is a holistic approach to system security. Arm provides system IP and example subsystems to silicon partners to help them build security into the chip.
The first step in building in trust into a system is the initial Root of Trust. This provides essential security services (you can think of it as a security toolbox) that can then be relied on no matter what else is happening on the device (e.g. even if the device is being attacked). Arm provides a family of security subsystems called CryptoCell to fulfil this function.
Action #3: Ask your design team about how they are creating a hardware based RoT.
While on one hand it’s important to design systems with a strong security foundation, it’s equally important to be able to fix problems after deployment - security holes will be found over the life of the product. Over the air (OTA) updates can patch vulnerabilities but they require a security foundation to ensure that the update can be applied without compromising the system. When choosing an IoT platform investigate how firmware can be updated OTA and the security mechanisms employed. Some examples of protocols that might be used include: OMA LWM2M, GlobalPlatform TMF and OTrP.
A related topic is lifecycle management where the state of a device (examples could be ‘in manufacture’ or ‘deployed’) can be carefully managed and used to affect the functionality of the product. A robust security mechanism is needed to store and control the lifecycle state.
Transport Layer Security (TLS) is likely to be familiar to you (you might recognise it from the padlock symbol when you are using a browser to do your online banking). It protects data between the client and a remote server and is equally applicable to protecting the data flowing between the IoT device and the cloud. It offers the security properties of secrecy, integrity and authenticity. Fortunately, there are well proven TLS software providers offering both open source and commercial implementations (including Mbed TLS). End-to-end security starts with good end point (hardware based) security and needs a robust protocol (such as TLS) to protect the information in flight.
Most IoT developers are not security experts; they want to get their product to market and focus on their differentiation. The easiest way of doing this and creating a product that will be resistant to attack, is to use an IoT platform that includes security functionality (such as OTA updates, TLS and crypto technologies), as well as supporting hardware based security features in chips. Arm’s Mbed OS is an example of a platform with “built-in” security that is being ported to the next generation of TrustZone enabled microcontrollers. Arm is also creating open source security software, that the industry can use as common building blocks. The first of these will be the Secure Partitioning Manager (a generic version of the Mbed uVisor) that provides isolated partitions for secure functions that need to be protected from the rest of the system.
After you’ve designed your IoT device, it is a good idea to invest in your product and pay a security researcher to expose security vulnerabilities, before a hacker does it for you. Typically this is done as a “Crystal box” exercise where the security expert has access to the source code and reference hardware. They will be able to do a source code review, with the option to use penetration testing to help you improve the design before it is released. They may even be able to help you improve your internal processes and training, so that future security engineering becomes better integrated with your product development.
It is now possible to apply mobile security techniques to IoT at all cost points. The introduction of TrustZone on microcontrollers as well as application processors, together with availability of security subsystems, offers a defense in-depth architecture which can be used to protect critical code and assets (such as cryptographic keys). The next step is to make it easier for IoT developers - who are not security experts - to use this architecture. A pragmatic way for most product developers is to choose an IoT platform that builds in security functions (such as OTA updates, TLS, and crypto libraries), as well as using the security hardware being built in by the chip vendors.
Any successful product will be attacked; the executives of a company should support their engineers with the resources they need but also question how trust and security are built-in at design time and assessed.