I often come across IoT systems where all the focus is on ensuring that the infrastructure and any data transmitted mitigates the risk of external or unwanted penetration. However, protection against physical access to connected devices, such as smart TVs, remote medical devices, security and home automation devices and smart appliances, is often overlooked.
Cybersecurity is already one of the biggest risks to business today, but most forget that every connected device represents an attack surface. With an expected 27.1 billion IoT devices worldwide by 2025 (IoT Analytics), and the use of connected devices on the rise, a complete view of how to secure IoT devices is important to factor into your cybersecurity policies and operations.
The required level of security of the device is primarily based on:
- 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.
Determining this level of security is best done at the start of the development of the IoT device and/or system to ensure that the correct hardware features are available to support it. Even with devices already in the field, it is best to evaluate how secure that device is and determine any upgrades that can be made to reduce any security risk or detect and reduce the impact of any unwanted breach. It is better to stop something bad from happening or know about it early than to deal with it long after it has happened.
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.
Questions to ask include:
- 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?
This means it’s wiser to implement security with consideration to the hardware from the get-go. Even so, such a secure and efficient solution requires a well-thought-out process. This process means starting the security analysis at the very beginning of the development cycle before any specific development or coding has begun. A process that also considers all issues such as how to store keys, securely update a device, debug securely and repair without security risks.
Here are just a few ways in which IoT devices can be secured:
- 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.
Scenarios such as:
- 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.
Best practice is to avoid the application firmware having direct access to these keys by storing them in an area of flash or an external peripheral that provides secure storage and enhanced cryptographic function utilising these keys. Ideally cryptographic functions are not called directly, but stored in a trusted “execution” environment where access to the service is through a hardware proxy or gateway. This way if the application is compromised or the flash is physically attached to external tools there is little chance that these certificates can be retrieved.
If not available in the System On Chip (SOC) itself, peripheral hardware components are available that securely store and verify security keys as well as providing some or all of the necessary cryptographic functionality. The storage keys are generally dedicated chips such as Secure Access Modules (SAM) or Trusted Platform Modules (TPM) providing a means to ensure physical tampering of the device will not expose those keys.
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.
Advanced RISC machines (ARM) based microprocessors use a Trusted Execution Environment (TEE) where code such as cryptography and secure key store functions run in its own operating environment and only respond to requests through data passing from untrusted firmware applications. Other Reduced Instruction Set Computer (RISC) based architecture has no standards available for trusted zones but they are dependent on the RISC manufacturers creating open source or proprietary mechanisms allowing for trust zones like functionality.
Often IoT devices store secret keys, user private data and the firmware itself in flash memory without sufficient means of protecting that data. This allows a hacker to gain access to those security keys or data, steal intellectual property from the firmware or change the firmware. Most reputable processors in the market provide the ability to either encrypt part or all of the flash memory using encryption keys generated by the hardware, only available as read or write by the hardware itself.
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.
The bootloader itself determines what partition in memory the valid application resides and runs the application from that memory address. Good application firmware practices allow two partitions for application software. While one partition is running the current application, the second is used to hold the upgraded application firmware. Once upgraded, firmware is downloaded and written to the non-running partition, the bootloader config is informed to switch to the upgraded partition, the application exits and the bootloader restarts the new firmware from that dedicated partition location.
Without the proper measures, physical access to the device would allow the bootloader or firmware to override the manufacturer’s firmware with a compromised bootloader or application providing access to the IoT system.
To mitigate this, the chain of trust needs to be established. On device start-up, the processor needs to ensure that the bootloader comes from a reputable source either by the bootloader existing in read-only memory or by validating the bootloader using encrypted hash keys that need to match the value of the hash function running over the bootloader. This is best done using a burnt-in tamper-proof public key (Root of trust public key – ROTPK) from the hardware manufacturer to perform the cryptographic function. If validation fails then the bootloader does not start up.
As with hardware validating bootloaders, the bootloader must validate the firmware by generating a hash value from the bootloader firmware and comparing it against the hash value supplied by the manufacturer. If the validation fails, the bootloader either falls back to the previous firmware load or stops, rendering the device unusable. Manufacturer supplied hash values are encrypted and stored in a storage section unable to be accessed by the firmware. The functionality to verify the hash value is performed in Trust execution environments to ensure that the validation functionality cannot be compromised.
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.
These steps are to;
- 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.
Whether you are creating new devices or already have IoT devices in the field evaluating the appropriate security for your device and implementing that security should be taken into consideration.
Don’t hesitate to get in touch with us at DiUS if you want to chat or need more help securing your IoT devices. Our team of IoT specialists have extensive expertise in software, firmware and hardware development, implementation of IoT platforms, managing device manufacturing and deployment at scale.