User Data Backup
How GetTrusted backups user data when requested.
Overview
We do not backup or restore enterprise data, we filter it out as managed personas and managed contacts can be recovered and should only be recovered through enterprise onboarding/recovery.
GetTrusted's Backup Flow creates encrypted, compressed backups of user data (contacts, personas, trust attestations) with deterministic key derivation for automatic backup recovery. The system uses HKDF-SHA256 for Backup Encryption Key (BEK) derivation, AES-256-GCM for encryption, and stores encrypted blobs in AWS S3 with zero-knowledge security.
Key Security Features:
Deterministic BEK Derivation: HKDF-SHA256(Master ID, passphrase) — always same BEK for recovery
Hardware-Backed BEK Storage: BEK stored in iOS Keychain / Android KeyStore after derivation
Zero-Knowledge Server: Backend stores encrypted blobs in S3, never sees plaintext
GZIP Compression: ~60% size reduction before encryption
AES-256-GCM Encryption: Authenticated encryption with nonce-based security
Automatic Backup Triggering: Data changes trigger automatic background uploads
Process Overview
Alice (an existing user) makes changes to her contacts or personas. The app automatically creates an encrypted backup and uploads it to AWS S3 via the GetTrusted backend.
Alice's Perspective (User with Automatic Backups)
Data export & field stripping
SDK queries local storage (contacts, personas, attestations).
Encrypted rows are decrypted with the database encryption key.
Device-specific fields are stripped:
Remove device_id
Remove created_at
Remove updated_at
Create BackupData structure: { master_id, contacts[], personas[], attestations[] }
Backend Perspective (GetTrusted API + AWS Services)
Process Flow Diagram
Cryptographic Security
BEK Derivation (HKDF-SHA256)
Deterministic Key Derivation:
HKDF-SHA256(Master ID, passphrase) → BEK
Security Properties:
Deterministic: Same Master ID + passphrase → same BEK (required for recovery)
Hardware-Protected Master ID: Master ID stored in Secure Enclave/StrongBox
User Knowledge Factor: Passphrase required (multi-factor security)
Standard KDF: HKDF-SHA256 is NIST-approved (RFC 5869)
One-Way: Cannot derive Master ID or passphrase from BEK
AES-256-GCM Encryption
Encrypted Blob Structure:
Security Properties:
Authenticated Encryption: Integrity and confidentiality guaranteed
Unique Nonce: Fresh random nonce per backup (no nonce reuse)
256-bit Key: BEK provides 256-bit security strength
Authentication Tag: 128-bit tag prevents tampering
AEAD: Encrypt-then-MAC integrated (NIST-approved)
Security Guarantees
Deterministic BEK for Recovery
Same Master ID + passphrase → same BEK
No random components in derivation (fully reproducible)
Required for automatic backup restoration on new device
HKDF-SHA256 ensures uniform distribution
Multi-Factor BEK Security
Hardware Factor: Master ID in Secure Enclave (cannot extract)
Knowledge Factor: User passphrase required
Attacker needs BOTH factors to decrypt backup
Breaking one factor insufficient for backup access
Zero-Knowledge Backend
Backend never sees BEK or plaintext data
S3 stores only encrypted blobs (opaque ciphertext)
Firestore stores only metadata (sizes, timestamps)
Backend compromise does NOT expose user data
Hardware-Protected BEK Storage
BEK stored in iOS Keychain / Android KeyStore
Hardware-level encryption automatically applied
Protected by device biometrics / passcode
Non-exportable from device hardware
Cleared on logout or backup disable
Field Stripping for Portability
Device-specific fields removed before backup
New device injects its own device_id on restore
Timestamps regenerated for new device
Clean migration across devices
Authenticated Encryption
AES-256-GCM provides integrity + confidentiality
Authentication tag prevents tampering
Modified ciphertext fails to decrypt
Nonce uniqueness prevents replay attacks
Compression Before Encryption
GZIP reduces plaintext size (~60% typical)
Compressed before encryption (standard practice)
Reduces S3 storage costs
Faster network transfer
Strategic Implications
Automatic Cross-Device Sync
Traditional problem:
User sets up new phone:
Manually re-add all contacts
Manually re-create personas
Lose trust attestation history
Hours of manual data entry
GetTrusted solution:
User recovers identity on new phone:
Enter passphrase (derives same BEK)
Automatic backup download from S3
Automatic restoration with BEK
All contacts, personas, attestations restored
Zero manual data entry
Zero-Knowledge Cloud Storage
Backend cannot:
Decrypt any backup data
Read contacts or personas
Access trust attestations
Derive BEK from encrypted blobs
Backend can:
Store encrypted blobs reliably (S3 durability)
Track backup metadata (sizes, timestamps)
Enable cross-device recovery (blob retrieval)
Audit access patterns (Firestore logs)
Last updated