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. Fachartikel auf der Betreiber-Website: Ende-zu-Ende-Verschlüsselung in der KryptSuite. Zur Einordnung gegenüber typischen Web-PVS-Architekturen (ohne Markennamen) siehe Verschlüsselung im Vergleich.
kumppani ist eine Ende-zu-Ende-verschlüsselte Online-Praxissoftware. Inhaltsdaten werden im Browser mit der Web Crypto API (AES-GCM 256) verschlüsselt. Der Server speichert Chiffretexte, nicht die Akte im Klartext. Der Masterkey entsteht im Client; der Betreiber hat keinen Klartextzugriff auf Inhaltsdaten. TLS schützt nur den Transport; At-Rest mit Betreiberschlüssel wäre die übliche Pflichtübung, nicht dieselbe Aussage.
Aktualisiert: 8. September 2026Zero-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.
„Technisch“ heißt hier: auch wenn wir es wollen, nicht: Support bekommt sie in der Oberfläche nicht angezeigt. Es gibt keine serverseitige Freigabe, die uns die Akte lesbar macht.
Was heißt bei kumppani „technisch kein Zugriff“ – im Unterschied zu einer Support-Freigabe?
Bei kumppani heißt das: ohne euren Masterkey bleiben Inhaltsdaten Chiffretext, auch für Admins mit Zugang zu Server und Datenbank. „Support sieht nur, was du freigibst“ ist dagegen oft eine Richtlinie für Mitarbeiter; wer die Schlüssel des Systems hält, kann denselben Klartext in der Regel auch ohne Freigabe lesen.
Das Wort „technisch“ soll Laien Unmöglichkeit vorgaukeln, wenn nur die Support-Ansicht gemeint ist. Die Prüffrage bleibt: Kann der Betreiber die Akte lesen, wenn er es will?
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), At-Rest und Inhaltsschutz
TLS (HTTPS) verschlüsselt die Verbindung zwischen Browser und Server. Das schützt unterwegs mitlesende Dritte. Für Gesundheitsdaten gilt zusätzlich die Verschlüsselung ruhender Daten als Stand der Technik; TLS allein reicht dafür nicht. Üblich ist At-Rest mit Schlüsseln des Betreibers – Pflichtübung nach Art. 32 DSGVO, aber der Anbieter kann entschlüsseln, sobald die Anwendung die Daten braucht.
Was ist der Unterschied zwischen TLS, At-Rest und clientseitiger Verschlüsselung?
TLS schützt die Übertragung. Verschlüsselung ruhender Daten mit Schlüsseln des Betreibers ist für Gesundheitsdaten Stand der Technik; der Betreiber kann trotzdem entschlüsseln. kumppani verschlüsselt Inhaltsdaten im Browser (AES-GCM), damit ruhende Daten ohne den Masterkey des Kunden nicht lesbar sind.
kumppani trennt bewusst: TLS für den Transport, AES-GCM im Browser für die ruhenden Inhaltsdaten. So schützt ihr die Akte auch gegen den Betreiber – nicht nur gegen den Diebstahl einer Festplatte.
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.