TL;DR
Worklist nutzt ChaCha20-Poly1305-Verschlüsselung mit Zero-Knowledge-Architektur. Ihre Daten werden mit dokumentierten kryptografischen Verfahren auf Ihrem Gerät verschlüsselt, bevor sie unsere Server erreichen. Selbst mit vollem Datenbankzugriff können wir Ihre Aufgaben physisch nicht lesen. Ein von Ihnen gespeicherter Backup-Schlüssel kann den Zugriff einmalig wiederherstellen, wenn Sie Ihr Passwort verlieren, ohne Worklist einen Entschlüsselungsschlüssel zu geben. Die Architektur unterstützt DSGVO-Datenminimierung und kann bei technischen Schutzmaßnahmen für HIPAA/SOC 2 helfen, wenn die erforderlichen Vereinbarungen und operativen Kontrollen bestehen.
Unser Grundprinzip.
Ihre Daten werden auf Ihrem Gerät verschlüsselt, bevor sie unsere Server überhaupt erreichen. Wir haben Worklist so entworfen, dass wir — das Unternehmen — Ihre Arbeitslisten, Aufgaben und Kommentare nicht entschlüsseln, lesen oder darauf zugreifen können. Das nennen wir Zero-Knowledge-Architektur.
Was Worklist anders macht.
Klassische Aufgabenverwaltung.
Was die Konkurrenz tut
- • Speichert Ihre Daten im Klartext auf ihren Servern
- • Kann jede Aufgabe, jeden Kommentar und jede Datei lesen
- • Scannt Inhalte ggf. für Werbung, KI-Training oder „Features“
- • Anfällig für Datenlecks, die alles offenlegen
Worklist (Zero-Knowledge).
Was wir tun
- • Verschlüsselt auf Ihrem Gerät, bevor Daten an unsere Server gehen
- • Wir können Ihre Aufgaben nicht entschlüsseln, selbst wenn wir wollten
- • Kein Scannen, kein KI-Training mit Ihrer privaten Arbeit
- • Datenlecks legen nichts Brauchbares offen — nur verschlüsselte Blöcke
Wie Zero-Knowledge-Verschlüsselung funktioniert.
Sie erstellen Ihr Konto.
Bei der Registrierung verlässt Ihr Passwort den Browser nie im Klartext. Stattdessen:
- Wir verwenden das OPAQUE PAKE-Protokoll, damit unsere Server Ihr Klartextpasswort nie sehen
- Nach erfolgreicher Registrierung oder Anmeldung gibt OPAQUE Ihrem Browser einen geheimen Export Key, den wir nie erhalten
- Auf Ihrem Gerät wird ein zufälliger 32-Byte-„Data Key“ erzeugt
- Dieser Data Key wird lokal mit einem Wrapping Key verschlüsselt, der aus diesem OPAQUE Export Key abgeleitet wird
- Der verschlüsselte Data Key liegt auf unseren Servern — aber wir können ihn ohne das clientseitige Entsperrmaterial nicht entschlüsseln
- Sie können einen einmaligen Backup-Schlüssel herunterladen. Er verpackt denselben Data Key in Ihrem Browser; wir speichern nur einen verschlüsselten Wiederherstellungs-Wrapper
Kernpunkt: Entsperrschlüssel und Data Key werden in Ihrem Browser verarbeitet. Wir speichern nur verschlüsselte Wrapper, nie Klartextpasswörter oder Workspace-Schlüssel.
Warum den verschlüsselten Data Key überhaupt speichern?
Damit Sie sich von jedem Gerät anmelden können. Wenn Sie den Computer wechseln oder Ihr Telefon nutzen, senden wir den verschlüsselten Blob, Ihr Browser entsperrt ihn nach sicherer Anmeldung lokal, und Sie sind wieder drin. Ohne dieses Vorgehen müssten Sie einen 32-Byte-Schlüssel manuell zwischen Geräten kopieren — schreckliche UX bei gleicher Sicherheit.
Sie erstellen eine Arbeitsliste oder Aufgabe.
Jedes sensible Datenstück wird auf Ihrem Gerät verschlüsselt:
- Listentitel, Beschreibungen und Einstellungen
- Aufgabentitel, -inhalte, Checklisten und Kommentare
- Vorlagen für wiederkehrende Aufgaben und Zeitpläne
- Alles wird mit ChaCha20-Poly1305 AEAD verschlüsselt (eine moderne, geprüfte Chiffre)
- Jede Arbeitsliste hat einen eigenen, aus Ihrem Data Key abgeleiteten Schlüssel
Unsere Server speichern nur den verschlüsselten Ciphertext — den Klartext können sie nicht lesen.
Sie laden Teammitglieder ein.
Beim Teilen von Arbeitslisten mit Kolleg:innen:
- Jedes Mitglied erhält eine eigene verschlüsselte Kopie des Listenschlüssels
- Schlüssel werden per HPKE (Hybrid Public Key Encryption) ausgetauscht
- Öffentliche Schlüssel werden in einem Transparenz-Log (Merkle Tree) veröffentlicht, um Man-in-the-Middle-Angriffe zu verhindern
- Wird ein Mitglied entfernt, wird der Listenschlüssel rotiert und alle Verbleibenden bekommen neue verschlüsselte Kopien
Unsere Server prüfen, ohne zu entschlüsseln.
Sie fragen sich vielleicht: „Wenn der Server nicht entschlüsseln kann, wie setzt er Berechtigungen durch?“
Wir nutzen HMAC-Beweise — kryptografische Signaturen, die Ihre Zugriffsberechtigung belegen, ohne den Klartext preiszugeben.
- Ihr Browser berechnet einen HMAC (Keyed Hash) der verschlüsselten Daten mit einem mitgliedschaftsspezifischen Schlüssel
- Der Server validiert den HMAC, um Ihre aktive Mitgliedschaft zu bestätigen
- Manipulationen oder Replays fremder Daten scheitern an der HMAC-Prüfung
- Wir entschlüsseln den Inhalt nie — wir prüfen nur Integrität und Autorisierung
Was unsere Server (nicht) sehen.
Wir sehen NICHT
- × Listentitel oder Beschreibungen
- × Aufgabentitel, -inhalte oder Checklisten
- × Kommentare oder Diskussionen
- × Vorlagen für wiederkehrende Aufgaben
- × Beliebige Inhalte in verschlüsselten Paketen
- × Ihr Passwort (auch nicht als Hash)
Wir sehen
- ✓ E-Mail des Kontos (für die Anmeldung)
- ✓ Mitgliedschaftsbeziehungen (wer in welcher Liste ist)
- ✓ Aufgabenstatus (offen/erledigt) und Priorität
- ✓ Fälligkeitsdaten und Zeitstempel
- ✓ Delegationszuweisungen (nur Nutzer-IDs)
- ✓ Metadaten für Abfragen (IDs, Erstellungsdaten)
Warum manche Metadaten sichtbar sind: Bestimmte Felder (wie Aufgabenstatus und Fälligkeiten) müssen im Klartext liegen, damit Server Abfragen effizient filtern, Erinnerungen senden und Datenbank-Indizes pflegen können. Diese Felder enthalten keine sensiblen Inhalte — nur betriebliche Metadaten, die die App funktionsfähig machen.
Sicherheits garantien.
Passwortauthentifiziertes Entsperren (nur clientseitig).
Ihr Passwort verlässt Ihr Gerät nie im Klartext. Erfolgreiche OPAQUE-Authentifizierung gibt Ihrem Browser einen Export Key, der Ihren Data Key lokal entpackt. Dieser wird per HKDF zu eigenen Schlüsseln pro Arbeitsliste erweitert.
Server kann Inhalte nicht entschlüsseln.
Unser Backend-Code ruft nie Entschlüsselungsoperationen auf Nutzerdaten auf. Er validiert nur HMAC-Beweise zur Autorisierung.
Schlüsselrotation bei Mitgliederwechsel.
Wird ein Mitglied entfernt oder verlässt das Team, wird der Listenschlüssel rotiert. Alle Verbleibenden erhalten neue verschlüsselte Kopien, damit das ausgeschiedene Mitglied keine künftigen Inhalte entschlüsseln kann.
Transparenz für Einladungsschlüssel.
Öffentliche Schlüssel für Einladungen werden in einem Append-only-Merkle-Tree protokolliert. Clients prüfen Inklusions- und Konsistenzbeweise, sodass der Server keine Schlüssel heimlich austauschen kann.
Backup-Schlüssel bleiben Zero-Knowledge.
Ein Backup-Schlüssel wird in Ihrem Browser erzeugt und muss von Ihnen gespeichert werden. Er erstellt einen separaten verschlüsselten Wrapper für denselben Data Key; wir speichern nur die Recovery-Credential-Datei und den verschlüsselten Wrapper, sodass wir ohne diesen gespeicherten Schlüssel weder Ihr Passwort zurücksetzen noch Ihre Daten lesen können.
Open-Source-Kryptografie.
Wir setzen auf erprobte Bibliotheken: strong-box (ChaCha20-Poly1305), OPAQUE (Passwortauthentifizierung), HKDF (Schlüsselableitung), Argon2id (OPAQUE-Passworthärtung und Legacy-Migration) und HPKE (Schlüsselaustausch). Der gesamte Krypto-Code ist Open Source und prüfbar.
Wie wir unsere Sicherheit verifizieren.
Unsere Sicherheitsaussagen sind nachprüfbar, kein Marketing. So stellen wir sicher, dass die Zero-Knowledge-Architektur wie versprochen funktioniert:
- Open-Source-Krypto-Code auf GitHub, frei zugänglich für externe Sicherheitsprüfungen
- Erprobte Bibliotheken inklusive ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497) und HPKE
- Kryptografische Beweise (HMAC), die serverseitige Entschlüsselung mathematisch ausschließen
- Transparenz-Logs (Merkle Trees) zum Erkennen von Schlüssel-Substitutionsangriffen
- Clientseitiges Entsperren aus OPAQUE Export Keys sorgt dafür, dass wir Passwort und Schlüssel nie sehen
- Einmalige Backup-Schlüssel werden vom Nutzer erzeugt und gespeichert, nie von Worklist
Trade-offs von Zero-Knowledge.
Ein Backup-Schlüssel kann den Zugriff nach Passwortverlust wiederherstellen.
Speichern Sie einmal einen Backup-Schlüssel und bewahren Sie ihn privat auf. Wenn Sie Ihr Passwort verlieren, können Sie damit das Passwort zurücksetzen und den Zugriff auf verschlüsselte Daten behalten. Da Worklist keine Kopie speichert, bleiben Konten ohne gespeicherten Backup-Schlüssel nicht wiederherstellbar.
Keine serverseitige Suche.
Da Aufgabeninhalte verschlüsselt sind, können wir keine serverseitige Volltextsuche über alle Aufgaben anbieten. Die Suche läuft nach der Entschlüsselung in Ihrem Browser.
Abhilfe: Wir optimieren die Client-Suche mit indizierten Lookups und schneller Entschlüsselung, damit sie performant bleibt.
Technische Spezifikationen.
| Symmetrische Verschlüsselung | ChaCha20-Poly1305 AEAD (via strong-box Library) |
| Data-Key-Entsperrung | OPAQUE Export Key + HKDF-SHA256 — leitet lokale Wrapping Keys für den verschlüsselten Data Key ab |
| Schlüsselhierarchie | HKDF-SHA256 — leitet Listen- und Mitgliedschaftsschlüssel aus dem Data Key ab |
| Passwortauthentifizierung | OPAQUE PAKE (Ristretto255-Kurve) |
| Backup-Schlüssel | Ein aktiver einmaliger Backup-Schlüssel pro Nutzer; clientseitig erzeugt und vom Nutzer gespeichert |
| Schlüsselaustausch (Einladungen) | HPKE (Hybrid Public Key Encryption) mit X25519 |
| Integritätsbeweise | HMAC-SHA256 |
| Serialisierung | CBOR (Concise Binary Object Representation) |
| Schlüsselgröße | 256 Bit (32 Byte) für alle symmetrischen Schlüssel |
Alle kryptografischen Operationen laufen in Ihrem Browser über WebCrypto-APIs und geprüfte, aus Rust kompilierte WASM-Module.
Audits & Transparenz.
Open-Source-Krypto-Stack.
Unsere komplette kryptografische Implementierung ist Open Source und auf GitHub verfügbar. Wir laden Sicherheitsforscher:innen ausdrücklich zur Code-Prüfung ein.
Auf GitHub ansehenCompliance.
Unsere Zero-Knowledge-Architektur unterstützt DSGVO-Datenminimierung und kann bei technischen Schutzmaßnahmen für HIPAA oder SOC 2 helfen. Regulierte PHI erfordern weiterhin eine schriftliche Vereinbarung oder BAA sowie die operativen Kontrollen und Anbieterbestätigung, die Ihr Compliance-Programm verlangt.
Häufige Fragen.
Was passiert, wenn ihr gehackt werdet?
Verschafft sich jemand Zugriff auf unsere Datenbank, sieht er nur verschlüsselte Blöcke — im Grunde zufällige Bytes. Ohne Ihr passwortauthentifiziertes Entsperren oder einen gespeicherten Backup-Schlüssel lassen sich die Daten mit heutiger Technologie mathematisch nicht entschlüsseln.
Können Behörden euch zur Entschlüsselung zwingen?
Nein, weil wir es schlicht nicht können. Wir haben die Schlüssel nicht. Selbst mit Durchsuchungsbeschluss können wir nur die verschlüsselten Ciphertexte herausgeben — ohne Ihr passwortauthentifiziertes Entsperren oder einen von Ihnen gespeicherten Backup-Schlüssel sind sie wertlos.
Was passiert, wenn ich mein Passwort vergesse?
Wenn Sie einen Backup-Schlüssel gespeichert haben, können Sie ihn einmalig nutzen, um Ihr Passwort zurückzusetzen und den Zugriff auf verschlüsselte Daten zu behalten. Ohne gespeicherten Backup-Schlüssel kann Worklist die Daten nicht für Sie wiederherstellen.
Wie unterscheidet sich das von „encrypted at rest“?
„Encrypted at rest“ heißt, dass Daten auf den Servern verschlüsselt liegen — der Server hat aber die Entschlüsselungsschlüssel. Ende-zu-Ende-Verschlüsselung bedeutet, dass nur Sie (die Endpunkte) die Schlüssel haben — der Server hat nie Klartextzugriff.
Können Worklist-Mitarbeitende meine Daten sehen?
Nein. Unser Backend ist so gebaut, dass er Nutzerdaten nie entschlüsselt. Selbst Datenbankadmins mit Vollzugriff können Ihre Arbeitslisten oder Aufgaben nicht lesen.
Was, wenn ich meine Daten exportieren möchte?
Sie können Ihre entschlüsselten Daten jederzeit aus der App exportieren. Da die Entschlüsselung in Ihrem Browser läuft, erhalten Sie lesbare JSON-/CSV-Dateien — keine verschlüsselten Blöcke.
Referenzen & Standards.
Unsere kryptografischen Entscheidungen folgen Industriestandards und peer-reviewed Spezifikationen.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Unser Standard für symmetrische Verschlüsselung
- 02 RFC 9497: OPAQUE Asymmetric PAKE Protocol — Zero-Knowledge-Passwortauthentifizierung
- 03 RFC 9180: Hybrid Public Key Encryption (HPKE) — Schlüsselaustausch für Team-Einladungen
- 04 RFC 9106: Argon2 Memory-Hard Function — Passwortbasierte Schlüsselableitung
- 05 NIST SP 800-175B: Guideline for Using Cryptographic Standards — Bundesweite kryptografische Leitlinie
- 06 GDPR Article 32: Security of Processing — EU-Datenschutzanforderungen
Bereit für echten Datenschutz?
Schließen Sie sich Teams an, die Worklist vertrauen, ihre Arbeit wirklich privat zu halten. Kostenlos testen — ohne Kreditkarte.
Kostenlose Testphase startenSicherheitsfragen? Schreiben Sie uns an security@worklist.app