Skip to content

Latest commit

 

History

History
116 lines (97 loc) · 11.7 KB

mitigations.md

File metadata and controls

116 lines (97 loc) · 11.7 KB

Mitigation Strategies Analysis for signalapp/signal-android

Mitigation Strategy: Strict Cryptographic Code Review and Testing (Signal-Specific)

  • Description:

    1. Identify Signal's Core Crypto Files: Maintain a precise list of files within the signal-android codebase that implement the Signal Protocol and related cryptography (e.g., files within libsignal-protocol-java, libsignal-service-java dealing with session management, key exchange, message encryption/decryption, and native code related to Curve25519, AES-GCM, etc.).
    2. Mandatory Expert Review: Enforce a policy that any modification to these identified Signal cryptographic files requires review by at least two security engineers with demonstrated expertise in the Signal Protocol itself. This is not a general code review; it's a specialized security review.
    3. Signal Protocol-Specific Checklist: Develop a review checklist specific to the Signal Protocol, including:
      • Correct implementation of Double Ratchet, X3DH, and related algorithms, according to the official specifications.
      • Verification that key derivation, usage, and rotation adhere to the Signal Protocol's requirements.
      • Checks for potential timing attacks or other side-channel leaks within the context of the Signal Protocol's implementation.
      • Review of any changes to cryptographic primitives (e.g., if using a different AES-GCM implementation, it must be thoroughly vetted).
      • Assessment of how changes might affect forward secrecy and post-compromise security.
    4. Signal-Specific Automated Testing:
      • Unit Tests: Write unit tests that specifically target Signal's cryptographic functions, covering edge cases and error conditions relevant to the Signal Protocol.
      • Integration Tests: Create integration tests that simulate complete Signal Protocol flows, including session setup, message exchange, and key rotation. These tests should verify the correct interaction of different components.
      • Known-Answer Tests (KATs): Use test vectors derived from the Signal Protocol specifications (or generated by a reference implementation) to verify the correctness of cryptographic operations.
    5. Upstream Synchronization and Conflict Resolution: Establish a process for regularly merging changes from the upstream signal-android repository. Any merge conflict within the identified cryptographic files must be resolved by a security engineer with Signal Protocol expertise. This is critical to avoid accidentally reverting security fixes.
    6. Documentation of Deviations: If any deviations from the upstream Signal Protocol implementation are absolutely necessary, document them extremely thoroughly, including the rationale, security analysis, and potential risks.

  • List of Threats Mitigated:

    • Incorrect Implementation of Signal Protocol (Severity: Critical): Directly addresses the risk of introducing bugs that break the core security guarantees of the Signal Protocol.
    • Signal-Specific Side-Channel Attacks (Severity: High): Helps identify and mitigate side-channel vulnerabilities that are specific to the way Signal implements its cryptography.
    • Key Compromise due to Signal-Specific Errors (Severity: Critical): Reduces the risk of introducing bugs that could expose Signal's cryptographic keys.
    • Regression Bugs in Signal's Crypto (Severity: Variable): Helps prevent the reintroduction of previously fixed vulnerabilities in Signal's code.

  • Impact:

    • Incorrect Implementation: Risk significantly reduced (e.g., from "Critical" to "Low").
    • Signal-Specific Side-Channels: Risk reduced (e.g., from "High" to "Medium").
    • Key Compromise: Risk significantly reduced (e.g., from "Critical" to "Low").
    • Regression Bugs: Risk reduced (e.g., from "Medium" to "Low").

  • Currently Implemented (Example):

    • General code review process exists.
    • Some unit tests for Signal's cryptographic functions.

  • Missing Implementation (Example):

    • No mandatory review by multiple Signal Protocol experts.
    • No Signal Protocol-specific checklist.
    • Limited integration testing of complete Signal Protocol flows.
    • No use of Signal-specific KATs.
    • Merge conflicts in Signal's crypto code are not always handled by Signal Protocol experts.
    • Incomplete documentation of deviations from upstream.

Mitigation Strategy: Secure Signal Key Management with Android Keystore (Signal-Specific)

  • Description:

    1. Identify Signal's Key Material: Precisely identify all cryptographic keys used by Signal within the signal-android codebase (identity keys, pre-keys, signed pre-keys, session keys, message keys, chain keys, etc.).
    2. Android Keystore for Long-Term Keys: Ensure that Signal's long-term keys (identity key, signed pre-key) are stored using the Android Keystore System.
      • Use KeyGenParameterSpec.Builder with settings appropriate for Signal's keys.
      • Crucially, set setUserAuthenticationRequired(true) to require user authentication (biometric or PIN) before Signal can access these keys. This is essential for protecting Signal's keys even if the device is unlocked.
      • Use setIsStrongBoxBacked(true) if the device supports it to store Signal's keys in the StrongBox secure hardware. This provides an extra layer of protection.
      • Verify that the correct key algorithms and purposes are used, matching Signal's requirements (e.g., KeyProperties.KEY_ALGORITHM_EC for identity keys, appropriate purposes for signing and encryption).
    3. Signal's Ephemeral Key Handling: For Signal's ephemeral keys (session keys, message keys, chain keys), ensure secure in-memory handling.
      • Use SecureRandom for generating these keys, ensuring it's properly seeded.
      • Attempt to overwrite key material in memory with zeros after use (e.g., Arrays.fill(keyMaterial, (byte) 0)). Understand the limitations of this on a managed runtime.
    4. Signal's Key Derivation (If Modified): If modifying how Signal derives keys (e.g., from a user-chosen passphrase), ensure the KDF is strong and aligns with Signal's security model. Use a well-vetted KDF like Argon2id with parameters appropriate for mobile devices and Signal's threat model.
    5. Signal's Key Rotation and Revocation: Review and potentially enhance Signal's key rotation and revocation mechanisms.
      • Ensure that key rotation is performed according to the Signal Protocol's specifications.
      • If modifying the revocation mechanism, ensure it's robust and prevents replay attacks.
    6. Careful Audit Logging (Signal Context): Log only Signal key management events (key generation, usage for encryption/decryption, rotation, deletion) without ever logging the key material itself or any information that could be used to derive it. Focus on logging actions within the Signal Protocol flow.

  • List of Threats Mitigated:

    • Compromise of Signal's Keys from Device Compromise (Severity: High): Reduces the risk of an attacker extracting Signal's keys from a compromised device, especially if the device is unlocked.
    • Compromise of Signal's Keys from Application Vulnerabilities (Severity: High): Reduces the risk of vulnerabilities within the signal-android codebase leading to key exposure.
    • Weak Key Derivation in Signal (Severity: High): Mitigates attacks against weak passphrases or secrets used to derive Signal's keys (if applicable).
    • Signal Key Reuse (Severity: Medium): Key rotation reduces the impact of a Signal key compromise.

  • Impact:

    • Device Compromise: Risk reduced (from "High" to "Medium" or "Low," depending on StrongBox and user authentication).
    • Application Vulnerabilities: Risk reduced (from "High" to "Medium").
    • Weak Key Derivation: Risk significantly reduced (from "High" to "Low").
    • Key Reuse: Risk reduced (from "Medium" to "Low").

  • Currently Implemented (Example):

    • Android Keystore System is used for Signal's identity key.
    • Ephemeral keys are stored in memory.

  • Missing Implementation (Example):

    • setUserAuthenticationRequired(true) is not consistently used for all of Signal's long-term keys.
    • setIsStrongBoxBacked(true) is not used, even on supported devices.
    • Ephemeral keys are not reliably zeroed out.
    • Signal's key rotation/revocation mechanisms have not been thoroughly reviewed or enhanced.
    • No careful audit logging of Signal key management events.

Mitigation Strategy: Strict Signal Protocol Version Enforcement and Downgrade Attack Prevention

  • Description:

    1. Identify Signal Protocol Versions: Determine the specific versions of the Signal Protocol supported by the signal-android codebase.
    2. Enforce Latest Version: Configure the application to strictly accept connections only using the latest, most secure version of the Signal Protocol supported by both communicating parties.
    3. Explicitly Reject Old Versions: Add code to explicitly reject any connection attempts using older, deprecated versions of the Signal Protocol. This should be a hard failure, not a fallback.
    4. Signal Version Negotiation Review: Thoroughly review the code within signal-android that handles Signal Protocol version negotiation (likely within SessionCipher and related classes).
      • Ensure that the application cannot be tricked into negotiating an older version of the protocol.
      • Look for any vulnerabilities that could allow an attacker to manipulate the version negotiation process, specifically within the context of Signal's implementation.
    5. Signal-Specific Downgrade Attack Alerting: Implement mechanisms to detect and alert the user to potential downgrade attacks related to the Signal Protocol.
      • Display a clear warning if the application is forced to use an older version (this should ideally never happen).
      • Log any attempts to downgrade the Signal Protocol version, including details about the remote party.
    6. Targeted Testing: Create test cases that specifically attempt to force the application to downgrade the Signal Protocol version. These tests should verify that the rejection mechanisms are working correctly.

  • List of Threats Mitigated:

    • Signal Protocol Downgrade Attacks (Severity: High): Prevents attackers from forcing the application to use a weaker, older version of the Signal Protocol, bypassing security improvements.
    • Exploitation of Old Signal Vulnerabilities (Severity: High): Reduces the risk of attackers exploiting vulnerabilities that have been fixed in newer versions of the Signal Protocol.

  • Impact:

    • Downgrade Attacks: Risk significantly reduced (from "High" to "Low").
    • Exploitation of Old Vulnerabilities: Risk significantly reduced (from "High" to "Low").

  • Currently Implemented (Example):

    • The application generally uses the latest Signal Protocol version.

  • Missing Implementation (Example):

    • No explicit, hard rejection of older Signal Protocol versions.
    • No dedicated code review focused on Signal's version negotiation logic.
    • No Signal-specific alerting for downgrade attempts.
    • No targeted tests for Signal Protocol downgrade attacks.