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 >>> >>> 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? Best regards Heinrich _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
