An Unforgeable Control Channel: TOFU + Asymmetric Signing

When a system can send commands to clients' machines, the most important question is: who is really authorized to send them? The intuitive answer — "a secret internal password" — is weaker than it seems. Here's why we chose something stronger.

The intuitive idea: a shared secret

The obvious idea: there's an "internal password" that only the system knows, and every command is verified against it. If something foreign tried to inject a command — it doesn't know the secret, so it fails. Sounds reasonable.

But there's a weakness here: to verify a command, the secret must be present at the verification point. If our cloud or the box is breached — the secret is readable, and the attacker forges commands at will. A shared secret (even a rotating one) breaks the moment someone sees it.

What we chose: asymmetric signing

Instead of a shared secret, we used an asymmetric key pair. The operator has a private key that never leaves them, and every command is signed with it. The agent on the box holds only the public key — which can verify a signature, but cannot forge one.

The difference is fundamental: a full breach of both our cloud and the client's box cannot forge a command, because the private key simply isn't present in either of those places. Our cloud only relays the signed command — it neither verifies nor runs anything.

Second hardening: TOFU — key pinning

But what if an attacker who breached our cloud swaps the public key for their own? Then they could sign themselves. To close this, we added TOFU (Trust On First Use): the agent pins the operator's key once, at first enrollment. On every check afterward, it verifies that the key the cloud presents is identical to the pinned one — and if not, it refuses.

Rotating the key is therefore a deliberate out-of-band action, not a silent overwrite from the cloud. An attacker who took over our cloud cannot swap the pinned key — the agent simply won't accept the swap.

Third hardening: no free shell

Even if a valid signature were somehow produced, we wanted the possible damage to be bounded. So the actions are a finite, parametric allow-list (such as reboot or restart-service) — and there is no "run arbitrary command" action. We deliberately removed every path that passes a string into a shell. Even a valid signature never reaches a root shell.

How we tested

We verified the model in behavior, not just in theory: we simulated the scenario where the cloud presents a key different from the pinned one, and confirmed that the agent indeed refuses (rc=2) and does not run. That pattern — pin → verify → refuse — is the core of our supply-chain resilience.

This article describes the trust model at the level of principle — and that's actually a strength to publish, because knowing how the defense works does not help an attacker (the private key is not exposed). There are no keys, secrets, or sensitive implementation details here.