Unlock the Door to my Secrets, but don't Forget to Glitch @ CCCamp23

In Security and Trust in Open Source Security Tokens, we presented an attack vector that exploits a feature which allows to disable the debug interface protection of a microcontroller under the condition that its entire flash memory is erased first. With the help of fault injection, the erase operation can be suppressed which ultimately allows access to the entire flash memory. Our publication left many open questions such as the practicability and generalizability of this attack vector. To answer these questions, we conducted a comprehensive evaluation in form of an academic research paper which includes multiple microcontrollers and different fault injection techniques.

Since publishing research papers is tedious and takes a lot of time, we decided to present a small preview of our results on the Chaos Communication Camp 2023. The talk gives a short introduction to the so-called flash erase suppression attack vector together with a live demonstration on the STM32L422 microcontroller. We chose this device for two reasons. First, it is already known to be vulnerable (CVE-2021-29414) due to our first publication and thus not part of the current coordinated vulnerability disclosure (CVD) process. Second, the voltage glitching setup for this microcontroller is very handy and thus predestined to be shown live on stage. Unfortunately, I was unable to attend the camp at short notice. Thankfully my colleague Silvan Streit was also at the camp and offered to give the talk for me. The video recording is available on media.ccc.de and the slides can be found here.

The comprehensive analysis will be presented at the Cryptographic Hardware and Embedded Systems (CHES) 2024 conference. I will cover the paper in a separate blog post and provide additional details and material, so stay tuned.

Security and Trust in Open Source Security Tokens

Electromagnetic fault injection (EMFI) setup with the Solo security token as target device

Hardware security tokens effectively prevent most password-related security issues and improve security indisputably. However, there are new threats from attackers with physical access which need to be discussed. Supply chain adversaries may manipulate devices on a large scale and install backdoors before they even reach end users. In evil maid scenarios, specific devices may even be attacked while already in use. For that reason, we thoroughly investigated the security and trustworthiness of seven commercially available open source security tokens, including devices from the two market leaders: SoloKeys and Nitrokey.

We identified and practically verified significant vulnerabilities in all seven examined tokens. The methods range from exploiting logical and architectural flaws to side-channel and fault injection attacks. Fortunately, due to the open source nature of the security tokens, we were able to propose firmware modifications which mitigate all identified vulnerabilities. Some of these modifications are already applied by the token manufacturers.

The results of this research will be presented at the Cryptographic Hardware and Embedded Systems (CHES) 2021 conference. The final and peer reviewed paper is already available on the Cryptology ePrint Archive.

One Exploit to Rule them All? On the Security of Drop-in Replacement and Counterfeit Microcontrollers

A bunch of microcontroller boards

After Exception(al) Failure, we bought a bunch of drop-in replacement chips for the STM32F1 series and analyzed them with respect to their firmware security features. We found lots of severe vulnerabilities and even encountered counterfeited devices. The results of this research will be published in form of a scientific paper at the 14th USENIX Workshop on Offensive Technologies on 11 August 2020. The work is a joint collaboration of Johannes Obermaier, Marc Schink and Kosma Moczek.

We will not publish the paper in advance to the conference in order to adhere the deadline of the coordinated disclosure process. However, here is a short teaser to bridge the time gap until the publication:

With the increasing complexity of embedded systems, the firmware has become a valuable asset. At the same time, pressure for cost reductions in hardware is imminent. These two aspects are united at the heart of the device, i.e., the microcontroller. It runs and protects its firmware, but simultaneously has to prevail against cheaper alternatives. For the very popular STM32F1 microcontroller series, this has caused the emergence of many competitors in the last few years who offer drop-in replacements or even sell counterfeit devices at a fraction of the original price. Thus, the question emerges whether the replacements are silicon-level clones and, if not, whether they provide better, equal, or less security. In this paper, we analyze a total of six devices by four manufacturers, including the original device, in depth. Via a low-level analysis, we identify all of them as being individually developed devices. We further put the focus on debug and hardware security, discovering several novel vulnerabilities in all devices, causing the exposure of the entire firmware. All of the presented vulnerabilities, including invasive ones, are on a Do it Yourself (DiY) level without the demand for a sophisticated lab – thereby underlining the urgency for hardware fixes. To facilitate further research, reproduction, and testing of other devices, we provide a comprehensive description of all vulnerabilities in this paper and code for proofs-of-concepts online.

More information will be published here soon – stay tuned!

Update (11 August 2020): The paper and supplementary material are now available.

Exception(al) Failure - Breaking the STM32F1 Read-Out Protection

The firmware of microcontrollers usually contains valuable data such as intellectual property and, in some cases, even cryptographic material. In order to protect the confidentiality of these assets, most microcontrollers feature some kind of firmware read-out protection. This security feature shall prevent adversaries with physical access to a device from reading out the internal flash memory. Nevertheless, security researchers as well as hobbyists showed repeatedly that these security features can be circumvented. In this research article, we examine the flash read-out protection (RDP) of the STM32F1 series from STMicroelectronics. We discuss a novelly discovered vulnerability whose exploitation would be the first non-invasive way to circumvent the feature. The issue results from an insufficient access restriction: flash data reads via the debug interface are blocked but the CPU's exception handling process is still able to read from flash memory via the ICode bus. We explain in detail why and how this vulnerability exposes major parts of the internal memory, thereby affecting device security.

Read more…

Coming soon: Breaking the STM32F1 Read-Out Protection

We identified a vulnerability in the read-out protection (RDP) mechanism of the STM32F1 series from STMicroelectronics. CVE-2020-8004 has been assigned to this issue.

An attacker with access to the debug interface can exploit this vulnerability and extract large amount of data from the flash memory. If you rely on this security feature, we highly recommend you to take appropriate action. The only way to avoid exploitation and thus keep the entire flash memory content confidential is to physically prevent an attacker from gaining access to the debug interface.

This announcement is part of a coordinated vulnerability disclosure process. An extensive article with technical details about the vulnerability will be published here on the 15 March 2020.

Contact: Marc Schink, Johannes Obermaier