IoT vendors. Avoid recalls, choose a secure chip

Processor choice in any scenario is important. It needs to account for a range of conditions and factors – peripherals, engineer familiarity, parts availability, and more.  IoT devices are no different. Unsurprisingly when it comes to selecting components, the primary drivers seem to price and performance. However, by choosing the wrong chip you’ll likely be missing out on essential security functionality. Worse than that, by choosing the wrong chip you won’t be able to correct product security issues in the field. Many issues can be fixed with a firmware update, but if you select the wrong chip your only option may be a product recall. We don’t need to go over why cost, brand damage, and embarrassment are bad things.

Here are four great examples that’ll make a real difference to the security of your products:

Secure credential storage

A widely used WiFi component in IoT devices is the ESP8266 WiFi module. The problem with this choice is that it has no internal flash, so it simply cannot store your user’s WiFi keys securely. An attacker with access to the device can recover the user’s credentials in under 20 seconds.

To handle this just use a better alternative, the ESP32 – the ESP8266’s natural successor. It deals specifically with the key storage problem by being able to encrypt external flash with a key stored securely inside the device. OK, there is  cost implication; it costs around $3 per device compared to $1.70 for the ESP8266. In volume this change could hit your bill of materials hard, but it may mean the difference between failure and success.

JTAG security

Microcontrollers generally have some type of debug access – JTAG, SWD or some proprietary variety, allowing access to flash, registers and RAM. The majority have “fuses” or other controls to prevent attackers abusing this access – but how effective are they?

If we look at the common EM3598 ZigBee chip there is JTAG read protection to prevent access to the flash memory. BUT it does absolutely nothing to stop the attacker inspecting the RAM. The private keys and decrypted data that you assumed were safe are not, and this isn’t always clear in documentation.

Hardware acceleration

If you aren’t battery powered, it might not make any difference if it takes 500ms or 10ms to encrypt data. But when you move to a device powered by a CR2032 battery, that’s the difference between one month and two years of battery life.

Many chips have hardware cryptography engines, supporting the most common algorithms such as AES-128 and SHA-256. These can be far quicker – and hence more energy efficient – than software implementations.

Entropy sources

Without a good entropy source for your Random Number Generator, you have no effective seed for your cryptography. Without randomness you have predictability, meaning that your crypto can be compromised. Entropy isn’t always easy to source, though environmental variables and chip jitter are sources used by some of the better IoT chipsets.

Conclusion

The chip at the heart of your IoT device might not be the obvious place to start with when it comes to IoT security. But if you unnecessarily constrain your developers by skimping on security functionality, you can pay the price further down the line, the cost of a product recall could take down your business.