Think Like an Attacker
How do you verify the security of microcontrollers? MCU manufacturers often make big claims, but sometimes it is in your best interest to verify them yourself. In this article, Colin discusses a few threats against code readout and looks at verifying some of those claimed levels.
By Colin O’Flynn
You’ve got your latest and greatest IoT toaster designed, and you’re looking to move forward with production. But one thing concerns you: How do you know this stellar code isn’t going to be cloned as soon as you release it to the market?
You turn to the firmware protection features of your chosen microcontroller, but how good is it? This article can’t hope to answer that question in general, rather it will instead give you a short example of how to help answer that question for any specific microcontroller.
— ADVERTISMENT—
—Advertise Here—
In particular, it will teach you to “think like an attacker” when reading through datasheets. Look for small loopholes that could have big consequences, and you will have a much better time navigating the landscape of potential attacks.
Know What’s Out There
One of the most important things is to keep an eye out for new and interesting attacks against these devices. In my January 2018 article (Circuit Cellar 330) I described how there is a published attack against some of the NXP LPC devices, which makes it very easy to unlock them. You can see the presentation entitled “Breaking Code Read Protection on the NXP LPC-family Microcontrollers” by Chris Gerlinsky which describes this attack. Another recent one is an attack against STMicroelectronics’ STM32F0 devices entitled “Shedding Too Much Light on a Microcontroller’s Firmware Protection” by Johannes Obermaier and Stefan Tatschner. That one is a little more limited, but still has some interesting information regarding potential security attacks.
I’m hoping to distill some of these attacks down into common problems, which will help you close a few loopholes before someone rips off your IoT toaster design. At least now if it fails in the marketplace you have no one to blame but yourself.
To give you something concrete to read (and for me to reference), I’ve chosen to use the ST STM32F303 series because it’s a device I’ve been using myself lately. I’m not going to be revealing any unknown vulnerabilities—so if you’re reading this from your office at STMicroelectronics, no need to sweat. It also has some pretty common configuration options, so makes for a nice reference you can apply to a range of other devices.
ST Read Protection (RDP)
The first step when you are looking at a new device should be to very carefully inspect the security or debug lock protection portion of the datasheet. They will typically go into a fair amount of detail around how the protection mechanism works.
The STM32F3 Reference Manual (RM0316) has this split into two sections. Section 5, entitled “Option byte description” provides information about how the flags are stored in flash. Section 4.3 entitled “Memory Protection” details how this is actually used to protect the code in your device.
Table 1
This excerpt from the datasheet shows how the flash memory read protection levels are defined for the STM32F3 device.
The two important pieces of information for us are replicated in Table 1 and
Table 2. They are the flash memory protection levels, and the associated access allowed at each level. The RDP byte is a special “option byte”, which is the value of a specific location in flash memory. Note the scheme they have chosen uses two bytes, where one is always programmed to be the complement of the other byte. This is presumably used for error checking, and if a byte is not matched with a complement, an error flag is set.
Table 2
Code protection levels 1 and 2 have differing protection abilities. This excerpt from the datasheet shows where flash memory can be read/written/executed from.
Right away you should notice that this scheme does not fall victim to the same problem as the LPC attack I talked about before. In particular the LPC attack exploited the fact a fault or glitch could corrupt the flag value, which caused the CPU to disable the protection.
With the STM32F303, these invalid levels will all map to Protection Level 1. This protection level does not allow external flash access, which “should” be a good sign. The highest protection level also claims to be impossible to remove, but if we could corrupt the value of the option bytes in memory we could downgrade from Protection Level 2 to Protection Level 1. In fact, this “downgrade” is exactly what was presented by Obermaier & Tatschner. The downgrade used a chip decapsulation and light to flip the bits, which is relatively invasive. Other fault attacks (such as voltage or EM) might work but would require investigation before assuming that. Such temporary fault attacks would require the value is read and latched.
— ADVERTISMENT—
—Advertise Here—
But as a good designer, you should assume such faults could be made possible. In this case it would be possible to “downgrade” the device from Protection Level 2 to Protection Level 1. So, what happens if an attacker performed this downgrade? That takes us into the second part of this article. …
Read the full article in the July 336 issue of Circuit Cellar
Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!
Circuit Cellar's editorial team comprises professional engineers, technical editors, and digital media specialists. You can reach the Editorial Department at editorial@circuitcellar.com, @circuitcellar, and facebook.com/circuitcellar
