skip to Main Content

Secure Boot on Steroids

One of the biggest threats to the internet of things (IoT) is the installation of malicious software (malware) on IoT devices that changes the behavior of these devices to facilitate very specific attacks. This malware is often the first step toward use of the device in a botnet that allows attacks like directed denial of service (DDoS), but also more subtle attacks that use the now-compromised device as a steppingstone toward further infiltration of connected systems that run critical processes.

Hacker 16x9 1024x576

The best-known botnet attack is undoubtedly the Mirai Botnet, which infected hundreds of thousands of devices. Back in 2016, criminals used Mirai to perform an attack that overloaded several servers around the world. With this attack they were able to disrupt services of many large online service providers, such as Twitter, GitHub, and Spotify. Although the peak of Mirai’s devastation was in 2016, it still has active spin-offs to this day. So, clearly botnet attacks are not only a threat to the devices that are compromised, but also are a threat to anything that is part of our connected world.

An important tool to prevent malware from being installed on IoT devices is Secure Boot.

What is Secure Boot?

Secure Boot prevents changes to the software that runs on a device, which is essential to ensure that malware like viruses and Trojans cannot be installed by an adversary. Embedded systems typically consist of a combination of hardware components, such as microcontrollers, communication chips, flash memories, and software that runs on the microcontroller and contains the application code that defines the functionality that brings value to the end customer.

The purpose of Secure Boot is to ensure that only genuine or trusted software code can run on a device. This involves controlling the sequence of events from the very start up of the device until and including running the application code. With Secure Boot, it is not possible for a non-trusted party to change the functionality from what was intended by the manufacturer.

Taking Secure Boot to the Next Level with QuiddiKey

While Secure Boot takes care of the code protection, there are other important assets on a device that need to be protected as well. These assets are the cryptographic keys that are used to encrypt sensitive data and enable trusted communication with other devices and services. The storage of these device-unique secrets poses an additional challenge to a device with Secure Boot: how can we be sure that these secrets are protected and cannot be read or, even worse, changed?

This is where QuiddiKey comes in to put your Secure Boot on steroids to serve as a complete solution that includes protecting cryptographic keys and other sensitive data. QuiddiKey is a hardware IP solution that enables device manufacturers and designers to secure their products with internally generated, device-unique cryptographic keys without the need for adding costly, security-dedicated silicon. It uses the inherently random start-up values of SRAM as a physical unclonable function (PUF), which generates the entropy required for a device-unique secret.

Find out more about how QuiddiKey can enhance Secure Boot to create a solution that goes beyond protection of code to include the safeguarding of device-unique secrets. Download the new application note, Secure Boot with QuiddiKey, which details how security-, system-, and software architects can effectively integrate secret-protection functionality with Secure Boot into their devices. The app note includes a useful explanation of the main relevant concepts and how these can be made to work together in an example architecture that can serve as a starting point for new projects.

The integration of Secure Boot with device-unique secret protection provides an IoT device with all required ingredients to safeguard its identity and protect itself against becoming mobilized into an army of malicious bots.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published.

Back To Top