Three Types of Attacks on IoT Devices
Just as there are three kinds of IoT device security risks to consider, there are three types of attacks that every IoT operator needs to consider.
Communication Attacks on IoT Devices
Communication attacks focus on exploiting communication ports on IoT devices.
In 2016, for example, a massive internet outage was produced by a botnet named Mirai. Mirai targeted a specific camera brand, more than 500,000 of which were connected to the internet with their SSH port open. What’s more, the root account of the camera was protected with a password hard coded into the device and set to the word ‘root’. Essentially, this made each camera a virtual sitting duck for the Mirai botnet.
- Unencrypted MQTT Communications
IoT devices are constantly connected and communicating with the cloud, with a base, and with each other. While those communications should be encrypted, oftentimes they are not. Indeed, in 2015 one researcher found that he could access the unencrypted information from hundreds of thousands of devices around the world by scanning Port 1833, the unencrypted port for MQTT.
Most IoT devices come equipped with generic accounts, and those accounts with credentials and passwords. As the Mirai Botnet attack proved, often times these IoT device security passwords are easily guessed and even more easily exploited. While best practice is to make a product unusable until the end user changes that generic password, many devices ship without even such elemental precautions.
Protecting from communication attacks is a matter of securing the ports and denying access to surfaces that attackers might use to breach devices.
Secure by Design to Avoid Software Attacks
Software attacks focus on getting access to a device, either remotely or locally, and executing software on that device. Protecting against such attacks can involve a number of different strategies, including:
A common attack vector for bad actors is pushing a false update or tampering with a true update to the embedded software on a device. Protecting against this threat is best achieved by embedding a root of trust in the product.
A root of trust means that, from the very first later of software (the root layer), each layer verifies the signature of the next layer that will load in the memory before it starts executing. An encryption key makes this root of trust possible, but it does come with its own problem: where should the key be stored, and how can we be sure that the key has not been tampered with?
NXP offers an elegant solution to this question of IoT device security which consists of fusing the hash of the public key into their i.MX family of microcontrollers. Because of this, when the ROM code loads the public key, it verifies the hash and verifies that it matches the value that has been fused in the processor. As it impossible to tamper with the eFuse of the processor, the only software that will ever be executed on the processor is that which is signed with the right private key.
While a root of trust ensures that software on the product cannot be tampered with. Yet validating a complete filesystem in the same way would be far too time consuming, yet again there is a secure solution. A tool like DM-Verify uses a Merkel tree to make the whole process faster in much the same way as a blockchain works for a cryptocurrency. There’s a limitation, though: the file system needs to be in read-only mode, and hence an alternative is to use DM-Crypt which encrypts the filesystem as a block level.
There are two significant advantages to this approach: first, the filesystem can still be modified during runtime, and second, the data at rest cannot be accessed.
This second advantage has an interesting and positive side effect of its own: if someone physically takes control of the device and unsolders the chip used to store the software from the IoT device board in an effort to access the data, it will be all but impossible to do so.
Yet the issue of secure storage of the key used for encryption remains.
For IoT devices that use a processor from the i.MX family, there is the option to use a black key. The black key is a secret key derived from a secret root key that is unique to each i.MX processor. The key is never accessible from the OS in a readable format and is, as such, incredibly secure.
Hardware Attacks on IoT Devices
Hardware attacks bypass network ports and software weaknesses and instead target the physical components of the device itself. Protecting against such attacks is getting a whole lot closer to the practical engineering of MacGyver.
Debugging code on a commercial version of a product is convenient but should be disabled. Most processors have a fuse that can be burnt to disable access to the JTAG interface.
Critical buses should also be routed within the internal layers of your PCB. While it might still be possible of x-ray the device, map the internal layers, and drill into the PCB, the cost/benefit analysis of such an attack is not positive for the bad actor.
Tamper protections should be stock standard and some processors include sensors that can detect a hacker trying to tamper with hardware. For example, the sensor could trigger a signal when a device is opened or tampered with that would zero all of the cryptographic keys in the RAM.
Finally, you could take action to drown a board in epoxy or use specialized screws to avoid physical tampering with your hardware. This won’t assuage all bad actors, of course, but again the cost/benefit analysis is in favor of the manufacturer over a bad actor tasked with tampering with a device.