attack-surface.md

Attack Surface Analysis for google/tink

Attack Surface: Nonce Reuse (with Deterministic AEAD)

• Description: Reusing the same nonce (Number Used Once) with a deterministic Authenticated Encryption with Associated Data (AEAD) scheme, like AES-GCM, completely breaks the confidentiality guarantees of the encryption.
• How Tink Contributes: Tink provides AEAD primitives, including AES-GCM. While Tink offers functions for generating random nonces, it's the application's responsibility to ensure nonces are never reused. Tink's provision of the vulnerable primitive, without inherently preventing misuse, is the direct contribution.
• Example: An application uses AES-GCM to encrypt messages. Due to a bug in the nonce generation logic (or incorrect use of Tink's API), the same nonce is used for multiple encryption operations. An attacker who observes multiple ciphertexts with the same nonce can recover the plaintext.
• Impact: Complete loss of confidentiality; attacker can decrypt all messages encrypted with the reused nonce.
• Risk Severity: Critical
• Mitigation Strategies:
  • Use Tink's Random Nonce Generation: Always use Tink's built-in functions for generating random nonces (e.g., NonceBasedCrypter). Do not implement custom nonce generation unless absolutely necessary and with extreme caution.
  • Secure Counter Management (if applicable, but discouraged): If using a counter-based nonce (generally not recommended with Tink), ensure the counter is stored securely, incremented correctly, and never wraps around or resets unexpectedly. This is significantly more error-prone than using random nonces.
  • Nonce-Misuse Resistant AEAD: Consider using a nonce-misuse resistant AEAD scheme like AES-GCM-SIV. These schemes are more tolerant of nonce reuse, although unique nonces are still best practice. This leverages a different Tink primitive to mitigate the risk.
  • Testing: Implement specific unit tests to verify that nonce generation is working correctly and that nonces are not being reused. This should include tests that deliberately attempt to reuse nonces to ensure the application handles them correctly.

Attack Surface: Associated Data (AD) Misuse (with AEAD)

• Description: Failing to provide the correct Associated Data (AD) during decryption, or using inconsistent AD across encryption and decryption, compromises the authentication aspect of AEAD. This can allow an attacker to tamper with the ciphertext without detection. This is a direct misuse of the Tink API.
• How Tink Contributes: Tink's AEAD primitives require AD. The security guarantees of AEAD depend on the correct and consistent use of AD, as enforced by the Tink API. The requirement for AD, and the potential for its misuse, is Tink's direct contribution.
• Example: An application encrypts data with AD representing the user ID. During decryption, a bug causes the application to omit the AD or use a different user ID when calling Tink's decryption function. An attacker could potentially modify the ciphertext without being detected.
• Impact: Loss of data integrity; attacker can modify encrypted data without detection; potential for authentication bypass.
• Risk Severity: High
• Mitigation Strategies:
  • Consistent AD: Ensure that the exact same AD is used during both encryption and decryption calls to Tink's API.
  • Contextual AD: Use AD that is meaningful and relevant to the context of the data being encrypted. This makes it harder for an attacker to substitute valid ciphertexts.
  • Documentation: Clearly document the AD requirements for each encryption operation, and ensure developers understand how to correctly use the Tink API with AD.
  • Testing: Implement tests that specifically verify the correct handling of AD during encryption and decryption, including negative tests where incorrect AD is provided to ensure the Tink API rejects it.

Attack Surface: MAC Verification Failure

• Description: Failing to verify the Message Authentication Code (MAC) before processing the associated data allows an attacker to tamper with the data without detection. This is a direct misuse of the Tink API, bypassing its intended security checks.
• How Tink Contributes: Tink provides MAC primitives. The application is responsible for correctly calling Tink's verification functions before using the data. The availability of the MAC primitive, and the potential to bypass its verification, is Tink's direct contribution.
• Example: An application receives a message and its MAC. Due to a programming error, the application processes the message before calling Tink's MAC verification function. An attacker can modify the message and forge a valid-looking MAC (if the MAC algorithm is weak or the key is compromised).
• Impact: Loss of data integrity; attacker can modify data without detection.
• Risk Severity: High
• Mitigation Strategies:
  • Verify Before Processing: Always call Tink's MAC verification function before processing or trusting the associated data. This is a fundamental security principle.
  • Strong MAC Algorithms: Use strong MAC algorithms like HMAC-SHA256 or AES-CMAC, as provided by Tink.
  • Sufficient Key Length: Use keys of sufficient length for the chosen MAC algorithm, following Tink's recommendations.
  • Code Review: Carefully review the code that handles MAC verification to ensure it's implemented correctly and that Tink's API is used as intended.

Attack Surface: Using Outdated Tink Versions

• Description: Using an outdated version of the Tink library that contains known security vulnerabilities.
• How Tink Contributes: Vulnerabilities may be discovered and patched in newer versions of Tink. Older versions remain vulnerable. The existence of the library itself, and the potential for it to become outdated, is the direct contribution.
• Example: An application uses an old version of Tink that has a known vulnerability in its AEAD implementation. An attacker exploits this vulnerability to decrypt data.
• Impact: Varies depending on the specific vulnerability, but can range from data breaches to complete system compromise.
• Risk Severity: High to Critical (depending on the vulnerability)
• Mitigation Strategies:
  • Regular Updates: Keep Tink updated to the latest stable release. This is the primary mitigation.
  • Dependency Management: Use a dependency management system to track and update Tink and other libraries, ensuring that updates are applied promptly.
  • Security Advisories: Monitor security advisories and mailing lists related to Tink to be aware of newly discovered vulnerabilities.

Attack Surface: Incorrect KeysetHandle Exposure

• Description: Accidentally exposing a KeysetHandle object, which contains sensitive keying material or information about keys, in logs, error messages, or other insecure locations.
• How Tink Contributes: KeysetHandle is the core object for interacting with keys in Tink. Its security is paramount, and Tink's design relies on the application handling it securely. The existence and sensitivity of the KeysetHandle are Tink's direct contribution.
• Example: A KeysetHandle is accidentally included in a log message during debugging. An attacker who gains access to the logs can potentially extract keying material.
• Impact: Potential key compromise, leading to data breaches or other security incidents.
• Risk Severity: High
• Mitigation Strategies:
  • Never Log KeysetHandles: Treat KeysetHandle objects as highly sensitive data and never log them directly. This is the most important mitigation.
  • Secure Storage: Store KeysetHandle objects in secure locations, such as encrypted storage or a KMS, and ensure that access to these locations is tightly controlled.
  • Limited Scope: Minimize the scope and lifetime of KeysetHandle objects within the application's code.
  • Code Review: Carefully review code to ensure that KeysetHandle objects are not accidentally exposed, and that they are handled according to best practices.