What is the ChainOfFools/CurveBall Attack on ECDSA on Windows 10 CryptoAPI (Crypt32.dll)

Could someone provide details?

  • $\begingroup$ Our site did not have any information about this. I wrote one so someone could find it helpful. $\endgroup$ – kelalaka Aug 9 at 20:24

ChainOfFools (or Microsoft's Chain of Fools) or CurveBall is a vulnerability in Microsoft's X.509 certificate verification affecting certificate chains that use ECDSA at any point, discovery by NSA!1.

From Microsoft site for CVE-2020-0601

An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. The user would have no way of knowing the file was malicious because the digital signature would appear to be from a trusted provider.

From the CERT site

Any software, including third-party non-Microsoft software, that relies on the Windows CertGetCertificateChain() function to determine if an X.509 certificate can be traced to a trusted root CA may incorrectly determine the trustworthiness of a certificate chain.

Therefore, an attacker can create a valid certificate chain so that a malicious code can be trusted.


TLS often uses ECDSA to authenticate servers and clients. Windows code distribution often uses ECDSA for code-signing. The vulnerability affects certificate checking if ECDSA has been used at any point in the chain (code signed with ECDSA, or website authenticated with ECDSA, or a CA authenticated with ECDSA by a root CA, etc.).

Given an ECDSA signature, one can easily create a new private key that has the same public key matches if domain parameters are controllable.

The trick is simple, let begin with defining a curve over a finite field $\mathbb{F}_p$;

$$E:y^2 = x^3 + ax + b$$

Standards defines the parameters, $(p,a,b,G,n,h)$, where $G$ is the base point, $n$ is the order of $G$ and $h$ is the cofactor. See for example secp256k1.

Since we agree on the standard we all use the same parameters. Then one selects a private $k \in [1..n-1]$ and calculates the public key by scalar multiplication $[k]G$. So, your private key is a number, but, the public key is a point on the curve and protected by the EC discrete log.

The attack point:

What if the programmers/designers of a library forget to check the base point?

Now the attacker can create a new private key that has the same public key with a different base point as follows;

Let the target public key be $P$ with $P=[k]G$ of the private key $k$. Then the attacker chooses random key $k'$ and calculates their malicious base point $G'$ with

$$G' = [1/k']P$$ the $1/k=k^{-1}$ is computable since the inverse exists in the finite field $\mathbb{F}_p$ and can be computed by the extendedGCD.

Now, in the new curve where all parameters are the same as the previous except the base point, the public key is the same as the target key, but the private key is not.

Since we assumed that the library is not checking the base point, the attackers can exploit this vulnerability and spoof the Windows certificate chain and the website or signed code will appear as a legitimate source.

1 Or, they don't need anymore!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.