Architecture Overview — Phoenix Platform Docs

Design Philosophy

PhoenixSig is built on a single principle: assume compromise will happen, and engineer recovery into the cryptographic architecture. This philosophy leads to a layered design where each layer provides a distinct security property, and the combination achieves something no single layer can provide alone.

The Three Layers

Layer 1: Phoenix Injection (Trust Foundation)

At the base of the architecture is the Phoenix Channel — the mechanism that makes Post-Compromise Security possible. Its core component is the VaultKey: a secret stored inside a Trusted Execution Environment (TEE) that is non-exportable and inaccessible to the main application processor.

The VaultKey participates in every cryptographic operation. Every key derivation, every state evolution, every context hash includes the VaultKey as an input. This is the Phoenix Injection Rule: if any operation omits VaultKey, PCS is broken.

When a Phoenix refresh occurs, the VaultKey is rotated using fresh entropy from within the TEE. Since the attacker cannot access the TEE, they cannot predict the new VaultKey, and therefore cannot predict any future state.

Layer 2: DyLWE State Core (Forward Security)

The middle layer is the DyLWE (Dynamic Learning With Rounding) state core. This is a deterministic function that evolves the system state with each operation.

DyLWE operates on post-quantum hardness assumptions, providing three critical properties:

Determinism: No dependency on external randomness (auditable, testable)
One-wayness: Cannot recover previous state from current state (forward secrecy)
Quantum resistance: Based on lattice problems believed hard for quantum computers

The state consists of a seed value, an epoch counter, an operation counter, and a quarantine flag. After each signing operation, the seed evolves irreversibly and the old seed is erased.

Key Insight

DyLWE provides forward secrecy but not PCS on its own. A deterministic system can be predicted by an attacker who captures the current state. PCS requires Phoenix injection (Layer 1) to break this predictability.

Layer 3: PQC Signing Engine (Signature Production)

The top layer is a standard post-quantum signature algorithm — either ML-DSA-65 (Dilithium, fast, small signatures) or SLH-DSA (SPHINCS+, hash-based, conservative).

PhoenixSig treats the PQC algorithm as a black box. It provides an ephemeral key pair, the PQC engine signs the message, and the ephemeral key is destroyed. This means PhoenixSig is algorithm-agnostic: if a new PQC standard emerges, only the top layer needs to change.

Data Flow: Signing

1. Context derivation Bind epoch, counter, message, and policy into a unique context 2. Epoch key derivation Derive ephemeral signing key pair from current state + VaultKey 3. Sign PQC engine signs the message with the ephemeral key 4. State evolution Advance internal state irreversibly via VaultKey-dependent evolution // old state is securely erased 5. Output Return signature bundle with Merkle authentication path

Data Flow: Verification

1. Extract epoch public key and Merkle path from signature bundle 2. Verify Merkle path: Confirm the epoch key belongs to the device's committed key tree 3. Verify PQC signature: Standard PQC verification using the epoch public key 4. Both pass → signature is valid

Data Flow: Phoenix Refresh (Recovery)

1. VaultKey rotated with fresh entropy inside TEE 2. All future key derivations produce completely different keys 3. All future state evolutions follow a different trajectory 4. Attacker’s state snapshot is now cryptographically useless

Why Three Layers?

Layer removed	Consequence
Without Phoenix injection	No PCS. Attacker with state can predict all future keys.
Without DyLWE core	No forward secrecy. No deterministic auditability. RNG dependency.
Without PQC engine	No actual signature. No quantum resistance.

Each layer is necessary. No two layers are sufficient without the third.

← Back to Documentation Request Demo