Skip to content

Latest commit

 

History

History
104 lines (87 loc) · 10.5 KB

threat-modeling.md

File metadata and controls

104 lines (87 loc) · 10.5 KB

Threat Model Analysis for google/tink

Threat: Key Material Exfiltration from Memory

  • 1. Threat: Key Material Exfiltration from Memory
    • Description: An attacker exploits a vulnerability in the application or operating system (e.g., a buffer overflow, memory leak) to read the raw key material from the application's memory. This could happen while the key is in use or if the key is not properly zeroed out after use. While this isn't solely a Tink issue, Tink handles the key material, making its proper handling crucial.
    • Impact: The attacker obtains the raw cryptographic key, allowing them to decrypt data, forge signatures, or perform other malicious actions.
    • Affected Tink Component: Any component that handles KeysetHandle or raw key material in memory. This is less about a specific Tink function and more about how the application uses Tink's outputs, but Tink is the component providing and managing the key material.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Minimize the time keys are held in memory in plaintext form.
      • Use a language and environment that provides memory safety guarantees (e.g., Rust, Java with appropriate security settings) where possible.
      • Ensure that sensitive memory is securely wiped (zeroed out) after use. This is often not automatic and requires explicit code. This is crucial when working with Tink's key material.
      • Use a KMS to avoid handling raw key material directly in the application whenever possible. This is the best mitigation.
      • Employ operating system-level protections (e.g., ASLR, DEP) to make memory exploitation more difficult.

Threat: Key Confusion Attack

  • 2. Threat: Key Confusion Attack
    • Description: An attacker tricks the application into using the wrong key for an operation. For example, they might manipulate the key ID or version information to cause the application to use an old, revoked key or a key intended for a different purpose (e.g., using an encryption key for signing). This directly involves how the application interacts with Tink's key management.
    • Impact: Data corruption, decryption failures, successful forgery of signatures, or other unintended consequences depending on the specific misuse.
    • Affected Tink Component: KeysetHandle, specifically the logic that selects the correct key based on ID and version. The application's key management logic, interacting directly with Tink, is the primary area of concern.
    • Risk Severity: High
    • Mitigation Strategies:
      • Implement strict validation of key IDs and versions before using a key. This validation must be done before passing the key to Tink.
      • Use a well-defined and consistent key naming and versioning scheme.
      • Implement robust error handling to detect and prevent the use of incorrect keys.
      • Regularly audit the key management code to ensure it correctly handles key selection and rotation, particularly its interaction with Tink's APIs.
      • Consider using a KMS to manage key versions and enforce policies, reducing the application's direct interaction with KeysetHandle.

Threat: Key Revocation Failure

  • 3. Threat: Key Revocation Failure
    • Description: After a key is compromised, the application fails to effectively revoke it. This could be due to a failure in the revocation mechanism itself, or because the application continues to use the revoked key despite the revocation attempt. This directly involves the application's interaction with Tink and a KMS.
    • Impact: The attacker continues to use the compromised key to decrypt data or forge signatures, even after the compromise is detected.
    • Affected Tink Component: The application's key revocation logic, which likely interacts with a KMS and uses KeysetHandle to manage keys. The interaction between the application, Tink, and the KMS is critical.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Implement a robust key revocation mechanism that integrates with a KMS.
      • Ensure the application checks the revocation status of keys before using them with Tink.
      • Implement a "fail-safe" mechanism to prevent the use of revoked keys, even if the revocation check fails.
      • Regularly test the key revocation process to ensure it works as expected, including the interaction with Tink.

Threat: Chosen-Ciphertext Attack (CCA) on Non-CCA Secure AEAD (Hypothetical Misuse)

  • 4. Threat: Chosen-Ciphertext Attack (CCA) on Non-CCA Secure AEAD (Hypothetical Misuse)
    • Description: An attacker sends a series of carefully crafted ciphertexts to the application, observing the decryption results. If the application misuses Tink to create a non-CCA-secure AEAD mode (which Tink does not provide by default), the attacker might be able to recover the plaintext. This is a hypothetical misuse, but it's included because it highlights the danger of deviating from Tink's recommended usage.
    • Impact: The attacker recovers the plaintext of encrypted data.
    • Affected Tink Component: Misuse of Aead interface, specifically if a developer were to try to implement a non-CCA secure mode using Tink's lower-level primitives. This is highly unlikely with proper Tink usage, but represents a direct misuse of Tink.
    • Risk Severity: High (if a non-CCA secure mode is somehow implemented)
    • Mitigation Strategies:
      • Always use Tink's recommended AEAD key templates (e.g., AesGcmKeyManager.aes128GcmTemplate(), AesCtrHmacAeadKeyManager.aes128CtrHmacSha256Template()). These are CCA-secure.
      • Do not attempt to implement custom AEAD modes using Tink's lower-level primitives unless you are a cryptography expert. This is the most important mitigation.
      • Implement robust error handling that does not reveal information about decryption failures to the attacker.

Threat: Tag Truncation Attack on MAC

  • 5. Threat: Tag Truncation Attack on MAC
    • Description: An attacker intercepts a message and its MAC tag, generated by Tink, truncating the tag. If the application's verification logic (which uses Tink) doesn't properly check the tag length, forgery is possible.
    • Impact: The attacker successfully forges a MAC for a modified message, bypassing integrity checks.
    • Affected Tink Component: Mac interface. The application's verification logic, using Tink's Mac.verifyMac() function, is the key area.
    • Risk Severity: High
    • Mitigation Strategies: * Use Tink's recommended MAC key templates with their default tag lengths. * Ensure the application, when calling Mac.verifyMac(), verifies the full length of the MAC tag. The comparison must be length-aware. * Do not allow the application to accept truncated MAC tags.

Threat: Associated Data (AD) Mismatch in AEAD

  • 6. Threat: Associated Data (AD) Mismatch in AEAD
    • Description: An attacker modifies the associated data (AD) of an AEAD-encrypted message (encrypted using Tink) without modifying the ciphertext. If the application, when decrypting with Tink, doesn't use the correct AD, the context is changed.
    • Impact: The application decrypts the message successfully but interprets it in the wrong context, leading to incorrect behavior.
    • Affected Tink Component: Aead interface. The application's use of the decrypt method with the correct AD, passed to Tink, is crucial.
    • Risk Severity: High
    • Mitigation Strategies:
      • Ensure that the exact same associated data is used during encryption (with Tink) and decryption (with Tink).
      • Implement robust error handling to detect and reject messages with mismatched AD. This error handling should wrap calls to Tink's decrypt function.
      • Carefully design the associated data to include all relevant context information.

Threat: Exploitation of Outdated Tink Library

  • 7. Threat: Exploitation of Outdated Tink Library
    • Description: An attacker exploits a known vulnerability in an outdated version of the Tink library that the application is using. This is a direct threat to Tink itself.
    • Impact: The attacker gains control of the application, compromises cryptographic keys, or performs other malicious actions, depending on the specific vulnerability.
    • Affected Tink Component: Any component, depending on the vulnerability.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Regularly update Tink and its dependencies to the latest stable versions. This is the primary mitigation.
      • Use a dependency management system to track and manage dependencies.
      • Monitor security advisories for Tink and its dependencies.
      • Implement a vulnerability scanning process to identify outdated libraries.

Threat: Insufficient Entropy for Random Number Generation

  • 8. Threat: Insufficient Entropy for Random Number Generation
    • Description: If the underlying system's random number generator (RNG) has insufficient entropy, the cryptographic keys generated by Tink might be predictable. While this is a system issue, Tink relies on the system RNG, making it a direct concern for Tink's security.
    • Impact: The attacker can predict the generated keys, compromising the security of the entire system.
    • Affected Tink Component: Any component that generates keys or uses random values (e.g., KeysetHandle.generateNew(), Aead, Mac, Signature). Tink's key generation functions are directly affected.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Ensure the operating system has access to a high-quality source of entropy (e.g., hardware RNG, sufficient entropy pool).
      • Monitor the system's entropy levels.
      • Use a well-vetted cryptographic library (like Tink) that relies on the system's secure RNG. This highlights the importance of trusting the underlying system when using Tink.