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 ...).

Regards,
Joakim

_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to