ECDSA signature verification checks
The original paper (Don Johnson, Alfred Menezes, Scott Vanstone. The Elliptic Curve Digital Signature Algorithm (ECDSA), International Journal of Information Security volume 1, 2001, pp.&nbsp;36&ndash;63) is surprisingly quiet about the rationale for all of these.


  
  Check that $Q_a$ is not equal to the identity element $O$, and its coordinates are otherwise valid.
  


If $Q_a=O$, then the step $(x_1,y_1)=u_1\times G+u_2\times Q_a$ turns into $(x_1,y_1)=u_1\times G$ because the identity element multiplied with anything ends up being the identity element &ndash; the same as normal math ($0\cdot a=0$).

Let's start with the verification equation and roll it back with the assumption that $Q_a=O$. As a reminder, the signature is $(r, s)$. The signature is valid if and only if $r \equiv x_1 \pmod{n}$.

$(x_1, \_) = u_1\times G+u_2\times Q_a = u_1 \times G + O= u_1 \times G$, where $u_1 = zs^{-1} \mod{n}$.

An attacker trying to forge a signature for a new message has control over:


$z$ is a trimmed hash of the message. The attacker can compute this.
$(r, s)$ are signature parameters and thus provided by the attacker along with the message.


Because $Q_a$ is gone from the picture, the part that effectively binds the private key into the signature, a valid signature becomes trivial:


Compute $z$.
Pick any $s$ at random in the range $0 &lt; s &lt; n$.
Compute $u_1 = zs^{-1} \mod{n}$.
Compute $(r, y_1) = u_1\times G$.


Because the verifier skips verification that $Q_a \ne O$, this checks out.

(Note that this requires a way for the attacker to supply a public key $Q_a$. In many cases, the public key is pre-shared or otherwise hard-coded so this issue rarely arises in practice. Often, there may not even be a way for an attacker to force $Q_a=O$ if there's no accepted bit representation of $O$ depending on the implementation.)


  
  Check that $Q_a$ lies on the curve.
  Check that $n*Q_a = O$
  


If $Q_a$ is not on the curve or has an order that does not equal the expected $n$ for the curve, it may lie on another curve $E'$, chosen by the attacker; $E'$ would typically be a curve that has a small order and then use the Chinese remainder theorem to discover information about the private key in Diffie&ndash;Hellman settings.

This can be abused in the context of a certificate authority (CA) using ECDSA as a proof of possession of the private key for $Q_a$ when $Q_a$ is not validated (adapted from Adrian Antipa et al. Validation of Elliptic Curve Public Keys, section&nbsp;4.3), though this is all in the context of ECMQV and thus a special case:


Select two values for $s$ and $u_2$ between $1$ and $n-1$ inclusive.
Compute $z$ and $u_1$ for ECDSA as normal; the message for $z$ may be chosen by the CA.
Compute $T_1=u_1\times G$ on curve $E$.
Compute $T_2=u_2\times Q_a$ on curve $E'$.
Compute $V=T_1+T_2$ using point addition as if both points were on curve $E$; the result will be on neither curve.
Set $r$ to the x-coordinate of $V$.
Compute $u_2'=rs^{-1}\mod{l}$, where $l$ is the order of a point with small, prime order on $E'$ that contains $Q_a$.
Repeat this procedure unless $u_2\equiv u_2'$
Output the signature $(r,s)$.



  
  Verify that $r$ and $s$ are integers in $[\![1;n-1]\!]$. If not, the signature is invalid.
  


The original paper by Johnson et al. notes on p.&nbsp;48 that (a) this mitigates attacks related to ElGamal signatures without such checks, and (b) the check that $r&gt;0$ in particular avoids an issue specifically relating to a base point $G=(0,\sqrt{b})$ (with $b$ from the short Weierstrass curve parameter for $E$: $y^2=x^3+ax+b$), though I am unaware of any elliptic curve standard specifying a base point with an x-coordinate of zero.

This also helps prevent malleability so that given an existing $(r, s)$ and existing message $m$, no new signature for the same $m$ can be made without possession of the private key. The group generated by the generator $G$ is a cyclic group of order $n$, which means that the cycle repeats after $n$ additions of $G$ to itself: $n\times G=O$, $(n+1)\times G=G$, &hellip;, therefore for every $(r, s)$, the tuple $(r + cn, r + cn)$ is also a valid signature for the same message for every integer $c&gt;1$. Note that $(r, -s\mod{n})$ is already another valid signature that may need to be guarded against as well.