Files
papers/lux-institutional-custody/sections/09-compliance-map.tex
zeekay ced35b03ed papers: Mar-3 freeze deliverables for hybrid PQ consensus stack
Quasar Horizon (consensus composition over Pulsar / ML-DSA / BLS lanes
under Prism + LSS lifecycle), Warp 2.0 (Pulse-backed cross-chain envelope
with forward-only v1->v2 migration and lattigo ReadUint64Slice DoS fix),
benchmark report (microbench, reshare, activation, Warp 2.0 verify, Prism
composition, GPU headroom, cross-WAN latency), and NIST IR 8214C-style
submission package (spec, parameter sets, domain separation, serialization,
reference-impl pointers, evaluation report, security analysis, side-channel
considerations).

All four deliverables compile cleanly via pdflatex+bibtex and reference
the canonical proof bucket files at proofs/{definitions,pulsar,lss,quasar}.
No duplication of proof bodies; cite by file path.
2026-03-03 12:00:00 -08:00

182 lines
6.8 KiB
TeX

\section{Compliance Map}
\label{sec:compliance}
%% =====================================================================
The architecture is built so that each significant compliance
framework maps to a small number of architectural elements. This
section gives that map. It is not a substitute for a SOC 2 readiness
assessment, but it is the input to one.
\subsection{FIPS 140-2 Level 3 (Tier 1 and Tier 2)}
\begin{itemize}[nosep]
\item Every signing component (Tier 1 cold and Tier 2 warm) is FIPS
140-2 Level 3 minimum (Utimaco SR-Se200 carries Level 4 physical)
\cite{nist-fips140-2,thales-luna7,utimaco-secsr,aws-cloudhsm,gcp-cloudhsm,yubihsm2}.
\item FIPS 140-3 substitutions \cite{nist-fips140-3} are accepted
where the validation is current; the architecture accepts both
generations during the FIPS 140-2 sunset window.
\item Tier 3 hot-tier KMS-backed CMKs use FIPS 140-2 Level 3 HSMs
behind AWS KMS and GCP KMS multi-tenant boundaries; the policy
constraint (per-day cap, time-lock) compensates for the multi-tenant
substrate.
\end{itemize}
\subsection{NIST SP 800-57 Key Management}
NIST SP 800-57 Part 1 Rev. 5 \cite{nist-sp800-57} is the canonical
reference for key-management lifecycle. The architecture's mapping:
\begin{table}[h]
\centering
\small
\begin{tabular}{p{4cm}p{10cm}}
\toprule
\textbf{SP 800-57 phase} & \textbf{Implementation} \\
\midrule
Generation &
Witnessed DKG ceremony (Section~\ref{sec:ceremony}); no aggregate
secret ever exists \\
Distribution &
Shares never leave their HSM boundary; distribution is by Feldman
VSS within the ceremony \\
Storage &
HSM-resident; tamper-evident, non-extractable \\
Use &
Threshold signing only; no plaintext key export under any policy \\
Refresh &
Proactive CGGMP21 refresh on the per-tier cadence
(Section~\ref{sec:ops}) \\
Revocation / destruction &
Vendor zeroisation procedure on hardware retirement; M-Chain ledger
records destruction event \\
Recovery &
Sealed-envelope 3-of-3 Shamir recovery passphrase \\
\bottomrule
\end{tabular}
\caption{SP 800-57 mapping.}
\label{tab:sp800-57}
\end{table}
\subsection{SOC 2 Type II}
The Trust Services Criteria \cite{soc2} relevant to custody operations
are CC1 (control environment), CC2 (communication and information),
CC3 (risk assessment), CC4 (monitoring), CC5 (control activities),
CC6 (logical and physical access), CC7 (system operations), CC8
(change management), and CC9 (risk mitigation). The mapping:
\begin{itemize}[nosep]
\item \textbf{CC6.1 (logical access).} Two-person rule, role
separation (Section~\ref{sec:ops}); IAM-managed access with quarterly
reviews.
\item \textbf{CC6.4 (physical access).} Tier IV DC for the on-prem
HSM, SCIF for the airgap vault, biometric+PIN entry, tamper-evident
seals on transport media.
\item \textbf{CC7.2 (anomaly detection).} M-Chain ledger anomaly
queries on every signing event; daily reconciliation.
\item \textbf{CC8.1 (change management).} Firmware-update policy
(Section~\ref{sec:hsm}); CGGMP21 share-refresh cadence; allowlist
change review.
\end{itemize}
The architecture is compatible with a SOC 2 Type II audit period of
twelve months and is designed to pass a Type II audit on first
attempt; first-year audit cost is approximately \$150{,}000.
\subsection{ISO 27001:2022}
The ISO 27001:2022 ISMS controls Annex A maps as follows
\cite{iso27001}:
\begin{itemize}[nosep]
\item A.5 (organisational): custody policy, witness role, audit
cadence.
\item A.6 (people): two-person rule, background checks on every
custody operator, training cadence.
\item A.7 (physical): SCIF, Tier IV DC, biometric access.
\item A.8 (technological): HSM-resident keys, threshold signing,
M-Chain audit log.
\end{itemize}
\subsection{CCSS Level 3}
The CryptoCurrency Security Standard \cite{ccss} Level 3 is the
highest level and is the appropriate target for an eight-billion-dollar
custodian. CCSS Level 3 requirements and mapping:
\begin{table}[h]
\centering
\small
\begin{tabular}{p{4.5cm}p{9cm}}
\toprule
\textbf{CCSS aspect} & \textbf{Implementation} \\
\midrule
1. Key/seed generation &
Witnessed DKG with hardware attestation
(Section~\ref{sec:ceremony}) \\
2. Wallet creation &
Threshold MPC; aggregate key never exists \\
3. Key storage &
Multiple-environment, multi-vendor HSMs; offline storage on cold
tier; geographic separation \\
4. Key usage &
Threshold $t$-of-$n$; multiple operators required for every signing \\
5. Key compromise procedure &
Documented incident-response runbook with proactive refresh and full
re-DKG paths (Section~\ref{sec:dr}) \\
6. Keyholder grant/revoke procedures &
Quarterly access review; hardware-attested termination \\
7. Third-party audits &
SOC 2 Type II, ISO 27001 surveillance, CCSS audit (annual) \\
8. Data sanitisation policy &
Vendor zeroisation on retirement; M-Chain destruction event \\
9. Proof of reserve &
Daily on-chain reconciliation against M-Chain ledger \\
10. Audit logs &
Hash-chained M-Chain log signed BLS + ML-DSA \\
\bottomrule
\end{tabular}
\caption{CCSS Level 3 mapping.}
\label{tab:ccss}
\end{table}
\subsection{Regional Frameworks}
\begin{itemize}[nosep]
\item \textbf{MiCA (EU) \cite{mica}.} The fund's EU-domiciled feeder
qualifies for CASP licensing under MiCA; the architecture meets MiCA
Article 67 (segregation), Article 68 (custody policy), and Article 70
(safekeeping records) by design.
\item \textbf{MAS PSN02 (Singapore) \cite{mas-psn02}.} The Singapore
share custodian (warm-tier $\mathbf{w}_2$ in asia-east1) is
engineered for MAS DPT licence terms: in-jurisdiction key custody,
SOC 2 attestation, segregated client funds, and travel-rule
integration via Chainalysis KYT \cite{chainalysis}.
\item \textbf{NYDFS BitLicense (US) \cite{nydfs-bitlicense}.} If the
US-domiciled vehicle elects BitLicense rather than OCC trust charter,
the architecture meets 23 NYCRR 200.7 (custody and protection of
customer assets) and 200.16 (cybersecurity).
\item \textbf{OCC trust charter (US) \cite{occ-trust}.} The
Anchorage-style OCC national trust charter is supported; the
architecture's hardware attestations and multi-jurisdiction
shares satisfy OCC Interpretive Letter 1170 fiduciary custody
expectations.
\item \textbf{12 CFR \S225 (US bank holding companies).} Where
the institutional client is a bank holding company, the architecture
is configured to meet Federal Reserve Regulation Y custody
requirements, including separately identifiable safekeeping records.
\end{itemize}
\subsection{Insurance}
The architecture is insurable. Lloyd's-syndicate-backed crime-and-specie
policies for digital-asset custody are written against CCSS Level 3
posture; the typical 2026-vintage policy provides up to \$500M per
incident on first-loss for cold-tier coverage and reduced limits for
warm and hot tiers. The \$8B AUM is not insurable as a single tower;
it is layered across multiple syndicates.
%% =====================================================================