A new attack on STM32F1’s read-out protection has been published (partially as of now).
The STM32F1 is used in some Nitrokey products as follows:
Nitrokey Start: Cryptographic keys and data objects (EF) are stored in the STM32F1. Private cryptographic keys are additionally encrypted with the user password (OpenPGP Card User PIN). Note that the product’s lower security (no tamper protection) has been communicated in our product description and that therefore the Nitrokey Start is positioned as an entry-level model (compared to our other smart card models).
Nitrokey HSM: No user information is persistently stored in the STM32F1.
Nitrokey Pro:
One-time passwords (HOTP, TOTP) are stored in the STM32F1. These serve as a second factor and are therefore accessible without authentication by default. Think of physical OTP tokens that display one-time passwords on an integrated display at the touch of a button.
The Password Safe stores passwords in the STM32F1. These are additionally encrypted with an AES key, which is stored in a tamper-proof smart card (and is PIN-protected).
Cryptographic keys are not stored in the STM32F1.
In summary, we are not surprised by such an attack and therefore we primarily use tamper-proof smart cards in our products. We assess the risk for our products as low and do not see any acute technical need for action. In the future we will change our products to other (more secure) microprocessors and smart cards.
Hi Jan, new attacks on the STM32F1 have recently been discovered and published:
It would be great if you could update this post to include the new attack vectors and their impact.
The described attacks allow a person with physical access to the device to read, modify, and reprogram the device to the full extent. While partially(!) reading data is possible with the attack mentioned in the initial post, this new attack gives access to the entire(!) data stored on the STM32F1. This lowers the bar for an attacker as there is no loss-of-information involved when reading and reprogramming the device anymore.
That means, someone can read out all stored (but partially encrypted) user data and firmware, modify the firmware (e.g., insert a backdoor, weaken or disable encryption/security, intercept and leak the smartcard PIN…) and reprogram the device. Such a modification would not be discoverable by the user as far as I see. IMHO, this creates a risk if someone is able to gain temporary access to the hardware token and performs such manipulations. This violates at least firmware integrity and authenticity which can no longer be guaranteed and consequently can also affect the user’s data.
A statement which takes such manipulations into account would be great. Especially since this new attack allows a full readout and makes manipulations way more easy.
Thank you for the PDF. I understand it is the published PDF to the same attack mentioned above, but not a new attack. Therefore my statement above still applies.
Hi Jan, thank you for your answer. The paper reiterates the attack described before, but it comprises also a novel attack.
I was especially referring to Section 7.4 “H3: Shellcode Exec. via Glitch and FPB”. This is a new attack that gives full access.
Hi Johannes!
STM32F1 doesn’t has a write protection. This means if somebody has physical access to the STM32F1 she can reset and flash any firmware (a reset has to be performed first). From the risk perspective, this is a man in the middle (MITM) attack, similarly to a potential MITM attack on the client PC (but potentially harder to execute and to detect.) I don’t see how Section 7.4 “H3: Shellcode Exec. via Glitch and FPB” changes this picture (only read it briefly).
