Untertitel: Warum „sicher und verschlüsselt“ oft nur den Transport meint – und was echte E2E verlangt.
Du schreibst der Behörde, lädst Nachweise hoch, nutzt ein Bürgerportal. Überall steht: „Sicher und verschlüsselt.“ Oft ist nur der Transport geschützt – TLS. Der Server liest den Klartext. Logs, Support, Cloud-Kopien können mitlesen.
Die These in einem Satz
Echte E2E heißt: nur Absender und Empfänger lesen den Inhalt – der Betreiber speichert Ciphertext, nicht den Klartext-Schlüssel.
Zwei schlechte Extreme
Ohne echte E2E: alles Klartext „weil Behörde lesen muss“ – und Marketing-E2E, während der Provider den Master-Key hält. Dazu der Alltag: echte Verschlüsselung ist umständlich, also weichen alle auf E-Mail und PDF aus.
Was es nicht ist
Kein reiner Krypto-Kurs. Kein Verbot rechtmäßiger, transparenter Zugriffe. Keine Verwechslung von TLS und Ende-zu-Ende. Keine heimliche Dauer-Backdoor als Default.
Sondern: Verschlüsselung vor dem Absenden, Schlüssel an den Enden, Ciphertext beim Betreiber – Ausnahmen sichtbar, befristet, auditierbar.
Drei Säulen
1. Echte E2E-Architektur
Client-side Encryption: Inhalt wird am Endpunkt verschlüsselt. Server speichert und routet Ciphertext. Nur Enden halten Entschlüsselungsmaterial. Mitlesen im Normalbetrieb = keine E2E.
2. Keine Schein-Verschlüsselung
TLS ≠ E2E. Server-side Encryption ≠ E2E. Labels müssen der Architektur entsprechen. Metadaten und Inhalt ehrlich trennen und kommunizieren.
3. Schlüssel an den Enden
Ableitung über Gerät, eID oder Wallet – nicht der Generalschlüssel in der Cloud des Betreibers. Recovery by design. Rechtliche Ausnahmen: sichtbar, befristet, protokolliert.
Der kulturelle Kern
| Extrem A | Extrem B | Echte E2E |
|---|---|---|
| Alles Klartext „weil Behörde“ | Absolutismus ohne Usability | Vertraulich by design |
| Vertrauen in Labels | DIY-Krypto-Chaos | Defaults sicher & nutzbar |
| Betreiber liest alles | Niemand darf je helfen | Enden lesen; Ausnahmen sichtbar |
Entscheidungsfilter
- Kann der Betreiber den Inhalt im Normalbetrieb lesen?
- Ist es TLS, Server-Encrypt – oder echte Client-side-E2E?
- Wer hält den Schlüssel – Enden oder Provider?
- Gibt es Recovery ohne heimlichen Master-Key?
- Sind Ausnahmen sichtbar und befristet?
- Weichen Nutzer auf Klartext aus – weil E2E unbrauchbar ist?
Kurzformel
Nur Absender und Empfänger lesen den Inhalt – der Betreiber speichert Ciphertext, nicht den Klartext-Schlüssel.
Leitlinie: Echte E2E · Keine Schein-Verschlüsselung · Schlüssel an den Enden
Serie System · Systembrief · Essay-Video auf YouTube @systembrief_de (Release laut Kalender).