Files
papers/lux-trust-kernel/sections/07-provider-accountability.tex
zeekay 4a753bb639 papers: reorganize into per-paper dirs, add Antje Worring as co-author
Restructured from flat .tex/.pdf files into per-paper subdirectories.
Added Antje Worring as co-author on all papers.
Synced PDFs to pdfs/ for download site.
2026-04-18 21:50:07 -07:00

37 lines
1.6 KiB
TeX

\section{Provider Accountability}
\label{sec:provider}
%% ===================================================================
The trust kernel enables a critical property: \emph{provider-independent
auditability}. A capsule's data may be hosted by any provider (cloud, on-premise,
edge), but the trust trail remains on-chain regardless of provider.
\subsection{Provider Switching}
When a capsule migrates from provider $P_1$ to provider $P_2$:
\begin{enumerate}
\item The capsule owner initiates a key rotation on the K-Chain, generating
new wrapping keys accessible only to $P_2$.
\item $P_1$ produces a \textsc{TransferReceipt} attesting to the data
handoff, anchored on-chain.
\item $P_2$ confirms receipt of the encrypted data and anchors a
\textsc{ReceiveReceipt}.
\item The owner revokes $P_1$'s capabilities on the K-Chain.
\end{enumerate}
At no point does the chain store the capsule's data. The chain stores only the
trust decisions (key rotation, capability revocation, transfer attestation) that
make the migration auditable.
\begin{proposition}[Provider Independence]\label{prop:provider}
Given a capsule $\mathcal{C}$ with receipt chain $\{\mathcal{R}_1, \ldots,
\mathcal{R}_n\}$ and a provider migration from $P_1$ to $P_2$, the receipt
chain after migration contains sufficient information for any third-party
auditor to verify: (a)~the identity of both providers, (b)~the time of
migration, (c)~the completeness of capability revocation from $P_1$, and
(d)~the continuity of the capsule's key lineage.
\end{proposition}
%% ===================================================================