Stability Buys Time: How Encrypted Robot Fleets Can Survive Key-Recovery Attacks

The Core Problem: Private Robots, Public Danger

Imagine a swarm of drones surveying a disaster zone, or a fleet of autonomous vehicles navigating a city, all coordinated by a remote cloud server. The cloud never sees where the robots actually are — it works entirely on encrypted data, computing the next move without ever knowing the current one. This is encrypted control, a technology that promises to keep sensitive operations truly private. The server could be hacked, the network could be tapped, and the robots' positions would remain invisible.

But there's a catch that nobody had really grappled with until now.

The encryption scheme that makes this possible — CKKS, the leading approach for handling real numbers like positions and velocities — has a built-in leak. Every time the robots decrypt a command to act, they unintentionally reveal a tiny bit of information about the secret key that protects everything. Watch enough decryptions, and an attacker can reconstruct that key. Once they do, the entire fleet is compromised.

This isn't a bug that can be patched away. The decryptions are unavoidable — the robots must decrypt to move. The leak is intrinsic to operating the loop.

A new paper from researchers at the University of Maryland models exactly how dangerous this leak is, how fast an adversary can exploit it, and crucially, what a defender can do about it. Their answer involves a game of timing, topology, and precision — and a surprising conclusion about which kind of network is most vulnerable.

---

The Science: What Was Studied

The researchers, Sai Sandeep Damera and John S. Baras, asked a question that sits at the intersection of cryptography, control theory, and game theory: if an adversary knows that a fleet of robots is running its coordination on encrypted data, how long can the encryption hold? And what does the defender need to do to keep the key safe?

They modeled a fleet of autonomous agents — drones, vehicles, or robots — that must coordinate with each other. Each agent encrypts its state (its position, velocity, and other measurements) and sends it to a cloud server. The server performs the coordination calculations entirely on these encrypted values, then sends back encrypted commands. Only when a command reaches an agent does decryption happen, and only the agent's own actuator sees the result.

The system uses CKKS encryption, a scheme designed specifically for approximate real-number computations. CKKS works by encoding real numbers into a mathematical structure where you can add and multiply while encrypted, but the decrypted result always carries a small amount of noise — the unavoidable artifact of the approximation. That noise is the leak.

The researchers analyzed this system under an Advanced Persistent Threat (APT) model: an adversary who is patient, computationally bounded, and willing to remain dormant while gathering information before striking. This is a realistic threat model for critical infrastructure or military applications, where the attacker has resources and can afford to wait.

To understand the full scope of the problem, Damera and Baras decomposed the attack into two phases, each requiring a different kind of defense. This two-phase structure is one of their central contributions, pulling game-theoretic models of persistent threats into the heart of the cryptosystem for the first time.

The first phase is purely passive. The adversary listens — tapping the encrypted traffic, watching the robots move, accumulating tiny fragments of information about the secret key from each decryption. Nothing looks anomalous; the system is behaving exactly as it should. The defender, unable to detect the eavesdropping, can only set a static defense in advance.

The second phase begins when the adversary decides to act. It manipulates the encrypted computation — perturbing ciphertexts or injecting false data — to accelerate key recovery or disrupt the fleet. The moment it does this, the manipulation disturbs the control loop, and a residual-based detector notices something is wrong. Now the defender can respond.

The transition from passive to active is therefore also the transition from invisible to detectable. It separates the two games.

The researchers studied this system using a combination of cryptographic analysis, control-theoretic stability arguments, and game theory. They implemented their framework on a nine-agent fleet across three different communication topologies — ring, torus, and complete graph — running on an OpenFHE-based pipeline to get concrete, measurable results rather than purely theoretical bounds.

---

What They Found

The Leak Is Inevitable, But Its Rate Isn't

The fundamental vulnerability comes from the structure of CKKS decryption. When the scheme decrypts a ciphertext, it returns the actual computation result plus a scaled error term: if the true value is z and the error is e with scale Δ, the decryption reveals z + e/Δ. This is by design — it's what makes CKKS work for approximate real arithmetic. But Equation 3 in the paper shows the deeper structure: the decryption also implicitly reveals a linear constraint on the secret key s, specifically c₁·s = Δ·z + e - c₀ (mod q), where c₀ and c₁ are the ciphertext components.

An adversary who knows the plaintext value z — either by observing the physical robot or by watching enough decryptions — can invert this relationship to extract information about s. One tapped ciphertext already yields a full-rank system, meaning the adversary isn't rank-limited; additional observations don't add new independent constraints, they just reduce the noise. The flooding level σ that the defender adds to each decryption determines how many noisy observations are needed to resolve the key.

This is the "flooding tradeoff" established by prior work from Li, Micciancio, and others: more noise means more observations needed to break the encryption, but also less accurate control commands.

The critical insight is that the system releases one decryption per control cycle, so the adversary accumulates leakage at exactly one observation per cycle. The recovery threshold Q_{break}(σ) — how many observations are needed to recover the key at flooding level σ — determines how long the key survives.

The Passive Phase: A Static Game

In the passive phase, the adversary is undetectable, so the defender cannot react. This reduces to a straightforward Stackelberg game: the defender commits to a flooding level σ ahead of time, and the adversary best-responds by spending its full observation budget Q up to whatever horizon it can remain passive.

The tradeoff is clean: higher σ means more noise in the decrypted commands, which degrades control accuracy, but it also means the adversary needs more observations to recover the key. The defender wants the minimum σ that keeps the key safe long enough, since excess noise hurts performance.

The researchers measured σ_{max} — the maximum flooding level the control loop can tolerate while staying stable — for each topology. This is topology-dependent because the closed-loop stability depends on the spectral properties of the communication graph. The complete graph, where every agent communicates with every other, is the most robust to noise. The ring, where each agent talks only to its immediate neighbors, is the most fragile. The torus sits in between.

The passive phase calibrates the active phase: the flooding level chosen here determines the leakage rate that the active game consumes.

The Active Phase: A Timing Game

When the adversary enters the active phase, everything changes. It can now manipulate the encrypted computation, choosing decryptions strategically to accelerate key recovery. Each manipulated observation removes more uncertainty than a passive one — the researchers model this with an amplification factor a_s > 1. But manipulation is detectable: it perturbs the control loop, and the residual-based detector flags it.

This creates a detection-evasion timing game in the FlipIt family. The defender can now use a second lever: re-keying. Rather than just adding noise, the defender can generate a fresh secret key and re-encrypt the entire fleet state, resetting the adversary's accumulated leakage to zero. The cost is computational — the whole fleet must pause, decrypt with the old key, re-encrypt with the new one, and resume — but it completely wipes the adversary's progress.

Crucially, bootstrapping — the ciphertext refresh that encrypted controllers already perform to handle unbounded horizons — is not a security lever. Bootstrapping refreshes the noise under the same key and leaves the leakage ledger intact. Only re-keying replaces the key itself.

The game now has a timing structure: how often should the defender re-key? Too frequently, and the computational cost becomes prohibitive. Too rarely, and the adversary accumulates enough leakage to recover the key before detection fires. The equilibrium is a cadence that's just aggressive enough to deny the adversary the time it needs, set by the control-theoretic fragility of the graph topology.

At the Stackelberg equilibrium, the defender re-keys on the "laziest" cadence that keeps the fleet secure. The adversary, knowing this, stays stealthy rather than aggressive, because overt manipulation triggers detection and failure. But even staying stealthy, the adversary is always making progress — the question is whether it can reach key recovery before the defender re-keys.

Topology Determines Everything

This is where the three-way tension among FHE precision, control accuracy, and re-key cadence becomes concrete. The researchers found that the topology of the communication graph sets the entire game.

In a well-connected complete graph, algebraic connectivity is high, stability margins are robust, and σ_{max} is large. The adversary needs many more observations to recover the key, Q_{break} is large, and the defender can afford a lazy re-keying cadence. The leakage ledger climbs slowly.

In a marginally-stable ring or torus, algebraic connectivity is low, stability margins are thin, and σ_{max} is small. The adversary needs far fewer observations to recover the key, Q_{break} is small, and the defender is forced to re-key vigilantly — much more frequently — to stay ahead. The leakage ledger climbs faster than the defender can reset it unless re-keying keeps pace.

The marginal graph must re-key far more often than the well-connected one. This isn't a minor operational inconvenience; it changes the equilibrium structure of the game itself.

The paper's Figure 2 shows this concretely. For a nine-agent fleet:

• The complete graph settles at a "Lazy" re-keying equilibrium — minimal computational overhead, adequate security.
• The ring requires "Moderate" re-keying — more frequent resets, higher overhead.
• The torus, sitting just above the stability threshold, demands "Vigilant" re-keying — the most aggressive cadence to keep the adversary from winning.

An "Aggressive" adversary column appears in the figure but is dominated by detection; the rational adversary stays stealthy, choosing a posture that keeps the defender guessing rather than risking the payoff from triggering the residual detector.

Precision Regimes: The Three Windows

Perhaps the most practically significant finding is that whether re-keying is needed at all depends on the FHE precision — and that this creates three distinct regimes.

At high precision, a static flooding baseline suffices. The noise floor is low enough that even a modest σ keeps the key safe for the mission horizon. The adversary never gets close to recovery, and re-keying is unnecessary overhead. The defender can commit σ = σ_{max} and let the mission run.

At low precision, static security fails outright. The noise floor is so high that the system can't tolerate enough flooding to keep the adversary at bay. The key will be recovered regardless of what the defender does statically. The mission is, in a sense, already lost before it begins.

Between these extremes lies the re-key window: a bounded regime of precision where static flooding isn't enough, but the system can tolerate enough noise to make re-keying the efficient solution. This is where the three-way tension among precision, accuracy, and cadence is most acute — and where the paper's analysis is most valuable. The efficient secure point sits in this window, where re-keying is precisely the price of precision efficiency.

The paper's Figure 2(a) maps these precision regimes for the three topologies. The floor, the window, and the ceiling shift with the graph structure, but the structure itself is universal.

---

Why This Changes Things

Encryption Was Never Enough

The encrypted control literature has largely assumed an honest-but-curious cloud: a server that follows the protocol faithfully, and whose only risk is that it might try to learn what it shouldn't. This model made sense as a starting point, and it remains relevant for many applications. But it's increasingly insufficient for high-stakes scenarios — military coordination, critical infrastructure, financial systems — where the adversary is not honest, not passive, and not bound by the protocol.

Damera and Baras push the threat model forward by asking what happens when the adversary is actively malicious and persistent. Not just curious. Not just compromised. Actively working to recover the key that protects the fleet.

This matters because encrypted control is moving from theory to deployment. NASA's work on homomorphic encryption for spacecraft, DARPA's investments in privacy-preserving machine learning, the growing interest in cloud-coordinated autonomous vehicles — all of these assume that encryption equals confidentiality. The paper shows that encryption alone doesn't equal security, not when the loop must decrypt to act.

Re-Keying Is Not Bootstrapping

One of the paper's clearest conceptual contributions is the sharp distinction between two operations that sound similar: bootstrapping and re-keying.

Encrypted controllers use bootstrapping to handle unbounded horizons. As operations accumulate, the ciphertext noise grows and the modulus shrinks. Bootstrapping refreshes a ciphertext to a high modulus, clearing the noise, so the controller can keep running. It's essential for long-duration missions.

But bootstrapping does not change the secret key. The noise refreshes; the key stays the same. An adversary who has been accumulating leakage through careful observation doesn't lose any of that progress when bootstrapping happens. The ledger doesn't reset.

Re-keying does reset the ledger. Generating a fresh key and re-encrypting the fleet state wipes the adversary's accumulated knowledge. But it also interrupts the mission — the whole fleet must pause and re-sync — and it has a computational cost that bootstrapping doesn't.

This distinction matters operationally. Teams building encrypted control systems might naturally assume that bootstrapping handles the refresh problem, that the indefinite-horizon capability of modern FHE also handles security. It doesn't. The paper shows that security requires an additional, deliberately security-motivated operation that the standard encrypted control pipeline doesn't perform.

Topology Is Security-Critical

The finding that graph topology determines re-keying cadence is both elegant and practically important.

Control theorists have long known that graph structure affects convergence speed, robustness to communication delays, and resilience to agent failures. The paper adds security to this list. A well-connected complete graph is the most secure topology — not just the most robust to noise, but the most forgiving in the timing game against an active adversary.

A ring or chain topology, common in many deployed systems for its simplicity and scalability, is the most vulnerable. Its low algebraic connectivity means thin stability margins, which means low σ_{max}, which means low Q_{break}, which means the adversary needs fewer observations to recover the key.

This creates an explicit tradeoff: a ring is easier to deploy and scale, but it demands more frequent (and costly) re-keying to maintain security. A complete graph is more robust, but it's also more expensive to deploy and less scalable. The paper gives teams a quantitative framework for navigating this tradeoff.

The Game-Theoretic Framework Transforms the Problem

By framing the problem as a two-phase FlipIt-style timing game, the paper does something that purely cryptographic or purely control-theoretic analyses couldn't: it captures the adversarial dynamic. The adversary is not a fixed budget attacker; it's a rational agent making strategic choices about when to act and how aggressively to probe. The defender's strategy — the re-keying cadence — is similarly a strategic choice, not just a parameter setting.

This framing has practical value. It tells the defender that there's an equilibrium re-keying cadence that minimizes cost while maintaining security — they don't need to over-provision. It tells the attacker that staying stealthy is rational and that aggressive moves are dominated. And it quantifies exactly how much the defender must pay (in re-keying frequency) for a given topology and precision level.

---

What's Next

Implementation and Empirical Validation

The paper instantiates its framework on OpenFHE.jl with a nine-agent fleet, measuring σ_{max} empirically for three topologies. This is a strong start, but the approach invites broader empirical validation. How do the results scale to larger fleets? To different dynamics (nonlinear systems, time-varying topologies)? To realistic communication channels with packet loss and delay?

The framework's dependence on topology raises immediate questions about robustness. What happens when the graph structure changes mid-mission, as agents move in and out of communication range? The paper focuses on static graph structure; dynamics could shift the equilibrium significantly.

The Amplification Factor

The active-phase analysis treats the amplification factor a_s — how much more leakage each active observation yields compared to a passive one — as a declared modeling parameter. This is reasonable for analysis, but the actual value depends on the specific attack. Some active attacks might yield modest amplification; others might be much more efficient at extracting key information.

Characterizing a_s for concrete attacks, perhaps in the style of the cryptanalytic work on CKKS by Liu, Pereira, and Yu, would sharpen the framework's predictions. The game-theoretic equilibrium shifts with a_s; knowing the distribution of a_s for realistic attacks would make the framework more actionable.

Partial Observation

The paper focuses primarily on full observation (κ = M), where the adversary knows the plaintext of every decryption. The partial observation case (κ < M) is identified as an extension, but the analysis of how the fleet's threshold κ/M modulates the game remains work in progress.

In practice, an adversary might observe only a subset of agents — either because it controls some agents directly, or because it can only measure some physical states. This partial information makes key recovery harder, extending Q_{break} and easing the defender's position. Quantifying this effect precisely would let defenders estimate their security margin from how much of the fleet they expect the adversary to observe.

Corrupted Agents and Multi-Player Games

The paper assumes the fleet is a cooperative defender: a single team, one objective, no internal conflicts. This is standard for the encrypted control literature, but real systems have corrupted or adversarial agents. A compromised agent that feeds false encrypted state to the cloud changes the leakage structure and potentially the equilibrium.

Corrupted agents as strategic players — cheating to extract information, refusing to re-key, launching their own attacks — are explicitly left to future work. But this is where the framework might have the most to say: a multi-player game where some agents are players in their own right, not just defenders, complicates the leakage ledger and the re-keying incentive structure in ways that pure cooperative analysis doesn't capture.

Beyond Control

The paper's final, most ambitious claim is that security for an approximate cryptosystem in a feedback loop is a dynamic game whose defender's move is the scheme's own refresh, and that this applies beyond control to any system that must repeatedly decrypt to act.

This is a large claim. The authors point to the argument structure — the two-phase game, the leakage ledger, the re-keying cadence — as general. But the instantiation is entirely on encrypted control. Whether this framework maps to other domains — encrypted signal processing, privacy-preserving machine learning inference, encrypted databases — is an open question.

The intuition is compelling: any system that must decrypt to act, and where the decryption leak is intrinsic to the approximate scheme, faces the same two-phase dynamic. The passive adversary accumulates, the active adversary manipulates, and the defender re-keys. The specifics of the leakage channel and the residual detector will vary, but the game-theoretic structure might be universal.

---

The Bottom Line

Encrypted control is real, and it's being deployed. A cloud that never sees where the robots are, computing commands entirely on encrypted state, is no longer science fiction. CKKS makes it work for real numbers, and bootstrapping makes it run indefinitely.

But CKKS leaks. Every decryption releases a tiny bit of the key, and an patient adversary will eventually recover it. The decryptions are unavoidable — the loop must actuate — so the leak is intrinsic. Encryption is necessary but not sufficient for security.

The defense is re-keying, not bootstrapping. Only generating a fresh key and re-encrypting the fleet resets the adversary's accumulated knowledge. How often you must do this depends on three things: how much FHE noise the control loop can tolerate (precision and σ_{max}), how sensitive the graph topology is to disturbance (the Laplacian's spectral gap), and how long the mission must run.

A well-connected complete graph can re-key lazily — maybe once per mission. A ring or chain, common in scalable systems, demands vigilant re-keying — far more frequently — to stay secure. The margin between lazy and vigilant is the margin between a system that pays a small security tax and one that pays a large one.

For engineers building encrypted control systems: the pipeline must include deliberate re-keying as a security operation, not just bootstrapping as a correctness operation. The frequency is a design choice, not an afterthought, and it must be set by the graph topology and the mission horizon.

For researchers: the framework opens a rich design space. How does dynamic topology shift the equilibrium? What attacks achieve the amplification factor, and how large is it? Can the defender choose topology strategically, balancing scalability against security? Can agents be partially compromised without compromising the whole fleet? These are all tractable questions, and the paper gives a rigorous starting point.

The paper's deepest insight might be this: security for systems that must reveal information to function is not a static property. It's a dynamic game played between an adversary who accumulates and a defender who resets, with timing as the contested resource. The defender's move is the cryptosystem's own refresh — not the operation that handles noise, but the operation that changes the key. And that cadence is fixed by the control loop's stability.

Stability buys time. But only if you re-key.