Android Security for Banking & Enterprise Apps — Threat Model, Keystore, Cert Pinning, and the OEM Realities
The first time I worked on a banking app, I learned something most Android developers never have to: the threat model is fundamentally different. Consumer apps protect against bugs and crashes; banking and enterprise apps protect against adversaries. Someone is actively trying to extract the user’s session token from your app’s memory, intercept network traffic, decompile the APK to find your API keys, run your app on a rooted device with Frida hooked into your auth flow. None of the “use Hilt, write tests, optimize cold start” advice prepares you for that.
The good news: Android has matured enormously on the security side. Encrypted storage with hardware-backed keys, biometric primitives, attestation APIs, certificate pinning — the platform gives you the tools. The bad news: most Android security writing is either (a) generic web-security advice with “Android” tacked on, or (b) checklists without explanation of what each item actually defends against. This post tries to be neither.
What we’ll cover: the threat model for a banking/enterprise Android app, the storage layer (Keystore, EncryptedSharedPreferences, when to use what), preventing screen capture and overlays, certificate pinning done correctly, biometric authentication that actually authenticates, and the realities of OEM-modified Android that complicate everything. Examples come from a fictional banking app because banking is the canonical high-stakes Android domain. Future posts will go deeper on root detection, file upload security, and biometric flows specifically; this post is the foundation.
The Threat Model — Who Are You Defending Against?
Before any code, articulate what you’re protecting and from whom. Five threat actors matter for banking/enterprise apps:
1. The casual attacker (a stolen phone). Someone picks up the user’s unlocked phone in a coffee shop. They want to open the banking app and transfer money. Defense: device-level lock, app-level re-authentication, session timeouts.
2. The technical attacker (a stolen rooted device). A more sophisticated actor with the unlocked phone, who can root it or attach a debugger. They want to extract session tokens, encryption keys, or stored credentials from the app’s data. Defense: hardware-backed key storage, root detection, anti-tampering, sensitive-data zeroing.
3. The network attacker. Someone on the same Wi-Fi network (or a malicious VPN) trying to intercept or modify API traffic. Defense: TLS (table stakes), certificate pinning, encrypted payloads at the application layer for highest-stakes operations.
4. The reverse engineer. Someone with a copy of your APK trying to find hardcoded secrets, understand business logic, or find vulnerabilities. Defense: R8/Proguard obfuscation, no secrets in code, server-side enforcement of business rules.
5. The malicious overlay app. An app installed alongside yours that draws on top of your screens, captures screen content, or impersonates your UI. Defense: FLAG_SECURE, overlay detection, careful clipboard handling.
For each defense you build, ask: which actors does this defeat? A lot of “security” code in banking apps targets actor #1 (the casual attacker) when actor #2 or #3 is the realistic threat. Conversely, paranoid root detection that breaks 30% of legitimate users is over-indexed on actor #2 when actor #1 was the actual concern.
The senior engineering signal: knowing which threats your defenses actually counter. Defense-in-depth is real, but every layer has a cost (UX friction, false positives, maintenance), and the cost has to be justified by the threat.
The Storage Layer — Where Keys and Tokens Live
Anything sensitive that the app stores locally is a potential leak. Tokens, encryption keys, PINs, transaction history with account numbers, biometric fallback secrets. The Android Keystore is what you build everything else on.
The Android Keystore — What It Actually Is
The Keystore is a hardware-isolated key vault on most modern Android devices. Keys generated inside it never leave it — you can use them to encrypt and decrypt data, sign payloads, or verify signatures, but you cannot extract the raw key bytes. On devices with a Trusted Execution Environment (TEE) or StrongBox security chip, the keys live in dedicated hardware that’s isolated even from a fully compromised Android OS.
What this means in practice: even if an attacker roots the device, they cannot read your encryption keys. They can use them (call into Keystore as your app would), which is why the operations need additional protection — biometric or PIN authentication required for sensitive key uses.
// Generate a hardware-backed AES key for encrypting tokens
fun generateMasterKey(): SecretKey {
val keyGenerator = KeyGenerator.getInstance(
KeyProperties.KEY_ALGORITHM_AES,
“AndroidKeyStore”
// ✅ The provider name is what makes this hardware-backed
// Without “AndroidKeyStore” you get a regular software key
)
val spec = KeyGenParameterSpec.Builder(
“com.example.bank.master_key”,
KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
)
.setBlockModes(KeyProperties.BLOCK_MODE_GCM)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
.setKeySize(256)
.setUserAuthenticationRequired(true) // 🔒 Biometric or device lock to use
.setUserAuthenticationParameters(
30, // Valid for 30 seconds after auth
KeyProperties.AUTH_BIOMETRIC_STRONG or KeyProperties.AUTH_DEVICE_CREDENTIAL
)
.setIsStrongBoxBacked(true) // Use StrongBox if available (Pixel 3+, some others)
.build()
keyGenerator.init(spec)
return keyGenerator.generateKey()
}Three flags worth lingering on:
setUserAuthenticationRequired(true): the key can’t be used at all without recent user authentication. This is the difference between “the attacker has to root the device” and “the attacker has to root the device and capture the user’s biometric or PIN.” For high-stakes keys (payment authorization, signing), set this.
setUserAuthenticationParameters(30, ...): after a successful biometric, the key remains usable for 30 seconds without re-authenticating. Long enough for a normal user flow; short enough that an attacker who steals the unlocked phone has limited time. Tune per use case — a single payment auth might want 5 seconds; a session of small operations might want 60.
setIsStrongBoxBacked(true): on devices that have StrongBox (a separate secure chip), the key lives there instead of in the TEE. The trade-off: StrongBox is slower (each operation costs ~100ms vs. ~10ms for TEE). For frequently-used keys, leave it off; for the master key that encrypts everything else, turn it on. Wrap in a try-catch and fall back to non-StrongBox — not all devices support it.
EncryptedSharedPreferences and EncryptedFile
For everyday sensitive storage (auth tokens, user preferences with personal data), don’t roll your own. AndroidX provides EncryptedSharedPreferences and EncryptedFile, both backed by the Keystore.
// Setup once, typically in a repository or app-startup initializer
val masterKey = MasterKey.Builder(context)
.setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
.build()
val prefs = EncryptedSharedPreferences.create(
context,
“auth_prefs”,
masterKey,
EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)
// Use it like any SharedPreferences
prefs.edit()
.putString(“session_token”, token)
.apply()
val token = prefs.getString(“session_token”, null)
// On disk: nothing readable. The bytes in the .xml file are ciphertext.
// Decryption happens in memory at read time, with the Keystore providing the key.One subtle thing: EncryptedSharedPreferences encrypts both keys and values, with different schemes. Keys use AES-SIV (deterministic, so you can look up by key); values use AES-GCM (randomized, with authentication tag). This is intentional: querying by key requires deterministic encryption; protecting values doesn’t.
What not to use it for: anything you need to query, sort, or aggregate. EncryptedSharedPreferences is for “put a few sensitive blobs in,” not for a database. For larger encrypted datasets, use SQLCipher (Room with SQLCipher integration) or design a schema where sensitive fields are encrypted at the column level.
The Hierarchy You Want
For a banking app, a typical storage hierarchy:
┌─────────────────────────────────────────────────────────────────┐
│ What │ Where │
├───────────────────────────────┼──────────────────────────────────┤
│ Master encryption key │ Keystore (hardware-backed) │
│ Session token, refresh token │ EncryptedSharedPreferences │
│ Recent transactions list │ Room + SQLCipher │
│ User preferences (theme etc.) │ DataStore (no encryption needed) │
│ Profile photo │ EncryptedFile │
│ Cached account balance │ Room (with column encryption) │
│ Logs, analytics events │ Plain DataStore (no PII) │
└─────────────────────────────────────────────────────────────────┘The mental model: encrypt what is private and durable. Don’t encrypt what is non-sensitive (you pay performance cost for nothing). Don’t store what doesn’t need to be stored at all (session tokens are the canonical example — in many architectures, only the refresh token persists; the access token lives only in memory).
Preventing Screen Capture and Overlays
This is one of the simplest defenses and one of the most overlooked. Android lets other apps screenshot your screens by default, including via the recent-apps thumbnail. For a banking app showing account balances, that’s a real risk.
// In every Activity that displays sensitive content
override fun onCreate(savedInstanceState: Bundle?) {
window.setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
)
super.onCreate(savedInstanceState)
setContent { BankingApp() }
}What FLAG_SECURE does:
- Prevents the system screenshot mechanism (button combo, third-party screenshot apps via accessibility) from capturing the screen
- Replaces the recent-apps thumbnail with a blank or generic icon
- Prevents screen recording apps from including this surface
- Prevents the screen from appearing in cast/mirror sessions
What it doesn’t do: prevent someone from photographing your screen with another phone. Photo OCR is rare in practice but possible. For absolutely critical screens (showing card numbers, OTP codes), consider hiding sensitive parts after a few seconds or requiring re-authentication to view.
For Compose, you can manage FLAG_SECURE per-screen using DisposableEffect:
@Composable
fun SecureScreen(content: @Composable () -> Unit) {
val activity = LocalActivity.current
DisposableEffect(Unit) {
activity?.window?.setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
)
onDispose {
activity?.window?.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)
}
}
content()
}Wrap any composable that shows sensitive data in SecureScreen { }. The flag is set on entry, cleared on exit; the rest of the app behaves normally. Trade-off: while FLAG_SECURE is set, even legitimate screenshots for support purposes are blocked. Some apps offer a “safe mode” toggle for non-sensitive screens.
Overlay Detection
The other side of this: malicious apps can draw on top of your screens (the “tapjacking” or “overlay” attack). Common in banking-app malware: an overlay that mimics your login screen, captures credentials, then forwards them.
The detection:
// Detect if any overlay is being drawn over our window
override fun onWindowFocusChanged(hasFocus: Boolean) {
super.onWindowFocusChanged(hasFocus)
if (hasFocus) {
// FILTER_TOUCHES_WHEN_OBSCURED rejects touches if window is partially obscured
window.decorView.filterTouchesWhenObscured = true
}
}
// Or programmatically check for overlay apps
fun hasOverlayPermissionGranted(context: Context): Boolean {
return Settings.canDrawOverlays(context)
}
// At sensitive moments (PIN entry, transaction confirm), check if overlays exist
fun isLikelyBeingOverlaid(view: View): Boolean {
// Touch events that arrive obscured will have FLAG_WINDOW_IS_OBSCURED set
// This isn’t bulletproof but it catches most casual overlay attacks
return view.windowVisibility != View.VISIBLE
}The setting filterTouchesWhenObscured is the lightweight defense: if anything is drawing over your view, touches are silently dropped. The user notices because their tap doesn’t do anything, which prompts them to look at what’s happening.
Certificate Pinning Done Correctly
TLS is mandatory but not sufficient. Standard TLS verifies the server’s certificate against the device’s trust store — a list of ~150 root CAs. Any of those CAs (or anyone who compromises one) can issue a valid certificate for your domain. Certificate pinning narrows that trust to specific known certificates or public keys.
For a banking app, certificate pinning is mandatory in 2026. The implementation, using OkHttp:
val client = OkHttpClient.Builder()
.certificatePinner(
CertificatePinner.Builder()
// Pin to specific public key hashes (SPKI hashes)
// Get these from your operations team or via openssl
.add(
“api.bank.com”,
“sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=”, // Primary
“sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=” // Backup
)
.build()
)
.build()Three rules of certificate pinning:
1. Always pin a backup. Certificates rotate. If you pin only the current cert, you’re a renewal away from a complete app outage. Pin the current and the next-renewal certificate (or a long-lived intermediate that’s under your control).
2. Pin the public key, not the leaf certificate. Public keys can be reused across renewals; certificates can’t. The SPKI hash (Subject Public Key Info hash) is what OkHttp’s sha256/... format expects.
3. Have a rollback strategy. If your pinned cert expires and you didn’t update the app, every user is locked out. Server-side controlled revocation/rotation is more complex; many apps use Network Security Config and accept that they need a forced-update mechanism for cert emergencies.
The Network Security Config XML alternative (declarative, more flexible):
// res/xml/network_security_config.xml
<network-security-config>
<domain-config>
<domain includeSubdomains=“true”>api.bank.com</domain>
<pin-set expiration=“2026-12-31”>
<pin digest=“SHA-256”>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</pin>
<pin digest=“SHA-256”>BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=</pin>
</pin-set>
</domain-config>
</network-security-config>The advantage: the expiration date acts as a fail-safe. After that date, pinning automatically disables on this domain (you fall back to standard TLS). This prevents the “everyone locked out” failure mode if someone forgets to update the app.
Reference it in the manifest:
<application
android:networkSecurityConfig=“@xml/network_security_config”>And critically: in debug builds, override the config to allow charles/mitm-proxy testing. Otherwise developers can’t debug TLS issues.
// res/xml/network_security_config_debug.xml
<network-security-config>
<debug-overrides>
<trust-anchors>
<certificates src=“user” />
</trust-anchors>
</debug-overrides>
</network-security-config>This config allows user-installed CA certs (like Charles Proxy’s) only in debug builds. Release builds maintain strict pinning.
Biometric Authentication That Actually Authenticates
The most common biometric mistake: using BiometricPrompt as a UI gate (“the user touched the fingerprint sensor, let them in”) without binding the biometric result to an actual cryptographic operation. That pattern is bypassable on rooted devices — you patch the “auth succeeded” callback to always return true.
The right pattern: bind the biometric authentication to a Keystore key, and require that key to perform a real operation (decrypting a token, signing a payload). This makes the biometric result cryptographically meaningful.
fun authenticateAndDecryptToken(
activity: FragmentActivity,
onSuccess: (String) -> Unit,
onError: (String) -> Unit
) {
// Get the Keystore-backed cipher
val cipher = getCipherForDecryption(“com.example.bank.token_key”)
val cryptoObject = BiometricPrompt.CryptoObject(cipher)
// CryptoObject is the BINDING: this Cipher can only be used after biometric success
val biometricPrompt = BiometricPrompt(
activity,
ContextCompat.getMainExecutor(activity),
object : BiometricPrompt.AuthenticationCallback() {
override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
val authenticatedCipher = result.cryptoObject?.cipher
?: return onError(“No cipher available”)
try {
val encryptedToken = loadEncryptedTokenFromStorage()
val decryptedBytes = authenticatedCipher.doFinal(encryptedToken)
onSuccess(String(decryptedBytes))
// ✅ This decryption could ONLY happen after successful biometric
} catch (e: Exception) {
onError(“Decryption failed: ${e.message}”)
}
}
override fun onAuthenticationError(errorCode: Int, errString: CharSequence) {
onError(errString.toString())
}
override fun onAuthenticationFailed() {
// Biometric was scanned but didn’t match. Don’t bail out yet —
// the user might try again. Multiple failures eventually trigger
// onAuthenticationError with ERROR_LOCKOUT.
}
}
)
val promptInfo = BiometricPrompt.PromptInfo.Builder()
.setTitle(“Authenticate to access your account”)
.setSubtitle(“Use biometrics or device PIN”)
.setAllowedAuthenticators(
BiometricManager.Authenticators.BIOMETRIC_STRONG or
BiometricManager.Authenticators.DEVICE_CREDENTIAL
)
.build()
biometricPrompt.authenticate(promptInfo, cryptoObject)
}Why this is meaningfully different from a UI gate: a rooted-device attacker who patches the success callback gets... nothing. They didn’t actually unlock the cipher; the encrypted token in storage remains encrypted; their patch is meaningless because the decryption never happens. The cryptographic binding is the security; the UI is just the prompt.
The setAllowedAuthenticators choice is important: BIOMETRIC_STRONG is fingerprint or face unlock at high confidence (Class 3 biometrics). BIOMETRIC_WEAK includes lower-security face unlock that’s easier to spoof — for banking, allow only STRONG. DEVICE_CREDENTIAL is the device PIN/password as a fallback for users who can’t use biometric for some reason; allow this for accessibility but be aware it’s a different security model.
Code Obfuscation and Hiding Secrets
R8 (covered in its own post) gives you obfuscation as a side effect. For a banking app, that’s a starting point, not the destination. Three additional considerations:
1. Don’t hardcode secrets in the APK. No API keys, no encryption keys, no auth tokens. Even with R8, anyone with the APK can extract strings. Strings are kept by R8 by default. The right place for secrets is server-side, fetched after authentication.
2. Use BuildConfig sparingly. If you use BuildConfig.API_BASE_URL to switch between production and staging, that’s fine — the URL isn’t a secret. If you’re using BuildConfig.SOME_API_KEY, that key is plainly visible in the decompiled APK.
3. For unavoidable client-side keys, use the NDK and string obfuscation. If your app genuinely needs a build-time key (rare, but happens with third-party SDKs that require it), embed it in C++ via the NDK with simple XOR obfuscation at minimum, or use a library like secrets-gradle-plugin + native code wrapping. This raises the cost of extraction from “run apktool” to “decompile native code and reverse the obfuscation” — not impossible, but not casual.
The honest reality: any value that ships in the APK is extractable by a determined attacker. Obfuscation raises the cost; it doesn’t prevent extraction. If your security depends on an attacker not finding a string in your APK, your security is broken. Move the secret to the server.
Memory Safety for Sensitive Data
Once you decrypt a token or decode a PIN, it’s in JVM heap memory. Garbage collection will eventually reclaim it — but “eventually” can be minutes. A memory dump in those minutes leaks the value.
The mitigation: hold sensitive values as CharArray or ByteArray, not String, and zero them after use.
// ❌ Strings are immutable, can’t be cleared
fun authenticateWithPin(pin: String) {
val hash = hashPin(pin)
api.authenticate(hash)
// pin remains in memory until GC, possibly minutes later
}
// ✅ CharArrays can be zeroed
fun authenticateWithPin(pin: CharArray) {
try {
val hash = hashPin(pin)
api.authenticate(hash)
} finally {
Arrays.fill(pin, ‘\u0000’)
// pin is now all-zeros in memory; the bytes can’t be recovered
}
}For text fields collecting PINs/passwords in Compose, this is annoying because TextField defaults to working with String. The workaround: use a custom TextFieldValue that holds the value as a CharArray, or for security-critical fields, fall back to View-based EditText (which has explicit char-array access) inside an AndroidView.
This is one of the cases where the “Compose for everything” ideal compromises with security needs. For a banking app, the View-based PIN entry is worth the inconsistency.
The OEM Reality That Complicates Everything
Everything above assumes Android works as documented. On a Pixel running stock AOSP, that’s mostly true. On Samsung, Xiaomi, Huawei, OPPO, OnePlus, and other OEM Android variants — which together represent the majority of users globally — some assumptions break.
Aggressive battery optimization can kill your foreground services, including legitimate ones used for security monitoring (e.g., a service that detects suspicious behavior). Samsung’s “sleeping apps” list, Xiaomi’s autostart blocking, Huawei’s Protected Apps list — each one breaks foreground services in different ways.
Some OEM-modified WebViews don’t respect Network Security Config. Certificate pinning that works on Pixel may silently fall back on other devices. Test pinning on actual hardware for each OEM you target, not just an emulator.
Root-by-default builds exist in the wild. Some Chinese OEM builds for certain markets ship with root access available; others have pre-installed apps that effectively act as root. Detection becomes a probability game, not a yes/no.
Custom Keystore implementations vary. Most OEMs respect the Android Keystore API, but the underlying hardware differs. StrongBox availability is uneven; TEE security guarantees differ by chipset and OEM customization.
What this means practically: test your security model on the actual device fleet your users carry, not just on the engineering team’s phones. Firebase Test Lab gives you access to thousands of device models. For high-stakes apps, run automated security tests across at least: Pixel (stock baseline), Samsung (largest userbase outside China), Xiaomi (large emerging-market presence), and the cheapest device your target market uses.
This is the OEM fragmentation reality that almost no Android security writing acknowledges. Your security is only as strong as the weakest device it runs on. The next post in this Security cluster will go deeper on root detection specifically; future posts will cover OEM survival patterns more comprehensively.
A Practical Layering for Your App
Stitching everything together for a banking app, here’s the layered defense:
┌──────────────────────────────────────────────────────────────────┐
│ Layer │ What it defends against │
├─────────────────────────────┼────────────────────────────────────┤
│ TLS + Certificate Pinning │ Network MITM attackers │
│ Keystore-backed encryption │ Local data extraction (rooted) │
│ EncryptedSharedPreferences │ File system reads (legitimate apps)│
│ FLAG_SECURE │ Screenshot/screen-record, overlays │
│ filterTouchesWhenObscured │ Tapjacking attacks │
│ BiometricPrompt + CryptoObj │ UI-bypass attacks │
│ R8 + ProGuard │ Casual reverse engineering │
│ Server-side enforcement │ EVERYTHING (this is the real bar) │
│ Root detection (probabilistic)│ Tampered devices │
│ Session timeouts │ Stolen unlocked phones │
│ FLAG_SECURE on recents thumb│ Recent-apps glances │
│ Memory zeroing for secrets │ Memory-dump attacks │
└──────────────────────────────────────────────────────────────────┘The single most important row in that table is server-side enforcement. Every client-side check can be bypassed by a determined attacker. The reason banks don’t lose money to client tampering is not that their apps are unhackable — it’s that their servers re-validate every transaction, run fraud detection, and reject suspicious activity regardless of what the client claims.
Client-side security exists to raise the cost of attacks and to protect users from incidental compromise (stolen phone, public Wi-Fi). It is not the line of defense for the bank’s money. Senior engineers building banking and enterprise apps internalize this distinction early.
What This Post Doesn’t Cover (Yet)
Each of these deserves its own post and will get one in this Security cluster:
- Root and tampering detection — Play Integrity API, RootBeer library, custom checks, the cat-and-mouse game
- Secure file upload to a server — client-side encryption, signed URLs, integrity verification, the difference between transport and at-rest encryption for files
- Biometric authentication deep dive — CryptoObject patterns for different operations, fallback strategies, accessibility considerations
- OWASP MASVS — the Mobile Application Security Verification Standard and how to map your defenses to it for compliance audits
- Anti-debugging and anti-tampering — ptrace detection, Frida detection, integrity checks against known modifications
- OEM survival patterns — battery optimization, push notifications, foreground services across the major OEM modifications
This post is the foundation: threat model, storage, screen capture, certificate pinning, biometric binding, OEM realities. The follow-ups go deeper on specific topics. Together they should cover what a senior engineer building a banking or enterprise Android app needs to know.
Closing
Most Android security advice on the internet is generic, checklist-driven, and missing the threat model that makes any of it make sense. The framing that helps: each defense exists to counter a specific actor and a specific attack. Build with that frame, audit with that frame, and your security work becomes proportional to actual risk instead of cargo-culted ceremony.
For a banking or enterprise app: hardware-backed key storage with biometric binding, certificate pinning with rotation strategy, FLAG_SECURE on sensitive screens, server-side enforcement of everything that matters. The rest is layers that raise the cost of attack — useful, but never the load-bearing wall. The server is.
That’s the foundation. Future posts in this Security cluster will go deeper on root detection (the OEM reality that complicates every assumption above), secure file upload, and biometric flows. If you’re building a banking, fintech, healthcare, or enterprise Android app, this is the area where senior engineering matters most — and where the gap between competent and excellent shows up in real audits, real penetration tests, and real attacks.
Happy coding!
Comments (0)
Sign in to leave a comment.
No comments yet. Be the first to share your thoughts.