Serverseitige vs. clientseitige Verschlüsselung: Welchem Modell solltest du vertrauen?

Serverseitige Verschlüsselung verschlüsselt Daten auf dem Server, nachdem er den Klartext empfangen hat — das erfordert Vertrauen in den Dienstanbieter. Clientseitige Verschlüsselung verschlüsselt Daten in deinem Browser, bevor sie gesendet werden, sodass der Server nie den Klartext sieht. Für das Teilen von Geheimnissen ist clientseitige Verschlüsselung sicherer, weil sie den Dienst als Vertrauenspunkt eliminiert — selbst ein kompromittierter Server kann deine Daten nicht lesen.

Dieser Beitrag vergleicht beide Ansätze: wie sie funktionieren, was jeder von dir verlangt zu vertrauen, und wo die echten Abwägungen liegen. Das ist kein Plädoyer für eine Seite — es ist ein Rahmen, um zu beurteilen, welches Modell zu deinem Bedrohungsmodell passt.

Für einen schnellen Überblick, warum clientseitige Verschlüsselung wichtig ist, lies unseren früheren Beitrag. Für eine detaillierte Betrachtung der spezifischen Implementierung von Vaulted, lies unseren Zero-Knowledge-Deep-Dive.

Wie serverseitige Verschlüsselung funktioniert

Im serverseitigen Modell übernimmt der Dienst die Verschlüsselung in deinem Namen. Der typische Ablauf:

Du gibst ein Geheimnis im Browser ein
Dein Browser sendet den Klartext über TLS an den Server
Der Server verschlüsselt die Daten mit einem Schlüssel, den er selbst verwaltet
Der Geheimtext wird in der Datenbank gespeichert
Wenn der Empfänger das Geheimnis anfordert, entschlüsselt der Server es und gibt den Klartext zurück

Der Verschlüsselungsschlüssel verlässt den Server nie. Er kann in einem Hardware Security Module (HSM), einem Cloud Key Management Service (KMS) oder einer Konfigurationsdatei liegen — aber der Server kontrolliert ihn vollständig.

Das serverseitige Vertrauensmodell

Bei serverseitiger Verschlüsselung vertraust du:

Dem Dienstbetreiber, deine Daten nicht zu lesen (er hat den Schlüssel und den Klartext im Speicher während der Ver- und Entschlüsselung)
Der Infrastruktur, nicht kompromittiert zu werden (ein kompromittierter Server legt sowohl Schlüssel als auch Daten offen)
Den Mitarbeitern des Betreibers, den Zugang nicht zu missbrauchen (jeder mit Serverzugang kann potenziell Geheimnisse lesen)
Der Rechtsprechung, keine Offenlegung zu erzwingen (der Betreiber kann zur Herausgabe von Daten gezwungen werden, weil er die Schlüssel hält)
Server-Logs und Monitoring, keinen Klartext zu erfassen (Logging-Frameworks können versehentlich sensible Daten aufzeichnen)

Das ist nicht zwangsläufig ein schlechtes Modell. Viele Dienste nutzen es erfolgreich — Cloud-Speicher, E-Mail-Anbieter und Datenbankdienste setzen alle auf serverseitige Verschlüsselung. Die Frage ist, ob der Kompromiss zu deinem Anwendungsfall passt.

Wie clientseitige Verschlüsselung funktioniert

Im clientseitigen Modell findet die Verschlüsselung im Browser statt, bevor irgendwelche Daten den Server erreichen. Der Ablauf ist anders:

Du gibst ein Geheimnis im Browser ein
Der Browser generiert einen Verschlüsselungsschlüssel und verschlüsselt die Daten lokal
Nur der Geheimtext wird an den Server gesendet
Der Verschlüsselungsschlüssel wird dem Empfänger über einen separaten Kanal übermittelt (typischerweise das URL-Fragment)
Der Browser des Empfängers entschlüsselt den Geheimtext lokal

Der Server sieht niemals den Klartext und hält niemals den Verschlüsselungsschlüssel. Er speichert und ruft verschlüsselte Datenpakete ab — mehr nicht.

Vaulted nutzt dieses Modell. Jedes Geheimnis erhält einen frischen AES-256-GCM-Schlüssel. Der Schlüssel wird im URL-Fragment (#) platziert, das Browser gemäß RFC 3986 nie in HTTP-Anfragen einschließen. Der Server empfängt den Geheimtext und einen zufälligen 12-Byte-IV zur Speicherung, aber der Schlüssel verbleibt vollständig in dem Link, der zwischen Sender und Empfänger geteilt wird.

Das clientseitige Vertrauensmodell

Bei clientseitiger Verschlüsselung vertraust du:

Dem Browser, Kryptografie korrekt zu implementieren (die Web Crypto API delegiert an native Krypto-Engines wie BoringSSL oder NSS)
Dem Anwendungscode, die Verschlüsselung tatsächlich clientseitig durchzuführen (das kannst du durch Inspektion der Netzwerkanfragen überprüfen)
Dem Link-Übermittlungskanal, sicher zu sein (jeder mit der vollständigen URL einschließlich Fragment kann das Geheimnis entschlüsseln)
Dem Gerät des Empfängers, nicht kompromittiert zu sein (nach der Entschlüsselung können Malware oder Bildschirmaufnahmen auf den Klartext zugreifen)

Du vertraust nicht dem Server, dem Dienstbetreiber, seinen Mitarbeitern oder seiner Rechtsprechung. Der Server ist ein Speicher-Relay für verschlüsselte Daten, die er nicht lesen kann.

Die Abwägungen im Vergleich

Kein Modell ist universell besser. Jedes trifft andere Abwägungen zwischen Sicherheit, Benutzerfreundlichkeit und Funktionsreichtum.

Sicherheitseigenschaften

Eigenschaft	Serverseitig	Clientseitig
Exposition bei Serverpanne	Schlüssel + Geheimtext offengelegt	Nur Geheimtext offengelegt (ohne Schlüssel wertlos)
Betreiber kann Daten lesen	Ja (hat die Schlüssel)	Nein (hat niemals Schlüssel)
Risiko rechtlicher Zwangsmaßnahmen	Betreiber kann nachkommen (hat Zugang)	Betreiber kann nicht nachkommen (hat keinen Zugang)
Risiko der Link-Abfangung	Nicht zutreffend (kein Schlüssel im Link)	Vollständige URL = vollständiger Zugang (durch Passphrase abgemildert)
Man-in-the-Middle	TLS schützt den Transit; Server sieht Klartext	TLS schützt den Geheimtext; Schlüssel im Fragment wird nie gesendet

Benutzerfreundlichkeitseigenschaften

Eigenschaft	Serverseitig	Clientseitig
Aufwand für Schlüsselverwaltung	Keiner für den Nutzer (Server übernimmt das)	Nutzer muss Link sicher teilen
Passwortwiederherstellung	Möglich (Server hält Schlüssel)	Nicht möglich (Schlüssel nur im Link)
Suche und Indexierung	Server kann Klartext durchsuchen	Ohne Entschlüsselung nicht möglich
Teilungsflexibilität	Server kann für neue Empfänger neu verschlüsseln	Neuer Link pro Empfänger erforderlich
Offline-Zugriff	Serververbindung zur Entschlüsselung erforderlich	Möglich, wenn Geheimtext und Schlüssel lokal gecacht sind

Funktionsabwägungen

Funktion	Serverseitig	Clientseitig
Audit-Logging des Inhalts	Möglich	Nicht möglich (Server kann Inhalt nicht lesen)
Inhaltsbasierte Richtlinien	Möglich (DLP, Compliance-Scanning)	Ohne Entschlüsselung nicht möglich
Schlüsselrotation	Server kann mit neuen Schlüsseln neu verschlüsseln	Erfordert Neugenerierung und erneutes Teilen der Links
Mehrseitige Zugriffskontrolle	Server kann Schlüssel pro Nutzer verwalten	Jeder Empfänger benötigt den Schlüssel direkt
Zero-Knowledge-Garantie	Nein	Ja

Wann serverseitige Verschlüsselung akzeptabel ist

Serverseitige Verschlüsselung ist eine vernünftige Wahl, wenn:

Du dem Dienstbetreiber und seinen Sicherheitspraktiken vertraust
Du Funktionen benötigst, die serverseitigen Datenzugang erfordern (Suche, Teilen, Compliance-Scanning)
Die Datensensibilität den Benutzerfreundlichkeitsaufwand der clientseitigen Verschlüsselung nicht rechtfertigt
Du in einem regulierten Umfeld arbeitest, wo die Compliance-Zertifizierungen des Betreibers wichtiger sind als Zero-Knowledge-Garantien
Die Komplexität der Schlüsselverwaltung vom Dienst und nicht vom Nutzer übernommen werden soll

Cloud-Speicherdienste, Enterprise-E-Mail und verwaltete Datenbankverschlüsselung nutzen dieses Modell alle effektiv.

Wann clientseitige Verschlüsselung notwendig ist

Clientseitige Verschlüsselung wird notwendig, wenn:

Du dem Dienstbetreiber deine Daten nicht anvertrauen kannst oder solltest
Die Daten sensibel genug sind, dass eine Serverpanne keinen Klartext offenlegen darf
Du eine Zero-Knowledge-Garantie benötigst — einen mathematischen Beweis, dass der Server deine Daten nicht lesen kann
Gesetzliche oder Compliance-Anforderungen verlangen, dass der Dienstbetreiber keinen Zugang zu Inhalten hat
Du Schutz vor Insider-Bedrohungen beim Dienstanbieter möchtest

Das sichere Teilen von Geheimnissen ist einer der stärksten Anwendungsfälle für clientseitige Verschlüsselung. Die Daten sind von Natur aus sensibel (Passwörter, API-Schlüssel, Zugangsdaten), das Teilen ist flüchtig (ansichtsbegrenzt, zeitbegrenzt), und die Vertrauensbeziehung ist minimal (du kennst den Dienstbetreiber möglicherweise nicht oder vertraust ihm nicht).

Wie Vaulted damit umgeht

Vaulted setzt ausschließlich auf clientseitige Verschlüsselung. Jedes Geheimnis wird im Browser mit einem frischen AES-GCM-Schlüssel verschlüsselt, bevor irgendwelche Daten den Server erreichen. Der Schlüssel reist nur im URL-Fragment, und ein optionaler Passphrase-Schutz fügt durch PBKDF2-Schlüsselableitung und AES-KW-Key Wrapping eine zweite Schicht hinzu.

Der Server speichert den verschlüsselten Geheimtext mit einer Ablaufzeit und einem Ansichtszähler. Er kann den Inhalt nicht entschlüsseln, durchsuchen oder inspizieren. Eine vollständige Datenbankpanne liefert nur verschlüsselte Datenpakete — rechnerisch nutzlos ohne die Schlüssel, die ausschließlich in den geteilten Links existieren.

Für die vollständigen kryptografischen Details — Schlüsselgenerierung, IV-Behandlung, Passphrase-Wrapping und die genauen Web Crypto API-Aufrufe — lies unseren Zero-Knowledge-Verschlüsselungs-Deep-Dive.

Deine Wahl treffen

Das richtige Verschlüsselungsmodell hängt davon ab, was du schützt und wem du bereit bist zu vertrauen.

Wenn du Funktionen wie Suche, Wiederherstellung oder zentralisierte Schlüsselverwaltung benötigst, ist serverseitige Verschlüsselung die praktische Wahl. Wenn du eine Garantie brauchst, dass niemand — nicht der Dienst, nicht seine Mitarbeiter, nicht ein Gerichtsbeschluss — deine Daten lesen kann, ist clientseitige Verschlüsselung das einzige Modell, das das bietet.

Für das sichere Teilen von Geheimnissen ist die Antwort eindeutig: Die Daten sind sensibel, die Interaktion ist kurz, und je weniger Parteien auf den Klartext zugreifen können, desto besser.

Bereit, ein Geheimnis mit Zero-Knowledge-Verschlüsselung zu teilen? Erstelle ein Geheimnis auf Vaulted — deine Daten verlassen deinen Browser nie unverschlüsselt.