Skip to content

Latest commit

 

History

History
154 lines (117 loc) · 12.4 KB

mitigations.md

File metadata and controls

154 lines (117 loc) · 12.4 KB

Mitigation Strategies Analysis for weidai11/cryptopp

Mitigation Strategy: Enforce Approved Algorithm and Mode Selection (Crypto++ Specific)

Description:

  1. Create an Approved List (Crypto++ Specific): The approved list must specify the exact Crypto++ classes and parameters to be used for each approved configuration. For example:
    • Approved: CryptoPP::AES::Encryption with CryptoPP::GCM<CryptoPP::AES>::Encryption, key size 256 bits, randomly generated IV using CryptoPP::AutoSeededRandomPool.
    • Forbidden: CryptoPP::DES_EDE2::Encryption, CryptoPP::ECB_Mode_ExternalCipher.
  2. Mandatory Code Review (Crypto++ Focus): The security reviewer verifies that the code uses only the approved Crypto++ classes and parameters, with no deviations. This includes checking for correct instantiation, correct use of member functions, and correct handling of return values.
  3. Wrapper Functions/Classes (Crypto++ Encapsulation): The wrapper functions/classes completely encapsulate the Crypto++ implementation. Developers should never directly access Crypto++ objects or functions outside of these wrappers. The wrappers handle all Crypto++-specific details (e.g., object lifetime, memory management, exception handling).
  4. Regular List Updates (Crypto++ Versions): The approved list is updated not only for new cryptographic recommendations but also to reflect any changes in the Crypto++ API across different versions. This ensures compatibility and avoids using deprecated features.

Threats Mitigated:

  • Use of Weak Crypto++ Algorithms/Modes: (Severity: Critical) - Prevents direct use of weak or inappropriate Crypto++ classes.
  • Incorrect Crypto++ API Usage (Algorithm/Mode): (Severity: Critical) - Ensures correct instantiation and parameterization of Crypto++ cryptographic objects.
  • Crypto++ Version Incompatibilities: (Severity: Medium) - Avoids using deprecated or changed features in newer Crypto++ versions.

Impact:

  • Use of Weak Crypto++ Algorithms/Modes: Risk reduced to near zero (within the wrappers).
  • Incorrect Crypto++ API Usage (Algorithm/Mode): Risk significantly reduced (within the wrappers).
  • Crypto++ Version Incompatibilities: Risk significantly reduced.

Currently Implemented:

  • Approved list exists in docs/security/crypto_approved_list.md and includes specific Crypto++ class names.
  • Wrapper functions for symmetric encryption (utils/crypto_wrappers.cpp) encapsulate Crypto++ usage.

Missing Implementation:

  • Wrapper functions for asymmetric encryption and digital signatures are missing; direct Crypto++ API calls are present in src/signature_module.cpp.
  • The approved list needs explicit version compatibility notes for Crypto++.

Mitigation Strategy: Secure Key Generation (using Crypto++)

Description:

  1. Mandatory AutoSeededRandomPool: All cryptographic keys must be generated using CryptoPP::AutoSeededRandomPool. No other random number generators are permitted for key generation. This is enforced through code reviews.
  2. Key Size Validation: The code that generates keys must validate the key size against the approved list and the requirements of the chosen algorithm (using Crypto++ constants where available, e.g., CryptoPP::AES::DEFAULT_KEYLENGTH).
  3. Key Derivation with Crypto++ KDFs: When deriving keys, use only approved Crypto++ KDF implementations (e.g., CryptoPP::PKCS5_PBKDF2_HMAC, CryptoPP::Scrypt, CryptoPP::Argon2_Factory). The parameters (iterations, memory cost, salt) are configured according to the approved list and validated during code review. The salt must be generated using CryptoPP::AutoSeededRandomPool.

Threats Mitigated:

  • Weak Key Generation (Crypto++): (Severity: High) - Ensures that keys are generated with sufficient entropy using Crypto++'s recommended PRNG.
  • Incorrect Key Size (Crypto++): (Severity: High) - Prevents using key sizes that are too small for the chosen Crypto++ algorithm.
  • Weak Key Derivation (Crypto++): (Severity: High) - Ensures the use of strong, approved Crypto++ KDFs with appropriate parameters.

Impact:

  • Weak Key Generation (Crypto++): Risk reduced to near zero.
  • Incorrect Key Size (Crypto++): Risk reduced to near zero.
  • Weak Key Derivation (Crypto++): Risk significantly reduced.

Currently Implemented:

  • CryptoPP::AutoSeededRandomPool is used for key generation in utils/key_generation.cpp.
  • Argon2id (using CryptoPP::Argon2_Factory) is used for key derivation in utils/key_derivation.cpp.

Missing Implementation:

  • Explicit key size validation against the approved list is not consistently implemented.

Mitigation Strategy: Secure Key Deletion (using Crypto++)

Description:

  1. Mandatory SecureWipeArray: Whenever a key (or any sensitive data) held in memory is no longer needed, it must be securely erased using CryptoPP::SecureWipeArray. This applies to CryptoPP::SecByteBlock instances and any other buffers containing key material.
  2. RAII with SecByteBlock: Encourage the consistent use of CryptoPP::SecByteBlock for storing keys and other sensitive data. SecByteBlock automatically calls SecureWipeArray in its destructor, ensuring secure deletion when the object goes out of scope.

Threats Mitigated:

  • Key Exposure in Memory (Crypto++): (Severity: High) - Reduces the risk of keys remaining in memory after they are no longer needed, making them vulnerable to memory dumps or other attacks.

Impact:

  • Key Exposure in Memory (Crypto++): Risk significantly reduced.

Currently Implemented:

  • CryptoPP::SecureWipeArray is used in utils/key_derivation.cpp and utils/crypto_wrappers.cpp.
  • CryptoPP::SecByteBlock is used consistently for sensitive data.

Missing Implementation:

  • Review all code interacting with Crypto++ to ensure consistent use of SecureWipeArray and SecByteBlock.

Mitigation Strategy: Integer Overflow/Underflow Prevention (Crypto++ Interaction)

Description:

  1. Input Validation (Crypto++ Specific): Before passing any size or length value to a Crypto++ function (e.g., buffer sizes, key sizes, IV sizes), rigorously validate the value. This includes checking for:
    • Negative values where they are not allowed by the Crypto++ API.
    • Values exceeding the maximum limits allowed by the specific Crypto++ class or function (consult the Crypto++ documentation).
    • Values that could lead to integer overflows/underflows in internal Crypto++ calculations (this is harder to assess and may require careful analysis of the Crypto++ source code).
  2. Fuzz Testing (Crypto++ Focus): The custom fuzzer must specifically target Crypto++ functions with a wide range of input sizes, including:
    • Very small values (near zero).
    • Very large values (near the maximum limits of the data types).
    • Values that are likely to cause overflows/underflows (e.g., MAX_INT - 1, MAX_INT, MAX_INT + 1).
    • Values that are specifically designed to test the boundary conditions of the Crypto++ API.

Threats Mitigated:

  • Integer Overflows/Underflows in Crypto++: (Severity: High) - Prevents vulnerabilities caused by integer overflows/underflows within Crypto++ itself or triggered by incorrect input to Crypto++ functions.

Impact:

  • Integer Overflows/Underflows in Crypto++: Risk significantly reduced (effectiveness depends heavily on the thoroughness of fuzz testing).

Currently Implemented:

  • Basic input validation is present in some areas, but not consistently applied to all Crypto++ interactions.

Missing Implementation:

  • Fuzz testing specifically targeting Crypto++ is not yet implemented.
  • Comprehensive input validation for all Crypto++ function calls is needed.

Mitigation Strategy: Memory Management Error Prevention (Crypto++ Objects)

Description:

  1. RAII with SecByteBlock (Mandatory): CryptoPP::SecByteBlock must be used for all dynamically allocated memory that will hold sensitive data (keys, plaintexts, ciphertexts) that are processed by Crypto++.
  2. Smart Pointers (for Crypto++ Objects): If Crypto++ objects themselves need to be dynamically allocated (which should be minimized), use std::unique_ptr or std::shared_ptr to manage their lifetime. Avoid raw pointers to Crypto++ objects.
  3. Memory Sanitizers (Crypto++ Testing): Run all tests that involve Crypto++ with AddressSanitizer (ASan) and MemorySanitizer (MSan) enabled. This includes unit tests and integration tests.

Threats Mitigated:

  • Buffer Overflows (Crypto++): (Severity: Critical) - Prevents buffer overflows within Crypto++ or caused by incorrect memory management when interacting with Crypto++.
  • Use-After-Free (Crypto++): (Severity: Critical) - Prevents use-after-free errors related to Crypto++ objects and buffers.
  • Double-Frees (Crypto++): (Severity: Critical) - Prevents double-free errors related to Crypto++ objects and buffers.

Impact:

  • Buffer Overflows (Crypto++): Risk significantly reduced.
  • Use-After-Free (Crypto++): Risk significantly reduced.
  • Double-Frees (Crypto++): Risk significantly reduced.

Currently Implemented:

  • CryptoPP::SecByteBlock is used consistently for sensitive data.
  • ASan is run as part of the CI/CD pipeline.

Missing Implementation:

  • MSan is not currently used.
  • Consistent use of smart pointers for dynamically allocated Crypto++ objects (not just data) needs review.

Mitigation Strategy: Crypto++ API Misuse Prevention (Detailed)

Description:

  1. API Documentation Review (Mandatory): Before using any Crypto++ API, developers must provide evidence (e.g., in code comments or commit messages) that they have read and understood the relevant sections of the Crypto++ documentation, including security considerations.
  2. Unit Testing (Crypto++ Specific): Unit tests must specifically target the correct usage of Crypto++ APIs. This includes:
    • IV Uniqueness: Tests that verify that a new, unique IV is generated for each encryption operation when required by the Crypto++ mode (e.g., CBC). This often involves mocking the random number generator.
    • Authentication Tag Verification: Tests that explicitly verify that the authentication tag is checked before decrypting or processing any data when using Crypto++ authenticated encryption modes (e.g., GCM, CCM). This includes testing with valid and invalid tags.
    • Padding Handling: Tests that verify correct padding and unpadding when using Crypto++ modes that require padding (e.g., CBC with PKCS#7). This includes testing with various input sizes and edge cases.
    • Error Handling: Tests that verify the correct handling of Crypto++ exceptions and error codes (e.g., CryptoPP::InvalidCiphertext, CryptoPP::InvalidKeyLength).
    • Parameter Validation: Tests that verify that the code correctly handles invalid input parameters to Crypto++ functions (e.g., invalid key sizes, invalid IV sizes).
  3. Code Review (Crypto++ Checklist): Code reviews must include a specific checklist for Crypto++ API usage, covering the points listed above (IV handling, authentication, padding, error handling, parameter validation).

Threats Mitigated:

  • Incorrect Crypto++ IV Handling: (Severity: Critical)
  • Missing Crypto++ Authentication Verification: (Severity: Critical)
  • Incorrect Crypto++ Padding Handling: (Severity: High)
  • General Crypto++ API Misuse: (Severity: Variable)
  • Crypto++ Exception Handling Errors: (Severity: Medium to High)

Impact:

  • All listed threats: Risk significantly reduced (effectiveness depends on the thoroughness of unit tests and code reviews).

Currently Implemented:

  • Some unit tests exist, but they are not comprehensive.

Missing Implementation:

  • Comprehensive unit tests covering all aspects of Crypto++ API usage are needed.
  • A formal Crypto++ API usage checklist for code reviews is needed.
  • Mandatory documentation review is not enforced.