Fault Attacks on ECC Signature Verification

Digital signatures used in embedded systems are often based on elliptic curve cryptography (ECC) thanks to its performance and low memory profile. In secure boot processes they provide the cryptographic foundation for guaranteeing the authenticity of a firmware image. At the same time, these resource-constraints and the physical exposure of such devices makes them prime targets for fault attacks. Prior work studied faults on signature generation in depth, yet nobody had systematically asked how vulnerable signature verification is to fault attacks combined with carefully crafted signature inputs. That is exactly the gap we set out to close.

20. August 2026

Existing fault research on ECC only targets signature generation [1], [2], [3], [4], we turn to verification, examining two levels:

the cryptographic level (what happens if you fault elliptic-curve points or parameters?), and
the implementation level (what happens inside real bootloader and crypto-library implementations under instruction skips and bit flips?).

We show how to enable signature forgery with a single bit flip, and how to bypass hardened secure bootloaders with a single skipped instruction. We also propose concrete countermeasures.

This blogpost is a summary of our recent work presented at CHES 2025. For further technical details, please refer to the paper “Fault Attacks on ECC Signature Verification”.

Why Signature Verification Is a Prime Fault Target

Secure bootloaders play a critical role in verifying the authenticity of software and firmware, especially in systems that are physically exposed to unauthorized individuals, a common scenario for embedded systems. They ensure that only software signed by the manufacturer is executed, and thereby prevent malicious firmware from running.

In the secure boot process, an attacker can supply an arbitrary firmware image together with a freely chosen signature value. Without the private key corresponding to the public key stored securely on the target device, the attacker cannot generate a valid signature. The bootloader detects invalid signatures and aborts the boot process. This holds, however, only as long as the attacker has no physical access to the device. If an adversary can inject a fault that tricks the device to erroneously accept a forged signature, they bypass this crucial step of the secure boot process.

We focus on exactly this setting and investigate the feasibility of attacks under realistic fault models.

Faulty Points and Weak Curves

A central part of our work examines what happens when faults are injected into elliptic-curve points or parameters in schemes based on Weierstraß curves. These so-called weak-curve attacks have been used against signature generation [1], but their application to signature verification had not been studied.

On a short Weierstraß curve $E: y^2 = x^3 + a x + b$, efficient implementations of the group law often use only parameter $\textbf{a}$ explicitly. Parameter $\textbf{b}$ never appears; it is given only "implicitly", through the curve point.

This has a subtle but dangerous consequence: flipping a bit in the x-coordinate of a point makes the implementation compute scalar multiplications on a different curve with a different $\textbf{b}$.

Alternative (but slower) algorithms or additional checks can prevent this. However, these measures are rarely implemented for verification, since no threat was previously known.

A Tiny Example

To demonstrate how an attacker can exploit this property, we show a toy example over $\mathbb{F}_{97}$ :

Let the original curve $E$ be $y^2 = x^3 + 2x + 14$ with base point $G = (14, 19)$ and order $ord(G) = 101$ .
A bit flip in the x-coordinate produces the faulted base point $G' = (12, 19)$ .
This faulted point $G'$ now lies on a totally different curve $E': y^2 = x^3 + 2x + 64$, obtained by solving for $\textbf{b}$, with $ord(G') = 24 = 2^3 \cdot 3$ .
The elliptic-curve discrete logarithm problem (ECDLP) on $G'$ can then be solved in $\textbf{$O(\sqrt{3})$}$ instead of $O(\sqrt{101})$, using Pohlig-Hellman.

The natural question is how often a fault lands on a curve this weak. Our estimates show that on a random 256-bit curve, a single bit flip can reduce ECDLP complexity from $2^{128}$ to roughly $2^{30}$, which is well within reach of offline computation.

What We Found: Breaking Down Each Scheme

Injecting the fault described above does not automatically compromise every ECC-based signature scheme. We investigated the impact of this faulty-point attack on several common schemes.

Elliptic Curve German DSA

The Elliptic Curve German DSA (ECGDSA) is a slightly modified variant of the widely used ECDSA algorithm. As it turns out, this small variation makes all the difference in this attack scenario. In ECGDSA, verification recomputes a witness point \[ R = [h \cdot r^{-1}] G + [s \cdot r^{-1}] P \] and accepts the signature as valid if $R.x = r$. If we fault the public key $P$, we obtain $P'$ on a (likely) weak curve. All scalar multiplications with $P'$ now happen on this weaker curve. This lets us:

fix an arbitrary value for the signature component $r$
find a point $X$ such that $R.x = [h \cdot r^{-1}]G + X$ via algebraic transformation of the Weierstraß group law
solve the ECDLP over the weak curve: find $u_2 = s \cdot r^{-1}$ such that $X = [u_2] P'$
compute the missing signature component: $s = u_2 \cdot r \bmod n$

The offline ECDLP over the weak curve is the only noteworthy cost, but as argued above, it is very feasible.

ECSDSA: Similar Story, But Not for All Variants

For ECSDSA (the EC-Schnorr variant specified in BSI TR-03111 [5]), verification computes

\[ Q = [s] G + [r] P, \quad r' = H(m \parallel Q.x) \]

and checks whether 𝑟^′ = 𝑟. We showed that by faulting 𝐺 to 𝐺^′ on a weak curve, we can again reduce forging a signature to solving an ECDLP on the weak curve, as long as only 𝑄.𝑥 is hashed. However, if the scheme also hashes 𝑄.𝑦, the attack fails.

ECDSA: Surprisingly Resilient to Faulty Points

For ECDSA, verification computes

$R = [h \cdot s^{-1}] G + [r \cdot s^{-1}] P$

and checks that $R.x = r$. This is almost the same as ECGDSA, just with $r$ and $s$ swapped. Despite the similarity, ECDSA verification doesn't break when $G$ or $P$ moves to a weak curve, even if both move to weak but distinct curves. In our paper, we explore why these attacks fail. Our complexity analysis shows that even under aggressive assumptions, no strategy beats generic Pollard's rho on the original curve.

EdDSA is unaffected: twisted Edwards curves include all parameters in the group law, so a faulted point will not affect the curve used in the calculation.

A Closer Look at Implementations

We now move from algorithms to implementations: what if an attacker can skip instructions, flip bits in RAM or flash, or corrupt big-integer metadata during verification?

We examined:

MCUboot (using Mbed TLS), and
wolfBoot (using wolfSSL).

Both bootloaders implement software hardening measures against fault attacks (e.g., redundant checks via macros). However, the verification routines in the underlying cryptographic libraries remain largely unhardened.

Consequently, targeting the unhardened verification routine in the cryptographic library bypasses all bootloader hardening measures. To address this, we first need to understand how these functions can be attacked.

Our Fault Model for Implementations

We abstract capabilities commonly achievable through voltage glitches [6], clock glitches [6], [7], EMFI [8], [9], [10], [11], or lasers [12] into the following fault model:

instruction skips (e.g., skip a compare, a branch, or a function call),
bit flips in RAM/flash/registers,
the ability to:
- set a big-integer limb count to 0 or 1 (making a value 0 or very small),
- cause arithmetic functions to return 0, one of their inputs, or a fixed constant,
- skip entire subroutines (e.g., a scalar multiplication or hash update).

With this model, we systematically walked through each step of the ECDSA and EdDSA verification algorithms, revealing ten attacks.

Implementation Attack on EdDSA

For brevity, we cover only one of the ten attacks we found in this blogpost. Most EdDSA implementations (including wolfSSL) use an optimized verification:

1. Check $0 \le s < n$.
2. Compute $h = H(R \parallel P \parallel m)$.
3. Compute $Q = [s] G - [h] P$.
4. Check $Q = R$.

Under our fault model: if we skip the scalar multiplication $[h] P$, the calculation becomes $Q = [s] G - P$. The faulted result could be the point at infinity, zero, or something else. As long as it no longer depends on $h$ and is predictable, the attack works. We use $P$ here because that is what we observed in a real implementation. With this fault, forging a signature is trivial:

1. Pick an arbitrary $s$
2. Compute $R = [s] G - P$

We demonstrated this in wolfSSL by skipping a single function call in the Ed25519 verification path.

Countermeasures

As mentioned, EC point and parameter faults can be mitigated using complete formulas that include all curve parameters. If the associated runtime overhead is unacceptable, on-curve checks for intermediate points also work.

For each implementation-level attack, we propose lightweight checks with negligible overhead. Some have already been integrated into wolfSSL (starting with version 5.7.6) [13].

These checks cannot prevent every attack, but they block basic ones and force adversaries to use more sophisticated techniques. Faults in real-world systems can be more complex than our model covers, so stronger countermeasures may be needed. There is no one-size-fits-all solution: countermeasures must be tailored to each implementation. Still, we hope our work provides implementers with clear guidance on what to consider.

Takeaways and Recommendations

Don’t overlook signature verification. Fault attacks on verification can bypass secure boot entirely, even when the bootloader itself is hardened.
Weierstraß curves with incomplete formulas have a structural weakness. A single-bit flip can turn a strong curve into a weak one. If you must use ECGDSA or ECSDSA, use complete formulas or add robust on-curve checks for witness points.
EdDSA and ECDSA are structurally better when faced with faulty points.
- ECDSA’s structure is robust against all of our approaches.
- EdDSA’s twisted Edwards group law naturally avoids the implicit-parameter problem.

Harden crypto libraries, not just bootloaders. Even hardened bootloaders may rely on unhardened crypto libraries, and a single instruction skip in the underlying library can break the entire secure boot chain.
Cheap, targeted checks go a long way. Our ECDSA/EdDSA hardenings add almost no runtime cost but prevent a wide range of realistic fault attacks.

Bibliography

[1] I. Biehl, B. Meyer, and V. Müller, “Differential Fault Attacks on Elliptic Curve Cryp- tosystems,” in CRYPTO~2000, M. Bellare, Ed., in LNCS, vol. 1880. Springer, Berlin, Heidelberg, Aug. 2000, pp. 131–146. Differential Fault Attacks on Elliptic Curve Cryptosystems | Springer Nature Link

[2] J.-M. Schmidt and M. Medwed, “A Fault Attack on ECDSA,” in 2009 Workshop on Fault Diagnosis and Tolerance in Cryptography (FDTC), 2009, pp. 93–99. A Fault Attack on ECDSA | IEEE Conference Publication | IEEE Xplore

[3] A. Barenghi, G. M. Bertoni, L. Breveglieri, G. Pelosi, S. Sanfilippo, and R. Susella, “A Fault-Based Secret Key Retrieval Method for ECDSA: Analysis and Countermeasure,” ACM Journal on Emerging Technologies in Computing Systems, vol. 13, no. 1, p. 8:1– 8:26, 2016. A Fault-Based Secret Key Retrieval Method for ECDSA: Analysis and Countermeasure: ACM Journal on Emerging Technologies in Computing Systems: Vol 13, No 1

[4] Cao, H. Shi, H. Chen, W. Wei, and J. Chen, “Lattice-Based Weak Curve Fault Attack on ECDSA,” in ICT Systems Security and Privacy Protection, A. Jøsang, L. Futcher, and Hagen, Eds., Cham: Springer International Publishing, 2021, pp. 146–161. Lattice-Based Weak Curve Fault Attack on ECDSA | Springer Nature Link

[5] “BSI TR-03111 Elliptic Curve Cryptography (ECC),” Technical Guideline, 2018. BSI – Technical Guideline BSI TR-03110

[6] T. Korak and M. Hoefler, “On the Effects of Clock and Power Supply Tampering on Two Microcontroller Platforms,” in 2014 Workshop on Fault Diagnosis and Tolerance in Cryptography, 2014, pp. 8–17. On the Effects of Clock and Power Supply Tampering on Two Microcontroller Platforms | IEEE Conference Publication | IEEE Xplore

[7] J. Balasch, B. Gierlichs, and I. Verbauwhede, “An In-depth and Black-box Character- ization of the Effects of Clock Glitches on 8-bit MCUs,” in 2011 Workshop on Fault Diagnosis and Tolerance in Cryptography, 2011, pp. 105–114. An In-depth and Black-box Characterization of the Effects of Clock Glitches on 8-bit MCUs | IEEE Conference Publication | IEEE Xplore

[8] H. Liao and C. Gebotys, “Methodology for EM Fault Injection: Charge-based Fault Model,” in 2019 Design, Automation & Test in Europe Conference & Exhibition (DATE), Mar. 2019, pp. 256–259. Methodology for EM Fault Injection: Charge-based Fault Model | IEEE Conference Publication | IEEE Xplore

[9] A. Dehbaoui, J.-M. Dutertre, B. Robisson, and A. Tria, “Electromagnetic Transient Faults Injection on a Hardware and a Software Implementations of AES,” in 2012 Workshop on Fault Diagnosis and Tolerance in Cryptography, 2012, pp. 7–15. Electromagnetic Transient Faults Injection on a Hardware and a Software Implementations of AES | IEEE Conference Publication | IEEE Xplore

[10] S. Ordas, L. Guillaume-Sage, K. Tobich, J.-M. Dutertre, and P. Maurine, “Evidence of a Larger EM-Induced Fault Model,” in Smart Card Research and Advanced Applications, Joye and A. Moradi, Eds., Cham: Springer International Publishing, 2015, pp. 245–259.

[11] S. Ordas, L. Guillaume-Sage, and P. Maurine, “Electromagnetic fault injection: the curse of flip-flops,” Journal of Cryptographic Engineering, vol. 7, pp. 183–197, 2016. Electromagnetic fault injection: the curse of flip-flops | Semantic Schola

[12] C. Roscian, A. Sarafianos, J.-M. Dutertre, and A. Tria, “Fault Model Analysis of Laser- Induced Faults in SRAM Memory Cells,” in 2013 Workshop on Fault Diagnosis and Tolerance in Cryptography, 2013, pp. 89–98. Fault Model Analysis of Laser-Induced Faults in SRAM Memory Cells | IEEE Conference Publication | IEEE Xplore

[13] wolfSSL, “Vulnerability Disclosure: wolfSSL Fault Injection Attack on ECC and Ed25519 Verify Operations.” Vulnerability Disclosure: wolfSSL Fault Injection Attack on ECC and Ed25519 Verify Operations – wolfSSL

Author

Kevin Schneider

Kevin Schneider joined Fraunhofer AISEC as a hardware security researcher in 2024 after studying computer science at TU Munich. He is part of the Physical Analysis and Countermeasures group and focuses his research on fault attacks and cryptanalysis.

Contact: kevin.schneider@aisec.fraunhofer.de

Fault Attacks on ECC Signature Verification

Why Signature Verification Is a Prime Fault Target