Viele Anbieter von Online-Software werben mit „Verschlüsselung“ oder „Datenschutz“. Gemeint ist oft nur TLS (HTTPS) – also der Schutz der Leitung zwischen Browser und Server. Das ist notwendig, aber unvollständig, sobald sensible Inhalte (Akten, Notizen, Termine, Anhänge) auf dem Server im Klartext verarbeitet oder gespeichert werden.
Die KryptSuite der tuuva.systems GmbH umfasst drei Produkte auf gemeinsamer technischer Basis:
Dieser Artikel beschreibt, wie die KryptSuite Transportschutz und clientseitige Inhaltsverschlüsselung trennt – und was „Zero-Knowledge“ bei uns konkret bedeutet. Die Architektur gilt für alle drei Brands. Ausführliche Produktdokumentation am Beispiel kumppani: kumppani.app/sicherheit.html; Kriterien-Tabelle ohne Markennamen: Verschlüsselung im Vergleich.
TLS verschlüsselt die Übertragung. Ein Mitlesender auf dem Netzpfad sieht keinen Klartext – der Server am Ende der Verbindung schon, sobald die Anwendung die Daten entschlüsselt und weiterverarbeitet.
Inhaltsverschlüsselung (Ende-zu-Ende im hier beschriebenen Sinn) bedeutet: Sensible Inhalte werden im Browser verschlüsselt, bevor sie synchronisiert werden. Zentral liegen dann Chiffretexte. Ohne den vom Nutzer kontrollierten Schlüssel sind sie für den Betreiber nicht sinnvoll auswertbar.
Wer nur TLS nennt, beantwortet die Frage „Kann der Betreiber die Inhalte lesen?“ noch nicht. Wer clientseitige Verschlüsselung und Schlüsselhoheit beschreibt, schon.
Alle drei Apps nutzen die Web Crypto API des Browsers. Ver- und Entschlüsselung der Inhaltsdaten erfolgt auf dem Endgerät. Für strukturierte Datensätze gilt ein Hybrid-Ansatz: Pro Dokument ein eigener AES-GCM-256-Schlüssel; die Nutzlast wird damit verschlüsselt; der Dokumentenschlüssel wird wiederum mit dem Masterkey geschützt abgelegt. Es werden zufällige IVs verwendet.
Der Masterkey wird im Browser erzeugt. Optional schützt eine Passphrase ihn über PBKDF2 (SHA-512, hohe Iterationszahl, zufälliges Salt) und AES-KW (Key Wrap). Auf dem Server liegt keine ungeschützte Masterkey-Form. Dateianhänge werden vor dem Upload im Client verschlüsselt und als Binärstrom übertragen.
Technische Metadaten, die Sync und Indexierung brauchen, bleiben bewusst außerhalb der verschlüsselten Nutzlast – das ist dokumentiert und kein „heimlich Klartext“.
Unter Zero-Knowledge verstehen wir: Für die Inhaltsdaten der Kunden – Kalender- und Geschäftsinhalte, bei kumppani insbesondere personenbezogene Daten, Gesundheitsdaten (PHI) und Quasi-Identifikatoren in der Anwendung – hat der Betreiber keinen Klartextzugriff. Synchronisiert werden Chiffretexte.
Das gilt nicht für jede technische oder geschäftliche Information: Authentifizierung, Vertrags- und Abrechnungsdaten, Betrieb und Support sowie Daten bei Drittanbietern (z. B. Identity-Provider) liegen außerhalb dieses Kerns. Transparenz dazu steht in den Datenschutzhinweisen.
Nein – bezogen auf die genannten Inhaltsdaten: Ohne Masterkey sind sie für uns technisch nicht auswertbar. Das ist der Unterschied zu typischen serverzentrierten Web-Apps, die Klartext auf dem Server brauchen, um Suche, Logik und Auswertung zu betreiben.
Wer Anbieter vergleicht, sollte öffentlich prüfbare Aussagen zu diesen Punkten suchen:
Genau diese Kriterien stellt die Vergleichsseite auf kumppani.app dar – ohne Konkurrenten zu nennen, damit die Aussagen belegbar und wartbar bleiben. Sie gelten gleichermaßen für die Bewertung von konttori und kalendaro.
Clientseitige Inhaltsverschlüsselung schützt ruhende Daten in der zentralen Speicherung. Sie schützt nicht vor:
Ein seriöses Bedrohungsmodell nennt diese Grenzen. „Sicher“ ist Kontext, kein Slogan.
tuuva.systems GmbH – Anbieter der KryptSuite (kumppani, konttori, kalendaro).
← Zum Blog · kumppani · konttori · kalendaro
