Security Architecture
Understand BackupEngine's end-to-end encryption flow, data path isolation, and zero-trust design.
Security-First Design
BackupEngine was designed from the ground up with security as a foundational principle — not bolted on after the fact. Every component in the architecture enforces the principle that your data is encrypted before it leaves your device and that the server never has access to your encryption keys or plaintext data.
- •Client-side encryption: All files are encrypted on your device using AES-256-GCM before upload.
- •Zero-knowledge default: BackupEngine servers never see your encryption key or plaintext data.
- •Presigned URLs: Backup data flows directly from your device to cloud storage. It never passes through BackupEngine application servers.
- •End-to-end integrity: Every chunk is authenticated with GCM authentication tags. Tampering is detected on restore.
Data Flow Architecture
Understanding how data flows through the system is essential to understanding the security model. BackupEngine separates the control plane (metadata, authentication, orchestration) from the data plane (actual backup data).
- •Control plane (Supabase): Handles authentication, session management, backup metadata, chunk manifests, and scheduling. No backup data passes through this layer.
- •Data plane (iDrive e2): Stores encrypted backup chunks. The client uploads and downloads directly using presigned S3-compatible URLs.
- •Presigned URLs: The control plane generates short-lived (15-minute) presigned PUT and GET URLs. The client uses these to communicate directly with storage.
- •No server-side decryption: The control plane never has access to encryption keys. Even if the control plane were compromised, backup data would remain encrypted.
1. Client: Scan files -> FastCDC chunking -> Compress -> Encrypt (AES-256-GCM) 2. Client -> Control Plane: "I need to upload chunk abc123" (metadata only) 3. Control Plane -> Client: Presigned PUT URL (expires in 15 min) 4. Client -> Storage (direct): Upload encrypted chunk via presigned URL 5. Client -> Control Plane: "Chunk abc123 uploaded successfully" (metadata only) Data never touches the control plane. The presigned URL is the only intermediary, and it grants time-limited, single-use access to storage.
Authentication and Authorization
BackupEngine uses multiple layers of authentication to ensure that only authorized users and devices can access the system.
- •User authentication: Email/password, Google, Microsoft, or Apple OAuth via Supabase Auth.
- •MFA required: All users must enable TOTP-based Multi-Factor Authentication. There is no option to disable MFA.
- •Device keys: Each device registers a unique cryptographic key pair. API requests from agents include a device signature.
- •JWT tokens: Short-lived access tokens (1 hour) with refresh tokens for session management.
- •Row-Level Security (RLS): Supabase PostgreSQL enforces that users can only access their own data at the database level.
ℹ Note
Infrastructure Security
The infrastructure hosting BackupEngine is configured with security best practices at every layer.
- •All network communication uses TLS 1.3 with strong cipher suites.
- •Database connections use SSL/TLS with certificate verification.
- •Supabase Edge Functions run in isolated Deno sandboxes with no shared state between invocations.
- •Object storage (iDrive e2) enforces server-side encryption at rest in addition to the client-side encryption already applied.
- •Multi-region support: Users choose their data region (US, Canada, or EU) at signup. Data never leaves the chosen region.
- •No plaintext secrets in code: All secrets are managed through environment variables and secret managers.