Key Backup Security | Sigma Auth

Sigma Auth's key backup system is designed with security-first principles, ensuring that private keys remain protected even if servers are compromised.

Encryption Architecture

Client-Side Encryption

All encryption and decryption operations happen exclusively in the user's browser using the bitcoin-backup npm package:

npm install bitcoin-backup

import { encryptBackup, decryptBackup, detectBackupType } from 'bitcoin-backup';

// Encryption process (client-side only)
const encryptedBackup = await encryptBackup(privateKey, userPassword);
// Only the encrypted result is transmitted to servers

// Decryption process (also client-side only)
const privateKey = await decryptBackup(encryptedBackup, userPassword);

// Detect backup format
const backupType = detectBackupType(backupData);
// Returns: 'BapMaster' | 'BapMember' | 'OneSat' | 'WIF' | 'Unknown'

The bitcoin-backup package (GitHub) provides:

AES-256-GCM encryption with PBKDF2 key derivation
Support for multiple wallet formats (BAP, OneSat, WIF)
Automatic format detection
Zero server-side dependencies

Encryption Details

Algorithm: AES-256-GCM for authenticated encryption
Key Derivation: PBKDF2 with 300,000 iterations and random salt
Initialization Vector: Randomly generated for each backup
Authentication Tag: Prevents tampering with encrypted data

Never on Servers

The following data never touches the server:

User backup passwords
Unencrypted private keys
Key derivation materials
Decryption processes

Storage Security

Cloudflare KV Storage

Backups are stored using Cloudflare's KV system:

Encryption at Rest: All data encrypted by Cloudflare
Global Replication: Automatic geographic distribution
Access Control: Restricted to authenticated Sigma Auth workers
Automatic Expiration: 10-year TTL with automatic cleanup

Data Structure

Stored backup format (all encrypted):

{
  "version": 1,
  "algorithm": "aes-256-gcm",
  "ciphertext": "base64-encoded-encrypted-data",
  "iv": "base64-initialization-vector", 
  "tag": "base64-authentication-tag",
  "salt": "base64-pbkdf2-salt",
  "iterations": 300000
}

Access Patterns

Keyed by: OAuth provider ID + hashed user identifier
No personal data: Only encrypted blobs and OAuth mappings
Rate limited: 5 attempts per hour per OAuth identity
Audit logged: All access attempts recorded

Authentication Security

OAuth Provider Verification

Before allowing backup access:

Valid OAuth token required from Google/GitHub
Token verification against provider's public keys
Identity mapping to internal backup identifier
Rate limiting applied per OAuth identity

Multi-Factor Protection

The backup system requires multiple factors:

OAuth account access (something you have)
Backup password knowledge (something you know)
Browser capability (something you are - client-side decryption)

Session Security

Short-lived sessions - 10 minute maximum
No persistent tokens stored for backup access
Fresh OAuth verification required for each restore
Automatic logout after successful restore

Threat Model Analysis

Server Compromise

Scenario: Sigma Auth servers are completely compromised Impact: ✅ No private keys exposed

Encrypted backups are useless without user passwords
OAuth mappings reveal no personal information
Attackers cannot decrypt existing backups

Database Breach

Scenario: Cloudflare KV storage is compromised Impact: ✅ No private keys exposed

All stored data is encrypted with user passwords
No password hints or recovery mechanisms stored
Brute force attacks are computationally infeasible

OAuth Provider Compromise

Scenario: Google or GitHub is compromised Impact: ⚠️ Limited exposure

Attackers could access encrypted backups
Still requires backup password for decryption
Users should rotate backup passwords if OAuth is compromised

Man-in-the-Middle Attacks

Scenario: Network traffic is intercepted Impact: ✅ No private keys exposed

All communication over HTTPS/TLS
Only encrypted backups transmitted
No sensitive data in URLs or headers

Client-Side Attacks

Scenario: User's browser/device is compromised Impact: ⚠️ Potential exposure during active use

Private keys exist in memory during decryption
Malware could capture passwords during entry
Mitigation: Use secure, updated browsers

Cryptographic Implementation

Key Derivation Function

// PBKDF2 parameters
const iterations = 300000;  // OWASP recommended minimum
const keyLength = 32;       // 256 bits for AES-256
const hashAlgorithm = 'SHA-256';
const salt = crypto.getRandomValues(new Uint8Array(16)); // 128-bit salt

Encryption Process

// Simplified encryption flow
async function encryptBackup(privateKey, password) {
  const salt = crypto.getRandomValues(new Uint8Array(16));
  const key = await crypto.subtle.importKey(/* PBKDF2 derivation */);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  
  const encrypted = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    key,
    new TextEncoder().encode(privateKey)
  );
  
  return { ciphertext, iv, tag, salt, iterations: 300000 };
}

Random Number Generation

Browser crypto.getRandomValues() for all random data
Cryptographically secure random number generation
Unique values for each encryption operation
No predictable patterns in generated data

Audit and Monitoring

Security Logging

All backup operations are logged:

Backup creation: OAuth identity, timestamp, success/failure
Restore attempts: OAuth identity, timestamp, success/failure
Failed decryptions: Rate limiting triggers, timing
No sensitive data: Passwords, keys, or personal info never logged

Monitoring Alerts

Automated monitoring for:

Unusual access patterns: Multiple failed attempts
Geographic anomalies: Access from unexpected locations
Rate limit violations: Potential brute force attempts
System errors: Encryption/decryption failures

Incident Response

In case of security incidents:

Immediate isolation of affected components
User notification if personal data potentially affected
Backup rotation recommendations for affected users
Security patch deployment and verification

Best Practices for Users

Password Security

12+ character passwords with mixed case, numbers, symbols
Unique passwords not used for other services
Password manager storage recommended
Regular rotation if OAuth account compromised

Device Security

Updated browsers with latest security patches
Avoid public computers for backup operations
Private browsing mode on shared devices
Clear browser data after sensitive operations

Account Security

Enable 2FA on OAuth provider accounts
Monitor OAuth activity for suspicious logins
Use strong OAuth passwords as they protect Bitcoin identity
Regular security reviews of connected applications

Compliance Considerations

Privacy Regulations

GDPR compliance: Users can delete all data instantly
Data minimization: Only encrypted backups stored
No personal profiling: No behavioral tracking
Transparent processing: Clear documentation of data handling

Security Standards

OWASP guidelines: Followed for web application security
Cryptographic standards: NIST-recommended algorithms
OAuth 2.0 security: RFC 6749 and security BCP compliance
Transport security: TLS 1.3 minimum for all communications

✅ Client-side encryption implementation
✅ Secure key derivation parameters
✅ Proper random number generation
✅ OAuth token verification
✅ Rate limiting and monitoring
✅ Secure storage configuration
✅ Incident response procedures
✅ Privacy compliance measures

Regular Reviews

Quarterly security assessments of backup system
Annual penetration testing by external security firms
Continuous monitoring of security best practices
Community security reviews through open source contributions

Next Steps

Implementation Guide - Add secure backup to your app
OAuth Restore Process - User-facing restore guide
Security Documentation - General security practices