Skip to content

MASTG-TEST-0210: Broken Symmetric Encryption Algorithms

Overview

To test for the use of broken encryption algorithms in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.

  • CommonCrypto: The CCCrypt function is used for symmetric algorithms and specifies the algorithm in its second parameter alg which can be one of the following CCAlgorithm constants:

    • kCCAlgorithmAES128
    • kCCAlgorithmDES
    • kCCAlgorithm3DES
    • kCCAlgorithmCAST
    • kCCAlgorithmRC4
    • kCCAlgorithmRC2
    • kCCAlgorithmBlowfish

  • CryptoKit: This library does not support weak encryption algorithms. It only supports secure symmetric algorithms including AES-GCM and ChaChaPoly.

  • Third-party libraries: Applications may include cryptographic functions through third-party libraries such as OpenSSL, BoringSSL, Libsodium, or even custom cryptographic implementations. These may support or expose weak encryption algorithms like DES, 3DES, RC2, RC4, or Blowfish.

Note: the Security framework only supports asymmetric algorithms and is therefore out of scope for this test (see note about symmetric keys).

Steps

  1. Run a static analysis tool such as radare2 for iOS on the app binary, or use a dynamic analysis tool like Frida for iOS, and look for uses of the cryptographic functions that perform encryption and decryption operations.

Observation

The output should contain the disassembled code of the functions using the relevant cryptographic functions.

Evaluation

The test case fails if you can find the use of broken encryption algorithms within the source code. For example:

  • DES
  • 3DES
  • RC2
  • RC4
  • Blowfish

This applies to Apple-provided APIs (e.g., CommonCrypto), third-party libraries (e.g., OpenSSL, Libsodium) and any custom implementations of cryptographic routines that replicate insecure algorithms (e.g., DES in C code) or use insecure configurations (e.g., ECB mode, short key sizes).

Stay up-to-date: This is a non-exhaustive list of broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region.

Some algorithms may not be considered broken as a whole, but may have risky configurations that should be avoided. For example, using a seed or IV that is not generated by a cryptographically secure pseudorandom number generator (CSPRNG) or that is not considered quantum-safe. For instance, an AES 128-bit key size is insufficient in the face of quantum computing attacks. This is important when building an app that uses data that will be stored for a long time. Make sure you follow the NIST recommendations from NIST IR 8547 "Transition to Post-Quantum Cryptography Standards", 2024.

Context Considerations:

To reduce false positives, make sure you understand the context in which the algorithm is being used before reporting the associated code as insecure. Ensure that it is being used in a security-relevant context to protect sensitive data.

Demos

MASTG-DEMO-0018: Uses of Broken Encryption Algorithms in CommonCrypto with r2