Security in Manufacturing: Closing the Backdoor in IoT Products (.PDF Download)
A secure system is only as strong as its weakest component, and every step in the manufacturing process is a component in that system. While much has been written about the security of wireless protocols, ICs, and deployed systems, securing the manufacturing process for those systems is often forgotten.
Let’s examine how we might attack an embedded system using a smart lock as an example. If we’re serious about attacking this system, we probably don’t want to compromise just one lock. We want to create a systematic exploit that can be used against any lock and then sold to others who want to bypass one specific lock in the field.
The lock manufacturer has anticipated our attack and spared no expense creating a secure product. From multiple code reviews to anti-side-channel-attack hardware to extensive penetration testing, the product is well-designed and protected. This would be a challenge if we were going to attack the lock itself, but we have another option. Attack the contract manufacture (CM) that assembles and tests the lock.
It’s almost universally required for firmware images to be transferred, stored, and programmed in plain text. All we need do is bribe one of the CM employees to give us the image, and then swap it out with an image we modified. The firmware will be nearly identical, but with a backdoor we can exploit whenever we wish. The CM will then be manufacturing compromised devices for us.
Our exploit requires no special hardware and only a moderate amount of sophistication to develop, making it extremely cheap to create. It also completely bypasses all the time and effort the manufacturer spent to secure its product.
Protecting Firmware Integrity
The fundamental problem in manufacturing is that with current embedded processors, it’s very difficult to guarantee the integrity of a firmware image. If the firmware is programmed in plain text, we can easily modify it on the test system as shown in block diagram 1 of Figure 1, where the red maker indicates code vulnerable to attack.