Skip to content

ic_siwb_provider: Insufficient key validation for ECDSA signatures leads to authentication bypass and impersonation

Critical
venkkatesh-sekar published GHSA-xqx6-6wr2-m9pc Apr 16, 2025

Package

cargo ic_siwb_provider (Rust)

Affected versions

< 184c2ed (commit)

Patched versions

184c2ed (commit)

Description

Caution

TL;DR: Identity providers must redeploy their SIWB instances immediately with the latest build of ic_siwb_provider.

Impact

The SIWB repository provides an authentication protocol for signing in to the Internet Computer using Bitcoin wallets. The core canister functionality is implemented in ic_siwb_provider.

For successful authentication, a user must perform the following steps:

  • Call siwb_prepare_login with a Bitcoin wallet address and receive a siwe_message that needs to be signed. The Bitcoin address is the address of the wallet that will perform the signature.
  • Perform the signature and generate a new session key, which will be part of the delegation chain signed by the canister. The ic_siwb_provider offers two signature variants: Bip322Simple and ECDSA. When using an ECDSA signature, you are required to provide an additional ECDSA public key of the wallet.
  • Call siwb_login with (signature, address, public_key, session_key, sign_message_type). If all verification steps are successful, a delegation is created, and a user principal is generated for the user.

Note

This user principal is bound to the given address, meaning the user will always receive the same principal for the same address

  • Call siwb_get_delegation with (address, session_key, expiration) to retrieve the delegation, which can then be used to sign messages for the IC on behalf of the user principal received in the last step.

Note

Delegations are self-contained and remain valid until the specified expiration time.

For successful authentication of an ECDSA signature, the siwb_login must perform the following steps:

  1. Verify that the signature is valid for the corresponding siwe_message.
  2. Recover the public_key from the signature.
  3. Check if the retrieved public_key is the same as the one provided.
  4. Check if the address created from the public key is the one provided.

Caution

The current implementation of SIWB, however, does not perform Step 4, which is a crucial step. Without this verification, an attacker can authenticate to any Bitcoin address of their choice by using a random ECDSA key pair, as the linkability between the address and the public_key is not correctly verified.

Furthermore, since principals are bound to the address, after successful authentication and retrieval of a delegation, the attacker gains access to all the funds in ledgers associated with that particular principal.

ic-siwb/packages/ic_siwb/src/login.rs

Lines 183 to 189 in 246740a

SignMessageType::ECDSA => {
let v = _verify_message(message_string, signature.0.clone(), public_key)
.map_err(|_| LoginError::AddressMismatch)?;
if verify_address(address.to_string().as_str(), v).is_err() {
return Err(LoginError::AddressMismatch);
}

All SIWB deployments made until 246740a4e29747462ae8fa36cf71c36a95992525 are vulnerable to this attack.

Patches

A fix has been merged in 184c2ed874c3c800241711b2d5fae6d9acf2faae. Identity providers must redeploy their SIWB instances immediately with the latest build of ic_siwb_provider.

Caution

The canister must be upgraded with the same salt and uri that was used during the installation of the ic_siwb_provider canister. Upgrading with a new seed will result in the canister generating new principals and the funds related to old principals will be permanently lost.

Workarounds

Unfortunately, there is no workaround for this attack. Since the IC does not offer delegation revocation, any delegations created before the canister upgrade remain valid until their expiration.

References

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

CVE ID

No known CVE

Weaknesses

Improper Authentication

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. Learn more on MITRE.

Improper Verification of Cryptographic Signature

The product does not verify, or incorrectly verifies, the cryptographic signature for data. Learn more on MITRE.