Fails and Fixes with IoT

After nearly 6 years of tearing apart ‘internet of things’ devices, here’s a look at the high level fails that we keep seeing.

We’re not going to go in to point issues such as Wi-Fi credential leakage and Bluetooth compromise: our blog is littered with those!

What are the root issues and what can be done about them early in the product design lifecycle?

Issues index:

• Inadequate Entropy
• Inappropriate choice of operating system
• Avoidance of secure per-device programming/secrets
• Cryptography

Inadequate Entropy

Back To Issues Index▲

Most cryptographic systems will require a source of entropy (or random numbers), for the generation of private keys, session keys, and nonces.

If this entropy is not drawn from a suitably unpredictable source, an attacker can predict the “random” numbers, leading to the system becoming compromised.

Example: Arduino documentation recommends use of ADC for entropy

The common Arduino development board recommends that users seed the random number generator (RNG) using a floating ADC input. This presents several problems.

The RNG takes a 32bit seed, but the ADC is only 10bits. This means that we have seriously limited the search space for an attacker wishing to determine the seed.

A floating ADC doesn’t produce random values over the 10bit space. Typically, only 50 or so values are generated. The search space is now tiny.

Although the Arduino is often seen as a toy, the same method has been found in commercial products.

Example: Linux board produces same SSL keys

After factory-reset, a Linux based device generates a new SSL key for securing HTTPS communications. It does this as the board boots.

The default source of entropy in Linux are keyboard and mouse timings and hard disk access timing. In an embedded system with no user input and flash memory with highly consistent timings, there is inadequate entropy.

It was found that the board produced a duplicate key after being rebooted less than 10,000 times. Although this may seem insignificant, a large deployment of IoT devices could see this issue occur accidentally, and a determined attacker could find duplicate keys themselves.

Potential solutions

Developers must be made aware of the risks of drawing entropy from predictable sources.

Many microprocessors lack a true/hardware random number generator. In devices such as these, it is possible to gather entropy from ADC inputs or thermal noise, but only after significant software processing. This should be provided as a library.

Nearly all connected systems will require entropy. Unfortunately, microprocessors with true/hardware random number generators tend to include significant additional security functionality and hence cost much more.

Introducing chips with hardware entropy sources at low cost would be beneficial.

Inappropriate choice of operating system

Back To Issues Index▲
A device manufacturer has a choice between different operating systems:

• A full-blown operating system such as Linux
• A real-time OS such as FreeRTOS or VxWorks
• Bare-metal operation, without a formal OS

The choice of operating system is often found to be inappropriate, meaning:

• The OS is too complex, increasing the attack surface and making it more difficult to keep the device updated and secure.
• The OS is too simple and cannot support modern security protocols or the workload required to be secure.

Example: Low power bare-metal device has knock-on impact

An energy monitor connects via 802.15.4 to the Smart Meter, gathers energy consumption readings, and sends them via HTTPS to a server, allowing customers to view data online. The microprocessor uses is PIC24 series, with the default Microchip TCP/IP stack. This only supports SSLv2 and SSLv3 with known insecure ciphers.

For the server to communicate with these devices, OpenSSL has had to be patched to allow them to connect. This will have to occur throughout the lifetime of the devices. Custom patched software is prone to security issues, either directly from the patch or because it cannot receive automated updates.

Beyond this, there is a risk that the encrypted data could be decrypted by an attacker due to the weak ciphers. The likelihood of this happening is small, but must be considered.

Example: Over-complex Linux device is insecure and unreliable

An IoT thermostat is based on an open-source development board, and runs a build of the Linux operating system. Communications are using HTTPS, secured well as OpenSSL is available in full.

However, the device is found to be running multiple services that are not required: telnet, SSH, and a web server. The system has not been minimised as the developer does not understand embedded Linux well enough to do so. Further, firmware updates take over 10 minutes and are prone to failure as providing dual-banked flash for such a big firmware image was prohibitively costly.

Potential solutions

Vendors should work with different operating system providers to give their customers a choice of potential operating systems. It is essential that these choices can be kept up-to-date for the foreseen lifetime of the product.

The relative advantages and disadvantages of each choice should be documented.

Avoidance of secure per-device programming/secrets

Back To Issues Index▲
Nearly all devices will require some form of identification and key material to be stored internally. This allows them to be identified and authenticated against the cloud or server system.

Some devices generate new key material during factory reset, but as a result, they cannot be authenticated as genuine devices.

Generating, programming, and storing sensitive key material in a factory environment is challenging from a security viewpoint, and increases production costs.

Example: MAC address used to generate key material

A connected device required a unique key to connect to the cloud system. To be secure, this key had to be at least 128bits in length. The costs for programming unique key material were found to be prohibitive.

Rather than hard-code the key, a key-derivation function was used. This took the MAC address of the device, with 24bits of entropy, and extended it to 128bits. The keys looked random, but an attacker could easily find all of them by brute-force, or by sniffing a single packet on the local network.

Example: Machine used to program device riddled with malware

A device manufacturer has contracted a factory to produce devices. As part of the process, each device is flashed with a firmware over JTAG, using a custom utility running on a PC. This generates a per-device certificate, signed by a certificate authority. The CA certificate is stored on the PC.

On visiting the factory to investigate unrelated quality issues, the PC running the utility is found to be compromised with malware. The CA certificate could have been leaked, allowing anyone to produce valid per-device certificates.

Potential Solutions

Vendors have proposed several solutions to deal with this issue, but none are widely adopted.

Dedicated crypto-chips with key material burned into them are available. These can be used to identify and authenticate devices. The additional cost can be prohibitive.

Cryptography

Back To Issues Index▲
Broadly speaking, cryptography issues can be divided into the following groups:

• Design issues
• Library implementation issues
• Application implementation issues
• Configuration issues

One of the biggest issues found in embedded systems are custom encryption algorithms and systems. This is commonly termed “roll your own cryptography”. Sometimes these are encryption algorithms built from the ground up, other times they are systems implemented using secure cryptographic primitives in an insecure manner.

Example: SSL/TLS without authentication of endpoints

Encrypting data between two endpoints is largely futile if it is not possible for either party to determine if the other is authentic. A large part of SSL/TLS concerns the use of certificates to allow servers and clients to identify themselves using a chain of trust.

Many libraries supporting SSL/TLS will establish an encrypted communication channel without fully validating the authenticity of the endpoints. For example, some libraries do not check that the server name in the certificate matches the expected name.

Because of this, it is often possible to intercept SSL communications from embedded devices.

Example: Weak encryption in bootloaders

Bootloaders are often limited in size and must run quickly to provide a good experience. A secure bootloader must load the firmware image, check the signature, and then decrypt the firmware.

It can be challenging fitting the required cryptography into this small space. Taking existing solutions using general purpose libraries such as openssl often gives solutions that are both too large and slow. Even embedded SSL implementations such as WolfSSL can be too big.

As a result, developers either implement their own cryptography, use insecure cryptography (such as XXTEA), or miss out secure bootloader functionality entirely.

Potential Solutions

Silicon vendors should provide cryptography libraries that are targeted towards embedded systems, and these should have ready-made solutions for the majority of common applications.

Conclusion

Getting hardware, firmware and crypto choices right early on can save a whole heap of issues down the line. Makes the right choices for security at the start can save product recalls, awkward PR problems and run-ins with privacy regulators.

Discuss security at the beginning, save yourself trouble later.