Verifying signatures at the edge

A firmware update reaches a device through the network, and networks are not trustworthy by default. TLS protects the transport layer, but TLS termination at the server does not guarantee that the artifact stored on that server is the one you built and tested. The device is the final gate. If the device does not independently verify the artifact before installing it, all upstream security controls amount to a strong lock on a house with an open window.

This post describes what the OTA-Pulse agent does at the edge: the exact sequence of steps from receiving a deployment notification to either applying the update or rejecting it.

Why edge verification matters

Consider the threat surface. An OTA server might be:

• Compromised by an attacker who substitutes malicious artifacts for legitimate ones.
• Misconfigured to serve an artifact from the wrong build channel (a development image pushed to production).
• Running outdated signing infrastructure that was revoked by your security team but not yet removed from rotation.

TLS does nothing in any of these cases. The device downloaded the artifact over an encrypted channel — from a server that is either malicious or wrong. The only defense is that the device carries a copy of the expected public key and refuses to install anything that was not signed with the corresponding private key.

The device configuration that enables this is intentionally explicit:

[security]
verify_signatures = true
reject_unsigned = true
keys_directory = /etc/soc-monitoring/signing-keys/active
max_verification_failures = 5
alert_on_failure = true
delete_on_failure = true

reject_unsigned = true means the agent will not install an artifact even if no signature file exists at all. The absence of a signature is treated the same as a bad signature.

What the agent does, step by step

When a deployment notification arrives, the OTA agent works through a fixed sequence:

Step 1: Parse the manifest. The deployment notification includes a manifest that describes the artifact — its name, version, expected size, hash algorithm, and the URL where the signature file can be retrieved. If the manifest is malformed or missing required fields, the agent rejects the deployment before downloading anything.

Step 2: Fetch the artifact. The agent downloads the firmware image to a staging area on the device’s writable partition. The staging area is separate from the active partition — the current firmware is not disturbed at this point.

Step 3: Fetch the signature. The agent downloads the detached .sig file. Signatures are stored alongside artifacts on the distribution server; the manifest points to both. If the signature fetch fails — file missing, server error, timeout — the agent aborts and reports the failure.

Step 4: Load keys. The agent scans /etc/soc-monitoring/signing-keys/active/ and loads all valid PEM-encoded public keys it finds. It supports both RSA-4096 and ECDSA-P384 keys in the same directory. The directory is mounted read-only, and the files are owned by root, so the loaded keys reflect exactly what was built into the firmware image.

Step 5: Verify. For each loaded key, the agent computes the artifact’s SHA digest and verifies the signature. The first successful verification ends the loop. If all keys fail, verification has failed.

Step 6: Apply or abort. A successful verification causes the agent to write the artifact to the update partition and schedule the reboot. A failed verification causes the agent to delete the artifact from the staging area, log the event, and report the failure to the server.

Threat model

Man-in-the-middle. An attacker intercepts the artifact in transit and substitutes a different binary. The signature was computed over the original binary, not the substituted one. The hash mismatch causes verification to fail. TLS mitigates this threat, but the signature check is an independent layer that holds even if TLS is bypassed or the certificate is wrongly trusted.

Rogue server. An attacker gains access to the OTA distribution server and replaces the artifact with a malicious image. The malicious image was not signed with the private key. The device does not have the attacker’s public key. Verification fails.

Replay attack. An attacker captures a legitimate, validly-signed artifact from an old firmware version and re-serves it to a device that has already updated. The agent includes the artifact version in its manifest validation. Deploying an older version than the device’s current version is rejected at the manifest step before signature verification even begins.

Recovery: A/B rollback on failure

If verification fails after the device has already committed to the update process, the agent does not simply halt. It triggers a rollback to the previous firmware slot.

Embedded Linux devices managed by OTA-Pulse use an A/B partition layout. At any given time, partition A is active and partition B holds either the previous known-good image or the staging area for the next update. If the verification step fails while the agent is processing a deployment to partition B, the system simply stays on partition A. The bootloader is never instructed to switch slots.

If the device has already rebooted into a new slot that is subsequently found to be invalid (rare, but possible if post-reboot health checks fail), the bootloader watchdog detects the non-confirming boot and falls back to the previous slot automatically.

The result is that verification failure is never a brick condition. The device stays on the last known-good firmware and waits for a corrected deployment.

Security lockdown after repeated failures

A single verification failure might be a transient server error or a deployment misconfiguration. Five consecutive failures on the same device are a different story.

After five failures, the agent activates a security lockdown: automatic updates are disabled, and an alert is sent to the server to notify administrators. The device remains operational on its current firmware but will not accept further updates until the lockdown is manually cleared. This prevents an attacker from repeatedly probing the device’s response to malformed artifacts.

Where to read more

For the server-side perspective — how artifacts are signed before they reach the device — see Signing every firmware artifact: how we do it.

For the security architecture overview covering key lifecycle, RBAC, and audit logging, see the Security page.

For the full signing and verification API reference, visit the Artifact signing reference in the docs.