OWASP Mobile M10:2024 Insufficient Cryptography testing verifies whether an app's encryption implementation actually protects data, not just whether encryption code is present in the binary. The assessment covers three layers: algorithm and mode selection, key generation and storage, and platform keystore integration, validated through static binary analysis, dynamic instrumentation, and manual key-extraction attempts. The hidden cost most teams miss: an app can pass every automated SAST scan for "uses AES-256" and still be trivially broken because the key sits hardcoded next to the ciphertext.
TL;DR
- Testing mobile cryptography means validating algorithm choice, key storage, and platform keystore usage together, not checking for AES in a code search.
- Static analysis alone misses hardcoded keys assembled at runtime; dynamic instrumentation with Frida or objection is required to catch them in 2026.
- Android Keystore and iOS Secure Enclave misconfiguration, not weak algorithms, cause most real-world M10 findings.
- AppSecure Security runs manual binary teardown and runtime key extraction as part of every mobile app penetration test.
Why Insufficient Cryptography Testing Matters
Encryption failures do not show up as outages. They show up during an incident, an M&A due-diligence review, or a regulator's audit request for evidence that cardholder or health data was actually protected at rest. By the time a hardcoded key or reversible obfuscation routine surfaces, the data has usually already left the device.
Regulated industries feel this first. PCI DSS 4.0 requires documented cryptographic key management for cardholder data environments. HIPAA's Security Rule expects encryption of PHI at rest and in transit with access controls around keys. GDPR treats weak encryption as a factor in breach notification severity. None of these frameworks accept "we use AES" as evidence — assessors want proof of correct implementation, which only manual testing produces.
The business risk compounds in mobile because the client-side binary is fully in the attacker's hands. Unlike a server, where cryptographic material stays behind a network boundary, a mobile app ships its encryption logic, and often its keys, directly to every device that installs it.
How Do You Test Mobile Cryptography for M10 Insufficient Cryptography?
Testing M10 follows a five-stage workflow, moving from passive discovery to active exploitation of any weakness found.
- Scope and prerequisites — obtain the IPA/APK, test accounts, and confirm authorization for binary decompilation and runtime hooking against a non-production build.
- Static binary analysis — decompile the app and search for cryptographic API calls, hardcoded secrets, and custom "encryption" routines that are actually encoding (Base64, XOR).
- Dynamic instrumentation — hook cryptographic functions at runtime with Frida to capture actual keys, IVs, and algorithm parameters as they execute, bypassing any obfuscation applied to the static binary.
- Key storage and lifecycle testing — determine where keys live (Keystore, Keychain, shared preferences, SQLite), how they are generated, and whether they survive a device backup or rooted extraction.
- Exploitability validation and retest — attempt to decrypt captured ciphertext using recovered keys, document the attack path, and confirm the fix after remediation.
Static review
- Coverage: Hardcoded keys, weak algorithm calls, custom crypto
- Tooling: MobSF, jadx, Hopper
Dynamic analysis
- Coverage: Runtime key capture, algorithm parameters
- Tooling: Frida, objection
Storage review
- Coverage: Keystore/Keychain usage, backup exposure
- Tooling: adb backup, iOS Keychain dumper
Network layer
- Coverage: TLS pinning bypass, cipher negotiation
- Tooling: Burp Suite, mitmproxy
Exploitation
- Coverage: Ciphertext decryption with recovered keys
- Tooling: Manual scripting (Python/CyberChef)
This mirrors the manual-first approach AppSecure applies across its mobile app penetration testing for fintech apps engagements, where key extraction from a rooted device is a standard exploitability check, not an edge case.
M10 Insufficient Cryptography: Static Binary Analysis
Static analysis starts with decompiling the APK or IPA and grepping for cryptographic API usage: Cipher.getInstance, CCCrypt, CryptoKit, or custom classes named anything resembling "Encryptor" or "SecureStore." The goal is to find every place the app claims to protect data and flag deviations from platform defaults.
Common static findings include ECB mode ciphers (no IV, patterns leak through ciphertext), MD5 or SHA-1 used for anything beyond checksums, and keys concatenated from string literals split across multiple classes to evade simple string search. None of these require dynamic testing to prove — they are visible the moment the binary is unpacked.
M10 Insufficient Cryptography: Dynamic Runtime Testing
Static review misses keys generated or transformed at runtime, which is why dynamic instrumentation is mandatory, not optional, for a credible M10 assessment. Hooking Cipher.doFinal() or CCCryptorCreate with Frida captures the actual key material and IV as the app processes real data, even when the static binary obfuscates the source.
This step also reveals key derivation weaknesses: an app might use PBKDF2 correctly in principle but with an iteration count of 1,000 instead of the 2026-recommended minimum of 600,000+ for password-based keys, or derive a key from a predictable device identifier instead of user-supplied entropy.
M10 Insufficient Cryptography: Key Management Testing
Key management is where most real findings live, more than algorithm selection itself. Testing here asks four questions:
- Where is the key generated — on-device, server-side, or derived from a password?
- Where is it stored — hardware-backed keystore, shared preferences, or a SQLite column?
- Does the key survive an unencrypted device backup?
- Is the key rotated, or does it live for the app's entire install lifetime?
A key stored in SharedPreferences on Android or a plist on iOS is recoverable from any rooted or jailbroken device in minutes, regardless of how strong the encryption algorithm wrapped around it is. This is the finding that most frequently downgrades an otherwise "AES-256 compliant" app to a failed assessment.
M10 Insufficient Cryptography: Platform Keystore vs Keychain Testing
Android Keystore and iOS Keychain/Secure Enclave exist specifically to solve the key-storage problem, but both are frequently misconfigured.
Android Keystore
- Correct Usage: Hardware-backed key generation with
StrongBoxwhere available - Common Misconfiguration: Falling back to software-backed keystore silently on older API levels
iOS Keychain
- Correct Usage:
kSecAttrAccessibleWhenUnlockedThisDeviceOnlyfor sensitive keys - Common Misconfiguration: Using
kSecAttrAccessibleAlways, exposing keys post-backup restore
iOS Secure Enclave
- Correct Usage: Biometric-gated key operations for high-value secrets
- Common Misconfiguration: Storing raw keys instead of Secure Enclave key references
Testing confirms which accessibility class and protection level the app actually requests, not what the documentation says it should request. This same platform-specific rigor applies to the insufficient binary protections (M7) category, since weak binary protections make key extraction significantly easier once a static or dynamic weakness is identified.
Why Cryptography Findings Vary Between Apps
Insufficient Cryptography severity is not uniform across mobile apps. These factors drive the difference:
- Data sensitivity — a banking app storing cardholder PANs carries higher exploitability impact than a media app caching thumbnails.
- Development framework — React Native and Flutter apps often rely on JavaScript-bridge crypto libraries with weaker platform integration than native Swift/Kotlin implementations.
- Legacy SDK dependencies — third-party SDKs bundled years ago frequently hardcode outdated algorithms that the current dev team never audited.
- Offline-first architecture — apps that must function without connectivity store more data locally, expanding the attack surface for key extraction.
- Regulatory scope — PCI DSS and HIPAA-scoped apps face stricter key-rotation and storage expectations than apps outside regulated data categories.
- Backup and sync behavior — apps that sync to cloud backup without excluding key material inherit whatever protection the OS backup mechanism provides, which is often weaker than the app's own encryption.
Compliance Mapping for Mobile Cryptography Testing
PCI DSS 4.0
- What It Requires: Strong cryptography for cardholder data at rest and in transit
- What Assessors Check: Documented key management lifecycle, algorithm inventory
- Testing Implication: Full key extraction and rotation review required
HIPAA Security Rule
- What It Requires: Encryption of ePHI at rest, addressable but expected
- What Assessors Check: Evidence encryption is "in use," not just configured
- Testing Implication: Key storage location and backup exposure testing
GDPR Article 32
- What It Requires: "Appropriate" technical measures including encryption
- What Assessors Check: Breach severity tied to whether data was "unintelligible"
- Testing Implication: Ciphertext decryption attempt during test
SOC 2
- What It Requires: Confidentiality criteria for sensitive data handling
- What Assessors Check: Control evidence for encryption key access restriction
- Testing Implication: Access control review around key material
NIST 800-53 / CSF
- What It Requires: Cryptographic protection (SC-13) with approved algorithms
- What Assessors Check: FIPS 140-validated module usage
- Testing Implication: Algorithm and mode verification against approved list
This mapping approach is consistent with how AppSecure structures compliance-driven testing across PCI DSS penetration testing engagements, where key management evidence is a standard deliverable requirement.
Related Questions on Mobile Cryptography Testing
Is M10 Insufficient Cryptography the same as using weak encryption algorithms?
No — M10 covers weak algorithms as one sub-case, but the majority of 2026 findings involve correct algorithms with broken key management, not the algorithm itself. An app using AES-256 with a hardcoded key fails M10 just as badly as one using DES.
Does enforcing HTTPS solve M10 Insufficient Cryptography?
No — HTTPS addresses transport encryption, which falls under insecure communication (M5), a separate category. M10 concerns data encrypted and stored on the device itself, independent of network transport security.
Can automated scanners fully test for Insufficient Cryptography?
No — automated scanners reliably flag hardcoded string patterns and deprecated API calls, but they cannot validate runtime key derivation, keystore accessibility settings, or whether recovered keys actually decrypt captured ciphertext. That validation requires manual dynamic testing.
Mobile Cryptography Testing Checklist
- Decompile binary and inventory every cryptographic API call
- Flag ECB mode, MD5/SHA-1 misuse, and custom "encryption" that is really encoding
- Hook cryptographic functions at runtime to capture actual keys and IVs
- Verify key storage location (Keystore/Keychain vs shared preferences/plist)
- Test key survival through device backup and restore
- Confirm hardware-backed storage (StrongBox/Secure Enclave) is actually engaged, not silently falling back
- Attempt full ciphertext decryption using extracted keys to prove exploitability
- Map findings to applicable compliance framework (PCI DSS, HIPAA, GDPR, SOC 2)
- Retest after remediation to confirm keys are no longer recoverable
Most of this checklist overlaps directly with the credential-handling review covered in improper credential usage (M1), since weak key storage and weak credential storage are frequently the same underlying architectural mistake.
Get your mobile app tested for M10
Manual binary teardown and runtime key extraction, not a scanner report.
FAQ
What is OWASP Mobile M10:2024 Insufficient Cryptography?
M10 is the OWASP Mobile Top 10 2024 category covering cryptographic implementation failures in mobile apps, including weak algorithms, poor key management, and improper keystore usage. It focuses on data protection failures on the device itself, separate from network transport encryption.
How do you test mobile cryptography for compliance audits?
Testing mobile cryptography for compliance combines static binary analysis, runtime key extraction with tools like Frida, and manual review of key storage against Android Keystore or iOS Keychain best practices. Auditors under PCI DSS or HIPAA expect documented evidence of key lifecycle, not just an algorithm name.
Is AES-256 encryption enough to pass an M10 mobile security test?
No, algorithm strength alone does not pass an M10 test. If the AES-256 key is hardcoded, stored in shared preferences, or derivable from a predictable value, the encryption provides no real protection regardless of key length.
What tools are used to test mobile app cryptography?
MobSF and jadx handle static decompilation, Frida and objection perform runtime instrumentation to capture keys, and Burp Suite covers the network layer. Manual scripting is then used to attempt decryption of captured ciphertext with extracted keys.
How is M10 Insufficient Cryptography different from M5 Insecure Communication?
M10 covers data encrypted and stored on the device, while M5 covers data protection in transit over the network. An app can pass M5 with correct TLS pinning and still fail M10 if locally cached data uses a hardcoded encryption key.
Does using the Android Keystore automatically prevent M10 findings?
No, the Android Keystore reduces risk but does not eliminate it if the app silently falls back to software-backed storage on older API levels or fails to request StrongBox-backed keys where hardware support exists. Testing must confirm which mode is actually active.
How often should mobile apps be tested for cryptographic vulnerabilities?
Apps handling regulated data such as cardholder information or PHI should undergo cryptography testing at every major release and at minimum annually, consistent with PCI DSS and HIPAA expectations for ongoing security validation.
Can insufficient cryptography findings be fixed without a full app rebuild?
Often yes, if the fix involves migrating key storage to the platform keystore or correcting key derivation parameters, since these are implementation changes rather than architectural redesigns. Custom encryption routines that replace standard libraries typically require more extensive rework.
One Last Thing
The finding that catches teams off guard most often in 2026 engagements is not a weak algorithm — it is a correctly implemented AES-256 routine wrapped around a key that never leaves shared preferences. Fix the storage location before touching the algorithm; it is almost always the higher-impact remediation.
Related Guides
Tejas K. Dhokane is a marketing associate at AppSecure Security, driving initiatives across strategy, communication, and brand positioning. He works closely with security and engineering teams to translate technical depth into clear value propositions, build campaigns that resonate with CISOs and risk leaders, and strengthen AppSecure’s presence across digital channels. His work spans content, GTM, messaging architecture, and narrative development supporting AppSecure’s mission to bring disciplined, expert-led security testing to global enterprises.
.webp)
