Tresor – Backup-Plattform & App

Dateiinhalte werden bereits auf dem Gerät in authentifizierten AES-256-GCM-Chunks verschlüsselt. File-Key-Envelopes verwenden XChaCha20-Poly1305; Geräte registrieren X25519-Public-Keys und erhalten benötigte Schlüssel als verschlüsselte Envelopes.

Private Geräteschlüssel bleiben auf dem Endgerät. Unter Android wird das lokale Schlüsselmaterial zusätzlich über den Android Keystore geschützt. Die API erhält keine unverschlüsselten Dateiinhalte und muss für den eigentlichen Datenpfad keinen Klartext verarbeiten.

Die Laravel-API koordiniert Uploads, aber die verschlüsselten Bytes laufen nicht durch den Application Server. Kurzlebige Presigned URLs erlauben den direkten Transfer in privaten S3-kompatiblen Object Storage.

Kleinere Dateien nutzen Single PUT, größere Dateien Multipart-Uploads. SHA-256-Prüfsummen, Quota-Reservierung, Upload-Lifecycle, Cleanup und Reconciliation sorgen dafür, dass auch abgebrochene oder verwaiste Uploads kontrolliert behandelt werden.

Tresor verwaltet Geräte als eigene sicherheitsrelevante Entitäten. Access- und Refresh-Tokens werden getrennt behandelt und rotiert; aktive Web- und Mobile-Sessions bleiben sichtbar und Geräte können gezielt entkoppelt werden.

Das Produktziel ist bewusst wartungsarm: herunterladen, anmelden oder registrieren, Sicherung einrichten und danach nur noch bei einem echten Grund eingreifen. Auth-Recovery und Session-Lebenszyklen sind deshalb Teil der Kernarchitektur und nicht nur Komfortfunktionen.

Automatische Sicherung auf Android muss mit JobScheduler-Quoten, Background-Limits und Foreground-Service-Regeln umgehen. Die App kombiniert geplante Hintergrundjobs mit kontrollierten Foreground-Pfaden und Recovery-Mechanismen, damit Sicherungen auch bei großen Medienbeständen zuverlässig weiterlaufen.

Verschlüsselung, Hashing, Upload und Statusverwaltung sind dabei Teil derselben Verarbeitungskette. Der Fokus liegt nicht nur auf theoretischem Durchsatz, sondern auf robuster Verarbeitung unter den tatsächlichen Einschränkungen mobiler Betriebssysteme.

Die aktuelle Android-App ist nur der erste Client. Die Architektur ist darauf ausgelegt, dieselbe globale Account-Identität, dieselben Vaults und dieselbe Backend-Logik später auch unter iOS, macOS und Desktop zu verwenden, ohne pro Plattform getrennte Konten oder Identitätsmodelle aufzubauen.

Weitere Schwerpunkte sind eine noch stärkere Restore-Erfahrung, adaptive Verarbeitung großer Medienbibliotheken und eine Plattform, bei der Gerätewechsel oder zusätzliche Clients möglichst wenig manuelle Arbeit verursachen.