GHSA-vjpq-xx5g-qvmm BSV Blockchain SDK has an Authentication Signature Data Preparation Vulnerability

• npm @bsv/sdk: < 2.0.0 → fixed in 2.0.0

BRC-104 Authentication Signature Data Preparation Vulnerability Summary A critical cryptographic vulnerability in the TypeScript SDK's BRC-104 authentication implementation caused incorrect signature data preparation, resulting in signature incompatibility between SDK implementations and potential authentication bypass scenarios. Details The vulnerability was located in the `Peer.ts` file of the TypeScript SDK, specifically in the `processInitialRequest` and `processInitialResponse` methods where signature data is prepared for BRC-104 mutual authentication. Vulnerable Code Locations: • `ts-sdk/src/auth/Peer.ts` lines 527-531 (signing) • `ts-sdk/src/auth/Peer.ts` lines 584-590 (verification) Root Cause: The TypeScript SDK incorrectly prepared signature data by: 1. Concatenating base64-encoded nonce strings: `message.initialNonce + sessionNonce` 2. Then decoding the concatenated base64 string: `base64ToBytes(concatenatedString)` This produced ~32-34 bytes of signature data instead of the correct 64 bytes. Buggy Implementation (Before Fix): ```typescript // CRITICAL BUG: Concatenating base64 strings before decoding data: Peer.base64ToBytes(message.initialNonce + sessionNonce) ``` Correct Implementation (After Fix): The fix properly decodes each base64 nonce individually, then concatenates the byte arrays: ```typescript data: [ ...Peer.base64ToBytes(message.initialNonce), ...Peer.base64ToBytes(sessionNonce) ] ``` Why This is Critical: BRC-104 authentication relies on cryptographic signatures to establish mutual trust between peers. When signature data preparation is incorrect: • Signatures generated by the TypeScript SDK don't match those expected by Go/Python SDKs • Cross-implementation authentication fails • An attacker could potentially exploit this to bypass authentication checks PoC The cross-language test suite demonstrates this vulnerability: 1. Setup: Use identical nonces and cryptographic inputs across TypeScript, Python, and Go SDKs 2. Vulnerable behavior: TypeScript SDK produces different signature data than Go/Python reference implementations 3. Impact demonstration: Authentication attempts between TypeScript clients and Go/Python servers fail due to signature mismatch Test Evidence: ```typescript // Buggy approach (produces ~32-34 bytes) const concatenatedB64 = INITIAL_NONCE_B64 + SESSION_NONCE_B64; const buggyResult = Array.from(Buffer.from(concatenatedB64, 'base64')); // Correct approach (produces 64 bytes) const correctResult = [...INITIAL_NONCE_BYTES, ...SESSION_NONCE_BYTES]; ``` Base64 Padding Short Circuit Analysis: The vulnerability occurs because base64 padding characters (`=`) act as early termination signals for base64 decoders. When concatenating base64 strings before decoding: 1. Individual nonces: Each 44-character base64 string decodes to 32 bytes 2. Concatenated string: 88-character string containing padding in the middle 3. Decoding result: Base64 decoder stops at the first `=` padding character, producing only 32 bytes instead of 64 Example with test data: • `INITIAL_NONCE_B64`: `"QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE="` (44 chars → 32 bytes) • `SESSION_NONCE_B64`: `"QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI="` (44 chars → 32 bytes) • Concatenated: `"QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE=QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI="` • Buggy decode: Only 32 bytes (decoder stops at first `=`) • Correct decode: 64 bytes (32 + 32, decoded separately then concatenated) Impact Vulnerability Type: Cryptographic signature verification bypass Severity: Critical (CVSS 9.1 - Critical) Affected Systems: • TypeScript SDK clients attempting to authenticate with Go or Python SDK servers • Any BRC-104 implementation relying on cross-SDK compatibility • Mutual authentication protocols using the affected signature preparation Who is Impacted: • Applications using the TypeScript SDK for BRC-104 authentication • Systems requiring cross-language/SDK authentication compatibility • Any peer-to-peer authentication scenarios where TypeScript clients communicate with non-TypeScript servers Potential Attack Vectors: • Authentication bypass through signature verification failure • Man-in-the-middle attacks if authentication is silently ignored • Denial of service through failed authentication attempts The fix ensures all SDKs now produce identical cryptographic signatures, restoring proper mutual authentication across implementations.