TL;DR
SealTask verschlüsselt lesbare Workspace-Inhalte vor der Synchronisierung auf Ihrem Gerät mit ChaCha20-Poly1305. Der Dienst besitzt nicht die nötigen Schlüssel zur Entschlüsselung, verarbeitet aber Konto-, Abrechnungs-, Sicherheits-, Audit-, Service- und Workspace-Metadaten. Ein gespeicherter Backup-Schlüssel kann den Zugriff nach Passwortverlust einmalig wiederherstellen. Für regulierte Nutzung bleiben Verträge und Kontrollen erforderlich.
Sicherheitsbegriffe sollten eine Grenze beschreiben – nicht nur eine Aussage schmücken.
Begriffe aus den Sicherheits-, Ratgeber-, Vergleichs- und Vorfallseiten von SealTask. Begriffe mit ausführlicher Erklärung verlinken auf ihre kanonische Seite.
Gesamtes Learning Center ansehenUnser Grundprinzip.
Lesbare Workspace-Inhalte werden auf Ihrem Gerät verschlüsselt, bevor sie unsere Server erreichen. SealTask kann Klartext von Aufgaben, Notizen, Kommentaren, Checklisten, Listentiteln oder Anhängen nicht entschlüsseln. Die unten genannten Metadaten verarbeitet der Dienst weiterhin. Diese Inhaltsgrenze nennen wir Zero-Knowledge-Architektur.
Was SealTask 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“
- • Ein Vorfall oder autorisierter Zugriff kann lesbare Inhalte und Metadaten offenlegen
SealTask (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
- • Ein Datenbankvorfall kann Ciphertext und Metadaten offenlegen, aber ohne clientseitige Schlüssel keine lesbaren Workspace-Inhalte
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.
Lesbare Workspace-Inhalte werden auf Ihrem Gerät verschlüsselt; Betriebsmetadaten bleiben serverseitig sichtbar:
- Titel und Beschreibungen von Arbeitslisten
- Aufgabentitel, -inhalte, Checklisten und Kommentare
- Der Inhalt wiederkehrender Aufgabenvorlagen ist verschlüsselt; Cron-Plan, Zeitzone, Aktivstatus, Iteration und Materialisierungszeitpunkte bleiben serverseitig sichtbar
- 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
Der Server speichert verschlüsselte Workspace-Payloads und die offengelegten Betriebsmetadaten; ohne clientseitige Schlüssel kann er den verschlüsselten Klartext 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 Einladungsschlüssel werden in einem Merkle-Transparenzprotokoll erfasst. Ein zuvor vertrauenswürdiger Checkpoint kann bei der Prüfung eine Abweichung sichtbar machen; der aktuelle Client bleibt jedoch nicht Fail-closed und bewahrt diese Erkennung nicht: Er kann den Checkpoint verwerfen und ab Genesis neu prüfen
- Wenn Sie eine Person entfernen, wird ihr serverautorisierter Zugriff auf die Liste widerrufen. Der Server, der die Änderung committet, signalisiert aktive Echtzeit-Streams nach dem Commit; Änderungen auf einem anderen Server sowie gebündelte oder nicht signalisierte Änderungen werden spätestens innerhalb von 30 Sekunden erneut geprüft. Bereits ausgelieferte oder im Transport gepufferte Daten lassen sich nicht zurückrufen. Die aktuelle Version rotiert den Listenschlüssel nicht automatisch, verschlüsselt die Liste nicht neu und löscht keine zuvor erhaltenen Inhalte oder Schlüssel. Erstellen Sie für eine neue kryptografische Grenze eine neue Liste nur für aktuelle Mitglieder.
Der Server prüft die HMAC-Konsistenz, ohne den Payload zu entschlüsseln.
Datenbankstatus von Sitzung und aktiver Mitgliedschaft autorisieren den Zugriff. Ihr Browser leitet getrennt mit HKDF und einer festen Protokollkonstante aus dem Listenschlüssel einen listenspezifischen Payload-Bindungsschlüssel ab; derselbe Bindungsschlüssel wird für jede Mitgliedschaft kopiert und vom Server gespeichert.
Der Server prüft mit diesem Schlüssel einen HMAC über den Ciphertext. Der Nachweis belegt nur, dass der HMAC zu diesen Ciphertext-Bytes passt, ohne sie zu entschlüsseln.
- Ihr Browser leitet den listenspezifischen Bindungsschlüssel mit HKDF aus dem Listenschlüssel ab; er ist kein Schlüssel zur Entschlüsselung von Workspace-Inhalten
- Der Server prüft die authentifizierte Sitzung und aktive Mitgliedschaft, bevor er die Anfrage autorisiert
- Der Server speichert den kopierten Bindungsschlüssel und kann damit passende HMACs über Ciphertext prüfen oder selbst berechnen
- Der HMAC belegt weder Aktualität noch Replay-Schutz, eine Bindung an Entität oder Mitglied noch Authentizität gegenüber dem Server
Was unsere Server (nicht) sehen.
Wir sehen NICHT
- × Lesbare Aufgabentitel
- × Lesbare Aufgabentexte und Notizen
- × Lesbare Inhalte wiederkehrender Aufgabenvorlagen
- × Lesbare Kommentartexte
- × Lesbare Checklisteninhalte
- × Lesbare Listentitel und -beschreibungen
- × Klartext von Anhängen
- × Kontopasswörter im Klartext
- × Schlüssel zur Entschlüsselung von Workspace-Inhalten
Beispiele sichtbarer Workspace-Metadaten (nicht vollständig)
- ✓ 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)
- ✓ Salts und Nachweise je Mitgliedschaft sowie der serverseitig gespeicherte listenspezifische Payload-Bindungsschlüssel, mit dem der Server passende HMACs prüft oder berechnet; dies ist kein Schlüssel zur Entschlüsselung von Workspace-Inhalten
- ✓ Wiederholungsplan, Zeitzone, Aktivstatus, Iteration und Materialisierungszeitpunkte
- ✓ Anhangsbeziehungen, Speicherkennungen, Ciphertext-Größe, Status und Zeitstempel
- ✓ Echtzeit-Ereignistypen, Akteur- und Entitätskennungen, Namen geänderter Felder, Zeitstempel und Anzahlen verpasster Ereignisse
Umfang und Sensibilität: Die angezeigte Liste enthält nicht abschließende Beispiele für serverseitig sichtbare Workspace-Metadaten; sie ist kein vollständiges Verzeichnis der aktuellen Persistenz-, API-Antwort- oder SSE-Ereignismodelle. Sie ist auch kein vollständiges Datenschutzinventar: Kontoauthentifizierung, Abrechnung, Sicherheit und Audit, Missbrauchsprävention und Servicetelemetrie sind getrennte Bereiche, die in der Datenschutzerklärung nicht abschließend beschrieben werden. Metadaten können selbst sensibel sein. Die Ciphertext-Größe eines Anhangs entspricht meist ungefähr der ursprünglichen Dateigröße.
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.
Der Server kann verschlüsselte Workspace-Payloads nicht entschlüsseln.
Das Backend entschlüsselt keine verschlüsselten Workspace-Payloads. Datenbankprüfungen von Sitzung und Mitgliedschaft autorisieren Anfragen. Mit dem gespeicherten listenspezifischen Bindungsschlüssel kann der Server einen zum Ciphertext passenden HMAC prüfen oder berechnen; das belegt Ciphertext-Konsistenz, nicht Aktualität, Replay-Schutz, eine Bindung an Entität oder Mitglied oder Authentizität gegenüber dem Server.
Zugriffsentzug ist begrenzt und wirkt nicht rückwirkend.
Wenn Sie eine Person entfernen, wird ihr serverautorisierter Zugriff auf die Liste widerrufen. Der Server, der die Änderung committet, signalisiert aktive Echtzeit-Streams nach dem Commit; Änderungen auf einem anderen Server sowie gebündelte oder nicht signalisierte Änderungen werden spätestens innerhalb von 30 Sekunden erneut geprüft. Bereits ausgelieferte oder im Transport gepufferte Daten lassen sich nicht zurückrufen. Die aktuelle Version rotiert den Listenschlüssel nicht automatisch, verschlüsselt die Liste nicht neu und löscht keine zuvor erhaltenen Inhalte oder Schlüssel. Erstellen Sie für eine neue kryptografische Grenze eine neue Liste nur für aktuelle Mitglieder.
Transparenz für Einladungsschlüssel.
Öffentliche Einladungsschlüssel stehen in einem append-only Merkle-Baum. Ein zuvor vertrauenswürdiger Checkpoint kann bei der Prüfung eine Abweichung sichtbar machen; der aktuelle Client kann ihn jedoch verwerfen und ab Genesis neu prüfen. Dieser Versuch und der Erstkontakt bleiben Vertrauensgrenzen, keine bedingungslose Kontinuitätsgarantie.
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 9807) und HPKE
- Der serverseitig gespeicherte listenspezifische Bindungsschlüssel ermöglicht es dem Server, einen zum Ciphertext passenden HMAC zu prüfen oder zu berechnen; Datenbankprüfungen von Sitzung und Mitgliedschaft autorisieren den Zugriff, während der HMAC weder Aktualität, Replay-Schutz, eine Bindung an Entität oder Mitglied noch Authentizität gegenüber dem Server belegt
- Merkle-Nachweise können eine Abweichung zu einem vertrauenswürdigen Checkpoint zeigen; der aktuelle Client kann ihn jedoch verwerfen und ab Genesis neu prüfen
- 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 SealTask
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 SealTask 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) |
| Zwei-Faktor-Authentifizierung | TOTP per Authenticator-App (RFC 6238) mit einmaligen Backup-Codes; optional pro Konto |
| 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 |
| Payload-Konsistenzkontrollen | 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 helfen. SealTask muss jeder Nutzung von PHI zuvor ausdrücklich schriftlich zustimmen. Soweit HIPAA gilt, müssen die Parteien vor der Nutzung eine HIPAA-konforme BAA abschließen. Verschlüsselung ist nur eine Schutzmaßnahme; Ihr Compliance-Programm muss die nötigen Betriebskontrollen und die Anbieterprüfung sicherstellen.
Häufige Fragen.
Was passiert, wenn Sie gehackt werden?
Ein Datenbankangreifer kann Ciphertext sowie Konto-, Routing-, Audit- und Workspace-Metadaten erhalten. Gespeicherte Workspace-Inhalte sind ohne clientseitige Schlüssel nicht lesbar; der Schutz hängt auch von Kryptografie, Clients und Schlüsselverwaltung ab.
Können Behörden Sie zur Entschlüsselung zwingen?
Eine rechtliche Anordnung kann Ciphertext und sichtbare Konto-, Abrechnungs-, Sicherheits-, Audit-, Service- und Workspace-Metadaten verlangen. Die Schlüssel zur Entschlüsselung lesbarer Workspace-Inhalte besitzen wir nicht.
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 SealTask 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 SealTask-Mitarbeitende meine Daten sehen?
Mitarbeitende und Datenbankadministratoren besitzen nicht die clientseitigen Schlüssel zur Entschlüsselung von Workspace-Payloads. Autorisierte Systeme und Personen können weiterhin auf die hier beschriebenen Metadaten zugreifen.
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.
Unterstützt SealTask Zwei-Faktor-Authentifizierung?
Ja. Sie können in den Sicherheitseinstellungen eine Zwei-Faktor-Authentifizierung per Authenticator-App (RFC 6238 TOTP) aktivieren und einmalige Backup-Codes speichern. Die Anmeldung erfordert dann Ihr Passwort und einen aktuellen Code. Dies schützt die Kontoanmeldung und ist von der clientseitigen Verschlüsselung getrennt, die Workspace-Inhalte schützt.
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 9807: The OPAQUE Augmented 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
- 07 RFC 6238 — TOTP — Zwei-Faktor-Authentifizierung
Bereit für echten Datenschutz?
Schließen Sie sich Teams an, die SealTask vertrauen, ihre Arbeit wirklich privat zu halten. Starten Sie mit Free — ohne Kreditkarte.
Kostenlos startenSicherheitsfragen? Schreiben Sie uns an security@sealtask.com