Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Once you have more than one device in the field, the very first hard problem is identity: how does the backend know which sensor sent which reading, that the device is who it claims to be, and that you can revoke a specific compromised unit without burning the whole fleet? IoT identity is layered — a MAC address (hardware), an IP address (network session), a device UUID (application-level), and ideally a per-device X.509 certificate signed by your CA (cryptographic). Each layer answers a different question, and any one of them being missing or weak is enough to compromise the whole fleet.
The four addressing layers, what they identify, and what attacks each defends against.
ifconfig (macOS/Linux) or ipconfig /all (Windows). Find your Wi-Fi adapter's MAC. Now change it for one session (macOS: sudo ifconfig en0 ether aa:bb:cc:dd:ee:ff). Reflect on how meaningful 'MAC-based access control' really is.openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes. Inspect it with openssl x509 -in cert.pem -text -noout. Identify the public key, the issuer, and the validity window.Use these three in order. Each builds on the one before.
In one paragraph, explain why an IP address is not a useful identity for an IoT device, and what a 'device certificate' adds over a simple UUID.
Walk me through what happens, cryptographically, when a device with a per-unit X.509 cert connects to AWS IoT Core for the first time — specifically how the broker verifies the cert.
Given a fleet of 100,000 sensors where one unit was found to be cloned (private key extracted via side-channel attack), how would you revoke that single unit without disrupting service to the other 99,999, and what would you change about provisioning to prevent the next attack?
LAYER 1 — MAC ADDRESS (link layer, 48 bits, hardware)
Format aa:bb:cc:dd:ee:ff
Scope LAN only — never appears on the public internet
Identity The radio chip on this specific board.
Trust Very low. MACs are trivially spoofable in software. Useful for
local-network filtering, useless for authentication.
LAYER 2 — IP ADDRESS (network layer)
Format IPv4: 192.168.1.42 | IPv6: 2001:db8::1
Scope Local network or global (depending on NAT, routing).
Identity The current network endpoint. Changes when device moves networks.
Trust None — IPs are session-level. Don't use as an identity.
LAYER 3 — DEVICE UUID / SERIAL NUMBER (application layer)
Format "DEV-A7F3-001492" or UUIDv4
Scope Embedded in firmware or NVS; survives reboots and moves.
Identity The "name" your backend uses for this unit.
Trust Low — a UUID is just a string. Anyone who reads firmware can
extract it. Useful for routing; not for authentication.
LAYER 4 — DEVICE CERTIFICATE (cryptographic, X.509)
Format a public key + signed claim from your private CA
Scope Cryptographic identity. Verifiable by your backend.
Identity "This is the only device on earth with the matching private key."
Trust High — assuming the private key stays in a secure element (ATECC608,
ESP32 secure boot, NXP EdgeLock SE050) and never leaves the chip.
PROVISIONING IN PRACTICE
────────────────────────
At manufacture:
1. Each board generates a key pair inside its secure element (private key never leaves).
2. Public key is sent to your CA, which issues a per-device cert signed by your CA root.
3. Cert is installed back on the device alongside its UUID.
In the field:
4. Device connects to broker over mTLS. Broker checks cert chain against CA root.
5. Broker maps cert serial → UUID → tenant → permissions.
6. To revoke: add cert serial to revocation list (CRL or OCSP). Done.