New-Tech Europe Digital Magazine | Feb 2016

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 through jamming 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 sensor data 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.

New-Tech Magazine Europe l 43