Mobile, Desktop, Embedded, and IoT Security

Obfuscation raises reverse-engineering cost but is not a substitute for secret management or server-side enforcement.

16.1 Mobile applications

Assume client-side code and local storage can be inspected on a compromised or user-controlled device.

Do not embed long-term service secrets in an app binary.

Use platform-provided secure storage for sensitive tokens where available.

Enforce authorization on the server.

Validate deep links and intent handling.

Protect WebViews and avoid unsafe JavaScript bridges.

Minimize permissions and data collection.

Protect local databases and backups according to sensitivity.

Handle screenshots, clipboard, notifications, and logs according to threat model.

Test certificate validation and network-security configuration.

Obfuscation raises reverse-engineering cost but is not a substitute for secret management or server-side enforcement.

16.2 Desktop applications

Validate IPC and plugin boundaries.

Protect update channels and verify update signatures.

Use least-privilege installation and runtime permissions.

Protect local credentials and configuration.

Avoid unsafe DLL/library search paths.

Harden auto-update and rollback mechanisms.

Do not trust local state for server-side authorization.

16.3 Embedded and IoT systems

Establish secure boot and chain of trust where supported.

Protect firmware signing keys.

Verify firmware updates before installation.

Support safe rollback protection where required.

Use unique device identities and avoid shared default passwords.

Disable debug interfaces in production or control access.

Minimize exposed services and privileges.

Protect secrets in storage and during provisioning.

Plan secure decommissioning and credential revocation.

Consider physical access, fault injection, debug ports, and side channels according to risk.

Design for long support lifetimes and patch delivery.

16.4 Firmware update design

A secure update flow should verify authenticity and integrity before installation, validate compatibility and version policy, use atomic or recoverable updates, handle power loss, and record status safely. A signature proves the update was signed by a trusted key; it does not guarantee the update is bug-free.

Verify before install: signature and anti-rollback Output (Python 3.10.4 on Ubuntu 22.04 (WSL2) with cryptography 3.4.8):

The version is signed together with the image, so it cannot be lowered without invalidating the signature, and the device refuses anything not newer than what it runs. A real update also needs an A/B or recovery partition so a power cut mid-install leaves a bootable image.

Text equivalent: the device verifies the signature and the version policy before writing anything, writes to the inactive slot, boots it, and only marks it good after a health check — otherwise it falls back to the previous slot.

from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
from cryptography.exceptions import InvalidSignature

signing_key = Ed25519PrivateKey.generate()       # in reality: kept offline / in an HSM
device_public_key = signing_key.public_key()     # provisioned into the device

def build_update(version: int, image: bytes):
    manifest = version.to_bytes(4, "big") + image
    return version, image, signing_key.sign(manifest)

def install(update, installed_version: int) -> str:
    version, image, signature = update
    try:
        device_public_key.verify(signature, version.to_bytes(4, "big") + image)
    except InvalidSignature:
        return "rejected: signature check failed"
    if version <= installed_version:
        return f"rejected: version {version} is not newer than {installed_version}"
    return f"installed version {version}"

good = build_update(8, b"firmware v8")
print(install(good, installed_version=7))
print(install(build_update(6, b"firmware v6"), installed_version=7))
version, image, signature = good
print(install((version, image + b"!", signature), installed_version=7))

installed version 8
rejected: version 6 is not newer than 7
rejected: signature check failed

flowchart TD
  DL[Download update] --> SIG{Signature valid?}
  SIG -->|no| REJ[Reject and report]
  SIG -->|yes| VER{Newer than installed?}
  VER -->|no| REJ
  VER -->|yes| WR[Write to inactive slot]
  WR --> BOOT[Boot new slot]
  BOOT --> HC{Health check passes?}
  HC -->|yes| COMMIT[Mark slot good]
  HC -->|no| RB[Fall back to previous slot]

16.5 Secure boot and measured boot

Secure boot verifies that boot stages are authorized before execution. Measured boot records measurements for later attestation. These mechanisms have different goals and need a well-managed root of trust, protected keys, recovery procedures, and update policy.

16.6 Automotive and safety-related systems

Security and functional safety are related but distinct disciplines. Consider secure diagnostics, authenticated update paths, ECU communication trust, key provisioning, debug access, network segmentation, replay protection, and incident response. Safety impact, timing constraints, lifecycle, and applicable industry standards must be handled by qualified teams and domain-specific processes.

16.7 IoT protocols

For MQTT, CoAP, BLE, Wi-Fi, and custom protocols:

Authenticate devices and brokers/servers.

Authorize topics, methods, and operations.

Use transport protection where supported.

Protect against replay and downgrade.

Limit message size, frequency, and parser complexity.

Secure provisioning, credential rotation, and device retirement.

Avoid transmitting sensitive telemetry unnecessarily.

Exercise

Create a secure firmware-update threat model covering signing keys, device identity, interrupted updates, downgrade attempts, debug access, and end-of-life devices.

Quiz

? An app binary contains a long-term API secret, obfuscated. Is that acceptable?
- Yes — obfuscation hides it. :: Obfuscation raises cost but does not keep secrets.
+ No — assume anything in the client can be extracted; keep long-term secrets on the server. :: Server-side enforcement is required.
- Yes, if the app is only on official app stores. :: Store distribution does not protect embedded secrets.
- Only for iOS. :: Same on every platform.

? What does a valid firmware signature prove?
+ The update was signed by a key the device trusts and was not altered. :: That is authenticity and integrity.
- The update has no bugs. :: Signed updates can still be buggy.
- The update is newer. :: Version policy must be checked separately — see the anti-rollback example.
- The signing key is still secret. :: Key protection is a separate concern.

? Which practices fit IoT devices? (select all that apply)
+ Unique per-device credentials :: No shared default passwords.
+ Disable or control debug interfaces in production :: Debug ports are a common entry point.
+ A plan for credential revocation at end of life :: Retired devices should not keep access.
- One firmware signing key copied to every 
…