Auf dieser Seite fassen wir zusammen, wie kumppani sensible Inhalte schützt und was wir mit „Zero-Knowledge“ meinen. Für ausführlichere Einordnung und Hintergrund siehe auch die Rubrik Softwarearchitektur in den FAQ sowie die Datenschutzhinweise der tuuva.systems GmbH. Zur Einordnung gegenüber typischen Web-PVS-Architekturen (ohne Markennamen) siehe Verschlüsselung im Vergleich.
Zero-Knowledge und Inhaltsdaten
Unter „Zero-Knowledge“ verstehen wir bei kumppani: Für die Inhaltsdaten unserer Kunden – insbesondere personenbezogene Daten, Gesundheitsdaten (PHI) und Quasi-Identifikatoren im Sinne der von euch in der Anwendung erfassten und gespeicherten Inhalte – hat der Betreiber keinen Zugriff auf Klartext. Diese Daten werden im Browser verschlüsselt; in der synchronisierten Datenbank und im Dateispeicher liegen nur Chiffretexte, die ohne den vom Kunden kontrollierten Masterkey nicht sinnvoll ausgewertet werden können.
Abgrenzung: Nicht jede technische oder geschäftliche Information fällt unter diese Definition. Beispiele außerhalb des „Inhalts-Zero-Knowledge“-Kerns sind unter anderem Authentifizierung (z. B. Zugang zur App), Vertrags- und Abrechnungsdaten, Betriebs-, Sicherheits- und Support-Prozesse sowie Daten, die Drittanbieter (z. B. Identity-Provider) im Rahmen ihrer Leistung verarbeiten. Transparenz dazu findet sich in den Datenschutzinformationen.
Kann der Betreiber Inhaltsdaten im Klartext lesen?
Nein – bezogen auf die unter „Zero-Knowledge“ genannten Inhaltsdaten: Sie werden im Browser verschlüsselt; wir sehen in der Datenbank und im Dateispeicher nur Chiffretexte und haben keinen Zugriff auf euren Masterkey in offener Form. Ohne diesen Schlüssel sind die Inhalte für uns technisch nicht auswertbar.
Architektur: Client-seitige Kryptografie
kumppani nutzt die Web Crypto API des Browsers (window.crypto.subtle).
Ver- und Entschlüsselung der Inhaltsdaten erfolgt auf dem Endgerät, bevor Daten zur
Synchronisation an die zentrale Datenbank übertragen werden. So entfällt ein klassischer Anwendungsserver,
der Patientendaten im Klartext verarbeiten müsste.
Für strukturierte Datensätze kommt ein Hybrid-Ansatz zum Einsatz: Pro Dokument wird ein eigener AES-GCM-256-Schlüssel erzeugt; die eigentliche Nutzlast wird damit verschlüsselt. Der zugehörige Schlüssel wird als JWK exportiert und wiederum mit dem Masterkey verschlüsselt abgelegt. Es werden zufällige IVs (96 Bit) verwendet. CouchDB-/PouchDB-interne Felder (z. B. mit Unterstrich Präfix) sowie ausgewählte technische Metadaten werden nicht in die verschlüsselte Nutzlast aufgenommen – das ist für Sync und Indexierung nötig und bewusst dokumentiert.
Transport (TLS) und Inhaltsschutz
TLS (HTTPS) verschlüsselt die Verbindung zwischen Browser und Server. Das schützt unterwegs mitlesende Dritte – ersetzt aber nicht eine clientseitige Inhaltsverschlüsselung: Ohne letztere können Daten auf dem Server in der Anwendungslogik wieder im Klartext anfallen, sobald sie verarbeitet werden.
kumppani trennt bewusst: TLS für den Transport, AES-GCM im Browser für die ruhenden Inhaltsdaten in der zentralen Speicherung. So schützt ihr eure Patienteninhalte auch gegen ein Auslesen der Datenbankkopie ohne Schlüssel – ein Szenario, das TLS allein nicht adressiert.
Masterkey und Passphrase
Der Masterkey (AES-GCM 256) wird im Browser erzeugt. Optional schützt ihr ihn mit einer Passphrase: Dabei wird ein Schlüssel für die Schlüsselumschließung (Wrap) mittels PBKDF2 abgeleitet – mit SHA-512, hoher Iterationszahl (800.000) und einem zufälligen Salt (256 Byte). Der Masterkey wird dann mit AES-KW (Key Wrap) exportiert und in gewrappte Form gespeichert; so liegt auf dem Server kein ungeschützter Masterkey vor.
Für den Alltag und die Offline-Nutzung wird der Masterkey nach erfolgreicher Einrichtung auch lokal im Browser vorgehalten, damit nicht bei jeder Sitzung erneut die Passphrase nötig ist. Das ist ein bewusster Kompromiss zwischen Sicherheit und Bedienbarkeit: Der Schutz der Cloud-Inhalte bleibt erhalten; gleichzeitig gilt wie immer der Schutz des Endgeräts (Malware, Diebstahl, lokaler Zugriff).
Wo wird der Schlüssel erzeugt?
Der Masterkey wird vollständig im Browser mit der Web Crypto API erzeugt
(generateKey für AES-GCM 256). Die Schlüsselableitung aus der optionalen
Passphrase (PBKDF2) und das Wrapping des Masterkeys (AES-KW) erfolgen ebenfalls im Client.
Auf dem Server liegt nur die gewrappte Darstellung plus Ableitungsparameter – nicht der
Klartext-Masterkey.
Dateien und Anhänge
Binärdaten (z. B. PDFs, Bilder) werden vor dem Upload im Client verschlüsselt und als application/octet-stream übertragen. IV und der für die Datei genutzte Schlüssel (verschlüsselt mit dem Masterkey) werden in den Metadaten des Dateidatensatzes gespeichert – der Speicher sieht ebenfalls nur Chiffretext.
Grenzen und Verantwortung
Keine Architektur ersetzt sichere Endgeräte, starke Passphrases, Backups des Masterkeys und vorsichtigen Umgang mit Phishing. Transportverschlüsselung (TLS) schützt die Übertragung; die hier beschriebene Inhaltsverschlüsselung schützt die ruhenden Daten in der zentralen Speicherung.
Was schützt Ende-zu-Ende-Verschlüsselung der Inhalte nicht?
End-to-End im hier beschriebenen Sinn schützt nicht vor:
- Malware oder kompromittierten Browsern – ein Angreifer mit Codeausführung auf dem Gerät kann Daten vor der Verschlüsselung oder nach der Entschlüsselung lesen.
- Phishing und Social Engineering – gestohlene Zugangsdaten oder Passphrases umgehen die Kryptografie.
- Physischem Zugriff auf ein entsperrtes Gerät oder auf lokale Browser-Speicher, in denen der Schlüssel für den Alltag vorgehalten wird.
- Verlust von Masterkey oder Passphrase – ohne Backup sind Daten nicht wiederherstellbar.
Diese Liste zu nennen ist Teil eines seriösen Bedrohungsmodells: Sie macht deutlich, dass „sicher“ nicht Marketing, sondern Kontext und Verhalten braucht.
System- und Konfigurationsdokumente mit Präfix internal/ durchlaufen in der Anwendung
nicht dieselbe automatische Feldverschlüsselung wie Patienteninhalte; dort liegen u. a.
schlüsselbezogene Konfigurationen in der dafür vorgesehenen Form (z. B. gewrappte Schlüsselmaterialien).
Glossar
Zero-Knowledge
Bei kumppani bezeichnet Zero-Knowledge die Inhaltsdaten der Kunden: PII, PHI und Quasi-Identifikatoren werden im Browser verschlüsselt; der Betreiber hat dafür keinen Zugriff auf Klartext.
Ende-zu-Ende-Verschlüsselung
Ende-zu-Ende-Verschlüsselung bedeutet hier, dass Inhaltsdaten vor der Synchronisation im Browser verschlüsselt werden und zentral nur als Chiffretexte vorliegen.
Masterkey
Der Masterkey ist der im Browser erzeugte Hauptschlüssel, mit dem weitere Datensatz- und Dateischlüssel geschützt werden; er wird nicht unverschlüsselt an den Server übertragen.
AES-GCM
AES-GCM ist das verwendete Verfahren für die Verschlüsselung strukturierter Inhaltsdaten und Dateianhänge mit 256 Bit und zufälligen IVs.
PBKDF2
PBKDF2 ist das Verfahren, mit dem aus einer optionalen Passphrase ein Wrapping-Schlüssel mit SHA-512, 800.000 Iterationen und zufälligem Salt abgeleitet wird.