mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
abf99d05fc
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.
80 lines
3.2 KiB
TeX
80 lines
3.2 KiB
TeX
\section{Progressive Security}
|
|
\label{sec:progressive}
|
|
|
|
New users should not face threshold setup on day one. A notes app with three
|
|
entries does not need 2-of-3 guardian recovery. A wallet with \$10 does not
|
|
need multi-party spend approval. Progressive security matches the security
|
|
model to the value at risk.
|
|
|
|
\subsection{Security Tiers}
|
|
|
|
\begin{definition}[Progressive Security Model]
|
|
A progressive security model $\mathcal{S} = \{(\nu_1, \Phi_1), (\nu_2, \Phi_2), \ldots\}$
|
|
maps value thresholds $\nu_i$ to security configurations $\Phi_i$. When the
|
|
value protected by a capsule crosses threshold $\nu_i$, the system prompts
|
|
the user to upgrade to configuration $\Phi_i$.
|
|
\end{definition}
|
|
|
|
Typical progression:
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{Progressive security tiers with automatic upgrade prompts.}
|
|
\label{tab:progressive}
|
|
\begin{tabular}{llll}
|
|
\toprule
|
|
\textbf{Tier} & \textbf{Trigger} & \textbf{Auth} & \textbf{Recovery} \\
|
|
\midrule
|
|
Basic & Account creation & Device key only & Email recovery \\
|
|
Standard & $>$ 100 records or \$100 & Device + passphrase & 2-of-3 guardians \\
|
|
Enhanced & $>$ 1000 records or \$10,000 & Device + biometric & 3-of-5 guardians \\
|
|
Maximum & $>$ \$100,000 & Hardware key + biometric & 3-of-5 + time lock \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsection{Upgrade Protocol}
|
|
|
|
When a user's capsule crosses a value threshold, the upgrade prompt appears:
|
|
``Your account now holds significant value. We recommend adding recovery
|
|
contacts for additional security. [Set Up Now] [Remind Me Later].''
|
|
|
|
If the user accepts:
|
|
|
|
\begin{enumerate}
|
|
\item The system generates a new $(t, n)$ sharing of the capsule key
|
|
appropriate for the new tier.
|
|
\item The user selects guardians (or the system suggests contacts based
|
|
on communication frequency, with user confirmation).
|
|
\item Guardian shares are distributed as described in Section~\ref{sec:recovery}.
|
|
\item The old security configuration is replaced. If the previous tier
|
|
had no threshold (1-of-1), this is the first introduction of threshold
|
|
cryptography---but the user experiences it as ``adding recovery contacts,''
|
|
not ``distributing Shamir shares.''
|
|
\end{enumerate}
|
|
|
|
\begin{remark}
|
|
The ``Remind Me Later'' option is genuine: users are never forced to upgrade.
|
|
However, the system records the refusal and surfaces the prompt again after
|
|
a reasonable interval (e.g., 30 days) or after the next significant value
|
|
increase. The balance between security nudging and user autonomy is a
|
|
product design decision, not a cryptographic one.
|
|
\end{remark}
|
|
|
|
\subsection{Downgrade Prevention}
|
|
|
|
Once a user upgrades to a threshold security tier, downgrading to a lower
|
|
tier requires approval from the current threshold. A user cannot unilaterally
|
|
remove their guardians, because the entire point of threshold security is
|
|
that no single party (including the user alone at the enhanced tier) can
|
|
make unilateral security decisions.
|
|
|
|
\begin{proposition}[Downgrade Resistance]
|
|
Under the progressive security model, downgrading from tier $\Phi_i$ with
|
|
threshold $t_i$ to tier $\Phi_j$ with threshold $t_j < t_i$ requires
|
|
$t_i$ approvals. An adversary who compromises the user's device (one share)
|
|
cannot downgrade to single-signer mode without $t_i - 1$ additional
|
|
compromises.
|
|
\end{proposition}
|
|
|