Threat Modelling: Smart Home IoT Camera

Scenario Explanation

A consumer buys a Wi-Fi security camera packaged with a vendor mobile app. The camera connects to the owner's home Wi-Fi and streams live video to the vendor's cloud service so the owner can view it remotely via the mobile app. The vendor provides OTA firmware updates, cloud storage for clips, and push alerts. The camera sits on the home LAN alongside laptops and phones. The owner sometimes uses public Wi-Fi to access the mobile app.

Key Behaviors

Camera performs periodic firmware checks and can download OTA updates.

Video streams are relayed through the cloud for remote viewing; local LAN viewing is supported if the app is on the same network.

Device enrollment used a factory-provisioned device certificate and a one-time activation token.

Vendor stores short-term video clips and access logs for 30 days.

Primary assets as per the scenario:

Video feed (privacy-sensitive, potential PII)

Device identity & credentials (device certs, user account creds, tokens)

Firmware & update mechanism

Cloud-stored video clips and metadata

Audit logs / telemetry

Primary threat actors:

External attacker / hacker (internet-facing attacks, MITM, exploit chains)

Botnet operators (use cameras as nodes for DDoS or scanning)

Malicious insider at vendor (access to stored video or signing keys)

Local attacker on the same LAN (pivoting from device to home PCs)

APT (if camera vendor is targeted for broad espionage, specific user is targeted for surveillance)

STRIDE Attack Vectors (Example + Mitigation)

Spoofing

What can happen: An attacker runs a rogue Wi-Fi AP in a coffee shop or performs DNS hijacking so the camera (or the mobile app) connects to the attacker’s server that imitates the vendor cloud. The attacker collects device activation tokens and credentials, or serves a fake login page to the user’s app to capture their account password.

Technical example: Camera does a DNS lookup for updates.vendor.com. DNS is poisoned and returns an attacker-controlled IP. Camera connects and sends device cert fingerprints or one-time activation tokens, which are captured.

Mitigations:

Mutual TLS (mTLS) with device certificates: Camera and cloud verify each other using X.509 certificates. Devices authenticate using a unique device certificate stored in secure storage (hardware-backed where possible).

TLS certificate pinning: Pin vendor public key or implement certificate transparency + pin rotation strategy. Ensure OTA pin updates are themselves securely signed and staged.

What is certificate pinning? Normally, when your IoT camera (or mobile app) connects to the vendor’s cloud:
The device asks the server for its TLS certificate.
The certificate is signed by a Certificate Authority (CA) trusted by the operating system.
If the certificate checks out, the device trusts the connection.
Problem:
If an attacker can trick the device into trusting a malicious certificate signed by any trusted CA (e.g., a compromised CA, or a government-issued interception cert), the device might talk to the attacker’s server or also known as spoofing!
Certificate pinning fixes this by saying: “Don’t trust all CAs. Only trust this specific certificate (or public key) for this service.”
This means:
DNS spoofing + fake certificate won’t work.
MITM proxies can’t intercept unless they have the exact pinned key.
⚠️ There is a lifecycle problem, where the cert might expire. You need to carefully solve this as well.

Secure bootstrapping / provisioning: Provision unique keys/certs at manufacturing or during secure first-run. Avoid shipping devices with identical default keys.

DNSSEC / DoH+ validation & hardening: Prefer DNS solutions that reduce risk of spoofing; combine with mTLS so even DNS manipulation fails authentication.

DoH (DNS over HTTPS) / DoT (DNS over TLS) Instead of sending DNS queries in plain UDP (easy to intercept), DoH/DoT wraps DNS traffic in encrypted tunnels
DNSSEC → guarantees the DNS record hasn’t been forged (authenticity + integrity).
DoH/DoT → guarantees the query/response can’t be intercepted or modified in transit (confidentiality + integrity).

Fail-safe behavior: on failing to validate server identity, deny sensitive actions (no auth, no firmware fetch), and log/alert the user.

Tampering

What can happen: Attacker intercepts OTA update process or replaces firmware in transit. Malicious firmware can exfiltrate video, create backdoor shells, or add the device to a botnet.

Technical example: An unauthenticated HTTP endpoint serves firmware. Attacker replaces the binary with a backdoored image; camera installs it and later provides an attacker shell.

Mitigations:

Signed firmware images: cryptographic signature verification before installation. Use asymmetric signatures (vendor private key signs; device verifies with embedded public key).

Secure Boot: root of trust in ROM/secure element ensures only signed kernels/firmware run.

Firmware rollback protection / version monotonic counters: refuse older firmware (avoid downgrade to known vulnerable versions).

Chunked signature verification & staged update: verify each chunk and final signature; include manifest metadata with hashes.

OTA over authenticated channels (mTLS): in addition to signature, transfer over authenticated, encrypted channel to prevent tampering-in-transit.

Local attestation & integrity checks: periodic runtime attestation (hash checks) and integrity sensors that report to cloud.

Hardware-backed key storage: store verification root keys in a secure element/TPM to prevent extraction.

Repudiation

What can happen: Vendor denies an insider accessed stored clips. Or logs are altered, making it impossible to prove what happened.

Repudiation = the ability for a user (or attacker, or vendor) to deny that they performed an action — and there’s no reliable way to prove otherwise.
In security, repudiation is dangerous because it creates accountability gaps: you can’t prove who did what, when.

Technical example: A malicious admin deletes or edits logs after accessing a clip; user complains but vendor's logs show nothing.

Mitigations:

Immutable, append-only audit logs: store tamper-evident logs (e.g., write-only, append-only with cryptographic chaining).

Log signing & remote attestation: sign logs with a cloud key and keep copies in multiple places.

Separation of duties & access control for logs: restrict who can view/export logs; require multi-person approvals for forensic access.

User-accessible logs / transparency: expose access events to owners (e.g., "User X viewed clip Y at time T from IP Z").

SIEM and retention policies: ingest logs into independent SIEM and retain for forensics; ensure integrity checks (HMACs) are periodically validated.

Information Disclosure

What can happen: Video streams or credentials are leaked. This could be via unencrypted streams, weak storage protections, or cloud API misconfiguration exposing links.

Technical example: Camera streams to rtmp:// unencrypted, attacker captures the stream. Or cloud backup uses public S3 objects with misconfigured ACLs exposing clips.

Mitigations:

End-to-end encryption (E2EE): encrypt media at source (camera) and decrypt only on authorized client (mobile app or owner-controlled endpoint). Cloud can store ciphertext but cannot decrypt.

TLS 1.3 everywhere + no weak ciphers: enforce modern TLS and disable TLS fallback; ensure perfect forward secrecy (PFS).

Encrypted storage at rest: server-side disk encryption plus per-object encryption keys; use customer-controlled keys for sensitive customers.

Short-lived access tokens & scoped URLs: avoid long-lived public URLs; use short-lived signed URLs for playback.

Secure key management: keys in HSM/KMS; rotate keys periodically and support revocation.

Minimal metadata storage: store minimal identifying metadata; anonymize where possible.

Credential hygiene: no default passwords, enforce password complexity, enforce MFA for user accounts, protect admin accounts via limited IP allowlists.

Network-level protections: WPA3 for device Wi-Fi ondevice; discourage weak pre-shared keys, warn users if using insecure Wi-Fi.

Denial of Service

What can happen: Botnet floods the cloud service or devices, making them unavailable. Or attacker floods the local network interface of the camera, causing missed events.

Technical example: Devices become part of Mirai like botnet and are used to launch volumetric attacks against the vendor cloud or other targets; or attacker sends repeated firmware update requests to overwhelm the update server.

Mitigations:

API rate limiting & throttling: per-device and per-IP rate limits on cloud APIs and update endpoints.

DDoS mitigation at network edge: use CDN / DDoS protection providers, autoscaling, and traffic scrubbing for cloud endpoints.

Device-side protections: limit number of concurrent connections; drop or slow suspicious traffic; implement backoff on retry.

Monitoring & anomaly detection: detect patterns of excessive load and isolate affected devices automatically.

Elevation of Privilege

What can happen: An attacker exploits a local buffer overflow in the camera firmware and gets root. From there they can pivot into the home LAN or modify firmware signing keys (if accessible).

Technical example: Vulnerable camera web UI allows command injection; attacker executes shell commands as root and installs rootkit that communicates with C2.

Mitigations:

Least privilege OS design: run services as unprivileged users; drop capabilities; use seccomp to restrict syscalls.

seccomp stands for secure computing mode.
It’s a Linux kernel feature that allows a process to restrict which system calls (syscalls) it can make.
Syscalls are the low-level requests that software makes to the Linux kernel — e.g.,
open() → open a file
socket() → create a network connection
execve() → run another program
mount() → mount a filesystem
If an attacker compromises a process, they’ll often try to use dangerous syscalls (like execve, ptrace, or mount) to escalate privileges or pivot. seccomp cuts off access to those syscalls the process should never need.

Normally an IOT camera would need
read() and write() (to read video frames, send them over network)
socket() (to handle connections)
ioctl()
It does not need:
execve() (running other binaries)
mount() (mounting filesystems)
ptrace() (debugging other processes)