IoT, Embedded, and Mobile Device Security Questions

Brief comparison

• Android Keystore: stores keys (asymmetric/symmetric) non-exportable, backed by Keymaster; optional StrongBox on supported devices. Use via Jetpack Security (EncryptedSharedPreferences / MasterKey).
• iOS Keychain: stores items (data) with fine-grained accessibility attributes; keys can be backed by Secure Enclave (private keys non-exportable) and synced via iCloud Keychain if allowed.

Usage patterns

• Android: generate a MasterKey in Keystore, encrypt tokens with AES-GCM and store ciphertext in EncryptedSharedPreferences or SQLite.
• iOS: store token data directly in Keychain with kSecAttrAccessible... flags (e.g., WhenPasscodeSetThisDeviceOnly) or wrap with a Secure Enclave key.

Hardware-backed & biometrics

• Android: hardware-backed when Keymaster/StrongBox available. Biometric gating via BiometricPrompt + setUserAuthenticationRequired/userAuthenticationValidityDuration on key.
• iOS: Secure Enclave for keys; biometric access control via kSecAccessControlCreateWithFlags with .biometryCurrentSet / .devicePasscode for Touch/Face ID (LAContext).

Limitations / backups

• iOS: Keychain items marked as non-synchronizable and device-only (ThisDeviceOnly) are not backed up or synced; default Keychain items may be included in encrypted iCloud backups or iCloud Keychain sync.
• Android: Keystore keys are tied to device/user and typically not included in backups. Auto Backup may include encrypted ciphertext if you store it in files; MasterKey marked for device-only prevents restore—be explicit. StrongBox keys survive less often across factory resets.

Design for cross-platform app

• Principle: store short-lived access tokens encrypted on device; keep long-lived refresh tokens server-side when possible.
• Use platform idiomatic secure storage:
  • Android: Jetpack Security (MasterKey + EncryptedSharedPreferences).
  • iOS: Keychain with kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly and kSecAttrSynchronizable=false.
• For biometric-protected tokens: store ciphertext encrypted with a keystore/keychain key requiring user auth; prompt BiometricPrompt/LAContext to unlock before use.
• Handle backups/migration: treat device-only keys as non-backup; implement refresh flow so tokens can be reissued after restore. Provide explicit account re-authentication path.
• Fallbacks: detect hardware support; if unavailable, use OS-backed but user-passcode protected key and shorter lifetimes.

This approach balances usability, platform capabilities, and safety: non-exportable keys, biometric gating when needed, and server-side refresh to minimize exposure.

Situation & scope
Threat model for a mobile banking app that stores auth/access tokens, supports biometric login, and calls backend APIs.

Assets

• User credentials and refresh/access tokens
• Biometric auth assertion (local)
• PII / account balances / transaction history
• Session cookies, MFA secrets, device identifiers
• App binary & signing keys, TLS certs

Threat actors

• Remote attacker (MITM, API abuse)
• Local attacker (device thief, rogue app)
• Insider (backend misuse)
• OS compromise (root/jailbreak, malicious drivers)
• Supply-chain attacker (tampered SDK)

Attack vectors

• Token theft from storage or memory
• Biometric bypass or replay
• MITM / cert spoofing
• Side-loading, instrumentation, code tampering
• Jailbreak/root enabling privileged access
• Insecure session management (long-lived tokens)

Mitigations — App layer

• Store tokens in hardware-backed keystore/Secure Enclave (iOS Keychain with kSecAttrAccessControl + biometry; Android Keystore with StrongBox when available)
• Use short-lived access tokens + refresh tokens; bind refresh to device + rotate on logout
• Require biometric + device PIN (local auth as second factor) and use LocalAuthentication APIs without exporting biometrics
• Certificate pinning (public-key pinning with fallback/rollover) and strict hostname verification
• Runtime integrity: obfuscation, tamper detection, detect debugger/Frida, verify signature
• Jailbreak/root checks (multiple heuristics: protected paths, su binary, unusual permissions) but treat as signal — restrict high-risk features or require re-authentication

Mitigations — OS / platform

• Prefer Secure Enclave / StrongBox; mark keys non-exportable, require user presence for sensitive ops
• Use system-provided biometrics APIs (no custom biometric data storage)
• Minimize permissions; use Android SafetyNet / Play Integrity or iOS DeviceCheck for device attestation
• Enforce App Transport Security (iOS) / Network Security Config (Android)

Mitigations — Network / backend

• TLS 1.2+/mTLS for sensitive endpoints; enforce cipher suites
• Certificate pinning server-side rotation plan; monitor pin failures
• Backend: token binding to device fingerprint, anomaly detection, revoke on compromise
• Rate-limit, enforce strong auth flows (OAuth 2.0 best practices), server-side session expiry and refresh policies

Session & key lifecycle

• Short-lived access token, refresh token encrypted in keystore, bind refresh token to device key (sign token requests with asymmetric key in Secure Enclave)
• On logout or detected compromise: revoke tokens server-side and wipe local keystore
• Wipe sensitive data on app background/timeout

Trade-offs & residual risk

• Root/jailbreak detection can produce false positives; prefer feature restrictions over blocking.
• Pinning increases operational complexity (rollover pins).
• Hardware-backed keys not available on all devices — degrade gracefully but limit features.

This design balances usability with strong platform-backed protections appropriate for banking-grade security.