IoT security: Protection against unwanted access to your devices

  • The type of information your device produces or holds.
  • How much protection is needed to support this information, the system or product that it is being developed for and the impact on security breaches to that product.
  • The ease of access to the device that unwanted intruders will have.

The IoT connectivity threat

Private security keys, passwords, sensitive data, or even the firmware itself is often stored on an IoT device, which can be easily read or altered with inexpensive tools. But it takes more than just software to protect against these vulnerabilities. Instead, it requires features available on the processor and/or peripheral components to the microprocessor. The nature of the device, legislative laws and the business logic of the ecosystem will determine what type of security is required and how much hardware assistance is needed.

  • What is the physical access to the device (public or in-company)?
  • Can a breach of the device be isolated, or will it affect other devices?
  • Will privacy-related, sensitive, regulated data be harvested, stored, or transferred?
  • Is the application or its data attractive targets for someone?
  • Which firmware or software will run on the processor?
  • Device unique identity: For each device, a key may be generated based on the unique properties of the underlying hardware. Such physical unclonable functions (PUFs) are the device’s unique, unforgeable fingerprint.
  • Secure boot: A secure boot process ensures that only correct, unaltered software is run.
  • Secure storage: The keys can be stored securely, in hardware, and will not leave the module.
  • Side channel attack protection: A protection against side-channel attacks, where the perpetrators would try to exploit the physical properties of the system such as energy usage to deduce the system’s secrets and gain access.
  • Anti tampering: Attempts to tamper with the device will be detected and logged.
  • Wide variety of cryptographic functions: A mechanism to securely offload authentication and encryption functionality to support the latest standards and algorithms, including, for example, those that are required on the Chinese market.
  • Secure debugging and OTA updates: A mechanism for secure debugging and updating the firmware remotely Over the Air (OTA).

What needs to be protected?

Before determining the security level required, an analysis of the potential fallout if the device data or software was to be compromised needs to be made. In particular, the potential damage regarding safety, privacy, personal or company loss, and damage to the company’s brand.

  • What would happen if a stored security key or certificate, or sensitive data was able to be retrieved outside the authorised group ?
  • What would happen if the firmware was changed so the device was working in a way that was unintended by the manufacturer?

Device identity

Each device needs a unique identity to be used by the cloud service in order to distinguish one device from another. The identity may be generated based on the unique properties of the underlying hardware. If a security requirement is that the device cannot be forged in the eyes of the service that it is attached to, then this identity should not be able to be read by external entities attached to the device. Likewise the identity should not be discoverable. For example, providing the Mac address as the identity opens up a security flaw as the Mac address is a discoverable property by scanning the wireless network.

Security keys

Security keys are generally used to provide authentication and authorisation with the backend servers handling your IoT devices and also provide encryption for both data in transit and at rest. Devices that put these keys into unprotected flash means those keys are able to be read via physical access to that flash using external tools.

Firmware attack protection

During runtime, security flaws in the application firmware may potentially come to light allowing hackers access to information or functionality on the device. Some microprocessor architectures try to mitigate this by separating secured and unsecured functionality and having data between the two passed via a trusted gateway. This ensures that if the firmware is compromised during runtime that it does not have the ability to decrypt data or access security keys directly.

Root of trust

When an IoT device is switched on, the hardware starts running instructions from a hardware defined memory location in flash. The microprocessor generally has a pre bootloader function starting the bootloader from a given flash memory address.

Secure debugging

Most microprocessors allow interfaces via specific processor pins for remote tools to monitor, pause and change memory values during the development stage of the hardware and firmware. To avoid unexpected physical access allowing a hacker to utilise this interface, the processor needs to be configured to securely disable functionality. Most manufacturers provide means to disable the interface either during burning the initial load onto the device or via some runtime configuration. This is normally a one-way irreversible process that should be part of your end of line configuration and testing.

Device hardening

For IoT devices running a higher-level OS such as Linux-based operating systems, there are normally numerous hardware interfaces such as USB and Ethernet ports that can be utilised to gain unwanted access to the device. Once accessed, the user may have the ability to read and write the data and the application. Such systems need to be configured to increase the security of the device. As with all high-level OS, there are configuration files and applications that can be set up to lock down the system from unwanted access.

  • Disable any unused physical ports from the device, reducing the user’s ability to access the OS physically.
    This includes USB ports and unused ethernet ports.
  • Restrict incoming and outgoing IP connections to known IP sources and the required IP ports.
    — Always use TLS/SSH connections for communication.
  • Avoid incoming remote logins.
    If possible, use tunneling mechanisms with agents on the device that trigger SSH tunneling. This removes the need to have incoming SSH connections directly to the OS from unknown sources.
  • Remove all unnecessary packages and applications from the OS.
    The less software on the system the less possible vulnerabilities that can be exploited.
  • Restrict “sudo” and “root” access.
    All applications should be running from a user/group that has only the permissions required to perform its function, therefore do not run these applications as root but have a separate user/group with restricted access for the application.
  • Restrict read/write access to all parts of the file system.
    All directories, files, and executables should be set to only allow the correct actions by the appropriate authority level.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
DiUS

DiUS

We specialise in using emerging tech to solve difficult problems, get new ideas to market & disrupt business models.