IoT Security Deep Dive — Secure Boot, TPM, TLS for IoT, OTA Security, and Tamper Protection

IoT security goes beyond TLS and passwords — it covers the entire device lifecycle from manufacturing to decommissioning. This deep dive covers hardware roots of trust, secure boot chains, firmware integrity, TLS optimisation for constrained devices, OTA update signing, IoT SAFE SIM-based security, and physical tamper protection.

In this tutorial, you’ll learn how to design a defence-in-depth security architecture for IoT devices that protects against remote attackers and physical tampering. Every connected device is a potential entry point into your network — Mirai (2016) used default passwords to recruit 600,000 devices. Today’s attacks target firmware, OTA channels, and hardware debug interfaces.

A medical IoT device monitoring patient vitals must resist tampering, ensure firmware integrity through secure boot, encrypt all data with TLS 1.3, authenticate to the cloud with X.509 certificates stored in a TPM, and survive physical attacks with tamper sensors and epoxy potting.

Defence-in-Depth Architecture

    graph TD
    subgraph "Hardware Security"
        TPM[TPM / Secure Element] --> SB[Secure Boot ROM]
        SB --> SB2[Bootloader Signature Verify]
        SB2 --> FW[Firmware]
    end
    subgraph "Communication Security"
        FW --> TLS[TLS 1.3 / DTLS 1.3]
        TLS --> Auth[Device Auth<br/>X.509 Certs]
        Auth --> Cloud[Cloud]
    end
    subgraph "Lifecycle Security"
        OTA[OTA Update] --> Sig[Signature Verify]
        Sig --> FW2[New Firmware]
        Audit[Audit Log] --> Cloud
    end
    style TPM fill:#e74c3c,color:#fff
    style SB fill:#e67e22,color:#fff
    style TLS fill:#27ae60,color:#fff
    style OTA fill:#3498db,color:#fff
  

Secure Boot Chain

Secure boot ensures only signed firmware executes on the device. The chain starts in immutable hardware (boot ROM) and verifies each stage before handing over control.

# Sign firmware binary for ESP32 secure boot
esptool.py --chip esp32 image_info firmware.bin

# Generate signing key
openssl ecparam -genkey -name prime256v1 -out secure_boot_key.pem

# Sign firmware
espsecure.py sign_data --keyfile secure_boot_key.pem --output firmware_signed.bin firmware.bin

X.509 Device Authentication

Every device needs a unique identity. X.509 certificates issued by a device CA provide strong authentication without shared secrets.

# Device certificate generation (CA side)
from cryptography import x509
from cryptography.x509.oid import NameOID
from cryptography.hazmat.primitives import hashes, serialization
import datetime

def generate_device_cert(device_id: str, ca_key, ca_cert):
    key = ec.generate_private_key(ec.SECP256R1)
    csr = x509.CertificateSigningRequestBuilder().subject_name(
        x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, device_id)])
    ).sign(key, hashes.SHA256())

    cert = x509.CertificateBuilder().subject_name(
        csr.subject
    ).issuer_name(ca_cert.subject).public_key(
        csr.public_key()
    ).serial_number(
        x509.random_serial_number()
    ).not_valid_before(
        datetime.datetime.now(datetime.timezone.utc)
    ).not_valid_after(
        datetime.datetime.now(datetime.timezone.utc) + datetime.timedelta(days=3650)
    ).sign(ca_key, hashes.SHA256())

    return cert, key

TLS for Constrained Devices

TLS 1.3 reduces handshake to one round trip (vs two in TLS 1.2) and removes weak ciphers. For ultra-constrained devices, use DTLS 1.3 over UDP or session resumption.

// ESP32 secure WiFiClient with TLS 1.3
#include <WiFiClientSecure.h>

WiFiClientSecure client;

void setup() {
    client.setCACert(ca_pem);         // Root CA
    client.setCertificate(client_pem); // Device cert
    client.setPrivateKey(key_pem);    // Private key
    client.setSSLVersion(0x0304);     // TLS 1.3 = 0x0304
}

OTA Update Security

Unsigned OTA updates are the #1 vector for firmware attacks. Sign every update and verify before installing.

# Secure OTA manifest signing
import hashlib, hmac, json

OTA_KEY = hmac.HMAC(b"device-specific-key", b"ota_signing", hashlib.sha256)

def sign_ota_manifest(version: str, firmware_hash: str, url: str) -> str:
    payload = f"{version}:{firmware_hash}:{url}"
    signature = OTA_KEY.copy()
    signature.update(payload.encode())
    manifest = {
        "version": version,
        "hash": firmware_hash,
        "hash_algorithm": "sha256",
        "url": url,
        "signature": signature.hexdigest(),
        "signing_algorithm": "hmac-sha256"
    }
    return json.dumps(manifest)

# Device-side verification
def verify_ota_update(manifest_json: str) -> bool:
    manifest = json.loads(manifest_json)
    payload = f"{manifest['version']}:{manifest['hash']}:{manifest['url']}"
    computed = OTA_KEY.copy()
    computed.update(payload.encode())
    return hmac.compare_digest(computed.hexdigest(), manifest['signature'])

IoT SAFE — SIM-Based Authentication

IoT SAFE (SIM Applet For Secure End-to-End Communication) stores credentials in the SIM card — the most widely deployed secure element globally. The private key never leaves the SIM, and authentication happens on the SIM’s secure processor.

Physical Tamper Protection

Common Mistakes

1. Shipping devices with debug interfaces enabled: UART and JTAG expose full device access. Blow eFuses in production to permanently disable them.
2. Hardcoded credentials in firmware: Hardcoded API keys and passwords are extracted via static analysis. Use per-device secrets in secure storage.
3. No revocation mechanism: When a device cert is compromised, there must be a way to revoke it. Implement OCSP or CRL distribution.
4. Ignoring side-channel attacks: Power analysis and EM radiation leak cryptographic keys. Use constant-time operations and shields.
5. Using TLS 1.2 or older: TLS 1.3 eliminates weak ciphers and reduces handshake overhead. Constrained devices have no excuse to stay on 1.2.

Practice Questions

1. What is a hardware root of trust? An immutable component (boot ROM, TPM, secure element) that anchors the device’s trust chain. All cryptographic verification traces back to it.

2. How does secure boot prevent persistent malware? Each boot stage verifies the next stage’s signature. If firmware is modified, the signature check fails and the device refuses to boot.

3. What is IoT SAFE and how does it work? A GSMA standard that uses the SIM card as a secure element for IoT. Credentials are stored and processed on the SIM’s secure processor.

4. Why is TLS 1.3 better than 1.2 for IoT? One-round-trip handshake (vs two), fewer cipher options, removal of weak algorithms, and 0-RTT for recurring connections.

5. How do you revoke a compromised device certificate? Maintain a Certificate Revocation List (CRL) or use OCSP stapling. The cloud checks revocation status during TLS handshake.

Challenge

Design a complete secure boot chain for a custom ESP32 board: generate device certificates, configure eFuses for secure boot, sign firmware, implement OTA verification, and test a rollback attack.

FAQ

Cross-References

• IoT Security
• IoT Overview
• ESP32
• MQTT
• Industrial IoT