Skip to content

Latest commit

 

History

History
74 lines (64 loc) · 5.86 KB

attack-tree.md

File metadata and controls

74 lines (64 loc) · 5.86 KB

Attack Tree Analysis for google/tink

Objective: To decrypt ciphertext or forge authenticated data protected by Tink without possessing the legitimate keys. [CN]

Attack Tree Visualization

                                      Decrypt Ciphertext or Forge Authenticated Data (Without Legitimate Keys) [CN]
                                                        /
                                                       /
                                                      /
                                 ---------------------
                                 |
                         1. Key Compromise [CN] [HR]
                                 |
                ---------------------------------
                |                |
       1b. Key Leakage   1c. Key Reuse
       (External to Tink) (Across Contexts)
       [HR]              [HR]

Attack Tree Path: 1. Key Compromise [CN] [HR]

  • Description: This is the overarching category encompassing all methods by which an attacker gains unauthorized access to the cryptographic keys used by Tink. It's a critical node because possessing the keys grants the attacker full control over the protected data. It's high-risk due to the prevalence of key compromise attacks.
  • Sub-Vectors (High-Risk):

Attack Tree Path: 1b. Key Leakage (External to Tink) [HR]

  • Description: This refers to the accidental or malicious exposure of the cryptographic keys outside of the intended secure environment. This is not a Tink vulnerability itself, but it completely undermines Tink's security.
  • Examples:
    • Storing cleartext keysets in source code repositories (e.g., GitHub, GitLab).
    • Hardcoding keys in configuration files that are not properly secured.
    • Accidental logging of keyset data.
    • Compromise of the Key Management Service (KMS) used to encrypt the keyset (e.g., AWS KMS, Google Cloud KMS, Azure Key Vault).
    • Phishing attacks targeting developers or administrators with access to keys.
    • Insider threats (malicious or negligent employees).
    • Exposure through insecure backups.
  • Likelihood: High
  • Impact: High (Complete loss of confidentiality and integrity.)
  • Effort: Varies widely (from trivial to very difficult, depending on the security measures in place).
  • Skill Level: Varies widely (from script kiddie to nation-state actor).
  • Detection Difficulty: Varies widely (from easy to detect if keys are in plaintext in source code, to extremely difficult if a sophisticated KMS compromise occurs).
  • Mitigation:
    • Never store cleartext keysets: Always use a KMS to encrypt keysets at rest.
    • Secure Configuration Management: Use secure methods for storing and retrieving configuration data (e.g., environment variables, secrets management services).
    • Least Privilege: Grant only the necessary permissions to access keysets and the KMS. Follow the principle of least privilege.
    • Auditing and Monitoring: Enable audit logs for KMS access and monitor for suspicious activity. Implement intrusion detection systems.
    • Multi-Factor Authentication (MFA): Enforce MFA for all accounts with access to keys or the KMS.
    • Regular Security Audits: Conduct regular security audits and penetration testing to identify vulnerabilities.
    • Employee Training: Train employees on secure coding practices and the importance of protecting cryptographic keys.
    • Incident Response Plan: Have a well-defined incident response plan in place to handle key compromise incidents.
    • Secure Backup and Recovery: Implement secure backup and recovery procedures for keysets, ensuring that backups are also encrypted and protected.
    • Input Sanitization: Sanitize all the inputs that are used to generate keys.

Attack Tree Path: 1c. Key Reuse (Across Contexts) [HR]

  • Description: Using the same cryptographic key for multiple different purposes or applications. This significantly increases the impact of a single key compromise. If one application or service is compromised, all others using the same key are also vulnerable.
  • Examples:
    • Using the same AEAD keyset to encrypt both user data and application logs.
    • Using the same signing key for multiple microservices.
    • Using the same key for both development and production environments.
  • Likelihood: Medium (Common mistake, especially in larger, complex systems.)
  • Impact: High (Compromise of one context leads to compromise of all contexts using the same key.)
  • Effort: Low (Once one context is compromised, the attacker has the key for all others.)
  • Skill Level: Low (Exploiting key reuse is trivial once the key is obtained.)
  • Detection Difficulty: Medium (Requires careful analysis of key usage across the entire system. Difficult to detect at runtime without specific instrumentation.)
  • Mitigation:
    • Key Isolation: Use separate keysets for different applications, services, and even different types of data within the same application. This is the primary mitigation.
    • Context Binding: If possible, cryptographically bind the key to the specific context using associated data in AEAD. This helps prevent misuse even if the key is leaked.
    • Key Derivation: Use key derivation functions (KDFs) to derive different keys from a single master key, ensuring that each derived key is used for a specific purpose.
    • Policy Enforcement: Implement policies and procedures to prevent key reuse, and enforce them through code reviews and automated checks.
    • Documentation and Training: Clearly document the importance of key isolation and provide training to developers.