threat-modeling.md

Threat Model Analysis for jedisct1/libsodium

Threat: Nonce Reuse in Symmetric Encryption (e.g., crypto_secretbox)

• Threat: Nonce Reuse in Symmetric Encryption (e.g., crypto_secretbox)

  • Description: An attacker observes multiple ciphertexts encrypted with the same key and nonce. Because the nonce is not unique, the attacker can perform cryptanalysis to recover the plaintext or forge messages. The attacker might passively monitor network traffic or have access to stored encrypted data.
  • Impact: Loss of confidentiality and integrity of encrypted data. The attacker can decrypt messages and potentially create valid-looking forged messages.
  • Affected Libsodium Component: crypto_secretbox, crypto_stream, and any functions requiring a nonce.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Use a unique nonce for every encryption operation with the same key.
    • Use randombytes_buf() to generate nonces.
    • If using a counter-based nonce, ensure it never repeats (e.g., by using a sufficiently large nonce space and persistent storage to track the counter).
    • Code review to ensure nonce generation and usage are correct.
    • Static analysis to detect potential nonce reuse.

Threat: Key Exposure due to Incorrect Memory Management

• Threat: Key Exposure due to Incorrect Memory Management

  • Description: An attacker gains access to the application's memory (e.g., through a separate vulnerability, a core dump, or a compromised debugging tool). If cryptographic keys are not properly handled using libsodium's memory management functions, they might be exposed in memory. The attacker could use a memory scanner or debugger.
  • Impact: Complete compromise of cryptographic keys, leading to loss of confidentiality and integrity of all data protected by those keys.
  • Affected Libsodium Component: All components that handle secret keys (e.g., crypto_secretbox, crypto_box, crypto_sign, crypto_auth).
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Use sodium_malloc() and sodium_free() for allocating and freeing memory that holds sensitive data.
    • Use sodium_memzero() to securely erase sensitive data from memory immediately after it's no longer needed.
    • Avoid storing keys in plain text in configuration files or environment variables.
    • Use a secure key management system (e.g., a key vault or HSM).
    • Minimize the lifetime of keys in memory.

Threat: Use of Deprecated or Weak Functions

• Threat: Use of Deprecated or Weak Functions

  • Description: Developers use functions that are marked as deprecated or known to be weaker than alternatives (e.g., using an older, less secure hash function). An attacker could exploit known weaknesses in these functions.
  • Impact: Reduced security; the specific impact depends on the function misused. It could range from weakened authentication to complete key compromise.
  • Affected Libsodium Component: Any deprecated or superseded function (check the libsodium documentation for the latest recommendations).
  • Risk Severity: High (depending on the specific function)
  • Mitigation Strategies:
    • Regularly review the libsodium documentation to identify deprecated functions.
    • Use static analysis tools to detect the use of deprecated functions.
    • Code reviews to ensure developers are using the recommended functions.
    • Compiler warnings should be treated as errors.

Threat: Failure to Verify Authenticated Encryption Tags

• Threat: Failure to Verify Authenticated Encryption Tags

  • Description: When using authenticated encryption (e.g., crypto_secretbox), developers fail to properly verify the authentication tag during decryption. An attacker could modify the ciphertext, and the application would not detect the tampering.
  • Impact: Loss of data integrity. The attacker can modify encrypted data without detection.
  • Affected Libsodium Component: crypto_secretbox, crypto_aead_*, and any functions that use authenticated encryption.
  • Risk Severity: High
  • Mitigation Strategies:
    • Always check the return value of decryption functions (e.g., crypto_secretbox_open, crypto_aead_*_decrypt). A non-zero return value indicates that the tag is invalid.
    • Code reviews to ensure proper tag verification.
    • Unit tests that specifically test for invalid tags.

Threat: Supply Chain Attack - Compromised Libsodium Binary

• Threat: Supply Chain Attack - Compromised Libsodium Binary

  • Description: An attacker compromises the libsodium build process or distribution channel, inserting malicious code into the library. The application then uses this compromised library.
  • Impact: Complete compromise of the application's security. The attacker could have full control over the cryptographic operations.
  • Affected Libsodium Component: All components.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Verify digital signatures of downloaded libsodium releases.
    • Use trusted package managers and official repositories.
    • Consider reproducible builds.

Threat: Using a too short key.

• Threat: Using a too short key.

  • Description: The developer chooses a key length that is too short for the chosen algorithm, making it vulnerable to brute-force attacks.
  • Impact: Loss of confidentiality. An attacker can decrypt the data.
  • Affected Libsodium Component: All components that use keys.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Use the recommended key sizes as specified in the libsodium documentation for each function.
    • Code reviews to ensure correct key sizes are used.