Full Report
The original implementation of Elliptic Curve Digital Signatures Algorithm (ECDSA) worked the same as DSA besides it used EC math. It has a known bad flaw: if you use reuse the nonce, then it's trivial to recover the private key with only two different messages. This has been the root cause for many hacks, such as the Playstation 3s key leak from Geohot. To prevent the duplicate usage of nonces on different data, deterministic signatures were created. The nonce, k, is deterministic based upon the private key and message used. For instance, hash(key||message) would always be the same for every message. Since the attack described above requires two separate messages, this removes the attack vector entirely. Or, so we thought. Since a bug in ellipitic.js was announced, this is being rethought. If two different messages can create the same nonce value then we have the same issue as before. In RFC6979 the JavaScript implementation converted a Uint8Array to a bigint. This had a bug that doesn't properly add leading zeros to a hex value. So, the arrays [1, 1, 30] and [17, 30] led to the same nonces being used. If an attacker could trick the system to sign these two pieces of data, they could recover the key as a result. So, if both are bad then how about we combine them? This is the concept behind hedged signatures. If there is BOTH a deterministic portion and a random portion, then BOTH would need to be done incorrectly for this to fail. There are some downsides, mentioned in the post, but it's interesting none-the-less.
Analysis Summary
# Vulnerability: Nonce Reuse due to Flawed Deterministic Signature Calculation in JavaScript Implementation
## CVE Details
- CVE ID: Not explicitly provided in the text for the `elliptic.js` bug, but it relates to the context of deterministic signature flaws.
- CVSS Score: Not explicitly provided in the text. (The severity is implied to be Critical due to private key exposure.)
- CWE: CWE-327 (Use of a Broken or Risky Cryptographic Algorithm - in context of flawed deterministic nonce generation), or CWE-321 (Use of Hardcoded Cryptographic Key - if a predictable outcome is essentially hardcoded).
## Affected Systems
- Products: JavaScript implementations using ECDSA with deterministic signing based on RFC 6979, specifically mentioning a bug in the `elliptic.js` library.
- Versions: Vulnerable versions of `elliptic.js` prior to the fix for the nonce generation issue described.
- Configurations: ECDSA implementations where the nonce generation (k) adheres to RFC 6979 but fails to correctly convert byte arrays to big integers, specifically due to improper handling of leading zeros.
## Vulnerability Description
The vulnerability stems from a fault injection class of attack against deterministic ECDSA signatures (as specified in RFC 6979). Deterministic signatures calculate the nonce ($k$) deterministically based on the private key ($d$) and the message ($m$) using a combination function (e.g., HMAC-DRBG): $k = \text{combine}(d, m)$.
The specific flaw occurred in a JavaScript implementation (noted in `elliptic.js`) where the conversion of the resulting byte array from the combination function into a BigInt for the nonce calculation failed to account for leading zeros. This resulted in different inputs (byte arrays representing different messages) mapping to the exact same nonce value ($k_{1} = k_{2}$). If an attacker can generate two distinct signed messages that result in the same deterministic nonce due to this conversion bug (e.g., `Uint8Array([1, 1, 30])` and `Uint8Array([17, 30])` leading to the same internal representation), the attack reverts to the classic reused nonce attack, allowing the private key to be trivially recovered from the two resulting signatures ($r, s_1$ and $r, s_2$).
## Exploitation
- Status: Not explicitly stated as exploited in the wild using *this specific* JS bug, but the mechanism relies on known key extraction techniques enabled by nonce reuse. Described as demonstrable via PoC against vulnerable systems.
- Complexity: Low, assuming an attacker can trick the system into signing two specific pieces of data crafted to collide under the faulty conversion logic.
- Attack Vector: Requires interaction with the signing process, likely via network or application interaction to submit the colliding message data.
## Impact
- Confidentiality: **High**. Private key can be fully recovered.
- Integrity: **High**. An attacker who recovers the private key can forge valid signatures for any arbitrary message.
- Availability: **Low**. Direct impact is on confidentiality/integrity; availability is unaffected unless key compromise leads to service disruption.
## Remediation
### Patches
- A patch for the specific `elliptic.js` vulnerability (GHSA-vjh7-7g9h-fjfh) should be applied, ensuring correct conversion of byte arrays to big integers, preserving leading zeros as required by cryptographic standards.
- The article promotes the use of **hedged signatures** (combining deterministic and random components) in newer libraries like `noble-curves` as a defense against *any* flaw in the deterministic nonce generation process.
### Workarounds
1. **Use Hedged Signatures:** Implementations using hedged signatures, where both the deterministic part and a random part must fail for the nonce to collide, significantly reduce the risk of private key exposure from silent implementation bugs. (Example libraries mentioned: `noble-curves`, `micro-eth-signer`, `btc-signer`).
2. **Ensure Strong CSPRNG Fallback:** While pure deterministic signing aims to eliminate randomness reliance, verifying the implementation correctly falls back or integrates cryptographically secure randomness if the deterministic calculation fails or is bypassed can reduce the overall risk profile associated with nonces.
## Detection
- Detection relies primarily on auditing signing services for known vulnerable library versions and configurations.
- **Indicator of Compromise (IoC):** Repeated signature generation using the *exact same* nonce ($k$) for different messages (though difficult to observe externally unless monitoring nonce calculation internally).
## References
- Advisory Link (Defanged): hxxps://github.com/indutny/elliptic/security/advisories/GHSA-vjh7-7g9h-fjfh
- Relevant Discussion: hxxps://paulmillr.com/posts/deterministic-signatures/