papers/lux-threshold-ux/sections/10-security-analysis.tex

%% ===================================================================
%% LP-134 canonical naming (2025-12-15):
%% Per LP-134 (Lux Chain Topology), M-Chain has been split into:
%%   M-Chain — MPC ceremonies for bridge custody of EXTERNAL wallets
%%             (CGGMP21, FROST, Pulsar-general)
%%   F-Chain — FHE compute + TFHE bootstrap-key generation (encrypted EVM)
%% M-Chain is REMOVED entirely; teleport is B-Chain (bridgevm, LP-6000). No teleportvm.
%% Where this paper says "M-Chain MPC" / "M-Chain threshold governance" /
%% "M-Chain TFHE" / "M-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
%% ===================================================================

\section{Security Analysis}
\label{sec:security}

\subsection{Threshold Security}

\begin{theorem}[Threshold UX Security Equivalence]
The security of each Threshold UX pattern (approval flows, social recovery,
shared workspaces, treasury management, regulated access) is equivalent to
the security of the underlying threshold cryptographic primitive (FROST,
Shamir sharing, threshold decryption), under the assumption that the UX
layer is a faithful mapping (it does not weaken the threshold, bypass
quorum requirements, or leak key material through side channels).
\end{theorem}

\begin{proof}
Each UX pattern maps one-to-one to a threshold operation:
\begin{itemize}
    \item Approval tap $\leftrightarrow$ FROST partial signature
    \item Guardian confirmation $\leftrightarrow$ Shamir share release
    \item Workspace admin action $\leftrightarrow$ threshold decryption
    \item Spend authorization $\leftrightarrow$ threshold signature
    \item Compliance approval $\leftrightarrow$ threshold co-decryption
\end{itemize}
The UX layer transforms user input into the corresponding cryptographic
operation without modification. No additional attack surface is introduced
beyond what exists in the underlying protocol. The mapping is injective:
each user action produces exactly one cryptographic operation, and no
cryptographic operation can be triggered without the corresponding user action.
\end{proof}

\subsection{Social Engineering Resistance}

The primary new attack vector in Threshold UX is social engineering:
an attacker convinces $t$ guardians to approve a malicious recovery
or transaction. Mitigations:

\begin{enumerate}
    \item \textbf{Out-of-band verification prompts.} The system suggests
    (but cannot enforce) that guardians verify recovery requests via a
    different channel (phone call, in-person meeting).

    \item \textbf{Time delays.} Recovery operations include a mandatory
    waiting period (e.g., 48 hours) during which the legitimate user can
    cancel the recovery if they still have access.

    \item \textbf{Guardian diversity.} The system encourages selecting
    guardians from independent social circles (family, work, friends)
    to reduce the probability that an attacker has social access to
    $t$ guardians simultaneously.

    \item \textbf{Anomaly detection.} The M-Chain monitors recovery
    patterns and flags anomalies (e.g., recovery requested from a new
    geographic region, multiple recovery attempts in a short period).
\end{enumerate}

\begin{proposition}[Social Engineering Bound]
If guardians are drawn from $k$ independent social circles with at most
$\lfloor n/k \rfloor$ guardians per circle, and the threshold $t > \lfloor n/k \rfloor$,
then an attacker who infiltrates a single social circle cannot achieve
the threshold. Full social engineering requires simultaneous infiltration
of at least $\lceil t \cdot k / n \rceil$ independent circles.
\end{proposition}