Wearable Electronics


handling spoofing/jamming. The developer needs to ensure that there is a solid, initial root of trust in each major component, and then define how this is used to link to the other components. Reference to industry standards and guidelines should be reviewed where possible. Delving a little bit deeper into the MPERS design showing just the cellular modem, Figure 3, highlights the principal security considerations for each component. In this diagram there are five different attack methods identified, highlighted by the number inside a circle and will be explained below. First and most importantly, 1, 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. Updating firmware not only allows new features to be incorporated but any identified security fixes to be implemented. For those devices connecting to the internet via a smartphone application an over-the-air (OTA) method might be ideal. However, those wearable devices with cellular connectivity, such as for our MPERS example, this can be made direct at any stage without having to wait for the wearable to be paired with the smartphone. While the concept of an OTA firmware update 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. Implementing OTA and being able to store several image versions is also likely to demand more memory so this will have an influence during the design phase too. The next consideration, 2, 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 host cloud-based 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. Ensuring that access to all interface channels and ports are properly controlled, 3, is crucial. This includes test and debug ports, that while they may physically be present on the board have been closed in production versions of the software. Likewise, any ports not used by the microcontroller or wireless modules should be closed. Leaving any accessible ports open is a simple route that is likely to be exploited. Access to device functionality, 4, 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, 5, 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. Engineers should carefully review what capabilities the GNSS and cellular modules might have when selecting them. For example, the u-blox EVA-M8M firmware incorporates a number of security features that can highlight to the host application though internal two status messages the possibility that the GNSS signals are being jammed by intentional interference. The ‘jamInd’ message indicates the presence of a narrowband continuous wave that is above a threshold determined during a normal reception environment, interfering with reception across all possible GNSS frequencies. The second message ‘jammingState’ alerts the host to the presence of both broadband and continuous wave interference. In addition, the u-blox GNSS module is able to detect attempts to spoof the satellite data. Should someone attempt to create a fake GNSS signal with the intention of fooling the receiver is in a different position that the true one a status flag is set. The spoofing detection feature uses anti-spoofing algorithms to monitor suspicious changes in the GNSS signal. To address the need for wide area connectivity in the next generation of connected wearables, u-blox is developing a new range of modules as shown in the table below. Security will be central to all of these products and so these new devices will embody what we refer to as our “5 pillars of security”. The pillars, as highlighted above, are Secure Boot and Firmware Update, Cellular Authentication through SSL, Secure Interfaces, Secure API’s and Jamming detection.


Figure 3: Building the security domain www.cieonline.co.uk www.u-blox.com/en Components in Electronics July/August 2016 27


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60