On Mon, Mar 29, 2021 at 03:02:21PM +0200, François Ozog wrote: > On Mon, 29 Mar 2021 at 14:46, Heinrich Schuchardt <xypron.g...@gmx.de> > wrote: > > > 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? > > > > Yes it was demoed by Riscure in a past Connect, I can't remember which > one. Joakim may certainly be more specific. > This demo triggered the concern with me and since then I have been > monitoring advances in the topic. You may want to check > https://www.riscure.com/uploads/2019/06/Riscure_Secure-Boot-Under-Attack-Simulation.pdf >
To give a real example, one of the first security issues reported [1] to the OP-TEE project was the Bellcore attack [2] put in practice. Our implementation wasn't using blinding [3], so the people reporting the issue were able to recover the private key from OP-TEE running on the HiKey device using SCA. They first scanned the device with different EM probe antennas and when they found a location on the chip giving the best signal they did an EM Fault Injection attack making the RSA-CRT computations to give faulty signatures (with up to 50% repeatability). With faulty signatures, a good signature and maths you'll be able to recover the private key. The mitigation? A software mitigation. This was running an Armv8-A where everything was up and running (including Linux), i.e., certainly not a tiny M-class device running things from flash. Related to Riscure as Francois referred to. They held workshop days a couple of months ago and majority of the talks was about glitching, fault injection etc. I can't remember the details, but in one talk they demoed a fault injection attack that had some percentage of success rate. Then they introduced a couple of software mitigation patterns one by one and at the end IIRC the success rate was almost zero (if not zero). I fully agree with Ard. Even though you can abstract certain things into libraries and helper functions, it's in my opinion not a "create a lib and enable it and you're secure" operation. I think software mitigation patterns should be carefully applied around sensitive operations. But as said it needs some education and motivation to why you should do it. From a logical view on the code it doesn't make sense to do identical "if" checks twice in the same function. But from a SCA mitigation point of view it can actually make sense. [1] https://www.op-tee.org/security-advisories/ [2] https://eprint.iacr.org/2012/553.pdf [3] https://en.wikipedia.org/wiki/Blinding_(cryptography) // Regards Joakim _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
