Phoenix Injection & PCS

Overview

Phoenix injection is the mechanism that provides Post-Compromise Security (PCS) — the ability for PhoenixSig to recover from full state compromise automatically. It is the single most important architectural component and the one that distinguishes PhoenixSig from all other signature systems.

The PCS Requirement

Post-Compromise Security means: if an attacker captures the complete device state at time t, there exists a future time t + Δ after which the attacker can no longer forge signatures, even if they retain the captured state.

This requires something that no deterministic evolution can provide alone: new entropy that the attacker cannot access or predict.

VaultKey: The Trust Anchor

The VaultKey is a cryptographic secret stored inside a Trusted Execution Environment (TEE):

PropertyRequirement
StorageInside TEE only (Android Keystore, Secure Enclave, SGX enclave)
ExportabilityNon-exportable. Cannot be read by any software outside the TEE.
OperationsCan be used for key derivation and HMAC operations inside the TEE boundary.
RefreshCan be rotated with new entropy generated within the TEE.

The VaultKey is not static. It is rotated during every Phoenix refresh, mixing in fresh TEE-generated entropy.

The Phoenix Injection Rule

Invariant #1 (Non-Negotiable)

Every hash, KDF, PRF, and state evolution operation in PhoenixSig MUST include the current VaultKey as an input.

If any operation omits VaultKey, that operation’s output becomes predictable to an attacker who captured the state before a refresh. PCS breaks.

This rule applies to every cryptographic operation in PhoenixSig: state evolution, epoch key derivation, and context computation all incorporate the VaultKey. No operation may bypass it.

Phoenix Refresh Protocol

The refresh process runs entirely inside the TEE. The device generates fresh entropy via the hardware RNG, mixes it with the existing VaultKey to produce a new VaultKey, and securely erases the old one. The specific construction ensures that no external observer — including software running on the same device — can predict the new key material.

After refresh:

  • All future key derivations produce completely different epoch keys
  • All future state evolutions follow a different trajectory
  • Any state snapshot from before the refresh is cryptographically useless

PCS Security Analysis

Attacker Model

At time t0, the attacker obtains:

  • Complete RAM contents (including all internal state variables)
  • Complete persistent storage
  • All application-level secrets

The attacker does not obtain the VaultKey (it’s inside the TEE and non-exportable).

Recovery Timeline

t0: Attacker captures full state Attacker can forge signatures using captured state t0 → t1: Compromise window Attacker produces forgeries (bounded by epoch policy) t1: Phoenix refresh occurs VaultKey rotated with fresh TEE entropy All future keys diverge from attacker’s predictions t1+: System recovered Attacker’s snapshot produces wrong keys Forged signatures fail verification

What PCS Does NOT Cover

PCS has explicit boundaries:

  • TEE compromise: If the attacker extracts the VaultKey from the TEE hardware (physical attack), PCS degrades to forward secrecy only
  • Persistent TEE access: If the attacker maintains ongoing access to the TEE, they see each new VaultKey and PCS cannot hold
  • Pre-refresh window: Between compromise and refresh, the attacker can forge. This window is bounded by refresh policy (configurable: minutes to hours)

Refresh Policy Configuration

Phoenix refresh can be triggered by multiple conditions:

  • Time-based: Automatic refresh every N minutes/hours
  • Operation-based: Refresh after N signing operations
  • Event-based: Refresh on device reboot, network reconnection, or anomaly detection
  • Manual: Explicit refresh triggered by application or administrator

The refresh interval directly controls the maximum compromise window. Shorter intervals mean faster recovery but more TEE operations. Typical configurations range from 15 minutes (high-security) to 24 hours (low-power IoT).


← Back to Documentation Request Demo