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.
I also think this is first about guidelines with a set of helpers.
For instance, lets consider:
if (checkstuff(input)==0)
{
dostuff();
}
It Can be transformed into something like (yet insufficient to be really protected but that's gives an idea, more to be read in the TFM code and readme.md)
/* SUCCESS is an arbitrary value != 0 as 0 is a typical value of a register when glitched */
if (checkstuff(input, &result) == SUCCESS)
{
letwaitarandomdelay();
if (doublecheck_successful_result(input, result) == SUCCESS)
{
/* this code is not protected against PC attacks */
dostuff();
}
--
Ard.