On 29.03.21 15:02, François Ozog wrote:
On Mon, 29 Mar 2021 at 14:46, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@gmx.de> wrote:
On 29.03.21 09:40, Joakim Bech wrote: > Hi, > > On Fri, Mar 26, 2021 at 07:36:34PM +0100, Heinrich Schuchardt wrote: >> On 26.03.21 15:12, François Ozog wrote: >>> Hi >>> >>> Trusted Firmware M recently introduced protection against glitching at >>> key decision points: >>> https://github.com/mcu-tools/mcuboot/pull/776 <https://github.com/mcu-tools/mcuboot/pull/776> >>> >>> To me this is a key mitigation element for companies that target PSA >>> level 3 compliance which means hardware attacks resilience. >>> >>> I believe similar techniques need to be used in different projects >>> involved in Linux secure booting (TF-A, OP-TEE, U-Boot, Linux kernel). >> >> Power glitches can induce changes in data, in code, and in CPU state. >> Signing selected variables cannot be a sufficient counter-measure. >> >> If you want to protect against power glitches, it seems more promising >> to do so on the hardware side, e.g. >> >> * provide circuitry that resets the board if a power-glitch or an >> electromagnetic interference is detected >> * use ECC RAM >> > I agree and disagree. Hardware mitigations are probably better, but > by applying software mitigations you can make it significantly harder to > perform a successful SCA. Most glitching attacks use some kind of time > offset from a known occurrence/event and then a single glitch. With > software mitigations, you can introduce randomness and also write the > code so it'd require multi-glitching attacks to make it a successful > attack. > > The greatest challenge with this is to convince and educate maintainers > that writing code that might look very weird actually makes sense in > certain areas of the code base. SCA software mitigations is no silver > bullet, but if you care deeply about security, then I think it's just > yet another mitigation pattern that you should apply, just as everything > else we're doing when it comes to trying to securing our products > (signatures, ASLR, measured boot, canaries, constant time functions, etc > etc ...). On devices that run the software completely from flash variables are a main attack surface for power glitches. U-Boot and Linux run from memory. There the major attack surface are not critical variables but the code itself. So while the approach taken on TF-M may fend off a significant percentage of power glitch attacks on the devices using it this might not hold true for U-Boot and Linux. Do any measurements analyzing the proportions of code, data, and CPU involvement in successful power glitch attacks exist?Yes it was demoed by Riscure in a past Connect, I can't remember which one. Joakim may certainly be more specific. This demo triggered the concern with me and since then I have been monitoring advances in the topic. You may want to check https://www.riscure.com/uploads/2019/06/Riscure_Secure-Boot-Under-Attack-Sim... https://www.riscure.com/uploads/2019/06/Riscure_Secure-Boot-Under-Attack-Simulation.pdf
Thanks for the reference.
The slides (75, 121) indicate that the major attack surface is changed code not changed variables.
The TF-M patches mentioned above focus on validating variables and introducing random delays when accessing them.
Riscures' emphasis on simulation suggests that it is not trivial to design code that is resilient to power glitches. Some design principles are provided in https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Chann....
Best regards
Heinrich