papers/defense/hanzo-cross-domain.tex

\documentclass[11pt,letterpaper]{article}
\usepackage{hanzo-defense}

\doctitle{Multi-Level Security and Cross-Domain Solutions\\via Homomorphic Policy Evaluation\\and Zero-Trust Fabric}
\docid{HAI-2026-007}
\docversion{Version 1.0 --- February 18, 2026}
\docdate{February 2026}
\docauthors{Hanzo AI Research --- Hanzo Team}
\docorgs{Hanzo Industries\\[email protected]}

\begin{document}
\makecover

\begin{abstract}
We present a cross-domain solution (CDS) architecture where data transfer policies are evaluated on encrypted content using fully homomorphic encryption (FHE), ensuring the cross-domain guard never observes plaintext. The architecture integrates four components: (1) a zero-trust overlay network with identity-first micro-segmentation enforcing mandatory access controls at every hop; (2) an FHE policy evaluation engine (ThresholdVM) performing content inspection on ciphertexts using BFV/BGV/CKKS/TFHE schemes with GPU-accelerated NTT operations; (3) a key management system with Shamir-based root key distribution, per-organization encryption isolation, and HIPAA/SOX/SEC compliance controls; and (4) an organization-scoped identity and access management layer deriving security labels from JWT claims and enforcing them at the API gateway. The result is a multi-level security (MLS) architecture where data flows between security domains are cryptographically mediated, no single component has access to both plaintext and policy decisions, and all cross-domain transfers produce immutable audit records anchored to a post-quantum blockchain.
\end{abstract}

\paragraph{Executive Summary.}
A cross-domain solution is the gatekeeper that decides what information may move between networks of different classification---for example, releasing an intelligence product from a Secret network to a coalition partner. Today that gatekeeper has to read the data in the clear to decide, which makes it the single most valuable target on the network: compromise it once and every cross-domain transfer is exposed. This architecture removes that weakness. The data stays encrypted the entire time; the gatekeeper checks it against release policy \emph{without ever decrypting it}, and the final release decision is split across a committee so no single operator or machine can be subverted to leak data. Every transfer leaves a tamper-proof, quantum-resistant audit record. For program offices and integrators running multi-level or coalition networks, the operational payoff is a guard that an adversary cannot turn into a data tap even with full physical access to it.

\tableofcontents
\newpage

% ============================================================================
\section{Introduction}
% ============================================================================

Cross-domain solutions enable controlled information sharing between networks operating at different security classifications. Traditional CDS architectures rely on trusted guards that inspect plaintext content against release policies---creating a high-value target where a single compromise exposes all cross-domain traffic.

This paper presents a fundamentally different approach: the guard evaluates policies on \emph{encrypted} content using fully homomorphic encryption. The guard learns only the Boolean policy decision (release/deny), never the content itself. This eliminates the single point of trust while maintaining mandatory policy enforcement.

\subsection{Problem Statement}

Naval operations require information sharing across multiple security domains:
\begin{itemize}
\item \textbf{Unclassified} $\leftrightarrow$ \textbf{Secret}: Intelligence products sanitized for coalition partners.
\item \textbf{Secret} $\leftrightarrow$ \textbf{Top Secret/SCI}: Analyst workstations accessing compartmented data.
\item \textbf{US} $\leftrightarrow$ \textbf{Coalition}: Multinational operations requiring controlled release.
\item \textbf{Operational} $\leftrightarrow$ \textbf{Administrative}: Preventing data spillage between networks.
\end{itemize}

Current CDS solutions (ISSE Guard, Radiant Mercury, High Speed Guard) process plaintext, requiring the guard itself to be trusted at the highest classification level. A compromised guard exposes all cross-domain traffic.

\subsection{Our Approach}

\begin{enumerate}
\item Data encrypted at source under FHE public key.
\item Guard evaluates content policy homomorphically on ciphertext.
\item Encrypted Boolean result threshold-decrypted by MPC committee.
\item If approved, data re-encrypted for destination domain.
\item Guard never sees plaintext; committee never sees policy result.
\end{enumerate}

% ============================================================================
\section{Architecture Overview}
% ============================================================================

\begin{figure}[H]
\centering
\begin{tikzpicture}[
  node distance=1.5cm,
  box/.style={draw, rectangle, minimum width=3.5cm, minimum height=1cm, align=center, font=\small},
  guard/.style={draw, rectangle, minimum width=3.5cm, minimum height=1cm, align=center, font=\small, fill=lightgray},
  arrow/.style={-{Stealth[length=3mm]}, thick}
]
\node[box] (src) {Source Domain\\(Classification A)};
\node[guard, right=2.5cm of src] (fhe) {FHE Policy Guard\\(sees only ciphertext)};
\node[box, right=2.5cm of fhe] (dst) {Destination Domain\\(Classification B)};
\node[box, below=1.2cm of fhe] (mpc) {MPC Committee\\($t$-of-$n$ threshold)};
\node[box, above=1.2cm of fhe] (zt) {Zero-Trust Fabric\\(identity verification)};

\draw[arrow] (src) -- node[above,font=\footnotesize] {FHE(data)} (fhe);
\draw[arrow] (fhe) -- node[above,font=\footnotesize] {re-encrypt} (dst);
\draw[arrow] (fhe) -- node[right,font=\footnotesize] {FHE(decision)} (mpc);
\draw[arrow] (mpc) -- node[right,font=\footnotesize] {approve/deny} (fhe);
\draw[arrow] (zt) -- (src);
\draw[arrow] (zt) -- (fhe);
\draw[arrow] (zt) -- (dst);
\end{tikzpicture}
\caption{FHE-based cross-domain solution architecture.}
\label{fig:cds-arch}
\end{figure}

\subsection{Security Invariants}

\begin{enumerate}
\item \textbf{Guard blindness}: The policy guard processes only ciphertexts. It cannot distinguish encrypted classified data from encrypted noise.
\item \textbf{Committee separation}: MPC committee members see decryption shares, never the full policy result or the data. Threshold ($t$-of-$n$) prevents minority collusion.
\item \textbf{Mandatory enforcement}: Zero-trust fabric verifies cryptographic identity at every hop. Security labels derived from JWT claims cannot be forged.
\item \textbf{Audit immutability}: Every cross-domain transfer produces a blockchain-anchored receipt with PQ signatures.
\end{enumerate}

% ============================================================================
\section{Zero-Trust Network Fabric}
% ============================================================================

\subsection{Identity-First Access Control}

Hanzo ZT provides the network underlay with mandatory access controls:

\begin{itemize}
\item \textbf{Cryptographic identity}: Every endpoint possesses a unique X.509 certificate with HSM-backed private key (PKCS\#11, YubiHSM).
\item \textbf{No implicit trust}: Network position (IP address, VLAN, subnet) confers zero access. Every connection requires identity verification.
\item \textbf{Micro-segmentation}: Policies define which identities can communicate. Cross-domain traffic flows only through designated guard endpoints.
\item \textbf{Policy enforcement}: Applied at every hop in the overlay mesh, not just at perimeter firewalls.
\end{itemize}

\subsection{Security Label Propagation}

Security labels are derived from the IAM identity system:

\begin{lstlisting}[caption={Security label derivation from JWT claims.}]
// Gateway extracts identity from JWT
X-Org-Id:    "navy-secret"     // Organization = domain
X-User-Id:   "analyst-0042"    // Subject identity
X-User-Email: "[email protected]" // Attribution

// Gateway enforces: only "navy-secret" org members
// can reach services in "secret" namespace
// Cross-domain requires FHE guard intermediary
\end{lstlisting}

The API gateway strips all client-supplied identity headers and derives them exclusively from cryptographically verified JWT claims. This prevents label forgery.

\subsection{Multi-Organization Isolation}

The platform supports 4+ organizations with complete cryptographic isolation:

\begin{table}[H]
\centering
\begin{tabular}{@{}llp{5cm}@{}}
\toprule
\textbf{Organization} & \textbf{Root Key} & \textbf{Isolation Mechanism} \\
\midrule
Org A & Separate AES-256 & KMS per-org encryption \\
Org B & Separate AES-256 & Separate key hierarchy \\
Org C & Separate AES-256 & Org-scoped IAM policies \\
Org D & Separate AES-256 & Independent audit logs \\
\bottomrule
\end{tabular}
\caption{Per-organization cryptographic isolation.}
\label{tab:org-isolation}
\end{table}

Each organization has its own root encryption key, IAM policies, KMS secrets, and audit trail. Cross-organization data access requires explicit policy and traverses the FHE guard.

% ============================================================================
\section{FHE Policy Evaluation}
% ============================================================================

\subsection{ThresholdVM: Computation on Encrypted Data}

ThresholdVM operates on the T-Chain, providing FHE as a native virtual machine:

\begin{table}[H]
\centering
\begin{tabular}{@{}llp{4.5cm}@{}}
\toprule
\textbf{Scheme} & \textbf{Domain} & \textbf{CDS Application} \\
\midrule
BFV & Integer & Keyword matching on encrypted text \\
BGV & Modular & Classification marker detection \\
CKKS & Approx.\ real & ML-based content classification \\
TFHE & Boolean & Arbitrary policy Boolean circuits \\
\bottomrule
\end{tabular}
\caption{FHE schemes mapped to CDS operations.}
\label{tab:fhe-cds}
\end{table}

\subsection{Policy Evaluation Flow}

\begin{algorithm}[H]
\caption{FHE Cross-Domain Policy Evaluation}
\begin{algorithmic}[1]
\State \textbf{Source} encrypts data: $c \gets \text{FHE.Encrypt}(\text{pk}_{\text{FHE}}, \text{data})$
\State \textbf{Source} encrypts metadata: $m \gets \text{FHE.Encrypt}(\text{pk}_{\text{FHE}}, \text{labels})$
\State \textbf{Source} sends $(c, m, \text{dest\_domain})$ to Guard
\Statex
\State \textbf{Guard} evaluates policy homomorphically:
\State \quad $r \gets \text{FHE.Eval}(\text{policy\_circuit}, c, m, \text{dest\_domain})$
\State \quad (Guard sees only ciphertexts; $r$ is an encrypted Boolean)
\Statex
\State \textbf{Guard} sends $r$ to MPC committee for threshold decryption
\For{each committee member $i = 1, \ldots, n$}
  \State $d_i \gets \text{ThresholdDecrypt}(\text{sk}_i, r)$
\EndFor
\State $\text{decision} \gets \text{Reconstruct}(d_1, \ldots, d_t)$ \quad ($t$ shares suffice)
\Statex
\If{decision = APPROVE}
  \State Re-encrypt data for destination domain key
  \State Forward to destination via zero-trust fabric
  \State Anchor audit receipt to blockchain (ML-DSA-65 signed)
\Else
  \State Log denial (encrypted), destroy ciphertext
\EndIf
\end{algorithmic}
\end{algorithm}

\subsection{GPU-Accelerated FHE Operations}

The Hanzo GPU kernel library provides Metal and CUDA kernels for FHE primitives:

\begin{itemize}
\item \textbf{NTT/iNTT}: Number Theoretic Transform for polynomial multiplication in $\mathbb{Z}_q[X]/(X^n+1)$.
\item \textbf{TFHE bootstrap}: Programmable bootstrap for refreshing ciphertext noise.
\item \textbf{Blind rotate}: Key operation in TFHE gate evaluation.
\item \textbf{Batch operations}: Parallel ciphertext processing across GPU threads.
\end{itemize}

GPU acceleration reduces FHE policy evaluation from seconds to milliseconds, making real-time cross-domain filtering practical.

\subsection{EVM Precompile Interface}

Smart contracts can invoke FHE operations via precompiles:

\begin{table}[H]
\centering
\begin{tabular}{@{}llr@{}}
\toprule
\textbf{Address} & \textbf{Function} & \textbf{Gas} \\
\midrule
\texttt{0x0700} & FHE encrypt/decrypt/eval & 500,000 \\
\texttt{0x0701} & Ciphertext ACL management & 25,000 \\
\texttt{0x0702} & Input proof verification & 50,000 \\
\texttt{0x0703} & Cross-chain gateway & 100,000 \\
\bottomrule
\end{tabular}
\caption{FHE EVM precompiles for on-chain policy enforcement.}
\label{tab:fhe-precompiles}
\end{table}

% ============================================================================
\section{Key Management for Multi-Level Security}
% ============================================================================

\subsection{Hanzo KMS Architecture}

The KMS provides 8 subsystems supporting MLS key lifecycle:

\begin{enumerate}
\item \textbf{Shamir Secret Sharing}: Root key split into $n$ shares over GF($2^8$); $t$ required for reconstruction. Custodians geographically distributed.
\item \textbf{Transit Engine}: Encryption-as-a-service with key versioning. Each security domain has independent transit keys with separate rotation schedules.
\item \textbf{HPKE Key Wrapping}: Content encryption keys (CEKs) wrapped using hybrid HPKE (X25519 + ML-KEM-768) per RFC~9180.
\item \textbf{Seal/Unseal Barrier}: AES-256-GCM barrier protecting all stored secrets. Auto-unseal via AWS/GCP KMS for operational environments.
\item \textbf{ACL Policy Engine}: Path-based capabilities with template variables (\texttt{\{\{identity.org\_id\}\}}) enabling per-domain access rules.
\item \textbf{Token Hierarchy}: Service, batch, and recovery tokens with parent-child revocation cascade. Compromised token revocation propagates instantly.
\item \textbf{Dynamic Secrets}: Temporary database credentials (PostgreSQL, MySQL, Redis, MongoDB) scoped to security domain and auto-expired.
\item \textbf{TFHE-KMS Bridge}: FHE key management integrated with policy evaluation pipeline.
\end{enumerate}

\subsection{Cross-Domain Key Isolation}

\begin{itemize}
\item Each security domain has an independent root key, never shared.
\item Cross-domain data transfer requires re-encryption under destination domain key.
\item Re-encryption occurs only after FHE policy approval and threshold decryption.
\item No single KMS instance holds keys for multiple domains.
\end{itemize}

\subsection{Compliance Controls}

\begin{table}[H]
\centering
\begin{tabular}{@{}lp{6.5cm}@{}}
\toprule
\textbf{Standard} & \textbf{Implementation} \\
\midrule
HIPAA & Break-glass tokens (time-limited), WORM audit logs \\
SEC 17a-4 & 6--7 year retention, immutable SHA-256 chain \\
SOX & Regulator escrow shards, cooperative reconstruction \\
GDPR & Per-org keys, graceful revocation \\
CNSA 2.0 & PQ algorithms for all key operations \\
\bottomrule
\end{tabular}
\caption{Regulatory compliance controls in KMS.}
\label{tab:compliance}
\end{table}

% ============================================================================
\section{Audit and Accountability}
% ============================================================================

\subsection{Blockchain-Anchored Audit Trail}

Every cross-domain transfer produces an immutable audit record:

\begin{itemize}
\item \textbf{Record contents}: Source domain, destination domain, policy ID, decision (approve/deny), timestamp, data hash (not data), requestor DID.
\item \textbf{Signature}: ML-DSA-65 (post-quantum) ensuring long-term non-repudiation.
\item \textbf{Anchoring}: Record hash committed to the Hanzo chain via Quasar consensus.
\item \textbf{WORM guarantee}: Write-once-read-many with SHA-256 hash chain prevents retroactive modification.
\end{itemize}

\subsection{Attestation Protocol}

Domain-typed attestations with equivocation detection:

\begin{itemize}
\item \textbf{CrossDomainTransfer}: Records each approved transfer with full provenance.
\item \textbf{PolicyUpdate}: Records changes to cross-domain policies.
\item \textbf{KeyRotation}: Records domain key rotation events.
\item Signing contradictory attestations (equivocation) is automatically detected and flagged.
\end{itemize}

% ============================================================================
\section{Bell-LaPadula Enforcement}
% ============================================================================

\subsection{Mandatory Access Control}

The architecture enforces Bell-LaPadula properties:

\begin{definition}[Simple Security Property (No Read Up)]
A subject at security level $L_s$ cannot read an object at security level $L_o$ where $L_o > L_s$. Enforced by the zero-trust fabric: identity JWT contains org-scoped level; gateway rejects requests to higher-level services.
\end{definition}

\begin{definition}[*-Property (No Write Down)]
A subject at security level $L_s$ cannot write to an object at security level $L_o$ where $L_o < L_s$. Enforced by the FHE guard: data flowing from high to low domain must pass policy evaluation.
\end{definition}

\subsection{Implementation}

\begin{enumerate}
\item \textbf{Read control}: Gateway checks \texttt{X-Org-Id} (derived from JWT) against service security label. Requests to higher domains rejected before reaching backend.
\item \textbf{Write control}: All data egress from a domain passes through the FHE guard. Downward flows require policy approval; upward flows are unrestricted.
\item \textbf{Label integrity}: Security labels are gateway-derived from cryptographic JWT claims. Client-supplied labels are stripped. Labels cannot be forged without compromising the IAM signing key.
\end{enumerate}

% ============================================================================
\section{Comparison with Existing CDS Approaches}
% ============================================================================

\begin{table}[H]
\centering
\small
\begin{tabular}{@{}lp{2.5cm}p{2.5cm}p{2.5cm}@{}}
\toprule
\textbf{Feature} & \textbf{Traditional Guard} & \textbf{Data Diode} & \textbf{FHE Guard (Ours)} \\
\midrule
Plaintext exposure & Guard sees all & One-way only & Never \\
Bidirectional & Yes & No & Yes \\
Content inspection & Full & None & On ciphertext \\
Single point of trust & Guard & No & No (threshold) \\
PQ-safe & Depends & N/A & Yes (FIPS) \\
Audit & Guard logs & Physical & Blockchain \\
ML classification & On plaintext & N/A & On ciphertext \\
\bottomrule
\end{tabular}
\caption{CDS approach comparison.}
\label{tab:cds-comparison}
\end{table}

The FHE-based approach uniquely provides bidirectional content-inspected cross-domain transfer with zero plaintext exposure. No commercially available CDS offers this capability.

% ============================================================================
\section{Performance Considerations}
% ============================================================================

\subsection{FHE Overhead}

\begin{table}[H]
\centering
\begin{tabular}{@{}lrr@{}}
\toprule
\textbf{Operation} & \textbf{CPU} & \textbf{GPU (Metal)} \\
\midrule
TFHE gate evaluation & 13 ms & 0.8 ms \\
BFV keyword match & 45 ms & 3.2 ms \\
CKKS ML inference & 200 ms & 15 ms \\
Threshold decrypt ($t$=3) & 50 ms & 12 ms \\
\midrule
\textbf{Total policy eval} & \textbf{$\sim$300 ms} & \textbf{$\sim$30 ms} \\
\bottomrule
\end{tabular}
\caption{FHE policy evaluation latency.}
\label{tab:fhe-perf}
\end{table}

GPU acceleration brings FHE policy evaluation to 30~ms---practical for real-time cross-domain filtering of message traffic, though not suitable for bulk file transfer without parallelization.

\subsection{Throughput}

With GPU acceleration and pipelined evaluation:
\begin{itemize}
\item \textbf{Messages}: $\sim$33 messages/second per GPU (real-time chat feasible).
\item \textbf{Bulk data}: Parallelize across multiple GPUs; 8-GPU node achieves $\sim$264 evaluations/second.
\item \textbf{Ciphertext expansion}: 100--1000$\times$ plaintext size (FHE-inherent). ZAP zero-copy design mitigates the internal memory cost.
\end{itemize}

% ============================================================================
\section{Naval MLS Deployment Scenarios}
% ============================================================================

\subsection{Coalition Information Sharing}

\begin{itemize}
\item US Secret data evaluated against release policy for Five Eyes partners.
\item FHE guard checks classification markers, source restrictions, and content sensitivity---all on ciphertext.
\item Approved data re-encrypted under coalition domain key and forwarded.
\item Full audit trail anchored to blockchain for post-operation review.
\end{itemize}

\subsection{Analyst Workstation Cross-Domain Access}

\begin{itemize}
\item Analyst at Secret level queries Top Secret/SCI database.
\item Query encrypted under FHE key; database returns encrypted results.
\item FHE guard evaluates sanitization policy on encrypted response.
\item Approved (sanitized) response decrypted for analyst's domain.
\end{itemize}

\subsection{Shipboard MLS Network}

\begin{itemize}
\item Multiple security domains on single shipboard network (physically separated VLANs, logically separated via zero-trust overlay).
\item FHE guards at domain boundaries, GPU-accelerated for real-time messaging.
\item KMS with separate root keys per domain, HSM-protected.
\item All cross-domain traffic audited with PQ-signed blockchain receipts.
\end{itemize}

% ============================================================================
\section{Strategic Context}
% ============================================================================

This cross-domain architecture is one capability within a broader sovereign stack built by Hanzo AI---an American-owned applied-AI lab and venture studio (Techstars '17, founded 2014) behind more than 100 venture-funded startups and several unicorns, led by a founder with deep expertise in both AI/ML and cryptography. Hanzo owns both halves of the problem that cross-domain security demands: the frontier AI models (the Zen family) that drive content classification on encrypted data, and the production post-quantum cryptography that mediates the transfers. This matters for the multi-level and coalition mission specifically: U.S.\ frontier AI has consolidated into a closed commercial duopoly, while the only broadly \emph{open} frontier model weights available today are largely of foreign origin---an untenable basis for a guard that inspects classified traffic. Hanzo is the American open-source frontier alternative, offering models and cryptography that are sovereign, auditable end-to-end, and deployable in air-gapped or edge environments without renting from the closed duopoly or depending on foreign open weights. The same stack has been hardened in production at scale---the agentic engineering pipeline delivered a FINRA/SEC-approved, SOC2 securities platform (consolidated from 200+ microservices into 3 compiled binaries) to production with a small team---evidence that the cryptographic and AI components described here are operational engineering, not laboratory prototypes.

% ============================================================================
\section{Conclusion}
% ============================================================================

We have presented a cross-domain solution architecture where the guard evaluates policies on encrypted content, eliminating the traditional single point of trust. The combination of FHE policy evaluation, zero-trust network fabric, threshold MPC decryption, and blockchain-anchored audit provides a multi-level security architecture with no plaintext exposure at the guard, no single point of key compromise, and immutable accountability.

This approach represents a paradigm shift in cross-domain security: instead of trusting the guard to handle plaintext responsibly, we make it cryptographically impossible for the guard to access plaintext at all.

% ============================================================================
\begin{thebibliography}{18}

\bibitem{fips203} NIST, ``ML-KEM Standard,'' FIPS 203, 2024.

\bibitem{fips204} NIST, ``ML-DSA Standard,'' FIPS 204, 2024.

\bibitem{rfc9180} R. Barnes \etal, ``Hybrid Public Key Encryption,'' RFC 9180, 2022.

\bibitem{tfhe} I. Chillotti \etal, ``TFHE: Fast Fully Homomorphic Encryption,'' JoC, 2020.

\bibitem{bfv} J. Fan, F. Vercauteren, ``Somewhat Practical Fully Homomorphic Encryption,'' IACR ePrint 2012/144.

\bibitem{ckks} J. Cheon \etal, ``Homomorphic Encryption for Arithmetic of Approximate Numbers,'' ASIACRYPT 2017.

\bibitem{belllapadula} D. Bell, L. LaPadula, ``Secure Computer Systems: Mathematical Foundations,'' MITRE, 1973.

\bibitem{shamir} A. Shamir, ``How to Share a Secret,'' CACM, 1979.

\bibitem{openziti} NetFoundry, ``OpenZiti: Programmable Zero Trust Networking,'' 2023.

\bibitem{cnsa2} NSA, ``CNSA Suite 2.0,'' 2022.

\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Hanzo, 2025.

\bibitem{corona} ``Practical Two-Round Threshold Signature from LWE,'' IACR ePrint 2024/1113.

\bibitem{isse} NSA, ``ISSE Guard Cross Domain Solution,'' 2020.

\bibitem{cdsguide} DISA, ``Cross Domain Solution Design and Implementation Guide,'' 2021.

\bibitem{zerotrust} J. Kindervag, ``Zero Trust Architecture,'' Forrester, 2010.

\end{thebibliography}

\section*{Reproducibility}
\textbf{Source code.} \texttt{github.com/hanzoai/fhe, hanzoai/kms} (commit \texttt{TBD}).\\
\textbf{Build.} make build (Rust 1.78+, OpenFHE bindings); GPU NTT via Metal/CUDA.\\
\textbf{Hardware tested.} Apple M2/M3 (Metal), NVIDIA A100/H100.\\
\textbf{Standards referenced.} NIST FHE (BFV/BGV/CKKS/TFHE), HIPAA, SOX, SEC, MLS.\\
\textbf{Contact.} [email protected].

\end{document}