IoT Security and Smart Devices

A quick recap

In the previous article, we looked at the typical architecture of an end-to-end IoT solution and different components playing role in it. We also saw a couple of terms used in discussing IoT security. In this article, we will focus on end devices. We will consider factors which can influence device security making them vulnerable to hacking. We will also discuss different ways to make them safe.

End devices

End devices are generally small, have minimal hardware and limited intelligence. More commonly they are either sensors or actuators, sometimes a combination of both. There might be some local processing power present, but it cannot be taken for granted generally. Because of these reasons, they generally send data and understand a limited set of commands. Since these devices are small and relatively cheaper, they come with minimal provisions to configure them.

This constrained ability and resources might sometime be a disadvantage to a hacker, because it also translates to minimum level of damage and control. More resourceful an end device is, more chances that it will attract hackers, It may give more control to hackers thereby causing more damage. But again, with more resources, more are the chances of having more robust security features implemented.

Since there is seldom an application running on end devices, there is a limited attack surface and smaller attack vector. These devices can be susceptible to physical attacks, may allow direct physical access. They may also allow hackers to "listen" to the communication they are doing, which may enable hackers to compromise configuration of the end device.

Physical security

As these devices are deployed "in field", they may be easier to access physically and being remote and unattended, they could be much more vulnerable to physical assault and damage. Additionally, physical access may also allow hacker to tamper with the device, gaining access to internal components and ports. This could be used to completely reconfigure the device to serve the purpose of the hacker. A few measures can be taken to ensure physical security.

• The device enclosure (casing) should be made stronger and tamper proof. Any tampering efforts should result in permanent damage to the device rendering it unreadable/non-writable.
• If feasible, tampering attempts should be logged and relayed upstream.
• There should not be any debug ports, interfaces on the production level device. In the development phase, those ports may be present on the device but once the device enters production, all such ports/interfaces should be removed.
• Having physical access to the device enables it to be reset by hacker. The reset, re-initialization process may reveal sensitive information to hacker. Hence the reset mechanism should be robust. Unless extremely essential, the device should not send or accept any data during reset-reinitialization mode. As long as possible, there should not be any easy external mechanism to reset the device.
• The device must need some kind of interface to communicate but it should be ensured while designing the device that no part of non-volatile storage, if present on device, is directly accessible using these interfaces.
• Implementation of heart-beats to monitor continuous presence of end device.
• If there are any discrete non-volatile memory components in the device, it must be ensured in design phase that they cannot be read from outside or they cannot be removed from the device.
• It is advisable to provide switchable or separate interfaces to configure the device and for data communication. However, considering the cost, usability and lifespan of the device, this may seem unfeasible. But if such provision is available, configuration interfaces must be secured - physically as well as logically.
• These days, hackers are increasingly relying on physical properties and characteristics of end devices. For example they might be susceptible to certain frequency ranges, voltages, temperature etc. Approach to testing devices in design phase should encompass these aspects as well.
• While testing individual discrete component is good, it is also essential and important to test "device as a whole" especially in the context of "physics" of the device. For example, vulnerability of a certain discrete component (as explained in previous point) may compromise entire device.
  

Configuration security

After gaining access to device, it can be exploited by changing configuration. This may allow attacker to reset the device to factory settings or configure a new password. Attacker may send a new device pairing request or install custom SSL certificates if applicable to control the device. Ultimately, all the traffic involving the device can be redirected to specific servers. Following are some of the prominent measures to avoid such exploitation.

• As far as possible the device must use TPM (Trusted Platform Module) to establish chain of trust.
• If the device is expected to receive software and/or firmware upgrades during its active life, there must be some minimum provision to verify the authenticity of upgrades.
• Ideally configuration data stored on device should be in encrypted mode. However, given the resource constraints and nature of device, it may not always be possible. In that case, amount of data stored on device should be kept minimum.
• A bare minimum data should be stored on end devices. This data should be just sufficient to establish initial communication with edge device.
• Any hard-coded, well-known values of parameters should be avoided - this also includes using default easy-to-guess passwords, user names, destination addresses etc.
• Whatever the means of configuring the device, if configuration data is to be stored on device, it must be unreadable by any direct means.
  

Communication security

In addition to having robust hardware and software, it is equally important to secure remaining factor - communication.

• Similar to configuration, communication done by the device should ideally be encrypted. However, similar constraints may not make this always feasible.
• The device should never initiate authentication mechanism using defaults. It may indicate edge device that it wants to communicate, but the authentication mechanism should be initiated from and handled by higher up levels.
• Communication made by end device be kept at minimum essential level. Content and frequency at which the device communicates should be configurable.
• Communication from end device must not depend on availability or any kind of acknowledgement from higher up devices.

And a little more ...

The end device security can also be viewed from a different perspective - the device life cycle, which can typically be as follows.

There is a possibility of tampering device during production and distribution phases as well. Generally device is designed, prototyped, tested and then given for mass production. Required software and firmware images are provided to the third-party which mass produces the device. Security and trust is very important here, because there are known cases of tampering hardware, software and firmware during manufacturing phase. For example, some of the data communication devices manufactured in China are known to have back-doors enabling access to device data. Software on many devices manufactured in China are known to have hidden spyware snooping on and relaying user data back to Chinese servers. All these incidences underscore the importance of securing production and distribution channels in order to protect device security.

What's next?

In the next part, we will continue our exploration of device security. We will also review edge devices - the next link in the chain of IoT solution. Mean time, please continue sending your feedback and comments!