xLock: Universal Passwordless Authenticator

The Problem

Passwords are broken. TOTP is phishable. Password managers are a band-aid that manages a broken system. They store secrets on one device — a single point of failure. One breach = everything.

The average person manages 100+ passwords. Password managers like 1Password and LastPass consolidate them behind a single master password. That master password protects a vault — a centralized database of every credential you own. When LastPass was breached in 2022, attackers exfiltrated encrypted vaults for millions of users. The encryption held, but the architecture was exposed: one database, one key, one target.

TOTP (Google Authenticator, Authy) generates a 6-digit code from a shared symmetric secret stored on both the server and the user's device. A server breach exposes every user's TOTP seed. The attacker can generate valid codes indefinitely, from anywhere, without the user's device. The 30-second window and manual code entry create friction and phishing opportunities.

Apple Passkeys and FIDO2 hardware keys improve on TOTP with asymmetric cryptography, but they introduce new problems: platform lock-in (Apple Passkeys live in iCloud Keychain, unusable on Android), no recovery path (lose your FIDO2 key, lose your accounts), and device dependency (your authentication is only as available as your hardware).

The Core Failure

The PRIVATE.ME Solution

DID-based push auth + XorIDA-split passkeys via xStore. No master password. No password database. Ed25519 passkeys split across independent storage nodes. Approve login with one tap. No keys to steal. No database to breach.

xLock eliminates the password vault entirely. Instead of encrypting credentials behind a master password, xLock generates an Ed25519 keypair for each service. The private key (passkey) is immediately XorIDA-split into shares and distributed across independent storage backends via xStore. No single backend ever holds enough information to reconstruct the passkey.

When you need to authenticate, xLock reconstructs the passkey on-demand in memory, signs the authentication challenge, and immediately purges the key material. The passkey exists in plaintext for approximately 30 microseconds — long enough to sign, short enough that memory scraping is impractical.

Push-based approval means no TOTP codes, no code entry, no phishing surface. A third-party service sends a challenge to your DID via the xLink gateway. Your device shows a prompt: Approve or Deny. One tap. The Ed25519 signature covers the exact challenge ID, timestamp, and action — replay is impossible, forgery requires the private key that never persists anywhere.

The New Way

Architecture

Three storage nodes. 2-of-3 threshold. xStore pluggable backends. Passkeys reconstructed on-demand, signed, and purged. Zero plaintext persistence.

xLock uses xStore to distribute passkey shares across three independent storage backends. Any two of three shares are sufficient to reconstruct the passkey (2-of-3 threshold). Each backend is pluggable — local encrypted storage, cloud provider, hardware security module, or even a paper QR code. The backends are operationally independent: compromising one reveals zero information about the passkey.

Authentication Flow

Security Model

Information-theoretic split. HMAC integrity verification before reconstruction. Zero-knowledge backends. Ed25519 + Web Crypto API. AES encrypts and hopes. XorIDA splits and guarantees.

xLock's security rests on information-theoretic guarantees, not computational assumptions. XorIDA threshold sharing over GF(2) ensures that any single share reveals zero bits of information about the passkey — not "hard to crack" but mathematically impossible to learn anything. This holds regardless of the attacker's computational power, including quantum computers.

Security Properties

HMAC Before Reconstruction

Every share carries an HMAC-SHA256 integrity tag computed at split time. Before XorIDA reconstruction, both shares are independently HMAC-verified. If either tag fails, reconstruction is aborted and the share is rejected. This prevents tampered shares from producing corrupted passkeys. The HMAC verification uses timingSafeEqual() to eliminate timing side-channels.

The Fundamental Difference

Comparison

How xLock compares to existing authentication solutions across security, usability, and recovery.

Integration

QR scan registration, xlock:// deep links, WebAuthn API compatibility. Drop-in replacement for existing authentication flows.

xlock:// URI Format

// Registration
xlock://register?service=acme.com&challenge=base64url&callback=https://acme.com/auth/callback

// Authentication
xlock://auth?service=acme.com&challenge=base64url&did=did:key:z6Mk...

// Recovery initiation
xlock://recover?service=acme.com&did=did:key:z6Mk...

Registration Flow

import { XlockVerifier } from '@private.me/xlock';

// 1. Generate a registration challenge
const verifier = new XlockVerifier({ origin: 'https://acme.com' });
const challenge = await verifier.createRegistrationChallenge();

// 2. Display QR code or open xlock:// deep link
//    User scans QR → xLock generates Ed25519 keypair
//    → XorIDA-splits private key across xStore backends
//    → Returns public key (DID) to service

// 3. Verify the registration response
const result = await verifier.verifyRegistration(response);
if (result.ok) {
  // Store result.value.did as the user's identity
  // did:key:z6Mk... — the Ed25519 public key
  await saveUserDid(userId, result.value.did);
}

import { XlockVerifier } from '@private.me/xlock';

// 1. Create auth challenge for a known DID
const challenge = await verifier.createAuthChallenge({
  did: userDid,
  action: 'Sign in to Acme Dashboard',
  metadata: { ip: '203.0.113.42', location: 'San Francisco' }
});

// 2. Challenge is pushed to user's device via xLink gateway
//    User sees: "Acme Dashboard wants to sign you in"
//    User taps Approve → xLock reconstructs passkey → signs → purges

// 3. Verify the signed response
const result = await verifier.verifyAuth(challenge.id);
if (result.ok && result.value.approved) {
  // Signature verified — user authenticated
  grantAccess(userId);
}

Enhanced Identity with Xid

xLock can optionally integrate with Xid to enable unlinkable authentication sessions — verifiable for the current session, but uncorrelatable across different devices, locations, or time periods.

Three Identity Modes

How Ephemeral Sessions Work

In xLock+ mode, each authentication session derives a unique DID via HKDF from the user's XorIDA-split master seed:

// User initiates authentication on mobile device
const challenge = await xlock.createChallenge({
  resource: 'https://app.example.com/dashboard',
  ephemeral: true // Enable Xid integration
});

// User approves via biometric (Face ID / Touch ID)
const proof = await xlock.approve(challenge);

// Result: unique DID for this device + resource + epoch
proof.did // did:key:z6MkY... (ephemeral, ~50µs derivation)
// Same user auth from laptop → different DID
// Same user auth next week → different DID (epoch rotation)

Key Benefits

Enterprise

RBAC, append-only audit logs, compliance-ready, Docker deployment, air-gapped capable. Everything an enterprise needs to deploy passwordless authentication on their own infrastructure.

3-Role RBAC

CLI Commands

# Start the xLock auth server
xlock serve --port 4500
  → HTTP server on :4500 with RBAC + JSONL stores

# Register a new user passkey
xlock register --did "did:key:z6Mk..." --service "acme.com"
  → Generates Ed25519 keypair, XorIDA-splits, stores shares

# Verify an audit log chain
xlock verify --audit-log ./auth-audit.json
  → Replays HMAC chain, reports integrity

# Export compliance report
xlock export --from "2026-01-01" --to "2026-04-01" --format json
  → Authentication events, challenge outcomes, anomalies

# Rotate storage backend shares
xlock rotate --did "did:key:z6Mk..." --backend "node-c"
  → Re-splits passkey with new random shares, updates backend

Deployment

Multi-stage Alpine Docker build. Non-root user. Read-only filesystem. Health checks. docker compose up and your auth server is running on port 4500. Air-gapped deployment supported via docker save/load for environments with no internet connectivity.

Append-Only Audit Logs

Every authentication event is recorded in an append-only JSONL log with HMAC-SHA256 chain integrity. Each entry links to the previous via hash chain — tampering with any entry breaks the chain. Auditors can independently verify the entire log history using the xlock verify command.

Feature Tiers

Consumer tier is free during beta. Enterprise tier adds compliance, RBAC, and self-hosted deployment.

Verifiable Authentication

Every xLock authentication produces a verifiable audit trail via xProve. HMAC-chained integrity proofs confirm that passkeys were split correctly, reconstructed faithfully, and purged completely.

Benchmarks

Performance characteristics measured on Node.js 22, Apple M2. xLock completes the entire authentication pipeline in under 2 seconds — dominated by human tap latency, not cryptography.

Authentication Method Comparison

Developer Experience

Progressive feedback for every operation. 19 error codes across 5 categories guide developers to correct failures fast. UX helpers via @private.me/ux-helpers.

Progress Callbacks

All asynchronous operations support progress callbacks via the unified onProgress handler:

interface ProgressUpdate {
  operation: string;    // e.g., "requestXlockAuth", "respondXlockChallenge"
  step: string;         // Current step name
  progress: number;     // 0–100 percentage
  message: string;      // Human-readable status
}

type ProgressCallback = (update: ProgressUpdate) => void;

Error Codes

19 error codes across 5 categories. Every error includes a code, message, category, and actionable resolution:

interface DetailedError extends Error {
  code: string;         // Unique error code
  category: string;     // Error category
  resolution?: string;  // Suggested fix
  details?: any;        // Additional context
}

Challenge Management (4 codes)

Response Validation (4 codes)

Passkey Operations (5 codes)

Recovery (3 codes)

Platform Integration (3 codes)

Code Example: 1-Tap Push Authentication

import { requestXlockAuth, respondXlockChallenge } from '@private.me/xlock';

// SERVER: Request authentication from user
async function serverRequestAuth(userId: string) {
  const challenge = await requestXlockAuth({
    userId,
    timeout: 120000, // 2 minutes
    onProgress: (update) => {
      console.log(\`[\${update.progress}%] \${update.message}\`);
      // 0%: Generating challenge
      // 50%: Sending push notification
      // 100%: Awaiting response
    }
  });

  // Challenge sent — wait for user response
  return challenge;
}

// CLIENT: Respond to push notification
async function clientRespondToPush(challenge: string) {
  try {
    const response = await respondXlockChallenge({
      challenge,
      onProgress: (update) => {
        console.log(\`[\${update.progress}%] \${update.message}\`);
        // 0%: Reconstructing passkey
        // 25%: Signing challenge
        // 50%: Purging key material
        // 100%: Sending response
      }
    });

    console.log('✓ Authentication successful');
    return response;

  } catch (error) {
    // Typed error with category and resolution
    if (error.code === 'PASSKEY_NOT_FOUND') {
      console.error(\`Error: \${error.message}\`);
      console.log(\`→ \${error.resolution}\`);
      // Resolution: "Verify passkey exists before authentication"

      // Generate new passkey
      await generatePasskey({
        userId,
        onProgress: (update) => console.log(update.message)
      });

    } else if (error.code === 'BIOMETRIC_REQUIRED') {
      console.error('Biometric unlock required');
      console.log(\`→ \${error.resolution}\`);
      // Resolution: "Enable biometric unlock for this device"

    } else if (error.code === 'CHALLENGE_EXPIRED') {
      console.error('Challenge expired — requesting new one');
      // Request fresh challenge from server

    } else {
      console.error(\`Unexpected error: \${error.message}\`);
    }
  }
}

// TYPICAL FLOW (1-3 seconds total)
// Server: Generate challenge → ~1ms
// Server: Send push → ~200-500ms
// Client: Receive push → ~0ms (platform handles)
// User: Tap notification + biometric → ~500-2000ms (human latency)
// Client: Reconstruct passkey → ~30µs
// Client: Sign challenge → ~1ms
// Client: Purge key material → ~1µs
// Server: Verify signature → ~1ms
// ✓ Authenticated

Ship Proofs, Not Source

xLock generates cryptographic proofs of correct execution without exposing proprietary algorithms. Verify integrity using zero-knowledge proofs — no source code required.

Use Cases

Honest Limitations

Six known limitations documented transparently. xLock’s push-based model trades offline capability for phishing resistance.

Ready to deploy xLock?

Talk to Sol, our AI platform engineer, or book a live demo with our team.