Was der Server nicht wissen muss
Zentraler Bestandteil des Cloud Computing ist ein Grundsatz, den kaum jemand hinterfragt: Sobald Daten auf einem Server eintreffen, sieht der Server sie. Alle Daten. Ihre Krankenakten, Ihre Suchanfragen, Ihre Finanztransaktionen. Der Server entschlüsselt alles, verarbeitet es, und wir alle vertrauen einfach darauf, dass alles in Ordnung ist. Datenschutzrichtlinien und Compliance-Zertifikate sind Verpflichtungen. Keine Garantien. Und Verpflichtungen lassen sich brechen.
Sichere Multi-Party-Berechnungen (MPC) sind seit Jahrzehnten eine Antwort der Kryptographen auf diese Problemstellung. Die Idee ist einfach: Mehrere Teilnehmer führen gemeinsam Berechnungen auf Daten durch, die sie nicht lesen können. In der Praxis ist MPC jedoch ein kompliziertes Thema.
1. Das Problem in der Praxis: eine sehr undichte Abstraktion
Als Forscher von UC Berkeley, Signal, ISRG und Coinbase versuchten, MPC in der Produktion einzusetzen, stellten sie fest, dass die eigentliche Kryptographie oft der kleinste Teil der Arbeit war [1]. Die größten Hürden lagen woanders: Wer sind die beteiligten Parteien in der Praxis? Wie authentifizieren sie sich gegenseitig? Wie wird Key Management gehandhabt? Und wie koordiniert man verteilte Systeme über Organisationsgrenzen hinweg? Bei ISRG etwa waren die meisten Bugs nach dem ersten ENPA-Deployment keine kryptographischen Probleme, sondern Scheduling- und Konsistenzprobleme zwischen den MPC-Parteien. Dazu kommt: Je mehr Cloud-Anbieter als separate Trust Domains eingesetzt werden, desto mehr multipliziert sich der Entwicklungsaufwand für Attestierung, Deployment-Tooling und Client-Authentifizierung gleichermaßen. Kurz: Das Implementieren eines MPC-Protokolls ist oft deutlich weniger aufwändig als das Vorbereiten seiner Deployments.
Bei MPC wird vom Client verlangt, geheime Anteile seiner Daten zu erstellen und diese auf mehrere Server zu verteilen, bevor die Berechnung beginnen kann. Dabei muss der Client die MPC-Teilnehmer bereits zum Zeitpunkt der Secret-Erstellung kennen, was eine Kopplung ist, die sich durch den gesamten Stack zieht. Das erfordert spezielle Client-Software, komplexe Key-Management-Infrastruktur, und macht jede Integration zu einem kleinen Forschungsprojekt in verteilter Kryptographie.
MPC ist deshalb eine undichte Abstraktion: Seine Interna dringen in jede Schicht und Komponente ein, die mit ihm in Berührung kommt: vom Client bis zur Cloud-Infrastruktur. Das erklärt, warum selbst gut finanzierte Organisationen wie Signal oder Coinbase Jahre brauchen, um MPC in Produktion zu bringen, und warum es in Endprodukten weit weniger verbreitet ist, als sein Potenzial rechtfertigen würde.
2. Eine Lösung: TLShare
Was wäre, wenn die Serverseite die Integration in MPC übernehmen könnte? Was wäre, wenn das ganz transparent passiert und sich der Client überhaupt nicht ändern müsste? Was wäre, wenn die Infrastruktur nichts von MPC wüsste? Wir kreisten immer wieder um diese Fragen und das brachte uns zu TLShare.
Das Setup. Ein TLS-Standard-Client (C), ein TLS-Server (S) und ein Proxy (P). Der Client merkt nichts Ungewöhnliches. Er öffnet eine normale TLS-Verbindung, wie sie dein Browser tausende Male am Tag aufbaut (zum Beispiel als du diese Seite geöffnet hast). DNS leitet die Verbindung zuerst durch den Proxy, aber aus Sicht des Clients redet er einfach mit einem Server.
Der Trick. Jede Cipher Suite in TLS (zumindest die empfohlenen) teilt eine strukturelle Eigenschaft: Sie basieren auf Counter-Mode-Verschlüsselung. Sie erzeugen einen pseudozufälligen Keystream und verknüpfen ihn per XOR mit dem Klartext. Diese XOR-Operation ist die Basis der Idee.
Wenn verschlüsselte Daten durch den Proxy (P) fließen, wendet P eine zusätzliche zufällige Maske auf den Ciphertext an, bevor er ihn an den Server (S) weiterleitet. Wenn S mit den normalen TLS-Keys entschlüsselt, bekommt er nicht den Klartext. Er bekommt Klartext plus Maske, was wie zufälliges Rauschen aussieht. Die Maske selbst, die nur P kennt, ist das andere Stück. Zusammen bilden diese beiden Werte ein kryptographisches additives Secret Sharing der Originaldaten. Keiner der beiden Server sieht den Klartext. Jeder hält etwas, das wie reiner Zufall aussieht. Aber zusammen, ohne ihre Shares jemals zusammenzuführen, können sie MPC-Protokolle auf diesen Shares ausführen.
Man kann es sich auch so vorstellen: Der Proxy kippt Farbe in die Nachricht, die der Server vom Client erhält. Der Server sieht eine Nachricht, die eine komplett andere Farbe hat als die Ursprüngliche, während der Proxy die Tönung geheim hält. Keiner hat das vollständige Bild der Nachricht.
Die Sicherheitsgarantie ist nun eine andere: Solange S und P nicht beide gleichzeitig kompromittiert werden, kann keine einzelne Partei den Klartext rekonstruieren. Keine SGX-Enclaves, keine Trusted Platform Modules. S und P müssen in getrennten administrativen Domänen betrieben werden (verschiedene Organisationen, verschiedene Cloud-Anbieter).
3. Was das in der Praxis bringt
Das klingt vielleicht unspektakulär, ist aber der eigentliche Punkt: Jeder Standard-TLS-Client funktioniert ohne Änderung. Browser, curl, Mobile Apps, IoT-Geräte. Der Client implementiert kein MPC, weiß nicht dass MPC passiert, und muss es nicht wissen. Aus seiner Sicht hat er einen normalen HTTPS-Request gemacht.
Die Berkeley-Deployment-Studie ergab [1], dass allein die Client-Authentifizierungslast, bei der sich jeder Client unabhängig bei jeder MPC-Partei authentifizieren muss, einer von mehreren Reibungspunkten, der die praktische Adoption bremst. TLShare eliminiert diese gesamte Problemkategorie, weil der Client nur eine einzige, normale TLS-Verbindung aufbaut.
Der Overhead ist praxistauglich: Je nach Anwendung einen ~15% Overhead in Latency. Bei einem typischen 500ms-API-Call sind das etwa 75 zusätzliche Millisekunden. TLShare ersetzt TLS nicht. Es verändert, was nach TLS passiert. Die Transportsicherheit ist Standard. Entschlüsselung auf der Serverseite bedeutet nicht mehr, dass Klartext offengelegt wird.
Was lässt sich damit bauen? Ein SMTP-Relay, das ausgehende E-Mails Ende-zu-Ende verschlüsselt, ohne den Mail-Client des Absenders zu verändern. Ein Analytics-Proxy, der Telemetrie von Browser, App oder IoT-Gerät entgegennimmt und privacy-preserving aggregiert (etwa über das Distributed Aggregation Protocol (DAP)) ohne dass ein einzelner Server jemals die Rohdaten eines Clients sieht. Transparente Cloud-Storage-Verschlüsselung über Standard-Protokolle wie SFTP oder NFS: Der Client arbeitet normal, der Storage-Server sieht nie den Klartext.
4. Wie TLShare im Vergleich abschneidet
Jeder bestehende privacy-preserving Ansatz zur serverseitigen Datenverarbeitung zwingt dich in ein Trilemma. Wähle zwei von drei: Datenvertraulichkeit gegenüber dem Server, serverseitige Verarbeitungsfähigkeit und Abwärtskompatibilität mit unveränderten Clients.
Standard-TLS gibt dir Verarbeitung und Kompatibilität, aber der Server sieht alles. Ende-zu-Ende-Verschlüsselung gibt dir Vertraulichkeit und Kompatibilität, aber der Server kann nichts berechnen. Trusted Execution Environments (Intel SGX, AMD SEV) geben dir Verarbeitung und erfordern oft nur minimale Client-Änderungen (Attestation), aber deine Sicherheit hängt an Hardware, die wiederholt gebrochen wurde: Foreshadow, Plundervolt, AEPIC Leak, SEVered, CacheWarp. FHE gibt dir Vertraulichkeit und Verarbeitung in der Theorie, bleibt aber um Größenordnungen zu langsam für allgemeine Workloads und erfordert spezialisierte Client-seitige Tools. Traditionelles MPC gibt dir Vertraulichkeit und Verarbeitung, verlangt aber MPC-fähige Clients und Custom-Protokoll-Integration.
| Ansatz | Server kann verarbeiten? | Client unverändert? | Hauptnachteil |
|---|---|---|---|
| Standard-TLS | Ja | Ja | Server sieht Klartext |
| E2EE | Nein | Nein | Keine serverseitige Verarbeitung; Key-Management-Last |
| TEEs (SGX/SEV) | Ja | Ja | Vertrauen in angreifbare Hardware |
| FHE | Teilweise | Nein | Um Größenordnungen langsamer; Spezialformate |
| Traditionelles MPC | Ja | Nein | Client-seitige Komplexität; Integrationslast |
| TLShare | Ja | Ja | Erfordert aufgeteilte Server-Infrastruktur |
Die nächstverwandte Arbeit zu TLShare ist Oblivious TLS [2], das den konzeptionell naheliegenden Ansatz verfolgt: einfach das gesamte TLS-Protokoll in einer MPC-Engine ausführen. Konkret verwenden sie SPDZ, um einen Multi-Party-Diffie-Hellman-Handshake auszuwerten, dann SHA-256-Schlüsselableitung als binären Schaltkreis, dann authentifizierte Verschlüsselung in der Record-Schicht. Alle drei Stufen laufen sequenziell, der Gesamtdurchsatz ist also durch die langsamste begrenzt: ihr Custom-MPC-freundliches AEAD-Schema, das bei etwa 300 KB/s Schluss macht. Der Handshake allein dauert ~1,7 Sekunden.
Lass das sacken. 300 KB/s. Das ist Modem-Territorium.
TLShare geht einen fundamental anderen Weg. Statt kryptographische Primitiven in eine General-Purpose-MPC-Engine zu stopfen, baut es auf bestehende TLS Implementierung auf, hält die teure symmetrische Kryptographie auf dem schnellen Pfad und nutzt die Struktur der symmetrischen Crypto klever aus. Das Ergebnis ist Performance in Schlagdistanz zu nativem TLS.
Bei einem kontinuierlichen 500-MB-Transfer (auf unserem Test-system) erreicht natives TLS 2,8 GB/s. TLShare schafft 2 GB/s, etwa eine 28% Verlangsamung. Die Record-Schicht von Oblivious TLS schafft 300 KB/s. Selbst wenn man großzügigerweise ihre 1,7-Sekunden-Handshake-Kosten komplett ignoriert und nur den Record-Layer-Flaschenhals misst, ist TLShare über 7.000x schneller.
Aber wie sieht der Overhead im Vergleich zu Standard Cloud aus der Nähe aus? Wir haben unsere Referenzimplementierung gegen natives TLS über Payload-Größen von 64 Bytes bis 1 MB gebenchmarkt und die Latenz gemessen.
TLShare fügt pauschal ~41ms pro Request hinzu, unabhängig von der Payload-Größe. Bei 64 Bytes ist das ein 237x-Multiplikator gegenüber rohem TLS. Bei 1 MB sind es 75x. Der Multiplikator schrumpft, weil die Fixkosten konstant bleiben, während rohes TLS mit der Datenmenge skaliert. Der wichtige Punkt: Diese Fixkosten stecken vollständig im Handshake-Relay, nicht in der Kryptographie. Das eigentliche XOR-Masking, die Kern-TLShare-Operation, ist vernachlässigbar wenig (< 1 ms). Der Rest ist Implementierungs-Overhead in unserem Referenzcode, der optimierbar ist: JSON-Serialisierung der Handshake-Nachrichten (jeder TLS-Record wird durchroundtrippt) und Latenz über ~13 Handshake-Round-Trips.
In einem echten Netzwerk-Deployment, wo Latenz in Millisekunden statt Mikrosekunden gemessen wird, sieht ein typischer 500ms-API-Call etwa 15% Overhead. Für die meisten Anwendungen ist das absolut im Rahmen.
5. InvisiCloud: Proof of Concept
Um zu beweisen, dass das Pattern funktioniert, haben wir etwas damit gebaut.
InvisiCloud ist Ende-zu-Ende-verschlüsselter Cloud-Speicher für statische Dateien, vergleichbar mit S3-Style-Object-Storage. Von aussen sieht es aus und verhält sich wie jeder andere Cloud-Speicher-Dienst: Standard-REST-API, Standard-Client-Libraries. Unter der Haube ist jede Datei per MPC Ende-zu-Ende verschlüsselt, wobei der Zugriff an Endnutzer-Identitäten statt an manuell verwaltete Schlüssel gebunden ist.
E2EE-Cloud-Speicher gibt es bereits. Proton Drive und Tresorit haben es ausgeliefert. Aber diese Dienste schieben das Key Management auf Nutzer und Entwickler ab. Du kümmerst dich um Schlüsselerzeugung, -verteilung, -wiederherstellung, Geräte-Sync. Ist der Schlüssel verloren, sind die Daten verloren. Diese Komplexität ist der Grund, warum die meisten Engineering-Teams E2EE entweder komplett auslassen oder fragile Wrapper darum bauen, die den Zweck zunichte machen. Whitten und Tygars Studie “Why Johnny Can’t Encrypt” ergab, dass nur ein Drittel der Teilnehmer es schaffte, eine Nachricht erfolgreich zu verschlüsseln, und ein Viertel versehentlich Geheimnisse im Klartext verschickte [3].
Key management is the hardest part of cryptography and often the Achilles’ heel of an otherwise secure system.
Ferguson, Schneier & Kohno, Cryptography Engineering (2010)
InvisiCloud beseitigt diese Last. Der Server kann deine Dateien nicht lesen, das ist eine mathematische Garantie, keine Policy. Nutzer verwalten keine Schlüssel, Zugriff ist identitätsbasiert. Entwickler ändern nichts an ihrer Integration, es ist eine Standard-API.
6. Wo wir stehen
Wir haben eine Referenzimplementierung: eine Ende-zu-Ende-verschlüsselte HTTP-REST-API, bei der der Server TLShare verwendet und der Client eine Standard-TLS-Verbindung. Es funktioniert. Der Overhead ist moderat. Der Client merkt nicht, dass etwas Besonderes passiert.
Als nächstes: komplexere MPC-Operationen auf den Shares, Pilot-Integrationen mit Partnern, Stresstests gegen härtere Workloads. Wir haben es gebaut, es funktioniert, und wir suchen nach harten Problemen, die wir darauf werfen können.
Wenn du an einem Problem arbeitest, bei dem Datenvertraulichkeit und serverseitige Verarbeitung wie ein Widerspruch klingen, schreib uns.
[1] Lindell et al., "The Deployment Dilemma: Merits & Challenges of Deploying MPC," MPC Deployments, Sep 27, 2023. https://mpc.cs.berkeley.edu/blog/deployment-dilemma.html
[2] Abram, D., Damgård, I., Scholl, P. & Trieflinger, S. "Oblivious TLS via Multi-Party Computation." Cryptology ePrint Archive, Paper 2021/318 (2021). https://eprint.iacr.org/2021/318
[3] Whitten, A. & Tygar, J.D. "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0." Proceedings of the 8th USENIX Security Symposium (SSYM'99), Washington, D.C., 1999. https://dl.acm.org/doi/10.5555/1251421.1251435