MASTG-TEST-0213: Use of Hardcoded Cryptographic Keys in Code
Content in BETA
This content is in beta and still under active development, so it is subject to change any time (e.g. structure, IDs, content, URLs, etc.).
Overview¶
In this test case, we will examine iOS applications for the presence of hardcoded cryptographic keys. Hardcoded keys can be typically found in calls to cryptographic functions or stored as constants or variables within the code. In iOS, cryptographic keys are often used in the following frameworks:
- Security Framework: The
SecKeyCreateWithData
function allows developers to create a cryptographic key from raw data. - CommonCrypto: The
CCCrypt
can be initialized with raw key data in itskey
parameter. - CryptoKit: Although
CryptoKit
provides higher-level abstractions for cryptographic operations, developers might still hardcode cryptographic keys in different formats and feed it to methods likeP256.Signing.PrivateKey.init(rawRepresentation:)
or similar.
Steps¶
- Run a static analysis tool such as radare2 for iOS on the app binary looking for cryptographic APIs as indicated above.
Observation¶
The output should include any instances where the app uses cryptographic functions that accept raw key data. Whenever possible, the output should also try to point to the raw key data from the binary.
Evaluation¶
The test fails if calls to cryptographic functions with hardcoded keys are found within binary.
You may find the keys being directly passed as arguments to cryptographic functions (byte arrays or string literals) or stored in variables or constants within the code. Typical representations of hardcoded keys include:
- Raw Byte Arrays: Cryptographic keys may be directly embedded in the code as arrays of
UInt8
orData
objects. For example, a 256-bit AES key might be represented as a[UInt8]
array. - Base64-Encoded Strings: Developers might encode cryptographic keys as Base64 strings within the code, which can be easily decoded by attackers if discovered.
- Hex-Encoded Strings: Keys are sometimes stored as hexadecimal strings, which are then converted to
Data
objects at runtime for cryptographic operations.
Ensure that any identified keys are indeed cryptographic keys used for security-relevant purposes. Avoid false positives by verifying the key's usage context (e.g., configuration settings or non-security-related constants might be misidentified as cryptographic keys).
Demos¶
MASTG-DEMO-0014: Use of Hardcoded ECDSA Private Key in CryptoKit with r2 MASTG-DEMO-0013: Use of Hardcoded RSA Private Key in SecKeyCreateWithData with r2