Home / Attacks & tests / Local Data Storage Security Testing for Mobile & IoT Devices
10 test cases
Local Data Storage Security Testing for Mobile & IoT Devices
This category examines how a device proves which device it is, how it authenticates the parties that talk to it, and how the material behind those proofs is stored. Its ten tests are about identity and access rather than storage alone, and it is named here for what it actually covers.
What an attacker is trying to achieve
The attacker wants to be accepted as a legitimate device, or as a legitimate controller of one. Devices are typically deployed in large identical fleets, so a weakness in how one proves its identity is usually a weakness in how all of them do.
Test cases
10 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
IOT-IDNT-01 Device Spoofing
Objective — Determine whether an attacker can present themselves to the service or the controller as a legitimate device.
How it is tested — Establish what the device presents to identify itself — a serial number, certificate, key or derived token — and where that material is held. Determine whether it is unique per unit or shared across the fleet. Using material recovered from one device, attempt to register and operate as that device from separate hardware, and attempt to enrol a device identity that was never manufactured.
Prerequisites — Two identical devices; the firmware and any per-unit provisioning data; the ability to speak the device's protocol from a computer.
Indicators — Identity material shared across the fleet; a device impersonated from other hardware; an unmanufactured identity accepted; identity asserted rather than proven.
Coverage — CWE-290CWE-798
Depth — Manual The fleet-versus-unit distinction requires two devices; one alone cannot show it.
IOT-IDNT-02 Identity Tampering
Objective — Determine whether the identity a device asserts can be altered, allowing one unit to claim to be another.
How it is tested — Locate where identity is stored — flash, a configuration partition, a dedicated element — and attempt to modify it, both through the device's own interfaces and by writing storage directly. Establish whether the service detects a device whose asserted identity does not match previously observed characteristics, and whether two units claiming the same identity are both accepted.
Prerequisites — Two identical devices; write access to device storage; the ability to observe how the service responds to each.
Indicators — Identity modifiable through a device interface or by writing storage; a duplicated identity accepted; the service not detecting a changed identity; identity held outside a protected element.
Coverage — CWE-290CWE-1263
Depth — Manual Requires writing device storage and observing the service's reaction.
IOT-IDNT-03 Pairing Attacks
Objective — Determine whether the process binding a device to a controller or account can be observed, joined or hijacked by a third party.
How it is tested — Capture the full pairing exchange and establish what secret it establishes and how. Determine whether pairing can be initiated by anyone in range, whether the window is bounded, and whether an attacker present during pairing can derive the resulting key. Attempt to pair an already paired device to a second controller, and to force the device back into pairing mode remotely.
Prerequisites — Two devices and a controller; capture capability on the pairing medium; the ability to be present during pairing.
Indicators — A pairing key derivable from captured traffic; pairing initiable by anyone in range; an already-paired device re-pairable without authorisation; pairing mode forceable remotely.
Coverage — CWE-294CWE-323
Depth — Manual Pairing happens once and must be captured as it occurs, which requires being present for it.
IOT-IDNT-04 Session Hijacking
Objective — Determine whether an established control session can be taken over or replayed by a party who did not establish it.
How it is tested — Capture control traffic between controller and device and establish what identifies the session. Replay captured commands and establish whether they are accepted after the session ends. Determine whether the session identifier is predictable, whether commands are bound to it cryptographically, and whether the device distinguishes a command from its legitimate controller from an identical one from elsewhere.
Prerequisites — A device and controller on an isolated segment; capture and replay capability; the ability to issue commands from separate hardware.
Indicators — Commands accepted on replay; a predictable session identifier; commands not bound to the session; the device accepting commands from any source on the network.
Coverage — CWE-294CWE-384
Depth — Manual Requires capturing a real session and replaying it from elsewhere.
IOT-IDNT-05 Brute Force Resistance
Objective — Determine whether the credentials and codes protecting the device resist systematic guessing, given the small keyspaces embedded devices often use.
How it is tested — Identify every secret a caller may guess: passwords, PINs, pairing codes, and identifiers used as access tokens. Establish the size of each keyspace and whether any rate limiting, lockout or backoff applies. Attempt systematic guessing against each interface, including physical ones, and establish whether a limit on one interface is absent on another.
Prerequisites — A device on an isolated segment; the ability to issue attempts at volume; authorisation, since lockout may render the device unusable.
Indicators — A keyspace small enough to exhaust; no rate limiting or backoff; a limit present on one interface and absent on another; a counter resetting on reboot.
Coverage — V2.2.1CWE-307CWE-521
Depth — Hybrid Guessing automates; establishing the keyspace and finding the unprotected interface does not.
IOT-IDNT-06 Device Impersonation Toward the User
Objective — Determine whether an attacker can present a device that a user or controller will accept as the genuine one.
How it is tested — Establish what the controller checks before accepting a device: an identifier, a certificate, a network name, or nothing beyond proximity. Stand up a substitute presenting the same characteristics and establish whether the controller connects to it and what it will send — credentials, configuration, keys. Determine whether the user is given any means of distinguishing genuine from substitute.
Prerequisites — A controller and a genuine device for comparison; hardware able to present the same characteristics; an isolated segment.
Indicators — A controller connecting to a substitute; credentials or configuration sent to it; no verification beyond an identifier the attacker can copy; no way for the user to tell the difference.
Coverage — CWE-290CWE-940
Depth — Manual Requires standing up a convincing substitute and observing what the controller volunteers to it.
IOT-IDNT-07 Weak Identifier Generation
Objective — Determine whether the identifiers, keys and tokens the device generates are unpredictable, or derived from values an attacker can obtain or guess.
How it is tested — Collect a large sample of generated values across several devices and examine them for structure, sequence and correlation with device characteristics such as serial number, address or manufacture date. Establish from the firmware what entropy source is used, and whether it is available at the moment of first boot, when many devices generate their long-lived keys.
Prerequisites — Several devices, ideally from the same production batch; the firmware image; the ability to trigger regeneration by resetting.
Indicators — Identifiers correlating with device characteristics; sequential or structured values; entropy unavailable at first boot; the same key generated by more than one device.
Coverage — CWE-330CWE-1241
Depth — Manual Needs samples from multiple devices; a single unit cannot show a generation weakness.
IOT-IDNT-08 Insecure Cryptographic Implementation
Objective — Determine whether the cryptography protecting identity and stored data is current, correctly used, and keyed with material the attacker cannot obtain.
How it is tested — Identify from the firmware which primitives are used and how keys are derived, stored and rotated. Establish whether encryption is implemented with a bespoke or obsolete algorithm, whether initialisation values are reused, and whether ciphertext is authenticated. Determine whether the key is unique per device or shared across the fleet, and whether it resides in the same storage as the data it protects.
Prerequisites — The firmware image and a disassembler; two devices to compare key material; sample ciphertext produced by the device.
Indicators — A bespoke or obsolete algorithm; a key shared across the fleet; initialisation values reused; ciphertext unauthenticated; the key stored beside the data.
Coverage — CWE-327CWE-321
Depth — Manual Requires reading the implementation from the firmware rather than observing the protocol.
IOT-IDNT-09 Backdoor and Undocumented Accounts
Objective — Determine whether accounts or access mechanisms exist that the documentation does not describe and the operator cannot disable.
How it is tested — Enumerate every account in the firmware's authentication data and compare against the documented set. Search the binaries for hardcoded credential comparisons, maintenance modes, and support or diagnostic access reached by an undocumented sequence. Attempt each discovered mechanism on a live device, and establish whether the operator has any means of removing it.
Prerequisites — The firmware image and a disassembler; the vendor's documentation for comparison; a live device to confirm on.
Indicators — An account in the image absent from the documentation; a hardcoded credential comparison in a binary; a maintenance mode reachable by an undocumented sequence; no way to disable it.
Coverage — CWE-912CWE-798
Depth — Hybrid Account enumeration automates; finding a comparison against a constant in a binary does not.
IOT-IDNT-10 Default Credentials
Objective — Determine whether the device ships with credentials that are the same across units, published, or never required to be changed.
How it is tested — Recover the shipped credentials from the firmware and documentation and test them against a device in factory state on every interface. Establish whether the device compels a change at first use or merely recommends it, and whether the change applies to every interface or only the one used to make it. Determine whether a factory reset restores them and whether they are derived from something printed on the device.
Prerequisites — A device in factory state; the firmware image and documentation; access to every interface including any physical or local one.
Indicators — Identical credentials across units; a change not compelled at first use; a change applying to one interface only; credentials derived from a visible serial number; a reset restoring them.
Coverage — V2.5.4CWE-1392CWE-1188
Depth — Hybrid Testing known defaults automates; establishing whether a change is compelled and fleet-wide requires the device.
What we need from you
At least two identical devices, so what is shared between units can be distinguished from what is unique to one; the ability to observe and replay pairing and control traffic; the firmware image; and an isolated network segment.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- CWE-290 — Authentication Bypass by Spoofing
- CWE-798 — Use of Hard-coded Credentials
- CWE-1263 — Improper Physical Access Control
- CWE-294 — Authentication Bypass by Capture-replay
- CWE-323 — Reusing a Nonce, Key Pair in Encryption
- CWE-384 — Session Fixation
- V2.2.1 — Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.
- CWE-307 — Improper Restriction of Excessive Authentication Attempts
- CWE-521 — Weak Password Requirements
- CWE-940 — Improper Verification of Source of a Communication Channel
- CWE-330 — Use of Insufficiently Random Values
- CWE-1241 — Use of Predictable Algorithm in Random Number Generator
- CWE-327 — Use of a Broken or Risky Cryptographic Algorithm
- CWE-321 — Use of Hard-coded Cryptographic Key
- CWE-912 — Hidden Functionality
- V2.5.4 — Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").
- CWE-1392 — Use of Default Credentials
- CWE-1188 — Initialization of a Resource with an Insecure Default
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.