On Fri, 26 Mar 2021 at 19:36, Heinrich Schuchardt xypron.glpk@gmx.de 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
Of course it is more promising to do this on the hardware side, nobody is debating that. Whether it makes sense to harden the software as well is completely orthogonal to that: on hardened hardware, it adds another layer of protection, and on hardware that cannot be hardened for some reason (cost, or more often, the fact that it has already shipped), it adds a layer of protection where no protection whatsoever was available beforehand.
However, I do share some of your skepticism: incorporation of these techniques is not trivial, and commoditizing it by dropping it into some library that you can link your software against is *not* what I would prefer to see. This only encourages a check the box mentality, where people either assume that having the library makes everything magically secure, or ($DEITY forbid), it gets sucked into the MISRAs or FIPSes of this world, and it becomes a certification requirement, and using the library is mandatory, regardless of whether there is a point to it, or whether it is being used in the right way.
So I'd be more interested in seeing how the underlying methods can be applied more widely, and not how it gets shrinkwrapped and shipped with a .h file without any need on the part of the developer to understand what really goes on under the hood.