Trust and then verify your IoT security

Article By : Bonnie Baker

It is critical to make sure that your embedded devices only run authorized firmware with authorized configuration code or data.

Is the data you are downloading into your equipment trusted or unmodified? Don’t get lulled into IoT complacency. It is critical to make sure that your embedded devices only run authorized firmware with authorized configuration code or data.

In the IoT environment, there are constant attempts to mischievously or maliciously disrupt or gain control. One would generally assume that, just out of the box, an equipment’s firmware or data authenticity and integrity is safe and secure. This is a good assumption, but things do change over time and upgrades are inevitable. During an upgrade, a hacker can attempt to modify the IoT device’s firmware or configuration data. How is this accomplished? It’s simple; if the gateway or door is open or the system’s security has flaws and the hacker inserts a fraudulent piece of firmware. This dangerous firmware could send confidential or sensitive data over the web, force a device to malfunction, induce unpredictable device behavior, or … well, let your imagination run wild.

data web security

Ensuring that your system only runs authentic firmware and has the capability to securely verify updates and downloads prior to acceptance is a basic need you will want to nail down. Without this, your system is not secure and vulnerable to exploitation. A fail-safe solution involves implementing secure boot and download on a cryptographic foundation to ensure authenticity and integrity of firmware and data.

Firmware authenticity and integrity

Trust and then verify is always a good strategy. The verification process involves making sure your device only runs with authorized firmware or uses authorized configuration data. You do this by using cryptographic digital signatures, which is like putting a seal or signature at the bottom of a letter. For the highest level of security and efficient key distribution, consider the asymmetric cryptographic algorithms for signatures, specifically the FIPS 186 Elliptic Curve Digital Signature Algorithm (ECDSA).

Asymmetric cryptography

In an asymmetric cryptography environment, there are mathematically related key pairs (public and private). As you might guess, the public key is open to anyone who cares to have it, but the private key is very secluded and protected. The private key’s information is critically confidential and never to be released.

The holder of the private key is the equipment’s “manufacturer.” When firmware or data is released, the manufacturer includes a private key-created ECDSA signature with the shipment. The receiver of this firmware or data verifies authenticity with the public key. An attacker can access the public key, but the ECDSA makes it mathematically infeasible to derive the private key. This is the benefit of asymmetric cryptography.  

Secure boot and secure download systems

It is possible to generate embedded system security methods with a secure microcontroller or secure hardware. Software or microcontroller/processor solutions are perfectly able to prevent unauthorized system access. An important characteristic of the microcontroller/processor option is the ability to perform computational activities. Major controller/processor vendors have these systems along with software libraries.

If a system does not have a secure microcontroller with authenticity and integrity in its computational capacity, an alternative hardware-based IC solution presents a cost-effective compact approach. For example, a DS28C36 (secure authenticator) or the more comprehensive MAXQ1061 (crypto controller) provides essential secure boot/download, and additionally, more security for your system.

Bonnie Baker has been working with analog and digital designs and systems for more than 30 years and is writing this blog on behalf of Maxim Integrated.

Related articles:

Leave a comment