The content of the article
Astrologers have proclaimed a decade of attacks on IoT devices. New threats require an integrated approach; therefore, not only their developers, but also iron producers are concerned about the security of embedded systems. Today, using the Nucleo debug board with STM32H743 as an example, I’ll tell you which attack vectors should be considered first and how you can protect firmware and sensitive data.
Mad style illumination Jean Michel Jarre or Rammstein’s new album from the speakers at half past four in the morning – it's all cute pranks compared to what the consequences could lead to hacking automatic pet feeders or wearable medical devices.
Updates “over the air” and the numerous debugging interfaces of smart devices can turn out to be a serious security hole, which will allow an experienced attacker to replace the factory firmware with his own, not to mention the banal theft of someone else's intellectual property. Stupid, stupid modern IoT!
What is Secure Boot for?
In general, a developer who wants to protect their device has two key tasks to solve.
- First of all, a firmware authentication mechanism (authentication) should be implemented. For this, various cryptographic algorithms are used (for example, SHA-256 and NIST P256). They allow you to make sure that only trusted code will be executed on the device.
- In addition, it is necessary to protect memory from external attacks and deprive the attacker of access to critical regions, which he could theoretically gain through software vulnerabilities or when using debugging interfaces (for example, JTAG) or a logical analyzer.
So, these are two different protection mechanisms and they pursue different goals, but only their combined application allows you to effectively deal with threats. In other words, even the most advanced cryptographic algorithms will be useless if a hacker can receive a decrypted firmware dump. Conversely, read-protected memory will not prevent the download of a program with malicious code.
How it works
Today, the easiest way to update a device’s firmware (SFU, Secure Firmware Update) is to send it the latest version remotely, “over the air”. Thus, we store on the server and distribute the already encrypted binary, which the client can download, confirm its integrity, authenticate, decrypt, and finally install.
At the same time, the following measures provide basic security: firstly, the possibility of alternative loading methods is excluded. For this, the confirmed Secure Boot is used, which forms the root of trust in our system. Secondly, private encryption keys must be stored in the device’s firmware and be individual.
In addition, the specific implementation of the cryptographic algorithm should be checked for resistance to AVK (attack on secondary channels, side-channel attack) or AMIS (attack by the method of induced failures, fault injection attack). We will come back to this.
Finally, care should be taken to protect against unwanted external access. Fortunately, many developers have already learned to turn off JTAG – the most coveted gift for an attacker. However, manufacturers do not stand still and today offer additional means to detect the impact, such as Anti-Tamper. They are not used as often as we would like.
Now let's see how the application of such recommendations in practice looks for the STM32 microcontroller line.
It is worth noting that the set of available protective equipment depends on the specific MK family (F, G, L and H). The demos in the X-CUBE-SBSFU package cover most of this set, but you should consult the documentation for complete details anyway. Specifically, today we are interested in:
- AN5156 – key material about the safety of microcontrollers STM32;
- UM2262 – A guide to the SBSFU framework in the XCUBE package;
- AN4838 – Apnout for MPU (Memory Protection Unit);
- PM0253 – manual on protection mechanisms for the core of Cortex-M7;
- DS12110 – datasheet on MK H743;
- RM0443 – reference on MK H743.
All links are in PDF.
Read Protection, RDP
This is the basic security mechanism that prevents access to the contents of the memory of the microcontroller by various debugging tools (JTAG, SWV and ETM). Its use is recommended in all cases on ready-made serial devices. Disabling RDP is only possible for the first level of protection and erases the contents of flash memory. Turning on the second level is an irreversible operation for a chip.
Theoretically, all this can complicate the service and finding the cause of the malfunction of the equipment returned by the user. However, since the application itself still retains the ability to write to read-only memory and modify it, the possibility of firmware updates (including using SFU) remains. When RDP is enabled, an attempt to access a protected area of the memory generates an error on the AHB bus.
On the H743, RDP bits are responsible for this function.
(15:8) in a pair of registers
FLASH_OPTSR_PRG from the Option Bytes area. In this case, the value
0xAA corresponds to a zero level of protection (default), value
0xCC – the first, and any other – to the second (maximum) level.
Formally, on the diagrams STMicroelectronics Option Bytes refer to the internal flash memory, however, direct access to them is impossible. To interact and make changes, the user needs to access the registers and follow a certain procedure (for more details, see the Option Bytes Modification section on page 157 RM0433).
Continuation is available only to participants
Materials from the latest issues become available separately only two months after publication. To continue reading, you must become a member of the Xakep.ru community.
Join the Xakep.ru Community!
Membership in the community during the specified period will open you access to ALL Hacker materials, increase your personal cumulative discount and allow you to accumulate a professional Xakep Score!
I am already a member of Xakep.ru