Everybody is talking about security these days. For the embedded developer, getting the system running as the marketing specification stipulated and on time, used to be a challenge in itself.
Today, the need to build security into every aspect of the design, whether it is a simple IoT sensor communicating with a server or a more sophisticated multicore application, requires thought and a careful appraisal of potential security attack points. In a perfect world, a design could be built from scratch with every functional block designed and developed within one team. However, the pressures of time-to-market and embracing a higher level of integration using, for example, pre-certified and type approved wireless modules, means that a more holistic approach to security needs to be considered.
When we look at, for example, an IoT sensor using a microcontroller and a wireless module, it is necessary to establish a chain of trust, from the sensor to the host, via the wireless antenna to the end application. Building a secure solution requires a holistic viewpoint to take into account all the technical and operation aspects of thesystem components and is not only limited to the wireless communication. The application might also encompass and utilise GNSS positional data, which has its own security consideration.
One potential approach to implementing the chain of trust is to divide it into a number of trusted domains. By investigating the fundamental methods necessary to protect each domain, the following define the areas of potential attack; device firmware, communications to the server, interface security, enforcing API control and robustness that includes handling spoofing/jamming.
Ensuring that your device is executing the code it should be requires a secure boot method to be implemented. When booting the system, it is crucial that each stage is authenticated prior to booting the next set of processes. When reviewing firmware security you also need to be mindful of how it might be updated. For many physically dispersed sensors the favoured approach is to enable an over-the-air method. While the concept is fairly straightforward,the chances of this becoming an attack point is high. Ensuring the downloaded firmware image or patch is validated prior to being flashed is essential.This must include a process that ensures the resulting image can be authenticated and integrity-checked before use; with an ability to back-track to the previously authenticated image should a security breach or hardware problem be encountered during the update process, whilst also preventing older versions from being accepted.
The next consideration is that of the communications or transport layer. There needs to be a mechanism for the device to be able to authenticate itself with the server, and vice versa. Whatever the method used, the device should be able to sign or encrypt any data communicated with the server. The ability to securely manage the keys used for the signing, decryption and encryption processes will ensure that these can be changed whenever necessary, even on a per session basis. Data being communicated is always open to the potential of being intercepted or compromised by man-in-the-middle attacks, including at the device interface level. Hence taking unauthorised control of the device is another possibility that needs to be avoided at all cost.
Access to device functionality is often via a number of defined APIs. Unfortunately, the access to device features and the implications for security can often be overlooked. Those wishing to exploit or compromise a device, even if for the fun of it, usually have a lot of time available to probe for open APIs and experiment with the interrelationship between them and device functionality. Sometimes APIs incorporated within code provide access not only to standard features and capabilities but also to premium or paid-for services. Developers also frequently provide undocumented APIs for their own testing and configuration so it is imperative that these are protected as well. Hence, formal authentication and authorisation techniques should be employed to allow access to or enable such API’s.
The final consideration is that of robustness for those applications that source data from external devices, such as a GNSS receiver, with location potentially an intrinsic part of the value of the sensor data. The concern here is how robust the solution is in detecting and handling failure cases. For example, either throughjamming the GNSS receiver, or spoofing the input to the GNSS receiver, it is just as important to detect that the reported position is different to reality as it is to protect against a direct attack on the rest of the system.Man-in-the-middle style attacks on the sensordata passed to the host will also be another consideration. Being able to detect both this and spoofing attacks and alerting the end-application are important aspects of incorporating security into your design.
As the IoT era advances forward security can no longer be an afterthought. Implementing a security regime into your product is as essential as the device’s core function.
