Chatkontrolle, warum Client-Side-Scanning Ende-zu-Ende-Verschlüsselung aushebelt

Problem

Die BfDI (Bundesbeauftragte für den Datenschutz und die Informationsfreiheit) zählt die Chatkontrolle in ihrer Pressemitteilung zum 34. Tätigkeitsbericht zu den Sicherheitsbefugnissen, die in der jetzigen Form nicht zulässig seien. Der Verordnungsentwurf gegen sexuellen Kindesmissbrauch im Netz fordert eine "Aufdeckungsanordnung", die Anbieter zwingen kann, alle Inhalte ihrer Nutzer auf bekannte Missbrauchsabbildungen oder auf Anbahnung zu prüfen. Bei Diensten mit Ende-zu-Ende-Verschlüsselung (E2E; nur Sender und Empfänger können den Inhalt lesen, der Dienst dazwischen nicht) ist das technisch nur über einen Scan auf dem Endgerät möglich, vor der Verschlüsselung. Der politische Begriff dafür lautet Client-Side-Scanning, kurz CSS (Scan auf der Nutzerseite; nicht zu verwechseln mit der Web-Technologie Cascading Style Sheets).

Für wen ist das? Für alle, die verstehen wollen, warum Client-Side-Scanning Ende-zu-Ende-Verschlüsselung aushebelt.

Kurze Antwort

Client-Side-Scanning prüft Inhalte auf dem Gerät, bevor die Ende-zu-Ende-Verschlüsselung greift - der Verschlüsselungs-Mechanismus bleibt formal unangetastet, aber an der Vertraulichkeit entsteht ein Leck. Kurz:

• Ein Filter sitzt zwischen Nutzer und seiner eigenen Krypto-Schicht und prüft, bevor verschlüsselt wird.
• Schlägt der Filter an, entsteht beim Anbieter ein Wissen über den Inhalt (etwa: "als rechtswidrig eingestuft"), auch wenn nicht der genaue Inhalt übertragen wird.
• "Ende-zu-Ende" gilt technisch weiter, der praktische Vertraulichkeits-Schutz aber nur noch für das, was der Filter durchlässt.
• Wer CSS einbaut, bewegt sich im Spannungsfeld zwischen geforderter Rechtssicherheit und der Umgehung echter Vertraulichkeit.

Tiefgang

Was Client-Side-Scanning konkret macht

Der typische Aufbau ist eine zweistufige Prüfung im Endgerät, ausgelöst beim Anhängen einer Datei an eine Nachricht oder beim Hochladen auf einen Cloud-Speicher. Stufe eins ist ein Hash-Match gegen eine vom Anbieter ausgelieferte Liste bekannter "Bad-Hashes" (ein Hash ist ein kurzer Prüfwert, der aus einer Datei berechnet wird). Stufe zwei ist ein Klassifikator, oft ein neuronales Modell, das auf "neue" Inhalte einer bestimmten Kategorie reagiert. Beide Stufen erzeugen im Trefferfall ein Signal, das der Anbieter unverschlüsselt empfängt. Jede der beiden Stufen ist für sich heikel; die Kombination ist die problematische, weil sie eine offene Liste zukünftiger Erkenntnisformen einbaut.

Perceptual Hashes und ihre Kollisionen

Die Hash-Stufe nutzt selten reine SHA-256-Werte; reines SHA-256 ist gegen die geringste Bildbearbeitung wirkungslos (ein einziges verändertes Pixel und der Hash unterscheidet sich vollständig). Stattdessen kommen perceptuelle Hash-Verfahren (Prüfwerte, die nach optischer Ähnlichkeit statt nach Bit-Gleichheit gruppieren) wie pHash oder Apples 2021 vorgestelltes NeuralHash zum Einsatz, die ähnliche Bilder auf nahe beieinanderliegende Hashes abbilden. Genau diese Eigenschaft ist auch ihr Schwachpunkt. Innerhalb weniger Wochen nach der NeuralHash-Veröffentlichung wurden frei wählbare Eingangsbilder konstruiert, die denselben Hash wie ein bekanntes Zielbild liefern; ein Angreifer kann damit gezielt false-positives (Fehlalarme) auslösen oder ein echtes Beweisstück gegen einen unverdächtigen Nutzer produzieren. Auch ohne böswillige Konstruktion sind die natürlichen Kollisionsraten (zufällige Übereinstimmungen verschiedener Bilder) in Abbildungs-Korpora hoch genug, um pro Million Bilder mehrere unbeteiligte Treffer zu erzeugen.

Function Creep ist Architekturmerkmal, kein Bedienfehler

Bugs in our Pockets, die 2021 erschienene Sammelarbeit von Abelson, Anderson, Bellovin und Kollegen, beschreibt einen strukturellen Punkt: ist die Pipeline aus Hash-Liste plus Klassifikator plus Anzeige-Pfad einmal in jedem Endgerät verbaut, ist die Frage nicht, ob sie für andere Inhalte erweitert wird, sondern wann. Genau das ist mit Function Creep gemeint: die schleichende Ausweitung eines Werkzeugs auf Zwecke, für die es nie gedacht war. Die Liste ist serverseitig kuratiert, die Modell-Updates sind serverseitig signiert, der Auslöser ist nicht überprüfbar. Eine Erweiterung um terroristische Symbolik, "extremistische" Texte oder politische Bilder lässt sich nicht technisch verhindern, nur vertraglich versprechen. Genau das hat das EDPB-EDPS Joint Opinion 04/2022 (gemeinsame Stellungnahme des Europäischen Datenschutzausschusses und des Europäischen Datenschutzbeauftragten) zum CSA-Entwurf festgehalten und entsprechend abgelehnt.

Das Verschlüsselungs-Versprechen vor Gericht

Der EGMR (Europäischer Gerichtshof für Menschenrechte) hat in der Sache Podchasov gegen Russland im Februar 2024 entschieden, dass eine staatliche Anordnung an einen Messenger-Anbieter, Ende-zu-Ende-Verschlüsselung zu schwächen oder Hintertüren einzubauen, nicht verhältnismäßig ist und Artikel 8 der Europäischen Menschenrechtskonvention (Recht auf Achtung des Privatlebens) verletzt. Die Argumentationskette ist ohne Weiteres auf CSS übertragbar: ein in den Client gebauter Filter ist funktional eine Hintertür, wenn die Aufsichtsschiene auch nur einmal greift; der Schutz ist nicht "fast unversehrt", er ist auf den Restbereich zusammengezogen, den der Filter passieren lässt.

Abgelehnte Alternativen

"Wir scannen nur SHA-256 von Hashlisten, keine Klassifikatoren." Das ist sauberer als ein neuronaler Klassifikator, aber die strukturelle Frage bleibt: wer kuratiert die Hashes, wer signiert die Updates, wer kontrolliert den Anzeige-Pfad. Wenn der Server, der die Liste verteilt, das Vertrauen genießt, das er fordert, ist die Kette so stark wie ihre schwächste Stelle, und das ist die Liste.

"Hybride Lösung mit Audit." Audits sind hilfreich für Modell-Drift und Kollisionsraten; sie helfen nicht gegen den eigentlichen Punkt, dass die Filter-Pipeline existiert und Inhalte unverschlüsselt für Inspektion verfügbar macht. Audit verschiebt das Problem auf eine Vertrauens-Frage zwischen Plattform und Auditor.

"Server-Side-Scanning unterscheidet sich davon." Tut es. Bei klassischer serverseitiger Prüfung war der Inhalt am Server ohnehin im Klartext; CSS überträgt den Vorgang in das Gerät des Nutzers, das per Definition unter dessen Kontrolle stehen sollte. Damit entstehen zwei separate Probleme: das Verschlüsselungs-Versprechen wird inhaltsleer, und das Endgerät selbst wird zum Werkzeug einer fremden Aufsicht.

Was Sie jetzt tun sollten

1. Prüfen Sie bei jedem eingesetzten Messenger oder Cloud-Dienst, ob "Ende-zu-Ende-Verschlüsselung" für die Inhalte gilt, die Ihnen wichtig sind - und ob ein Vor-Verschlüsselungs-Scan vorgesehen oder angekündigt ist.
2. Unterscheiden Sie bewusst zwischen einem eng benannten Eingangsfilter (etwa ein reiner Hash-Abgleich beim Upload zum Dienst) und einer offenen, gerätegebundenen Aufsicht über alle Inhalte.
3. Für besonders schützenswerte Kommunikation (Mandanten-, Patienten-, Geschäftsgeheimnisse) bevorzugen Sie Dienste, die Inhalte ausschließlich auf dem Endgerät verschlüsseln und dem Server kein Schlüsselmaterial geben.
4. Verfolgen Sie den Stand des EU-Verordnungs-Verfahrens (Chatkontrolle/CSA), bevor Sie langfristige Plattform-Entscheidungen treffen, und ziehen Sie die verlinkten Stellungnahmen heran.
5. Dokumentieren Sie für Ihr Unternehmen, welche Daten an welche Dienste gehen, damit Sie bei einer künftigen Aufdeckungsanordnung handlungsfähig bleiben.

Wie Dernium hier hilft

Wir bauen unsere Dienste so, dass die Nachricht auf dem Endgerät bleibt, solange sie das soll. Dernium Office basiert auf CryptPad und hält die Inhalte der Pads im Browser verschlüsselt; der Server bekommt nur schlüsselmaterial-lose Daten zu sehen. Bei Dernium Send gibt es bewusst einen schmalen Pre-Upload-Filter, der Datei-Hashes (kein Inhalt, kein Modell) gegen eine kuratierte Liste bekannter NCMEC- und BKA-Hashes (NCMEC = US-Meldestelle für Kindesmissbrauch, BKA = Bundeskriminalamt) prüft; das ist nicht E2E-Bruch im Sinne der Chatkontrolle, weil die Datei zum Hochladen ohnehin an Dernium geht, nicht an einen E2E-Empfänger, und weil die Filter-Logik exakt benannt ist (SHA-256-Match, keine Klassifikation, keine Funktions-Erweiterung). Den Unterschied zwischen "engem, transparentem, ausgewiesenem Eingangsfilter" und "offener, gerätegebundener Aufsicht" halten wir aktiv aus, weil er für unser Schutzversprechen entscheidend ist.

Offene Punkte

Eine ehrliche Diskussion müsste die empirische Trefferqualität perceptueller Hash-Verfahren auf realistischer Verkehrslast belegen, einschließlich der Rate echter false-positives bei legalen Inhalten. Die Modell-Anbieter veröffentlichen solche Zahlen nur selektiv, und unabhängige Reproduktion ist mangels Test-Korpus schwierig. Bis dahin bleibt die Behauptung "präzise erkannt, kaum Fehlalarme" eine Vertrauens-Frage, kein Mess-Ergebnis. Die zweite, größere Lücke betrifft die rechtsstaatliche Folge eines Treffers: was geschieht mit dem Anschluss, der über einen kollidierenden NeuralHash beanstandet wird, und wie schnell ist der Eintrag in einer Verfahrens-Akte wieder zu beseitigen. Beide Punkte gehören in jeden seriösen Diskurs zur Chatkontrolle, vor jeder Mehrheits-Entscheidung im Verordnungs-Verfahren.

Häufige Fragen

Bleibt meine Verschlüsselung mit Client-Side-Scanning intakt?

Technisch ja, praktisch nur eingeschränkt. Die Verschlüsselung der Übertragung wird nicht gebrochen - der Scan läuft davor, auf dem Gerät. Sobald der Filter aber etwas beanstandet, entsteht beim Anbieter ein Wissen über den Inhalt. Der Vertraulichkeits-Schutz gilt damit nur noch für das, was der Filter durchlässt, nicht mehr für alles.

Warum reicht ein einfacher SHA-256-Abgleich nicht für die Bilderkennung?

Weil SHA-256 schon bei der kleinsten Veränderung eines Bildes einen völlig anderen Wert liefert - ein einziges geändertes Pixel genügt, und der Treffer entfällt. Deshalb setzt Client-Side-Scanning auf perceptuelle Hashes, die ähnliche Bilder zusammenführen. Genau diese Toleranz macht sie aber anfällig für Kollisionen und gezielt erzeugte Fehlalarme.

Was ist Function Creep und warum ist er hier so zentral?

Function Creep bezeichnet die schleichende Ausweitung eines Werkzeugs auf neue Zwecke. Ist die Scan-Pipeline einmal auf jedem Gerät verbaut und wird die Erkennungs-Liste zentral vom Server gepflegt, lässt sich rein technisch nicht verhindern, dass künftig auch andere Inhalte erfasst werden - politische Bilder, Texte, Symbole. Verhindern lässt sich das nur durch Versprechen, nicht durch die Architektur selbst.

Ist der Hash-Filter von Dernium Send dasselbe wie Chatkontrolle?

Nein. Bei Dernium Send geht die Datei zum Hochladen ohnehin an Dernium, nicht verschlüsselt an einen Ende-zu-Ende-Empfänger; es gibt also kein Vertraulichkeits-Versprechen zu brechen. Der Filter ist außerdem eng und benannt: ein reiner SHA-256-Abgleich gegen bekannte Missbrauchs-Hashes, ohne Klassifikator und ohne offene Erweiterbarkeit. Die Chatkontrolle dagegen würde einen erweiterbaren Scan auf dem Gerät erzwingen, vor der Verschlüsselung.