Skip to content

S03:2023 - Cryptographic Failures 🔑🚨

Overview

Cryptographic failures can be catastrophic and may lead to the compromise of data, unauthorized transactions, and the exposure of private keys. Snaps can request private keys without an explicit need to do so, self-manage key material instead of relying on MetaMask account management, and potentially undermine established MetaMask security controls. There can be traditional failures like the use of weak algorithms, untrusted or weak sources of entropy, unenforced security standards on user inputs, signing and encryption-based vulnerabilities. Cryptographic Failures takes position #3 in the Snap Security Top 10.

Description

This section underscores the significance of sound cryptographic techniques, proper key management, and secure implementation to protect sensitive data, transactions, and user assets.

Cryptographic failures encompass a range of vulnerabilities related to the improper use, implementation, or management of cryptographic mechanisms within the Snap. Inadequate cryptographic practices can lead to the compromise of user data, unauthorized transactions, or the exposure of private keys, posing significant risks to the security of the extension. A thorough understanding and careful implementation of cryptographic principles are essential for building a secure and resilient wallet solution.

  • The Snap uses insecure parameters from untrusted sources for cryptographic actions.
  • The Snap uses weak or insecure algorithms.
  • The Snap allows weak sources of entropy or does not enforce secure password policies where applicable.
  • The Snap performs HTTP requests without transport security enabled.
  • The Snap accesses MetaMask's key root for a specific coinID without an explicit need for it.
  • The Snap attempts to manage the MetaMask Ethereum key root, potentially undermining security controls of the wallet.
  • The Snap can be tricked into signing arbitrary data.
  • Lack of replay protection.
  • Insecure signature-based authorization.
  • Hardcoded keys.

How to Prevent

  • Implement secure key management practices, including the generation, storage, and rotation of cryptographic keys.
  • Protect private keys from unauthorized access, encrypt at rest, and use MetaMask's account management where applicable.
  • Access private keys only when absolutely necessary.
  • Employ well-established and widely recognized cryptographic algorithms for encryption, hashing, and digital signatures.
  • Stay informed about any developments regarding the cryptographic algorithms used and update them as needed.
  • Use cryptographically secure random number generators for key generation and other cryptographic operations to ensure unpredictability and resistance to attacks.
  • Enforce secure communication protocols to encrypt data in transit between the extension and external servers.
  • Conduct regular security audits and penetration testing to identify and address potential vulnerabilities in the cryptographic implementation of the extension.

Example Misuse Scenarios

Scenario #1: Private Key Export

The Snap provides means to export the private key, revealing it to the dApp.

Please note that keys are never meant to leave the trust module!

Scenario #2: Undermined Security

A Snap implements generic key handling for many chains. In this scenario, it does so by accessing the low-level coin specific root keys for a chain/network. Besides others, it also requests to access MetaMask's Ethereum root keys.

The problem arises when the Snap does not implement—at minimum—the same security controls MetaMask already has in place. This way, the Snap functionality undermines established security procedures and controls built into MetaMask, increasing the risk of key material to be leaked.

Snaps that request low-level entropy are always at an elevated security risk. Avoid if possible and fall back to safe alternatives like the MetaMask account API.

Scenario #3: Algorithm & Parameters

  • The key utilized for encryption does not meet security best-practices requirements.
  • Initialization Vector used does not meet recommended best practices.
  • The use of weak or deprecated encryption algorithms may expose sensitive user data to unauthorized access or decryption by attackers.

Scenario #4: Entropy Sources

  • Do not allow low-entropy passwords.
  • Checking expiry against a client-provided system time is useless.
  • Server cannot rely on client's randomness.

Scenario #5: BIP44 account discovery

Non-compliance with the BIP44 account discovery algorithm.

Scenario #6: Man-in-the-Middle HTTP

Failure to enforce secure transport layer protocols may expose communication channels (Extension/Browser <-> Service) to man-in-the-middle attacks, enabling attackers to intercept and manipulate sensitive data.

Scenario #7: Hardcoded Keys

Inadequate key management practices may lead to the compromise of cryptographic keys, allowing attackers to impersonate users, decrypt confidential information, or perform unauthorized transactions.