01 //
Protocol_
Design
FACTS
Factor-based Attestation & Credential Transport System
Cloud-native hosts often bootstrap identity using static secrets, a practice that creates a pervasive threat of undetected runtime compromise. Sophisticated solutions are fragmented, and still force a painful trade-off: operational stability or robust security. This challenge is exacerbated when working with cost-optimized virtual machines, deliberately lacking a hardware root of trust or provider-signed metadata. Simply put, risks compound catastrophically at scale.
$P(\text{compromise}) = 1 - (1 - p)^N$
where $p$ is the per-workload risk of credential exfiltration via logs, memory dumps, or prompt injection. At the scale of modern agentic AI, $P \approx 1$ becomes an architectural inevitability. FACTS works differently; keys are a product of authentication, in contrast to key agreement that requires separate authentication altogether. Identity emerges only when needed, then vanishes.
FACTS Protocol Suite
CFA (Day 1)
Composite Factor Attestation — A three-phase ceremony creating a "Blind Verifier" that validates identity without possessing the secrets to forge it.
TELS (Day 2)
Time-bound Ephemeral Liveness Signals — A forward-chaining ratchet that turns state drift into immediate connection termination.
Technical Highlights
Zero-Knowledge Identity Derivation
The revealed identity key is indistinguishable from random; observing it reveals nothing about the factors that produced it. PF exposure is tolerated operationally but correlation with identity defeats unlinkability.
Exposure Tolerance: The Provisioning Factor can traverse untrusted channels—logs, config files, CI/CD pipelines—because possession alone is insufficient. Security derives from composition with the confidential Evidence Factor, not from protecting every factor as a secret.
TELS: The Cryptographic Kill Switch
Beyond simple monitoring, TELS binds the transport layer's session keys (TLS PSK) directly to the platform state. If a monitored file changes, the ratchet forks, the Pre-Shared Key diverges, and the TLS handshake fails immediately with an IncorrectBinder error. This enforces state integrity at the packet level.
Transport Polymorphism
The security model relies on payload composition, not transport integrity. The same Rust toolchain demonstrates secure identity bootstrap over synchronous TLS, REST, and even asynchronous "dead-drop" transports (S3/DNS) without code changes.
JIT Declarative Identity
Declarative identity is achieved through the cryptographic intersection of three independently-sourced factors:
Id = Provisioning(PF) ∩ Evidence(EF) ∩ Validation(VF)
$$Identity(t) = \text{Derive}(\underbrace{PF}_{\text{Anchor}} + \underbrace{\text{Unseal}(\text{Grant}(VF), \text{Capability}(EF))}_{\text{High Entropy Secret}})$$
- → PF: Provisioning Factor - Public, exposure tolerant voucher that identifies who is intended to be authorized
- → EF: Evidence Factor - Confidential, defines what properties an authorized entity must have
- → VF: Validation Factor - Secret, computationally independent nonce that demonstrates proof of possession of PF+EF values
Composition Rules
- Factor Independence: Factors must be obtained through administratively independent channels. The Provisioning Factor traverses the control plane; the Evidence Factor derives from platform mechanisms. An attacker must compromise both channels—neither alone suffices.
- High-Entropy Source: At least one factor in the composition must be computationally indistinguishable from a uniform random string of ≥128 bits. Public or predictable factors contribute to security only when composed with a confidential high-entropy factor.
- Domain Separation: Keys derived with identical factors but distinct contexts remain computationally independent. Each derivation stage uses unique context labels to prevent cross-phase attacks.
Architecture: Identity Convergence
'Authz') --> K_SEAL EF(Evidence Factor
'Authn') --> K_SEAL K_SEAL[Derive: Sealing Key] -->|Unseal| VF(Vault Factor
High Entropy Secret) PF --> K_ID VF --> K_ID K_ID[Derive: Identity Key] -->|Sign| AUTH[Verifiable Proof of
Authz + Authn] style PF fill:#0000ee,stroke:#01579b style EF fill:#dd0000,stroke:#01579b style VF fill:#aa00ee,stroke:#ff6f00 style K_ID fill:#0e0e0e,stroke:#2e7d32,stroke-width:2px
Intent/Fulfillment Separation
Bearer-token systems conflate authorization with authentication—possessing the token is the proof. Factor composition separates these concerns:
- • Provisioning Intent (PF): What workload should exist—the control plane's authorization decision
- • Provisioning Fulfillment (EF): Cryptographic proof that the intended workload does exist
Authentication requires proving both across independent channels. Intent without fulfillment is an unused voucher; fulfillment without intent is unauthorized execution. This eliminates the provisioning race condition where whoever presents a token first wins.
Trust Anchor Normalization
The Evidence Factor provides an abstraction over heterogeneous trust sources:
- • Hardware roots of trust: TPM quotes, TDX/SEV-SNP reports, SGX attestations
- • Orchestrator credentials: Kubernetes ServiceAccount tokens, cloud IMDS metadata
- • Artifact-based proofs: Filesystem measurements, container image hashes, configuration digests
The composition equation remains unchanged regardless of trust anchor. Security properties degrade gracefully based on what's available—hardware-rooted deployments achieve the strongest guarantees, while artifact-based deployments maintain exposure tolerance without hardware dependencies. The protocol doesn't change; the assurance level does.
Implementation & Formal Modeling
-
→
facts-cli:Declarative command-line toolchain - → Standard crypto-agile core (HKDF, Ed25519, PQC)
- → Security properties orthogonal to transport
- → TELS Ratchet Engine: 100ms resolution
Yes, this means your server can cryptographically prove
it hasn't been pwned — every 100ms. No pressure.
- → Formal models for CFA and TELS protocol in ProVerif
- → Modeled under Dolev-Yao adversary assumptions
- → Tested properties include Integrity, Forward Secrecy & One-way injunction
- → Computational indistinguishability (Zero-Knowledge) modeled via PRF equivalence
Pre-print Access
Full TRACE output demonstrates public manifest distribution, JIT key derivation through full cryptographic ceremony. Research pre-print is available for review upon request.