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