Channel Integrity & Authentication
Channel Provenance Protocol — per-counterparty cryptographic authentication of electronic communications. Three sender profiles. Four attack scenarios. Cooperative-consensus verification at the recipient. Trust-mark rendered in user-agent chrome, outside sender-controlled content.
Enrolled senders — registry
REAL · sender_secret per profileEach profile holds a sender_secret in HSM-equivalent storage. Selecting a profile binds the next compose action to that profile’s identity.
Compose communication
Per-counterparty key: HMAC-SHA-256(sender_secret, recipient_id || content_hash || session_nonce). Signature attaches as channel header. The verification client at the recipient independently re-derives the same key from registry-published material.
Adversary console
REAL · 4 attack typesFour named attack types from the MP21 P1 specification. Each demonstrates a distinct verification-failure mode caught by the recipient client.
Per-counterparty KDF — live values
Signing key is unique per (sender, recipient, content, nonce) tuple. A leaked key for one pair does not compromise any other pair.
Inbox — recipient verification client
v1.0 · syncedThe trust-mark below is rendered in user-agent chrome by the verification client — outside any sender-controlled content area.
Live message flow
Binôme cooperative verifier consensus
REAL · consensus protocolThree independent verifier instances, optionally from different organisations. Default mode: 3-of-3 unanimous. Other modes supported by protocol: 2-of-2, 2-of-3 quorum (one endpoint may be compromised, two-of-three legitimate-state persists).
Adversarial inputs optimised against any one verifier’s training distribution still fail at the other two — the cooperative requirement is the defence.
Trust-mark at user-agent level
The “Authenticated by ARIA — [sender]” badge is rendered by the verification client in trusted browser or OS chrome, not in the message content area.
Bonjour, votre virement de 2 500 EUR a ete execute...
Same protection model as TLS lock icons, OS-level OAuth consent screens, and platform-level biometric prompts.
Trap & attribution feed
REAL-TIME · LAST 30 DAYSVerification failures populate this feed with forensic context routed to the impersonated sender’s threat-intelligence team. Gated on cryptographic verification failure — not on passive scanning.
Event feed
Multi-channel coverage
The protocol is channel-agnostic. Same per-counterparty KDF, same trust-mark architecture, same cooperative-consensus modifier across every carrier.
Architectural summary
Channel Provenance Protocol binds the signature to (sender_secret, recipient_id, content_hash, session_nonce), optionally extended to channel state (sequence number, hop topology, cooperative consensus). The four attack types share a common verification-failure mode: at least one KDF input cannot be reproduced by the attacker, so the re-derived signature does not match the received signature.
The defence is architectural, not detective. The recipient client does not need to recognise the attack as anomalous — the cryptographic re-derivation either matches or it does not. False positives under legitimate traffic are structurally zero. Graceful degradation under partial compromise is provided by the cooperative-consensus modes.
Cross-references: MP21 P1 channel-protocol; MP20 P92 / P94 physical-document family with the same KDF substrate; MP19 P88 Binôme cooperative primitive; FLE-PROSODY-2025-PCT-001 prosody embodiment (Track A platform-licensing reserved — not surfaced in this demo).
Per-Counterparty Continuity
The primitive specifically targeting the SolarWinds-class attack. Each bilateral relationship maintains a per-counterparty cryptographic continuity record derived from interaction history through HMAC-SHA-256 with character-extraction fingerprints plus fake-phrase obfuscation. An attacker holding stolen credentials cannot reproduce the relationship’s internal state — substitution is detected at the bilateral protocol layer.
Legitimate pair · vendor ↔ customer
REAL · evolving HMAC chainA vendor (software update distributor) and a customer (enterprise IT) have built up continuity across eight interactions. The continuity record at each side evolves with every legitimate exchange. Below: the record state on the customer side after each interaction.
Continuity record — live state
Continuity record at step N is HMAC-SHA-256(record_{N-1}, fingerprint_N || obfusc_N || content_hash_N). The chain is one-way; rewinding requires the inputs at every step, which requires the relationship’s history.
Stolen-credential attacker — substitution attempt
REAL · mismatch detectionThe attacker has the vendor’s signing credentials (e.g., from a build-pipeline compromise — SolarWinds-class). The attacker can produce signed updates that pass PKI verification. What the attacker cannot do is reproduce the customer’s continuity record — the attacker has not participated in the eight prior interactions.
CUSTOMER SIDE
The customer’s verification client holds record_8 from the legitimate chain. When the attacker’s update arrives, the client computes expected_record_9 based on the attacker’s payload + customer’s held record_8. The attacker has no way to forge a fingerprint and obfuscation that match what the legitimate vendor would have produced.
Disabled until the legitimate chain has at least 5 interactions.
ATTACK RESULT
Character-extraction fingerprint
Each interaction’s content yields a fingerprint that is stable for the relationship (same patterns produce the same fingerprint) and not directly invertible (fingerprint does not reveal content). The construction combines bigram statistics, token-length distribution moments, and a relationship-keyed hash. The fingerprint is one of three KDF inputs to the continuity step.
Fake-phrase obfuscation
PART · stable seeded generatorEach step contributes an obfuscation input that is not directly observable from interaction logs. Generated from a relationship-keyed PRG seeded at enrollment. Defeats the offline-replay variant where an attacker has logged communications — logs alone do not yield the obfuscation input.
Composition with the rest of the suite
COD composes with AUT (authentication provides per-message integrity; COD provides per-relationship continuity above it). COD composes with Storage (storage operations require continuity-verified counterparty before authorisation). The two-layer defence — per-message authentication and per-relationship continuity — is the architectural answer to SolarWinds-class supply-chain attacks where the attacker holds legitimate per-message credentials but does not hold per-relationship state.
The Signal Protocol’s double-ratchet maintains per-counterparty state for forward secrecy — the closest cited prior art. ARIA-COD distinguishes by using per-counterparty state specifically as a substitution-detection primitive, with character-extraction fingerprints and fake-phrase obfuscation as KDF inputs that produce a stable per-relationship fingerprint while remaining resistant to direct content disclosure. The combination is filed as the inventive core.
Cross-references: AUT (per-message integrity, MP21 P1 filed); Storage (per-operation authorisation, MP21 P5 filed); Internal-Channel Encryption (within Binôme cooperative-verification, MP21 P4 filed). The SolarWinds end-to-end walk-through using all three primitives composed is in Section 5.
Authenticated Deniable Communication
Written-channel protocol. Real Shamir GF(2^8) threshold sharing (k=3 of N=5, configurable). Sequence-locked silent-failure: wrong-order chunk opening returns an error indistinguishable from insufficient-chunks — denying the attacker oracle access. Cover-message generation is bound to the per-counterparty key.
Anna · sender (enrolled)
cp_id pendingThe real message is composed locally. It is never transmitted as ciphertext — a cover message, plausible business correspondence between Anna and Bernard, carries the real message embedded steganographically.
SESSION STATE
The wire — what any observer sees
5 transport pathsFive transport paths carry one cover message plus four chunk-bearing packets. None are distinguishable from each other on casual observation. The cover is plausible business correspondence. The chunk packets look like opaque transit traffic.
Bernard · recipient (enrolled)
σ_session in Secure EnclaveBernard’s recipient client receives the cover and chunks. σ_session is retrieved from local Secure Enclave (set at enrollment, never on the wire). Recovery: select k=3 chunks, order by σ, attempt authenticated decryption.
RECEIVED
RECOVERED REAL MESSAGE
Silent-failure attack mode: wrong σ returns the same error as “insufficient chunks.” The attacker gets no oracle signal.
Six layers — wire to real meaning
Sequence-locked threshold — the cryptographic novelty
REAL · GF(2^8) Shamir + AES-GCM wrapK_recover is split via Shamir polynomial interpolation over GF(2^8) into 5 chunks; any 3 are mathematically sufficient. Each chunk is ALSO wrapped using a key derived from the contents of all chunks scheduled to precede it in σ_session. σ_session is a permutation of the 5 indices, set freshly at session establishment, stored only at Bernard’s Secure Enclave and at the registry. It never travels on the wire.
Wrong-order opening fails an authenticated-decryption integrity check. The error is indistinguishable from “insufficient chunks collected” — the attacker gets no oracle access by which to brute-force σ. With 5 chunks, an attacker without σ faces 5! = 120 permutations, each test requiring Bernard’s enrollment credential AND producing no signal about which positions are correct. With N=8, 40,320 permutations; with N=12, 479,001,600.
Coercion-resistance under legal compulsion
Suppose Bernard is compelled by legal authority to disclose received content. He can comply with a partially-honest disclosure:
The compliance is harder to disprove than with simple threshold sharing. The real message remains hidden.
What ARIA-ENC does NOT defend against
HONESTYEndpoint compromise. If Bernard’s device is compromised AND σ_session is exfiltrated before session end, the recovered message is exposed.
Forward secrecy across credential compromise. Compromise of registry-stored long-term enrollment credentials may permit retroactive decryption depending on protocol parameters.
Anonymous operation. Both endpoints are identified to the registry. Registry metadata (which endpoints, when, what duration) is available to legal process. This is by design — the architectural answer to dual-use concerns.
Voice-channel ENC
FILED · Demo in queueVoice-channel embodiment. Written cover serves voice: at the sender, voice content is reduced to a written-form transcript that is embedded in a written cover; at the recipient, voice is locally reconstructed from the recovered text using pre-registered sender voice profile. The wire carries no voice or text of the real content — only the cover correspondence. Latency and quality constraints are operationally stringent and the demonstration build is queued.
SyncVid — video-channel ENC
FILED · Demo in queueVideo-channel deniable communication with synchronised state attestation across multiple parties. Architectural design parallels voice-channel: written cover carries video reconstruction parameters; recipient locally reconstructs from pre-registered profile. Synchronised state attestation handles multi-party video where each participant must reconstruct a coherent shared video state.
Authenticated Deniable Storage
Six sub-inventions are filed at USPTO. Operational demo artifacts are queued for build. This section presents the architecture honestly — what each sub-invention is, how it composes with the rest of the suite, and what the comparison to conventional encrypted storage looks like.
ARIA-DSK
Filed · demo in queuePersistent storage on conventional storage media (disk, SSD, cloud-storage backend). Provides authenticated deniability with the disk-resident format indistinguishable from generic encrypted storage under casual inspection. Cover-content is selected from the user’s authentic data, per-document KDF derives from cover identifier and content hash, protected content is embedded steganographically into authentic cover documents.
ARIA-MEM
Filed · demo in queueVolatile-memory variant for in-process secret protection. Memory contents survive cooperative-verification challenge but become unrecoverable after process termination. Hardware-enclave integration: Intel SGX, AMD SEV, ARM TrustZone.
ARIA-VAULT
Filed · demo in queueVirtual mailbox credential storage. Pseudo-email-accounts on conventional providers carry credential split. Inter-account correspondence has cover-coherence (the messages between accounts read plausibly), credentials are embedded steganographically in selected messages, account-level threshold distribution spreads the credential across N independent providers. Addresses the password-manager attack class: compromise of one vault does not yield the credential population.
Self-Cooperative
Filed · demo in queueSelf-cooperative architecture across user devices. A single operator runs cooperative-verification across their own devices (phone + laptop + secure-element token). Provides quorum-based access from operator’s own devices without requiring a counterparty. Mutual device authentication on recovery; cooperative revocation flow on device loss.
Hardware embodiment
Filed · demo in queueDedicated storage-device hardware integrating the ARIA-STORAGE primitive at the firmware level. Embedded controller, secure element, hardware RNG, cover-content flash region, embedded-protected-content flash region, sideband authentication channel. Default mode presents host file-system view as ordinary cover content; authenticated mode presents the extended view with protected content recovered.
Trusted-custodian
Filed · demo in queueTrusted-custodian configuration for institutional contexts where a regulated custodian holds part of the cooperative-verification quorum (legal escrow, financial trustee, regulated data fiduciary). Day-to-day access path: user portion only. Extraordinary access path: user + custodian cooperation under registry-recorded terms.
Conventional encrypted storage vs. cover-from-authentic-data
CONVENTIONAL ENCRYPTED STORAGE
LUKS / dm-crypt, VeraCrypt, BitLocker, FileVault, encrypted file systems, encrypted cloud-storage backends. All produce identifiable encrypted storage observable on inspection. Forensic examination reveals the presence of encrypted data even when content remains undecryptable.
Steganographic file systems exist (StegFS, RubberhoseFS) and provide deniability properties, but lack per-document key derivation, sequence-locked threshold recovery-key distribution, and cover-from-authentic-data architecture — they use generic decoy content rather than the user’s actual data.
ARIA-STORAGE COVER-FROM-AUTHENTIC-DATA
Cover-content is the user’s authentic data (photos, documents, audio, scans) with independent retention value. To an inspector, the storage substrate is indistinguishable from generic personal data. There is no encrypted blob to find — the protected content is embedded in authentic cover documents.
Per-document key derivation, sequence-locked threshold recovery-key distribution, opening-sequence-ordered chunk opening with silent-failure denial of oracle access. Composes with AUT (authenticated access), COD (continuity-verified counterparty), Binôme (cooperative consensus for high-stakes recovery).
Composition with the rest of the suite
Storage operations require authenticated access via AUT (per-message integrity), continuity-verified counterparty via COD (per-relationship state), and optionally cooperative consensus via Binôme (multi-verifier quorum). The composition is the suite’s full architectural posture for data-at-rest.
In Section 5, the credential-theft lateral-movement scenario shows COD + Storage composing against an attacker who has stolen working credentials: the attacker can authenticate at the AUT layer but cannot reproduce the per-relationship continuity required by COD, and cannot locate sensitive material in the storage substrate where ARIA-STORAGE cover-from-authentic-data has hidden it among ordinary user data.
Chain Composition — the architectural moat
The strategic value of ARIA is not in any single primitive but in the composition. Three scenarios. The principal walk-through is SolarWinds-class supply-chain compromise — six steps, walked twice (primitives off / primitives on) with a toggle mechanic in between. Two adjacent scenarios round it out: synthetic-audio executive impersonation and credential-theft lateral movement.
Primitive toggles — observe the composition
REALToggle the five primitives on/off and observe how the SolarWinds-class attack outcome changes below. The mechanic is the central didactic device of this section — the composition value, not the individual primitive value.
SolarWinds-class supply-chain compromise — six steps
2020 · 18,000+ customers · 9-month dwell timeThe canonical attack timeline. The all-primitives-off column is the actual 2020 historical outcome. The primitives-on column is what ARIA delivers as configured by the toggles above.
Adjacent scenario · Synthetic-audio executive impersonation
Attacker calls the treasury function impersonating the CFO with a cloned voice. Requests urgent wire transfer to attacker-controlled account.
The defence is architectural — not detection-based. The treasury function does not need to detect the voice clone; the absence of authentication is the signal.
Adjacent scenario · Credential-theft lateral movement
Attacker has working credentials. PKI / MFA accepts them. Standard IAM provides no architectural defence against legitimate-credential lateral movement.
The per-customer continuity record is the SolarWinds amplification killer — the attacker has to compromise each victim individually rather than achieving one-to-thousands amplification.
Try your own SolarWinds-class scenario
SIM · SCIM-routedDescribe a supply-chain or substitution-class scenario from your own experience or threat model. The input routes through SCIM (Semantic Confidence Intent Mapping) for intent analysis, then through the studio-brain proxy to generate an architectural analysis of which ARIA primitives apply and what the composition outcome would be. Both SCIM and the AI proxy are real production endpoints.
SCIM endpoint: scim-api.soaf01.workers.dev · AI proxy: studio-brain.soaf01.workers.dev/ai · Model: claude-sonnet-4-20250514. No browser-to-Anthropic call. Falls back gracefully if the endpoints are unreachable.
About this demonstration
Honest framing of what is and is not operationally shown, the architectural principles documented even where no operational surface exists, and the filing status of every primitive referenced.
Demonstrated vs. architecturally presented
SCIM-first architectural principle
All free-text → AI surfaces in SoafAii applications route through SCIM (Semantic Confidence Intent Mapping) for analysis, clarification, and brief generation before reaching any generation model. The demo’s single free-text surface is the Section 5 “Try your own scenario” input — that input goes through SCIM’s analyze and brief endpoints with graceful fallback if unreachable.
AI proxy isolation
No browser-to-Anthropic call. Every AI invocation routes through the studio-brain proxy (Cloudflare Worker holding the API key as a Wrangler secret). The model string used by this demo is fixed: claude-sonnet-4-20250514.
Runtime health monitoring
REAL · ARIA-H embeddedThe Health badge in the header is the SoafAii Health module — aviation-grade tiered reporting (GREEN/AMBER/RED) with fingerprinting, periodic checks, self-healing for DOM regressions, and security isolation. Click the badge or press Ctrl+Shift+Q for the embedded QA panel.
Two-tier guided tour
5-step quickstart · 14-step fullFirst-launch detection via aria_mehler_tour_seen_v1 in localStorage. Two-tier picker on first launch: 5-step quickstart for the productive-in-five-minutes path, or 14-step full walkthrough for the comprehensive orientation. Re-openable at any time from the (?) help button in the header. ESC or click outside to dismiss.
Filing status summary — portfolio context
As of May 2026 the primitives referenced in this demo are all filed at USPTO at provisional stage. PCT conversions are scheduled across 2026–2027. The applicant at provisional is the inventor personally; assignment to BIS WLL (Bahrain) is scheduled at PCT conversion within twelve months of each filing.
Twenty-one master patents are filed at USPTO across the broader SoafAii portfolio. The list above covers the primitives directly referenced in this demonstration.
Technical infrastructure
Single-file HTML. No external script CDNs at runtime (fonts are the only external dependency). The file works offline once loaded; only the SCIM analyze and AI proxy calls (Section 5 free-text input) require network. All other primitives run entirely in-browser.