Wearable Electronics
Making your wearable design secure both now and
in the future
Wearable devices are becoming more and more popular in everyday life. Kim Kaisti, product management director, u-blox, Pascal Herczog, vice president of cellular technology, u-blox and Charles Sturman, senior principal product strategy, u-blox talks about how to make them secure
T
he latest consumer “must have” appears to be a wearable device. Whether you seek the style of an
Apple Watch, a sports performance fitness band or an immersive gaming headset, you’ll have an immense choice. While many of these devices are aimed at extending the reach and usefulness of your smartphone, there is another emerging sector of wearables where the emphasis is on knowing the location of the wearer. These personal trackers, or mobile personal emergency response systems (MPERS) are finding adoption for tracking children, elderly relatives and lone workers. In addition to being able to track the wearer they also provide a ‘Help’ button function so that the wearer can communicate the fact that they are ill, lost or their life is under threat.
Needless to say, connectivity is
omnipresent for any wearable device. Typically, short-range Bluetooth and Wi-Fi communications are used, of which Bluetooth is probably the most common when using a smartphone for local storage, data presentation and as a
gateway to a cloud-based analysis application. Equally, cellular is the prime requirement for other applications, such as the MPERS example, which requires full mobility of communication. In common with Internet of Things (IoT) devices, the mention of connectivity goes hand-in-hand with that of security. Most wearable devices will contain some personal data, and in the case of a fitness monitor, heart rate, or blood glucose measurements may be taken. Time- stamped location information will also be present, and potentially login profiles and passwords to cloud platforms too. At a high level a developer, when working on any wearable project, should keep in mind the security topics of device, application and service. The design phase 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
Figure 2: Functional block diagram of a people tracking/MPERS system
approved wireless modules, means that a more holistic approach to security needs to be considered. Security needs to be implemented with an end-to-end approach. Potential places for a security attack, an attack surface, could include the sensors, local storage, compute processing, device configuration, authentication methods and data transport. To understand some of the security concepts, let’s first look at the functional parts of our example MPERS wearable device (Figure 2). There are four key
component parts, namely, the sensors that detect the person’s heart rate, temperature etc, location information received through a global navigation satellite system (GNSS), wide area connectivity typically provided by a cellular/LTE module, and, if required for indoors/home proximity detection, a short range communication method that is typically provisioned by a Bluetooth module. Examples of the wireless components used for this device might include a u-blox LARA-R211 multiband LTE module and a u-blox EVA M8M GNSS device.
Hosting the application and managing the transfer of data will be a microcontroller as indicated in the centre of Figure 2. Creating a secure device will rely on establishing an end-to-end chain of trust, from the sensor(s), the GNSS source, through the wireless connectivity to the end cloud application and back again. One potential approach to
Figure 1: Diversity of wearable devices 26 July/August 2016 Components in Electronics
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
www.cieonline.co.uk
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