Doesn’t it make sense to learn from the security mistakes that others have made, and avoid the pain which they had to go through in putting their mistake right?
Here at Foundries.io, we like to share best practice for IoT device security as widely as we can, and to help our customers take advantage of the broad set of processes and capabilities for improving security provided in the FoundriesFactory™ platform. So here we have compiled a list of the most common security mis-steps that Foundries.io has seen, described the risk that they expose the device to, and a great way for others to avoid them.
There are broadly three ways in which IoT product manufacturers commonly leave devices exposed:
- Failure to implement basic security functions
- Operational process mistakes
- Errors in configuring the available security capabilities
Implementing basic security functions
Security protection is a multi-faceted, complex set of arrangements ‐ there is a lot for device developers to get their arms round. But a failure to implement basic security capabilities gives attackers the easiest access into a device. If you are going to do anything to secure an IoT device, do the basic things first.
While many basic security protections, such as encryption of data shared on the internet, are routinely implemented, one is surprisingly often omitted: secure boot.
Yet secure boot is essential: it ensures that a device can only start up with an authenticated image of the device’s firmware, and reduces the risk that an attacker could substitute a corrupt version of the firmware that puts the device or the user’s data at risk.
The worst instance of this mistake is when an IoT device design is based on an SoC which does not have a secure boot capability. This is an irrecoverable position: the only solution is to redesign the product with a new SoC that does support secure boot.
Almost as bad is the situation in which the SoC supports secure boot, but the developer does not implement the secure boot capability in the application. This puts the device at severe risk of attack. With the use of special firmware, however, it is possible to activate secure boot in devices which are already in the field.
But the lesson to learn here is: always choose an SoC that supports secure boot, and always include secure boot implementation in the product development process.
Getting operational security processes right
The protection afforded by a root certificate authority (CA) is based on the private key used to encrypt it. It is so essential that this private key should remain secret that not even Foundries.io keeps a back-up of private keys for a customer’s root certificate authority or of root keys for The Update Framework (TUF).
The mistake to avoid? Don’t lose the key!
It is surprising how often this happens ‐ and it has severe consequences. It's possible to have Foundries.io reset public key infrastructure (PKI) keys, but resetting the keys means that all devices in the field will lose connectivity with the device gateway. After the PKI key reset, there is no way to restore the device’s connection to the gateway ‐ it will require a new device registration to Foundries.io.
The answer is to implement appropriate procedures for storing keys securely.
Experience shows that other key management processes also frequently expose the OEM to risk. For instance, each instance of the FoundriesFactory platform has a Factory key provided for convenience in development. This key is unique to the customer’s instance of the FoundriesFactory software, so the security risk is relatively low. But nevertheless, it is good practice to rotate the key before the design goes into production.
Another process mistake concerns permissions granted to staff and third-party contractors. It is a common mistake to grant universal, unbounded permissions. This creates the risk that a potentially hostile developer or third party can create or rotate sensitive security assets such as PKI or TUF keys, and so damage a fleet of devices in the field. This can easily be prevented by implementing user groups with permissions that are restricted both in scope and time.
In fact, the TUF mechanism in the FoundriesFactory platform allows update security to be bolstered even further. It is possible to create a rule requiring more than one person to sign the artifact verifying that the OTA is approved for release to production: this means that an adversary needs to compromise more than one target to obtain the TUF security keys. This multi-signature capability in the FoundriesFactory platform adds redundancy to the critical cryptographic key, improving product safety; eliminates the need for key sharing among those authorized to release updates; and increases the protection of TUF metadata from unintentional modifications.
Avoiding errors in security system configuration
The third class of common security errors concerns the way that security protection features are implemented on the device.
For instance, as we said above, we believe secure boot is a non-negotiable security feature, so it is always good when a manufacturer activates the secure boot capability in their SoC. But it should be done the right way: Foundries.io provides tutorials and software examples hosted on github which explain how to generate secure boot keys offline (outside the FoundriesFactory platform). These examples, including the keys used, are for demonstration only: developers always need to generate and securely store their own secure boot keys.
Failure to do so constitutes a severe security breach. In most cases, it is not possible to replace this insecure public key once a device has been provisioned. This fault cannot be fixed with an OTA patch.
Other measures to harden a production design before it is shipped are equally important. In the device’s software, care should be taken to disable unused services, to close open connections, and disable the root password for accessing console/ssh. The severity of these issues is low, since they can be rectified with an OTA update or fioconfig change.
Failure to close off hardware vulnerabilities is a more common, and a more dangerous, mistake. For instance, failing to disable the JTAG interface exposes the device both to certain types of physical attacks and to the risk of firmware replacement. While an OTA update can usually fix the problem, it can be a difficult fix to implement, though the level of difficulty differs from SoC to SoC.
To reduce the attack surface, unused interfaces such as USB, UART and HDMI should be disabled before a design is released for production. If they are not, this step can be performed via device tree and an OTA update.
Likewise, a Docker container with security privileges for developers should be hardened before the design is finalized. There is a high risk to the device’s integrity if an adversary can access the Docker container and run it in privileged mode. Again, this vulnerability can be eliminated with a normal OTA update.
For flexibility in the development phase, design teams often enable rollback in prototypes. If rollback capability is retained in a device in the field, an attacker could use it to roll back to an earlier version, which may contain a vulnerability that had been eliminated by an OTA update. An advanced OTA instruction can disable the rollback permission for devices in the field.
A different way to leave a production device exposed is through failures to implement good practice for key storage. The common faults we see here are:
- Storing API credentials or plain text tokens in non-secure areas of memory. If the adversary can access the file system via an exploit or by extracting the filesystem from the device, they can access these tokens or credentials. Instead, developers should use the capability in their FoundriesFactory software for allocating sensitive data to secure storage (such as the Replay Protected Memory Block (“RPMB”) section of an eMMC drive), or to a secure element or Trusted Platform Module (TPM).
- Allowing plain u-boot environment variables to be stored and/or enabled for editing in external memory, such as an eMMC or QPSI drive. This means that an adversary can extract and modify these variables, compromising the device’s security.
Avoid the mistakes by addressing security systematically
In this blog, we have listed the most common ways in which IoT device manufacturers can fail to implement good security practices, according to Foundries.io’s experience. Of course, one important response to this is to learn the individual lessons described above.
But effective security protection is more than a checklist or box-ticking exercise: an IoT product is a complex system which comprises device hardware and software, connectivity to the cloud, the cloud service, and the applications which run in the cloud. Securing the product requires securing the entire system ‐ and so the device manufacturer should take a systematic view of its security.