PhoenixSig Threat Model

1. Adversary Model

PhoenixSig is designed to resist the following adversary classes, ordered by increasing capability:

Adversary Class	Capabilities	PhoenixSig Response
Remote Software Attacker	RCE on application processor, RAM access, file system read/write	Full PCS recovery after Phoenix refresh
Insider Threat	Authorized access to device, may extract application-level secrets	VaultKey in TEE — non-exportable, insider cannot extract
Supply Chain Attacker	May compromise firmware, inject backdoors in software updates	TEE attestation detects tampered firmware; quarantine mode activated
Quantum Adversary (Future)	Access to cryptographically relevant quantum computer	ML-DSA/SLH-DSA backends — NIST PQC standards
Physical Device Capture	Full hardware access, TEE probing, side-channel attacks	Partially mitigated — see Section 5

---

2. Attack Surfaces

2.1 Application Layer

The primary attack surface. An adversary with remote code execution can read the current state (sigma, epoch, counter) from memory. PhoenixSig's response: Even with full state capture, the attacker cannot forge future signatures after a Phoenix refresh, because VaultKey is isolated in the TEE and cannot be read from the application processor.

2.2 State Rollback

An attacker may attempt to restore a previous device state to reuse old signing keys. PhoenixSig's response: Monotonic epoch and counter enforcement. Verifiers reject signatures from stale epochs. Hardware-backed counters (where available) prevent OS-level rollback.

2.3 RNG Manipulation

Compromised or weak random number generators could make key derivation predictable. PhoenixSig's response: DyLWE core is deterministic — it does not depend on OS RNG. Entropy comes exclusively from VaultKey (TEE-anchored) and the current state, both of which are outside attacker control.

2.4 Side-Channel Attacks

Timing, power analysis, or electromagnetic emanation attacks against the signing operation. PhoenixSig's response: Delegated to the PQC implementation (ML-DSA/SLH-DSA) which must use constant-time implementations. TEE execution provides an additional isolation boundary.

2.5 Merkle Tree Manipulation

An attacker may attempt to forge Merkle authentication paths. PhoenixSig's response: The Merkle root (RootPK) is published and committed at enrollment time. Forging a valid path requires finding a preimage of the hash function — computationally infeasible under standard assumptions.

---

3. Security Assumptions

Assumption	Supports	If Violated
TEE isolates VaultKey correctly	PCS	PCS degrades to forward security only
HKDF behaves as random oracle	All properties	State evolution becomes predictable
Module-LWR is computationally hard	Forward security	Past states may be recoverable
ML-DSA/SLH-DSA is unforgeable	Signature validity	Signatures can be forged regardless of PCS
Attacker access is temporary	PCS recovery	Persistent access = persistent compromise

---

4. PCS Boundary Conditions

4.1 The Compromise Window

Between the moment of compromise (t₁) and the first Phoenix refresh (t₂), the attacker can forge signatures. This window is the fundamental limitation of PCS — the system cannot retroactively invalidate the compromise, only ensure recovery after refresh.

Minimizing this window is an operational concern: automatic periodic refresh, anomaly-triggered refresh, and quarantine-on-reboot all reduce the exposure period.

4.2 What PCS Cannot Do

• Prevent the initial compromise itself
• Retroactively invalidate signatures issued during the compromise window
• Protect against persistent, ongoing TEE compromise
• Replace physical security for high-value hardware

---

5. Residual Risks

These risks remain after all PhoenixSig mitigations are applied:

Risk	Severity	Mitigation Strategy
TEE hardware vulnerability (e.g., Spectre-class)	High	Monitor TEE vendor advisories; firmware update policy
Compromise window forgery	Medium	Minimize refresh interval; anomaly detection
Merkle tree exhaustion	Low	Tree re-enrollment protocol; capacity planning
Implementation bugs	Medium	Third-party audit; open-source core components

---