Mobile and IoT security

Computer Science (Cyber Security) (B.E./B.Tech) · Platform security · free study notes for exams, placements and interviews

In short

Mobile and IoT security is the practice of protecting smartphones, mobile apps and resource-constrained connected devices (and their gateways, radios and cloud back-ends) against attacks on data at rest, data in transit, the application binary, the firmware and the physical hardware. It matters because the Indian attack surface is overwhelmingly mobile - UPI, DigiLocker, net-banking, Aadhaar-based eKYC and government services run on phones - while cheap routers, CCTV cameras, smart meters and medical sensors ship with default credentials and no update path. It is examined in AICTE/CBCS electives on mobile and IoT security, in GATE CS security questions on authentication and cryptographic protocols, and in professional syllabi (CEH, CompTIA Security+, OSCP, eMAPT). Employers recruiting on it include TCS, Infosys, Wipro, HCLTech, Accenture, Deloitte, PwC, EY, KPMG, Qualys, Palo Alto, Jio, Airtel, Nokia, Ericsson, Samsung R&D, Paytm, PhonePe, Razorpay, Zoho, and product-security teams in banks and NBFCs. Typical first jobs are mobile application penetration tester, IoT/embedded security analyst, product security engineer and MDM/endpoint administrator.

Explained

The mobile platform security model

Layered defence: verified boot → hardware-backed keystore → kernel with SELinux/sandbox → signed application → app-level controls. Breaking one layer should not give the attacker the next.
Android sandbox: every app gets a distinct Linux UID; files in its private directory are inaccessible to other UIDs. Inter-app communication is only through IPC - Intents, Binder, ContentProviders, BroadcastReceivers, Services - which is exactly where authorisation bugs appear.
Android hardening: SELinux in enforcing mode (since 5.0), Verified Boot/AVB with rollback protection, Keystore and StrongBox (keys held in a tamper-resistant element, usable but not extractable), scoped storage (10+), runtime permissions (6.0+), Play Protect scanning, and Project Mainline modules updated through the Play Store without a full OTA.
Permissions: install-time (normal), runtime/dangerous (camera, location, contacts, SMS), signature (only apps signed by the same key) and special (SYSTEM_ALERT_WINDOW, accessibility, MANAGE_EXTERNAL_STORAGE). Overlay plus accessibility abuse is the standard Indian banking-trojan pattern, used to capture OTPs and overlay fake login screens.
iOS hardening: mandatory code signing, App Store review, the Secure Enclave (separate coprocessor holding the UID key and biometric templates), Data Protection classes that tie file keys to the passcode, per-app sandbox (seatbelt) profiles, App Transport Security (TLS by default), and pointer authentication on ARM64e.
App signing: Android uses APK Signature Scheme v2/v3/v4 and Play App Signing (the developer uploads an AAB; Google holds the release key). The signature guarantees the *same author*, not that the author is trustworthy.
Rooting / jailbreaking: gaining privileged access by exploiting the bootloader or kernel. It disables sandbox and keystore guarantees, so any sensitive app must detect it - but detection is only a speed bump, since Frida and Magisk hide-modules defeat naive checks.
Supply chain: third-party SDKs (ads, analytics, crash reporting) run with the host app's permissions. An app can be privacy-compliant and still leak location through an SDK; this is OWASP Mobile M2.

Mobile application vulnerabilities, testing and tooling

OWASP Mobile Top 10 (2024 list): M1 Improper Credential Usage · M2 Inadequate Supply Chain Security · M3 Insecure Authentication/Authorization · M4 Insufficient Input/Output Validation · M5 Insecure Communication · M6 Inadequate Privacy Controls · M7 Insufficient Binary Protections · M8 Security Misconfiguration · M9 Insecure Data Storage · M10 Insufficient Cryptography.
OWASP MASVS v2 groups requirements as MASVS-STORAGE, -CRYPTO, -AUTH, -NETWORK, -PLATFORM, -CODE, -RESILIENCE, -PRIVACY; the MASTG is the matching test guide, and MAS-L1/L2 plus R (resilience) are the verification levels quoted in audit reports.
Insecure storage in practice: API keys in strings.xml, tokens in SharedPreferences or plist files, PII in SQLite and WebView caches, secrets in logs, sensitive data in automatic backups (android:allowBackup="true") and in screenshots of the task switcher.
Insecure communication: no TLS, accepting all certificates in a custom TrustManager, ignoring hostname mismatch, falling back to HTTP, or trusting user-added CAs. Fix: TLS 1.2/1.3, the Network Security Configuration file, and certificate or public-key pinning with a backup pin and a planned rotation.
Authentication flaws: client-side-only checks, PINs verified in the app, JWTs with alg:none or no expiry, OTP validated locally, biometric result used as a boolean instead of releasing a key from the keystore via setUserAuthenticationRequired.
Binary protection: no obfuscation (R8/ProGuard), no anti-debug/anti-hook, no integrity check - allowing repackaging of a paid or banking app and redistribution through third-party stores.
Static analysis flow: obtain the APK/IPA → apktool to decode resources → jadx/dex2jar to read Java/Kotlin → inspect AndroidManifest.xml for exported components, debuggable, allowBackup, usesCleartextTraffic → grep for secrets → run MobSF for an automated report.
Dynamic analysis flow: rooted device or emulator → proxy traffic through Burp/mitmproxy with the CA installed as a system certificate → Frida/objection to hook and bypass root detection and SSL pinning → inspect the sandbox for files and databases → drozer for IPC and exported-component attacks.
Mobile malware families seen in India: fake banking/loan apps, SMS-stealers that forward OTPs, remote-access trojans distributed as APKs over WhatsApp, and "screen-share fraud" using legitimate remote tools - a social-engineering problem that no app hardening fully solves.

The IoT security problem and its architecture

Why IoT is different: constrained CPU, RAM and battery; long field life (10-15 years for a meter) against short vendor support; no screen or keyboard for configuration; physical accessibility; and huge homogeneous fleets, so one bug scales to millions of devices.
Reference layers: (1) perception/device - sensors, actuators, MCU; (2) network/transport - BLE, Zigbee, Wi-Fi, LoRaWAN, NB-IoT, 5G; (3) edge/gateway - protocol translation, local rules; (4) platform/cloud - broker, device registry, data store; (5) application - mobile app, dashboard, API.
OWASP IoT Top 10: weak/guessable/hardcoded passwords · insecure network services · insecure ecosystem interfaces (web/API/cloud/mobile) · lack of a secure update mechanism · insecure or outdated components · insufficient privacy protection · insecure data transfer and storage · lack of device management · insecure default settings · lack of physical hardening.
Device identity: every unit needs a unique secret - a per-device certificate (X.509) or key injected at manufacture and held in a secure element / TPM / TrustZone / PUF. A shared global key or the MAC address as a "password" is the classic design failure.
Secure boot chain: immutable ROM boot code verifies the bootloader signature → bootloader verifies the kernel/firmware → anti-rollback counter blocks downgrade to a vulnerable version. Measured boot additionally records hashes for remote attestation.
Secure OTA update: signed firmware image, version/rollback check, integrity hash, encrypted transport, A/B (dual-bank) partitions so a failed flash falls back, and a staged rollout. Absence of signing is why consumer routers and cameras stay exploitable.
Hardware attacks: UART/JTAG/SWD debug headers left populated; SPI flash desoldered and dumped with a programmer; voltage/clock glitching to skip a signature check; side-channel power or EM analysis to recover AES keys; chip decapping in well-funded labs. Countermeasures: disable debug in production fuses, encrypt flash, constant-time crypto, tamper detection, epoxy/potting.
Firmware analysis workflow: obtain the image (vendor site, OTA capture, flash dump) → binwalk to identify and extract → mount the SquashFS/JFFS2 root → look for /etc/passwd hashes, hardcoded keys, private keys, telnet/BusyBox services, .config files → disassemble binaries in Ghidra → emulate with QEMU/FirmAE to test the web interface.

IoT and radio protocol security

MQTT: publish/subscribe over TCP 1883, TLS on 8883. Risks - anonymous access enabled on the broker, wildcard subscription (#) exposing every topic, no per-topic ACL, and username/password without TLS. Secure it with TLS, client certificates, and topic-level authorisation.
CoAP: compact REST over UDP 5683, secured with DTLS on 5684 (PSK, raw public key or certificate modes); OSCORE gives object-level security that survives proxy hops. Unauthenticated CoAP is also a UDP amplification reflector.
BLE: pairing associations are Just Works (no MITM protection), Passkey Entry, Out-of-Band and Numeric Comparison; LE Secure Connections uses ECDH on P-256, while legacy pairing is breakable. Other risks - static MAC enabling tracking, characteristics readable/writable without authentication, and sniffing with Ubertooth/nRF52 dongles.
Zigbee / 802.15.4: AES-128-CCM* with a network key; the weak point is key transport during joining (the well-known default trust-centre link key) and the touchlink commissioning flaw.
LoRaWAN 1.0.x/1.1: root keys AppKey/NwkKey; OTAA (keys derived per join) is far safer than ABP (static session keys). Frame counters must be checked to block replay; 1.1 adds a join server and better rekeying.
Wi-Fi: WPA2-PSK is vulnerable to offline dictionary attack on a captured handshake; WPA3-SAE resists it, and WPS PIN should be off. Enterprise deployments should use WPA2/3-Enterprise with EAP-TLS.
Cellular IoT: NB-IoT/LTE-M inherit SIM-based mutual authentication, which is strong; the weak links move to the management API and eSIM provisioning.
Botnets: Mirai (2016) simply tried ~60 default telnet credentials on cameras and DVRs and built a fleet that drove ~1 Tbps DDoS - the canonical example that weak defaults, not exotic exploits, cause mass IoT compromise. Variants still scan Indian broadband ranges continuously.

Controls, standards and Indian law

Device-side controls: unique per-device credentials (or forced change at first use), no hardcoded secrets, minimum services exposed, firmware signing, hardware root of trust, encrypted storage of secrets, watchdog and rate limiting, and a published vulnerability-disclosure policy and support period.
Network controls: segment IoT onto a separate VLAN/SSID, deny device-to-device traffic, egress-filter to known endpoints, MUD (RFC 8520) profiles to declare expected flows, and network-based anomaly detection since agents cannot be installed on constrained nodes.
Mobile fleet controls: MDM/UEM/EMM (Intune, Workspace ONE, Scalefusion, 42Gears) enforcing passcode, encryption, OS version, remote wipe and app allow-lists; Android Enterprise work profile or iOS User Enrolment to separate corporate and personal data on BYOD; app shielding/RASP for banking apps.
Global standards: ETSI EN 303 645 (consumer IoT baseline, 13 provisions), NIST IR 8259 and SP 800-213 (federal IoT), IEC 62443 for industrial devices, ISO/IEC 27400 IoT security and privacy guidelines, ISO/IEC 27402 baseline requirements, GSMA IoT Security Guidelines, and OWASP MASVS/MASTG for apps.
Indian framework: TEC's Code of Practice for Securing Consumer Internet of Things, aligned to ETSI EN 303 645, is the national baseline; MTCTE under the Indian Telegraph (Compulsory Testing and Certification of Telecom Equipment) Rules, 2017 requires certification of notified telecom equipment, and ITSAR security requirements are tested by labs designated under the NCCS - which product categories are currently notified changes by TEC/DoT notification, so the live list must be checked before relying on it. BIS IS 17428 covers a data-privacy assurance framework for organisations.
Incident reporting: the CERT-In Directions of 28 April 2022 require reporting specified cyber incidents within 6 hours of noticing, keeping ICT logs for 180 days within India, NTP synchronisation to NIC/NPL servers, and KYC retention by VPS/cloud/VPN providers - these bind IoT and app operators alike.
Data protection: the Digital Personal Data Protection Act, 2023 with the DPDP Rules, 2025 governs personal data from phones and sensors; the core Data Fiduciary duties (notice, consent, breach intimation to the Board and affected persons, erasure) and the omission of IT Act s.43A take effect only from 13 May 2027, so until then s.43A of the IT Act, 2000 and the SPDI Rules, 2011 continue to apply. The Act's Schedule provides penalties up to ₹250 crore for failure to take reasonable security safeguards. Unauthorised access, data theft and identity misuse also attract IT Act ss. 43, 66, 66C, 66D and 72A.
Sector rules: RBI's directions on digital payments security, mobile banking and IT governance (secure SDLC, app hardening, device binding, two-factor authentication); UIDAI's Aadhaar authentication regulations and registered-device requirement for biometric capture; TRAI/DoT telecom licence security conditions. Sanchar Saathi/CEIR handles lost or cloned-IMEI handsets.

Key points

Sandbox - OS isolation of each app by UID/profile; all cross-app access must go through IPC, which must be authorised.
Hardware-backed keystore - keys usable but non-extractable; StrongBox/Secure Enclave store them in a separate secure chip.
Verified/secure boot - each stage cryptographically verifies the next, with anti-rollback to block downgrade attacks.
Runtime permissions - dangerous permissions granted at use time (Android 6+); overlay plus accessibility is the main banking-trojan abuse path.
Certificate pinning - app accepts only a known certificate or public key; must have a backup pin, else an expiry bricks the app.
Root/jailbreak detection - raises attacker cost only; Frida and Magisk bypass naive checks, so never make it the only control.
OWASP Mobile Top 10 (2024) - credentials, supply chain, auth, I/O validation, communication, privacy, binary protection, misconfiguration, storage, cryptography.
MASVS/MASTG - the verification standard and test guide; MAS-L1, MAS-L2 and MASVS-RESILIENCE are the audit levels.
Static vs dynamic analysis - apktool/jadx/MobSF read the binary; Frida/Burp/objection attack the running app.
IoT constraints - limited CPU, RAM and energy force lightweight crypto (AES-CCM, ECC, ChaCha20) and session resumption over repeated handshakes.
Unique per-device identity - a shared global key means one extraction compromises the whole fleet.
Signed OTA with A/B partitions - the single most valuable IoT control; without it, a bug is permanent.
Default credentials - the root cause of Mirai-class botnets; baseline standards now ban universal default passwords.
MQTT/CoAP - secure with TLS 8883 and DTLS/OSCORE 5684 respectively, plus per-topic/resource authorisation.
BLE Just Works - no MITM protection; use Numeric Comparison or OOB with LE Secure Connections.
LoRaWAN OTAA over ABP - fresh session keys per join and enforced frame counters stop replay.
Hardware attack surface - UART/JTAG, SPI flash dump, glitching and side channels; disable debug in production, encrypt flash.
Indian compliance stack - TEC Code of Practice for consumer IoT (ETSI EN 303 645 aligned), MTCTE/ITSAR testing for notified telecom equipment, CERT-In 6-hour reporting and 180-day logs, DPDP Act 2023 with Rules 2025 (duties from 13 May 2027; s.43A/SPDI Rules apply until then).

Formulas and examples

Key space K = N^L (N = symbols in the alphabet, L = length); Entropy H = L × log₂N bits
Expected offline cracking time t = K / (2 × R) (R = guesses per second; the 2 gives the average, half the space)
Energy per transmission E = V × I × t (joules); Charge per cycle q = I × t (mAh when I in mA, t in hours)
Battery life (hours) = Battery capacity (mAh) / Average current (mA)
Average current I_avg = Σ(I_i × t_i) / T over one duty cycle of period T
Aggregate DDoS bandwidth B = n × b (n = bots, b = per-bot uplink)
ALE = SLE × ARO (annual loss expectancy ₹; SLE = single loss expectancy ₹; ARO = events per year)
ROSI = (ALE × mitigation effectiveness − control cost) / control cost

Example 1 - PIN and passphrase strength on a handset. A 4-digit PIN gives K = 10⁴ = 10,000 combinations, H = 4 × log₂10 = 4 × 3.3219 = 13.3 bits. An offline attack at R = 5,000 guesses/s takes t = 10,000/(2 × 5,000) = 1 second. A 6-character password from 62 symbols gives K = 62⁶ = 56,800,235,584 and H = 6 × 5.9542 = 35.7 bits; at the same rate t = 56,800,235,584/10,000 = 5,680,024 s ≈ 65.7 days. On-device, hardware rate limiting is what actually saves the 4-digit PIN: with Gatekeeper/StrongBox enforcing escalating lockout delays after a few failures (and optional wipe after a set number of attempts), exhaustion is impossible - which is why extracting the key material off-device is the attacker's real goal.

Example 2 - cost of TLS on a battery-powered sensor. A node with a 1,000 mAh lithium cell sends one reading per hour: transmit 25 mA for 2 s, sleep at 5 µA otherwise.

Charge per hour (TX) = 25 mA × (2/3600) h = 0.01389 mAh; sleep ≈ 0.005 mAh → total 0.01889 mAh/h.
Life = 1,000/0.01889 = 52,938 h ≈ 6.0 years (ignoring self-discharge).

Now add a full DTLS handshake per message, costing another 5 s of radio at 25 mA = 0.03472 mAh:

Total = 0.05361 mAh/h → life = 1,000/0.05361 = 18,653 h ≈ 2.1 years, a 65% cut.

Conclusion: security is not dropped, it is re-engineered - DTLS session resumption, PSK instead of certificates, or OSCORE over CoAP keeps confidentiality while restoring most of the battery life.

Example 3 - botnet scale from default passwords. 50,000 compromised CCTV DVRs each on a 2 Mbps uplink give B = 50,000 × 2 = 100,000 Mbps = 100 Gbps - enough to saturate most enterprise links. If only 1% of a 5,000,000-unit fleet keeps the default password, that is 50,000 devices; forcing a password change at first boot removes the entire capability.

Example 4 - business case for secure boot plus per-device certificates. A vendor ships 10,000 smart locks. A firmware-tampering incident is estimated to cost ₹500 per device in recall, replacement and support → SLE = 10,000 × 500 = ₹50,00,000. ARO is judged 0.4 (once in 2.5 years) → ALE = 50,00,000 × 0.4 = ₹20,00,000/year. Signing infrastructure plus a secure element at ₹60 per unit costs about ₹6,00,000/year, and is assessed 80% effective.

ROSI = (20,00,000 × 0.8 − 6,00,000)/6,00,000 = (16,00,000 − 6,00,000)/6,00,000 = 1.67 → 167%. The control pays for itself, before counting DPDP Act exposure.

Example 5 - equivalent key sizes for constrained devices.

Security level	Symmetric	RSA modulus	ECC key	Suitability on an 8-bit/32-bit MCU
80-bit (legacy)	80 bits	1024 bits	160 bits	RSA too slow; ECC acceptable
112-bit	3DES (deprecated)	2048 bits	224 bits	ECC preferred
128-bit (today's baseline)	AES-128	3072 bits	256 bits (P-256, Curve25519)	ECC/AES-CCM standard choice
192-bit	AES-192	7680 bits	384 bits	ECC only

ECC delivers the same strength with roughly a twelfth of the key length at the 128-bit level, which is why DTLS/TLS cipher suites for IoT use ECDHE with AES-CCM-8.

Aspect	Mobile (smartphone app)	IoT (constrained device)
Compute	GHz CPU, GB of RAM	MHz MCU, KB of RAM
OS	Android/iOS with sandbox and SELinux	RTOS or stripped Linux, often no isolation
Update	Store/OTA within days	Rare, often never; needs signed A/B OTA
Identity	User account plus device attestation	Per-device certificate or PSK in a secure element
Physical access	Owner-held, screen-locked	Publicly mounted, debug ports reachable
Transport	HTTPS/TLS 1.3	DTLS, TLS-PSK, OSCORE, link-layer AES-CCM
Main failure	Insecure storage, weak auth, repackaging	Default credentials, unsigned firmware

Where it is used

Banking, fintech and payments: mobile app penetration testing, device binding, app shielding and RASP for UPI and net-banking apps in banks, PhonePe, Paytm, Razorpay; RBI-driven secure SDLC audits.
Product companies and OEMs: Samsung R&D Bengaluru/Noida, Qualcomm, Bosch, Honeywell, Tata Elxsi and L&T Technology Services build secure boot, keystore integration and ITSAR-compliant firmware for handsets, meters and automotive ECUs.
Telecom and smart metering: Jio, Airtel, Nokia and Ericsson secure NB-IoT/5G device management; smart-meter rollouts under discoms require ITSAR-tested gateways and key-management systems.
Consulting and audit: Deloitte, PwC, EY, KPMG, TCS and Wipro run mobile/IoT VAPT, ETSI EN 303 645 and IEC 62443 gap assessments, DPDP readiness and CERT-In empanelled audits.
Healthcare and wearables: infusion pumps, patient monitors and fitness bands - BLE pairing hardening, firmware signing and privacy controls on health data.
Job roles: mobile application security engineer, IoT/embedded security researcher, hardware security analyst, product security engineer, MDM/UEM administrator, CERT-In empanelled auditor, bug-bounty hunter on Indian app programmes.

Interview questions

Q: How does Android isolate one app's data from another's? A: Each app runs under its own Linux UID with a private data directory, enforced by file permissions and SELinux policy; sharing is possible only through explicit IPC such as Intents or ContentProviders.
Q: What is certificate pinning and what is its main operational risk? A: The app trusts only a specific certificate or public key instead of any CA-signed one, defeating MITM with a rogue CA; the risk is that certificate rotation or expiry breaks every installed copy, so backup pins and a remote-configurable pin set are essential.
Q: If root detection can be bypassed with Frida, why implement it? A: It raises the attacker's cost and filters out casual tampering and mass automated fraud; it must be one layer among server-side checks, attestation and anomaly detection, never the sole control.
Q: Where should an Android app store an authentication token? A: Keep it in memory where possible, otherwise encrypt it with a key generated in the hardware-backed Keystore (ideally StrongBox, bound to user authentication) - never in plain SharedPreferences, external storage or logs.
Q: Why is a 4-digit device PIN acceptable but a 4-digit password on a web service is not? A: The device enforces rate limiting and lockout in hardware, so only a handful of online guesses are possible; a web password can be attacked offline from a stolen hash at millions of guesses per second.
Q: What made the Mirai botnet effective? A: It used a short list of factory-default telnet credentials on cameras and DVRs - no exploit was needed - and the homogeneity of those fleets let a trivial attack scale to hundreds of thousands of devices.
Q: What does secure boot protect against, and what does it not? A: It stops execution of unsigned or downgraded firmware, so persistent implants fail; it does not protect against vulnerabilities in correctly signed firmware, nor against runtime memory attacks.
Q: How would you approach a black-box IoT device assessment? A: Map the ecosystem (device, radio, mobile app, cloud API), scan exposed services, sniff and attempt replay on the radio link, extract and analyse firmware via OTA capture or flash dump, probe UART/JTAG, then test the app and API - usually the weakest point is the cloud API authorisation.
Q: Why is DTLS used with CoAP instead of TLS? A: CoAP runs over UDP for low overhead on lossy constrained networks, and DTLS is the datagram variant of TLS; OSCORE is used additionally when proxies must forward messages without seeing the payload.
Q: Which BLE pairing mode is unsafe and why? A: Just Works provides no man-in-the-middle protection because there is no out-of-band confirmation of the key exchange; Numeric Comparison, Passkey Entry or OOB with LE Secure Connections should be used.
Q: What are the CERT-In 2022 directions that an IoT platform operator must follow? A: Report specified cyber incidents within six hours of noticing them, synchronise clocks to NIC/NPL NTP servers, and retain ICT system logs for 180 days within India.
Q: Which Indian law applies if a wearable vendor leaks users' health data today? A: The Digital Personal Data Protection Act, 2023 with the DPDP Rules, 2025 is the governing framework, but the Data Fiduciary duties including breach intimation commence on 13 May 2027 - until then s.43A of the IT Act, 2000 with the SPDI Rules, 2011 governs compensation for failure to protect sensitive personal data, alongside ss. 66/72A and CERT-In reporting.

Common mistakes

Treating the mobile app as a trust boundary - validating OTPs, prices, limits or entitlements on the client instead of the server.
Calling root detection, obfuscation or an SSL-pinning check a "fix" for a server-side authorisation flaw.
Confusing encoding with encryption: Base64 strings or a hardcoded AES key in the APK give zero confidentiality.
Leaving components exported in the manifest (android:exported="true", debuggable, allowBackup) and ignoring IPC and deep-link testing.
Shipping one shared symmetric key or a MAC-address-derived password across an entire IoT fleet, so one extracted key compromises all units.
Building OTA update without signature verification, version anti-rollback or a fallback partition - an update channel then becomes the attack channel.
Quoting law loosely: assuming the full DPDP Act duties are already enforceable (they commence 13 May 2027), or claiming a scheme is mandatory without checking the current TEC/DoT notification.
Omitting the energy budget from an IoT security design and then dropping encryption entirely instead of choosing PSK, session resumption or lightweight AES-CCM.