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!

Comments

Post a Comment

Popular posts from this blog

Security in Linux Kernel - Part 2

Image
  In the previous part of this series, we saw role of LSMs in kernel security. As mentioned earlier, there are eight LSMs available today in the modern Linux kernel. In this part, let's have a look at different main stream LSMs. SMACK Simplified Mandatory Access Control Kernel ( SMACK ) is designed primarily for embedded linux systems with an intention to make it easier for administrators. This was the second LSM (after SELinux) to be accepted in the linux kernel. It appeared in the 2.6.25 kernel release. This is an attribute (label) based simple LSM, and is the default for Linux implementations tuned for Automotive industry. Yama Yama collects system-wide DAC security restrictions that are not handled by the core kernel itself. It offers control over scope of ptrace() system call to control ptrace attachment by processes. Build time configuration option CONFIG_SECURITY_YAMA and runtime option through sysctls can be used to enable this LSM. The ptrace restrictions can be controll...
Read more

Security in Linux Kernel - Part 3

Image
  In this short post we will explore a Linux system call facilitating secure computing. In earlier parts of this series we saw how LSMs protect the kernel. However, LSMs occupy a much deeper position in the call hierarchy and do not offer protection at process level. Additional mechanism is required to provide protection at process level. Need for a system call In Linux, applications programs use a number of system calls, in fact a large number of system calls are available to applications programmer. These processes using system calls expose a large area of the kernel to malicious attacks. Linux offers a mechanism to limit this capability using seccomp system call, thereby reducing the attack surface. seccomp is enabled using prctl() system call with appropriate operation mode. seccomp Modes The seccomp system call works in two modes - strict mode (SECCOMP_SET_MODE_STRICT) and filter mode (SECCOMP_SET_MODE_FILTER). When seccomp is set to first mode, i.e. strict mode , process has ...
Read more

Trusted Platform Module

Image
In the previous article, we discussed end device security and various factors affecting it. There was a fleeting mention about TPM - the Trusted Platform Module. In this installment we will discuss mode about the TPM. Generally, for any device, the safest way to ensure it's integrity is to make sure it always boots from a secured, verified and unalterable source. This forms the logical "root" of the entire boot process. Once the device boots from a trusted source, it further uses it to verify each and every software component it utilizes. Every module checks and verifies integrity of the next module to be loaded thus forming a "chain of trust" which if broken can be easily detected. This chain of trust then can be extended to encompass other devices across and upstream the network hierarchy. In this installment, let's have a deeper look at TPM. What is TPM? TPM is (generally) a chip designed to provide security related functions. It provides functiona...
Read more