Recommended SOC Deployments
Raspberry Pi 5 + Zymbit SCM
A bare Pi 5 running a sensor is a device whose entire security model is the lock on the cupboard door. Pull the card, mount it on a laptop, read every credential the sensor was holding. Adding a Zymbit Secure Compute Module changes that: an independent HSM holds the keys, watches its own tamper sensors, and encrypts the filesystem without trusting the Pi to be honest about its state. That is the difference between an appliance you can deploy somewhere you do not control and one you cannot. It costs more than the Pi it protects, ties up GPIO, and adds a second component that can fail on its own — which is why it belongs on the sensor holding credentials and not on all twelve boards.
Under the Hood Architecture
Hardware Cryptography
The BCM2712 accelerates AES, and with the kernel crypto API driving it, LUKS2 full-disk encryption stops competing with the sensor for CPU. Confirm it is actually engaged rather than assuming — a misconfigured stack falls back to the software path silently, and the only symptom is a sensor that drops packets under load months later.
Secure Boot & OTP
Secure boot rests on one-time-programmable memory. Setting revoke_devkey=1 locks the SoC into signed-boot mode permanently, so nobody swaps in their own OS image. Read "permanently" literally: the fuse burns once, there is no recovery path, and losing the signing key turns the board into a paperweight. Prove the whole pipeline on a sacrificial board first.
Real-World Attack Surface
Bootloader Flashing & SPI Extraction
Without the OTP fuse burned, anyone holding the board can dump the EEPROM with a clip and a cheap programmer, then flash a bootloader that loads whatever they like. The board comes back up looking entirely normal, which is the problem — nothing in your monitoring distinguishes a tampered sensor from a healthy one.
GPIO Pin Hijacking
The 40-pin header is an unauthenticated console. UART gives a serial login prompt, I²C and SPI give a path to whatever is on those buses, and none of it requires opening a case that was probably never locked. Every deployment guide tells you to enable the serial console for debugging; almost none tell you to disable it before the board leaves your desk.
Mandatory Hardening Baseline
- Read-only root: mount the root filesystem read-only with tmpfs over the volatile directories. This is as much about uptime as security — a logging sensor writes a card to death in months, and a card going read-only under you leaves a board that still answers pings while quietly recording nothing.
- OTP secure boot: write your public key hash into EEPROM and enforce signed boot. Do this last, after the image is final and the signing key is backed up somewhere you will still have access to in three years.
- Physical pin protection: disable the serial console, then remove or block unused GPIO headers and seal the unit in a tamper-evident enclosure. Accept the trade — you are also removing your own debugging access, so anything you cannot diagnose over the network becomes a site visit.
Security Pros & Cons
| Architecture | Security Pros | Security Cons |
|---|---|---|
| BCM2712 AES extensions | Makes LUKS2 and VPN throughput viable on a sensor | Needs the kernel crypto path configured — falls back to software silently |
| OTP secure boot | Signed boot blocks an attacker swapping the OS image | Burned once; a lost signing key bricks the board with no recovery |
| Zymbit SCM | Independent HSM with its own tamper sensors, keys never on the Pi | Consumes GPIO and costs more than the board it protects |
