Quarantine & Anti-Rollback

Overview

Quarantine mode and anti-rollback are PhoenixSig’s defensive mechanisms against state manipulation attacks. Together, they ensure that the system cannot be tricked into reusing old states or signing with potentially compromised keys.

Quarantine Mode

When Does It Activate?

The device enters quarantine automatically when:

• Device reboot: The state was in volatile memory and may have been tampered with during shutdown
• Anomaly detection: The state counter doesn’t match expected values, or system integrity checks fail
• Suspected compromise: Application-level indicators suggest the device may have been tampered with
• Sync loss: The device’s state is inconsistent with expected progression (e.g., unexpected epoch gap)

Behavior During Quarantine

While quarantined, the device:

• Does NOT sign real payloads: Any signing request for actual messages is rejected
• Produces diagnostic signatures only: Ping/heartbeat signatures that signal “I’m alive but quarantined”
• Sets quarantine_flag = true in the device state

This prevents an attacker who has temporarily compromised the device from using the signing capability during the vulnerability window.

Exiting Quarantine

The device exits quarantine only after a successful Phoenix refresh:

1. The TEE performs VaultKey rotation with fresh entropy
2. The state seed is re-derived using the new VaultKey
3. The quarantine flag is cleared
4. Normal signing resumes with a fresh cryptographic state

This ensures that even if the device was compromised before entering quarantine, the new state is unknown to the attacker.

Anti-Rollback Protection

The Threat

A rollback attack restores the device to a previous state. If successful, the attacker can:

• Reuse epoch keys that should have been destroyed
• Produce signatures that appear to come from an earlier time period
• Bypass forward secrecy by restoring pre-evolution state

Defense: Monotonic Counters

PhoenixSig maintains strictly monotonic counters at multiple levels:

State Rejection

Before any signing operation, the system checks:

if (proposed_epoch < stored_epoch) REJECT
if (proposed_epoch == stored_epoch && proposed_counter <= stored_counter) REJECT
if (TEE_counter_available && proposed_tee_counter <= stored_tee_counter) REJECT

Any attempt to use a state with epoch or counter values that don’t advance is rejected immediately. The system will not sign, and it may enter quarantine as a precaution.

Hardware Counter Integration

When available, TEE-backed monotonic counters provide the strongest anti-rollback guarantee:

• Android: Rollback protection via verified boot and hardware-backed keystore counters
• Apple: Secure Enclave’s anti-replay counter (monotonic, tamper-resistant)
• Server (SGX): Monotonic counters via trusted platform services

Without hardware counters, anti-rollback relies on software enforcement, which protects against remote attacks but not physical hardware tampering.

Combined Defense Model