Accountable authentication with privacy protection: The Larch system for universal login

TL;DR

Credential compromise is hard to detect and mitigates poorly, and centralized SSO exposes users to privacy risks. Larch introduces an auditable, privacy-preserving authentication log that operates with existing RPs supporting FIDO2, TOTP, or passwords by splitting the authentication secret between the client and a log service. It employs split-secret authentication protocols, zero-knowledge proofs, and a two-party ECDSA with preprocessing (plus garbled circuits for TOTP) to ensure that every successful authentication is logged without revealing RP identity, and that the log cannot authenticate on behalf of the user. The implementation demonstrates practical latency, modest storage, and favorable throughput, and the approach enables broad adoption of FIDO2-like security without requiring changes to relying parties or centralized identity providers.

Abstract

Credential compromise is hard to detect and hard to mitigate. To address this problem, we present larch, an accountable authentication framework with strong security and privacy properties. Larch protects user privacy while ensuring that the larch log server correctly records every authentication. Specifically, an attacker who compromises a user's device cannot authenticate without creating evidence in the log, and the log cannot learn which web service (relying party) the user is authenticating to. To enable fast adoption, larch is backwards-compatible with relying parties that support FIDO2, TOTP, and password-based login. Furthermore, larch does not degrade the security and privacy a user already expects: the log server cannot authenticate on behalf of a user, and larch does not allow relying parties to link a user across accounts. We implement larch for FIDO2, TOTP, and password-based login. Given a client with four cores and a log server with eight cores, an authentication with larch takes 150ms for FIDO2, 91ms for TOTP, and 74ms for passwords (excluding preprocessing, which takes 1.23s for TOTP).

Figures (10)

• Figure 1: The client and log service run split-secret authentication where the client obtains the credential for amazon.com and the log service obtains an encryption of amazon.com under the client's key. The client's inputs are its share $x$ of the authentication secret, the archive key $k$, a random nonce $r$, and the string amazon.com. The log's inputs are its shares $y_\texttt{amazon}, \dots, y_\texttt{google}$ of all the client's authentication secrets and the commitment $\mathsf{cm}$ to the archive key generated at enrollment. The $\mathsf{MakeCred}$ function takes extra inputs for FIDO2 and TOTP.
• Figure 2: Larch security goals.
• Figure 3: On the left, larch FIDO2 latency decreases as the number of client cores increases (latency is independent of the number of relying parties). In the center, larch password latency grows with the number of relying parties, with the majority of the time spent on client proof generation. On the right, larch TOTP latency grows with the number of relying parties, with the majority of the time spent in an input-independent "offline" phase as opposed to the input-dependent "online" phase (both phases require network communication).
• Figure 4: On the left, per-client storage overhead at the log decreases as presignatures are replaced with authentication records (client enrolls with 10K presignatures). On the right, minimum cost of supporting more authentications with passwords, (128 relying parties), FIDO2, and TOTP (20 relying parties). Both axes use a logarithmic scale.
• Figure 5: Communication for larch with passwords increases logarithmically with the number of relying parties (both axes use a logarithmic scale).

Theorems & Definitions (9)

• Theorem 1
• proof
• Lemma 2
• Lemma 3
• proof
• Claim 4
• proof
• Theorem 5
• proof