Homomorphe Verschlüsselung – Ermöglicht sichere Berechnungen mit verschlüsselten Daten

Veröffentlicht: Juni 2025. Aktualisiert: August 2026. Geprüft vom Verschlüsselungsberatungsteam von Encryption Consulting.

Was ist homomorphe Verschlüsselung und warum ist sie wichtig?

Homomorphe Verschlüsselung (HE) ist eine Verschlüsselungsklasse, die es ermöglicht, Berechnungen direkt auf dem Chiffretext durchzuführen, ohne ihn jemals zu entschlüsseln. Die Entschlüsselung des Ergebnisses ist dabei identisch mit der Berechnung des ursprünglichen Klartexts. Dies ist relevant, da Unternehmen so sensible Daten an Cloud-Dienste, KI-Modelle oder externe Analysedienstleister weitergeben und aussagekräftige Ergebnisse erhalten können, ohne die zugrundeliegenden Daten jemals einzusehen.

In einem typischen HE-Workflow generiert ein Client ein Schlüsselpaar und, bei fortgeschritteneren Verfahren, einen separaten Auswertungsschlüssel. Der Client verschlüsselt Daten mit dem öffentlichen Schlüssel und sendet nur den Chiffretext an den Server. Der Server verwendet den Auswertungsschlüssel, um Additionen und Multiplikationen mit diesem Chiffretext durchzuführen, ohne dabei jemals den privaten Schlüssel zu berühren oder den Klartext wiederherzustellen. Der Client allein entschlüsselt das Endergebnis mit dem privaten Schlüssel. Wie das ISACA-Whitepaper von 2024 zu datenschutzverbessernden Technologien ausführt, kann HE „dazu genutzt werden, Erkenntnisse aus Berechnungen zu gewinnen, ohne den Inhalt eines Datensatzes preiszugeben“, wobei die Daten „im Ruhezustand, während der Übertragung und während der Berechnung“ verschlüsselt bleiben.

Dieser Beitrag erklärt alle wichtigen Abkürzungen, erläutert die Auswahl eines geeigneten Verfahrens, zeigt die aktuelle Geschwindigkeit von FHE auf und vergleicht HE mit Alternativen wie Secure Multi-Party Computation (MPC) und Trusted Execution Environments (TEEs). Eine kürzere, verständliche Einführung in das Konzept finden Sie in unserem zugehörigen Artikel „ Homomorphe Verschlüsselung – Grundlagen“.

Welche Arten von homomorpher Verschlüsselung gibt es, und welches Verfahren sollten Sie verwenden?

HE gibt es in drei Stufen, die sich dadurch unterscheiden, welche Operationen auf dem Chiffretext erlaubt sind und wie oft.

• Teilweise homomorphe Verschlüsselung (PHE): Unterstützt eine Rechenart, entweder Addition oder Multiplikation, unbegrenzt oft. Klassische Beispiele sind: RSA (Multiplikation) und Paillier (Addition).
• Etwas homomorphe Verschlüsselung (SHE): Unterstützt sowohl Addition als auch Multiplikation, jedoch nur für eine begrenzte Anzahl von Operationen, bevor das Rauschen im Chiffretext zu groß wird, um ihn korrekt zu entschlüsseln.
• Vollständig homomorphe Verschlüsselung (FHE): Unterstützt beliebige Schaltkreise, jede Kombination von Additionen und Multiplikationen, unter Verwendung eines Bootstrapping-Schritts, der das Chiffretextrauschen auffrischt. NIST-Projekt zur datenschutzverbessernden Kryptographie beschreibt FHE als Möglichkeit zur „nicht-interaktiven Auswertung von Funktionen und Operationen über verschlüsselte Daten“, ohne jemals den geheimen Schlüssel preiszugeben.

Innerhalb von FHE bestimmt das gewählte Schema, welche mathematischen Operationen Ihre Anwendung tatsächlich ausführen kann. Die folgende Tabelle fasst die vier in der Praxis relevanten Schemata zusammen, die alle in der Open-Source- Bibliothek OpenFHE und, für BFV und CKKS, in Microsoft SEAL implementiert sind.

Schema	Unterstützte Operationen	Dateityp	Beste Passform
BFV (Brakerski/Fan-Vercauteren)	Exakte Addition und Multiplikation ganzer Zahlen	Ganze Zahlen, modulare Arithmetik	Exakte Analysen von ganzzahligen oder kategorialen Daten, bei denen die Genauigkeit nicht nachlassen darf.
BGV (Brakerski-Gentry-Vaikuntanathan)	Exakte Addition und Multiplikation ganzer Zahlen, gebündelt mittels SIMD-ähnlicher Datenverarbeitung	Ganze Zahlen, gepackte Vektoren	Ähnlich wie BFV; häufig in akademischen Anwendungen und bei der Verarbeitung von Ganzzahl-Batches eingesetzt.
CKKS (Cheon-Kim-Kim-Song)	Näherungsarithmetik mit reellen und komplexen Zahlen	reellwertige Vektoren	Datenschutzkonformes maschinelles Lernen, Statistik und approximative Analytik
TFHE (Fast Fully Homomorphic Encryption over the Torus)	Boolesche Gatter und kleine Nachschlagetabellen mit sehr schnellem Bootstrapping pro Gatter	Bits und kleine ganze Zahlen	Verzweigungslogik, Vergleiche und verschlüsselter Kontrollfluss

Als Faustregel für die Auswahl gilt: Verwenden Sie BFV oder BGV, wenn das Ergebnis exakt sein muss; CKKS, wenn Sie bei maschinellem Lernen und statistischen Anwendungen einen kleinen Näherungsfehler zugunsten der Geschwindigkeit tolerieren können; und TFHE, wenn Ihre Berechnung von Vergleichen oder Verzweigungen und nicht von Arithmetik mit großen Ganzzahlen dominiert wird. Ein ENISA-Bericht zur Datensicherungstechnik fasst den zugrunde liegenden Zielkonflikt gut zusammen: FHE „bietet guten Schutz und Nutzen, aber eine geringe Leistung“. Genau deshalb sind die Wahl des Verfahrens und sein Anwendungsbereich hier wichtiger als bei herkömmlichen Verschlüsselungsentscheidungen.

Gegen welches Bedrohungsmodell schützt die homomorphe Verschlüsselung?

HE ist für einen ehrlichen, aber misstrauischen (halbehrlichen) Rechenanbieter konzipiert: einen Anbieter, der die angeforderte Berechnung korrekt ausführt, dem Sie aber Ihre Klartextdaten nicht anvertrauen möchten. HE beseitigt diese Vertrauensvoraussetzung vollständig; der Server arbeitet mit einem für ihn unlesbaren Chiffretext, und dies gilt selbst dann, wenn der Speicher des Servers später kompromittiert wird, da dort niemals Klartextdaten vorhanden sind, die gestohlen werden könnten.

HE allein schützt nicht vor jeder Bedrohung im Einsatz:

• Ein bösartiger Server: Standardmäßige HE-Systeme setzen voraus, dass der Server das Protokoll korrekt befolgt. Ein Server, der ein gefälschtes Ergebnis liefert, kann unentdeckt bleiben, sofern nicht zusätzlich Integritätsprüfungen oder verifizierbare Berechnungen durchgeführt werden.
• Kompromiss auf Clientseite: Der geheime Schlüssel befindet sich beim Client (oder bei der Person, an die der Client ihn delegiert). Wird dieser Schlüssel gestohlen, sind alle damit verschlüsselten Texte – sowohl vergangene als auch zukünftige – offengelegt.
• Lücken bei Endpunkten und Zugriffskontrolle: HE schützt Daten, die beim Rechenanbieter verwendet werden; es ersetzt jedoch nicht die Transportverschlüsselung, das Identitäts- und Zugriffsmanagement oder die Überwachung der Systeme, die Ergebnisse anfordern und empfangen.
• Absprachen mehrerer Parteien: Bei Multi-Key- oder Threshold-FHE-Einstellungen, die für kollaborative Berechnungen verwendet werden, hängt die Sicherheit davon ab, dass eine definierte Menge von Parteien nicht kollaboriert, was explizit modelliert und nicht einfach angenommen werden darf.

Die richtige Bedrohungsmodellierung von Anfang an ist das, was eine HE-Implementierung, die das Risiko tatsächlich reduziert, von einer unterscheidet, die lediglich die Berechnung hinter eine teure mathematische Schicht verlagert, ohne zu ändern, wem vertraut werden muss.

Wie evaluiert und implementiert man homomorphe Verschlüsselung?

Nutzen Sie diese Abfolge, um von der Frage „Sollten wir HE einsetzen?“ zu einem funktionierenden Pilotprojekt zu gelangen:

1. Bestätigen Sie, dass HE tatsächlich erforderlich ist. Erläutern Sie klar und deutlich, warum Zugriffskontrolle, Vertragsbedingungen oder Standardverschlüsselung im Ruhezustand und während der Übertragung nicht ausreichen und warum dem Rechenzentrumsanbieter insbesondere der Umgang mit Klartextdaten nicht anvertraut werden kann.
2. Wählen Sie ein System, das auf der Betriebsführung basiert, nicht auf dem Marketing. Exakte Ganzzahlmathematik deutet auf BFV oder BGV hin; approximatives maschinelles Lernen mit reellen Zahlen deutet auf CKKS hin; boolesche oder vergleichsintensive Logik deutet auf TFHE hin.
3. Wählen Sie eine geprüfte, aktiv gepflegte Bibliothek. Microsoft-SIEGEL und OpenFHE sind die beiden am weitesten verbreiteten Open-Source-Optionen; entwickeln Sie keine eigenen kryptografischen Primitiven.
4. Wählen Sie die Parameter anhand der Standards und nicht nach dem Prinzip „Raten“. Das Sicherheitsstandard von HomomorphicEncryption.org veröffentlicht Parametertabellen für Sicherheitsstufe, Grad des Polynommoduls und Länge der Chiffretextmodulkette; die meisten Bibliotheken liefern auch einen Parametergenerator mit.
5. Prototyp auf einem repräsentativen Ausschnitt der realen Arbeitslast. Ermitteln Sie die tatsächliche Latenz und den Durchsatz auf Ihrer Zielhardware (CPU, GPU oder Beschleuniger), bevor Sie Budget für einen kompletten Systemaufbau festlegen.
6. Schlüsselmanagement im Voraus planen. Entscheiden Sie, wo der geheime Schlüssel gespeichert wird, ob er durch ein HSM geschützt wird, wie der Auswertungsschlüssel an den Rechenanbieter verteilt wird und wie die Schlüsselrotation abläuft.
7. Berücksichtigen Sie das Rauschbudget und das Bootstrapping bei der Schaltungsentwicklung. und fügen Sie Integritätsprüfungen hinzu, wenn Sie nicht davon ausgehen können, dass der Rechenanbieter ehrlich, sondern nur neugierig ist.
8. Pilot mit Ausweichpfad, Skalieren Sie dann, sobald Sie die tatsächlichen Kosten, die Genauigkeit (insbesondere für die approximative Arithmetik von CKKS) und die Interoperabilität mit bestehenden Datenpipelines gemessen haben.

Wie hoch ist der tatsächliche Leistungsmehraufwand bei homomorpher Verschlüsselung?

Kurz gesagt: FHE ist immer noch um Größenordnungen langsamer als die Verarbeitung von Klartext. Jeder Anbieter, der für allgemeine Arbeitslasten etwas anderes behauptet, sollte nach konkreten Benchmark-Ergebnissen gefragt werden. Laut dem Benchmark-Bericht von Duality Technologies aus dem Jahr 2026 ist der Overhead von unoptimiertem FHE auf reiner CPU-Hardware etwa 10,000-mal langsamer als der von Klartext . Bei durchsatzorientierten Arbeitslasten reduziert sich die Verlangsamung auf etwa das 10- bis 100-Fache, sobald Batchverarbeitung und optimierte Parameter angewendet werden. Dieselbe Quelle berichtet, dass sich die FHE-Leistung insgesamt in den letzten fünf Jahren um den Faktor 1,000 bis 10,000 verbessert hat und dass mit optimiertem CKKS und Batchverarbeitung verschlüsselte logistische Regressionsanalysen mit über 10,000 Datensätzen in 2 bis 10 Sekunden abgeschlossen werden können, während verschlüsselte Batch-Analysen mit über 1 Million Datensätzen auf GPU-beschleunigter Hardware in wenigen Minuten abgeschlossen sind.

Bei höheren Arbeitslasten ist die Lücke weiterhin groß. Raluca Ada Popa vom MC2-Projekt der UC Berkeley merkt an, dass das Training eines mittelgroßen neuronalen Netzes wie VGG16 auf einem Datensatz wie CIFAR-10 unter HE oder MPC „Jahre dauern kann“. Daher ist das vollständige Modelltraining unter FHE für die meisten Organisationen derzeit noch unpraktisch; verschlüsselte Inferenz auf einem kleinen Modell oder aggregierte Analysen sind das realistische kurzfristige Ziel. Dies deckt sich mit der Zusammenfassung des IEEE , das HE als „eine der leistungsstärksten“ verfügbaren Datenschutztechnologien bezeichnet, aber gleichzeitig einräumt, dass sie sich für den allgemeinen Geschäftseinsatz „noch in einer frühen Phase“ befindet.

Was die Lücke tatsächlich schließt: algorithmische Verbesserungen (CKKS für approximative Arithmetik, TFHEs schnelles Bootstrapping), Compiler-Tools (OpenFHE, Zamas Concrete) und Hardwarebeschleunigung auf GPUs und neuartigen FHE-spezifischen Beschleunigern. Gehen Sie bei jeder Leistungsangabe gleich vor: Fragen Sie nach dem Schema, der Operation, der Hardware und der Batchgröße, denn die Aussage „homomorphe Verschlüsselung ist jetzt schnell“ ohne diese vier Details ist nicht überprüfbar.

Wie schneidet homomorphe Verschlüsselung im Vergleich zu MPC und Trusted Execution Environments ab?

HE ist einer von drei praktischen Ansätzen für die Datenverarbeitung, bei der Daten nicht an den Rechenanbieter weitergegeben werden sollen. Die anderen beiden sind Secure Multi-Party Computation (MPC), bei dem die Daten in geheime Anteile zwischen Parteien aufgeteilt werden, die nicht kollaborieren dürfen, und Trusted Execution Environments (TEEs), auch Confidential Computing genannt, bei denen die Daten in einer hardwareisolierten Enklave entschlüsselt werden. Jeder Ansatz wägt Vertrauen und Leistung auf unterschiedliche Weise ab.

Ansatz	Vertrauensannahme	Typischer Leistungsaufwand	Deployment-Modell
Homomorphe Verschlüsselung (HE/FHE)	Kein Vertrauen in den Rechenanbieter erforderlich; die Daten bleiben durchgehend verschlüsselt.	Etwa 10- bis 10,000-mal langsamer als Klartext, wobei sich die Geschwindigkeit durch GPUs und optimierte Bibliotheken verringert.	Nur Software; läuft auf jedem Cloud- oder On-Premises-Server
Sichere Mehrparteienberechnung (MPC)	Keine einzelne Partei hat Zugriff auf die vollständigen Daten; dies erfordert eine definierte Gruppe nicht kollaborierender Parteien.	Ähnliche Größenordnung wie HE für komplexe Arbeitslasten; besser geeignet für spezifische Protokolle wie private Set-Intersections.	Erfordert die Koordination mehrerer Parteien über verschiedene Vertrauensdomänen hinweg, häufig lokal oder in einer privaten Cloud.
Trusted Execution Environment (TEE / Confidential Computing)	Vertraut dem Chiphersteller und der Hardware-Zertifizierung des Cloud-Anbieters, nicht dem Software-Stack des Cloud-Betreibers.	Etwa 20 Prozent bis 2-facher Mehraufwand für die meisten Arbeitslasten.	Ab heute bei den vertraulichen Computing-Angeboten der wichtigsten Cloud-Anbieter verfügbar.

Wählen Sie HE, wenn Sie der zugrunde liegenden Hardware oder dem Cloud-Anbieter überhaupt nicht vertrauen können und die Arbeitslast gering genug ist, um den Mehraufwand zu tolerieren. Wählen Sie MPC, wenn mehrere verschiedene Organisationen jeweils einen Teil der Daten verwalten und keine als alleiniger Vertrauenspunkt fungieren kann. Wählen Sie TEE, wenn Sie nahezu native Leistung benötigen und eine hardwarebasierte Vertrauensannahme akzeptieren können. Beachten Sie dabei, dass Enklaven ihre eigene Historie von Seitenkanalangriffen aufweisen und darauf angewiesen sind, dass der Cloud-Anbieter die Firmware zeitnah aktualisiert.

Welche Abhängigkeiten im Schlüsselmanagement entstehen durch die homomorphe Verschlüsselung?

HE verlagert das Risiko der Schlüsselverwaltung, anstatt es zu beseitigen. Der geheime Schlüssel des Clients darf niemals den Server erreichen; nur der öffentliche Schlüssel (zur Verschlüsselung) und der Auswertungsschlüssel (für Berechnungen) werden ausgetauscht. In der Praxis führt dies zu einigen Abhängigkeiten, die die meisten Teams unterschätzen:

• Geheime Schlüsselverwahrung: Der geheime Schlüssel sollte auf die gleiche Weise geschützt werden wie jeder andere wertvolle kryptografische Schlüssel, idealerweise in einem HSM oder einem verwalteten Schlüsselverwaltungssystem, nicht in einer Konfigurationsdatei oder Umgebungsvariablen.
• Die Auswahl der Parameter und des Sicherheitsniveaus wirkt sich auf den Schlüssel selbst aus. Der Grad des Polynommoduls und die Modulkettentiefe bestimmen sowohl das Sicherheitsniveau als auch die Anzahl der Operationen, die der Chiffretext vor dem Bootstrapping überstehen kann. Daher kann eine spätere Änderung der Sicherheitsanforderungen eine Neugenerierung von Schlüssel und Parametern erzwingen und nicht nur eine Konfigurationsänderung.
• Die Post-Quanten-Haltung ist bereits gut, aber nicht wartungsfrei. Moderne FHE-Verfahren basieren auf Ringlern-mit-Fehlern (Ring-LWE)-Gitterproblemen, derselben Problemklasse, die auch dem ML-KEM-Standard (FIPS 203) des NIST zugrunde liegt. Daher gelten sie per Konstruktion als postquantensicher. Dies ändert jedoch nichts an der Notwendigkeit kontinuierlicher kryptografischer Anpassungen, da sich die Parameterempfehlungen weiterentwickeln.
• Die Einstellungen für Mehrfachschlüssel und Schwellenwerte fügen eine Schlüsselzeremonie hinzu. Die kollaborative Datenverarbeitung durch mehrere Dateneigentümer erfordert die Verteilung und, in manchen Designs, die gemeinsame Erzeugung von Schlüsselmaterial, was die gleiche Strenge der Governance erfordert wie jede andere Schlüsselzeremonie mit mehreren Beteiligten.

Da das Tool-Ökosystem für das Lebenszyklusmanagement von HE-Schlüsseln weit weniger ausgereift ist als das der Standard-PKI, sollten Verwahrung, Rotation und Inventarisierung von HE-Schlüsseln als erstklassige Designentscheidung und nicht als nachträglich hinzugefügter Gedanke an die Kryptographie betrachtet werden.

Wo wird homomorphe Verschlüsselung heute eingesetzt?

• Datenschutzkonformes maschinelles Lernen und Analytik: IBM-Forscher demonstrierten Verschlüsseltes maschinelles Lernen auf Bankdaten mit einer Genauigkeit, die der unverschlüsselten Basislinie entspricht, und Zamas Concrete ML Compiler wurden verwendet, um verschlüsselte neuronale Netzwerkinferenz mit veröffentlichten Leistungsbenchmarks auszuführen, was zeigt, dass dies ein funktionierendes, wenn auch noch spezialisiertes, Bereitstellungsmuster ist.
• Gesundheitswesen und Genomik: Duality Technologies und das Dana-Farber Cancer Institute angewandte HE um eine sichere groß angelegte genomweite Assoziationsstudien über mehrere Institutionen hinweg, ohne jemals die zugrunde liegenden Genomdaten zu entschlüsseln.
• Überprüfbare Wahlen: Microsofts ElectionGuard verwendet homomorphe Auszählung, um verschlüsselte Stimmzettel zu zählen, ohne einzelne Stimmen zu entschlüsseln, und unterstützt so durchgängig überprüfbare Wahlen.
• Cloud- und SaaS-Analysen: Prinzipiell können alle in der Cloud gehosteten Analysen, Datenbankabfragen oder KI-Inferenzprozesse mit verschlüsselten Eingaben durchgeführt werden, sodass ein SaaS-Anbieter Ergebnisse liefern kann, ohne jemals auf Klartext zugreifen zu müssen.

Die meisten dieser Implementierungen sind noch klein und im Pilotmaßstab und nicht auf Standardarchitektur ausgelegt, was mit dem oben beschriebenen Leistungsbild übereinstimmt: HE amortisiert sich am schnellsten bei spezifischen, hochsensiblen Berechnungen, nicht als vollständiger Ersatz für die Standarddatenverarbeitung.

Hilft homomorphe Verschlüsselung bei der Einhaltung von DSGVO, HIPAA und PCI DSS?

HE stärkt die technischen Sicherheitsvorkehrungen, die diese Rahmenbedingungen bereits erfordern, ersetzt aber nicht die ihnen zugrunde liegenden rechtlichen und verfahrenstechnischen Verpflichtungen.

• Datenschutz: Die Leitlinien des Europäischen Datenschutzausschusses zur Meldung von Datenschutzverletzungen sehen eine Ausnahme vor, wenn Daten durch Verschlüsselung unlesbar gemacht werden; wenn HE sicherstellt, dass durchgesickerter Geheimtext ohne den Schlüssel nicht entschlüsselt werden kann, muss eine Verletzung dieses Geheimtextes möglicherweise nicht gemeldet werden. Rechtsexperten weisen jedoch darauf hin, dass die HE-Verarbeitung selbst einer Rechtsgrundlage bedarf. Artikel 32.
• HIPAA: Wenn geschützte Gesundheitsdaten mit HE verschlüsselt werden und der Entschlüsselungsschlüssel ausschließlich bei der verantwortlichen Stelle verbleibt, können diese Daten oft für Zwecke außerhalb des Geltungsbereichs von HIPAA als anonymisiert behandelt werden, was eine sichere Auslagerung von Analysen von Patientendaten unterstützt.
• PCI DSS: PCI DSS nennt HE nicht explizit, aber die Durchführung der Betrugserkennung auf verschlüsselten Karteninhaberdaten ohne deren Entschlüsselung reduziert das Risiko im Einklang mit den durchgängigen Datenschutzzielen von PCI.
• NIST und ISO/IEC: NISTdas Privacy-Enhancing Cryptography-Projekt und das von der Community betriebene Sicherheitsstandard von HomomorphicEncryption.org (Erstmals veröffentlicht im Jahr 2018 und wird bei jeder Normungskonferenz aktualisiert) formalisieren die Sicherheitseigenschaften von HE, während ISO/IEC 18033-6:2019 Mechanismen wie Exponential ElGamal und Paillier spezifiziert.

Was sind die Grenzen der homomorphen Verschlüsselung?

• Performance-Overhead: Selbst nach einer Verbesserung um das 1,000- bis 10,000-fache innerhalb von fünf Jahren ist FHE bei rechenintensiven Aufgaben wie dem Training vollständiger Modelle immer noch deutlich langsamer als die reine Textberechnung.
• Die Operationstypen sind durch das Schema eingeschränkt: BFV und BGV ermöglichen exakte Ganzzahlarithmetik, CKKS tauscht Genauigkeit gegen Geschwindigkeit bei reellen Zahlen, und TFHE verarbeitet Boolesche Logik gut, aber nicht effizient Arithmetik mit großen ganzen Zahlen, sodass die Wahl des Schemas die Rechenleistung der Anwendung begrenzt.
• Komplexe Schlüssel- und Parameterverwaltung: Die Auswahl sicherer und effizienter Parameter erfordert kryptografisches Fachwissen, und das Werkzeugökosystem für die Verwaltung von HE-Schlüsseln ist weit weniger ausgereift als PKI oder Standard-Schlüsselmanagement.
• Begrenzter Schutz vor einem bösartigen Server: Der Standard HE geht von einem ehrlichen, aber neugierigen Rechenanbieter aus; ein böswilliger Anbieter kann falsche Ergebnisse liefern, wenn keine Integritäts- oder überprüfbare Berechnungsmechanismen hinzugefügt werden.
• Reifegrad der Werkzeuge und Interoperabilität: Bibliotheken unterscheiden sich hinsichtlich der unterstützten Schemata, der Sprachbindungen und der Hardwarebeschleunigung, und Chiffretexte oder Parametersätze lassen sich im Allgemeinen nicht zwischen Bibliotheken übertragen.
• Kein Ersatz für andere Steuerungselemente: HE schützt Daten während der Nutzung vor einer bestimmten Bedrohungsklasse; Zugriffskontrolle, Transportverschlüsselung, Endpunktsicherheit und Überwachung sind weiterhin erforderlich.

Was würde Encryption Consulting empfehlen?

Die meisten Organisationen, die heute HE evaluieren, sollten FHE nicht standardmäßig wählen. Zunächst muss sichergestellt werden, dass die Berechnung tatsächlich kryptografische Vertraulichkeit seitens des Rechenanbieters erfordert – etwas, das Zugriffskontrolle, Verträge oder Standardverschlüsselung im Ruhezustand und während der Übertragung nicht gewährleisten können –, bevor der Leistungsaufwand gerechtfertigt ist. Sobald diese Voraussetzung erfüllt ist, empfehlen wir, eine Pilotstudie mit einer eng begrenzten Berechnung durchzuführen, beispielsweise einer verschlüsselten Aggregation oder einer CKKS-basierten Inferenz an einem kleinen Modell, und diese direkt mit einer Alternative für vertrauliches Rechnen (TEE) zu vergleichen, bevor Produktionsbudget bereitgestellt wird.

Da aktuelle FHE-Verfahren gitterbasiert und bereits quantenmechanisch sicher sind, ist die Einführung von HE ebenfalls eine langfristige kryptografische Verpflichtung. Unsere Beratungsdienste für Verschlüsselung helfen Ihnen zu beurteilen, ob HE, MPC oder Confidential Computing am besten zu Ihrem konkreten Datenaustauschproblem passt, die Parameter anhand des HomomorphicEncryption.org-Standards zu dimensionieren und die Schlüsselverwaltungsarchitektur entsprechend zu entwerfen. Da HE-Schlüsselmaterial und kryptografische Ressourcen im Zuge der Weiterentwicklung von Bibliotheken und Parameterrichtlinien verwaltet werden müssen, kombinieren wir diese Beratungsleistung typischerweise mit CBOM Secure für die Bestandsaufnahme kryptografischer Ressourcen und unserer Expertise im Bereich Krypto-Agilität . So stellen wir sicher, dass eine HE-Implementierung upgradefähig bleibt und nicht zu einem weiteren fest codierten Legacy-System wird.

Fazit

Homomorphe Verschlüsselung ist die einzige weit verbreitete Technik, die Daten während des gesamten Berechnungsprozesses verschlüsselt, nicht nur im Ruhezustand oder während der Übertragung. Ihre drei Stufen (PHE, SHE und FHE) und ihre vier Funktionsschemata (BFV, BGV, CKKS und TFHE) bieten Ihnen vielfältige Optionen, je nachdem, ob Ihre Arbeitslast exakte Ganzzahlberechnungen, maschinelles Lernen mit approximativen reellen Zahlen oder Boolesche Logik erfordert. Die größte Einschränkung ist die Leistung: Selbst nach einer 1,000- bis 10,000-fachen Verbesserung innerhalb von fünf Jahren ist FHE immer noch deutlich langsamer als die Berechnung mit Klartext und sollte daher nur für Arbeitslasten eingesetzt werden, die die Vorteile von FHE explizit benötigen, anstatt standardmäßig verwendet zu werden. Vergleichen Sie FHE mit MPC und Confidential Computing für Ihr konkretes Bedrohungsmodell, wählen Sie die Parameter und das Schlüsselmanagement von Anfang an korrekt aus und testen Sie die Lösung zunächst in einem kleinen Pilotprojekt, bevor Sie sie skalieren.

Häufig gestellte Fragen

Ist homomorphe Verschlüsselung heute schon produktionsreif? Für eng definierte Berechnungen wie verschlüsselte Aggregation, Suchvorgänge oder CKKS-basierte Inferenz auf kleinen Modellen ja, mehrere Organisationen setzen FHE bereits produktiv mit Bibliotheken wie Microsoft SEAL und OpenFHE ein. Für allgemeine Workloads wie das Training vollständiger Modelle oder komplexe SQL-Analysen ist FHE für die meisten Produktionsbudgets jedoch noch zu langsam, und vertrauliches Rechnen oder MPC sind in der Regel besser geeignet.

Benötige ich Kenntnisse in Kryptographie, um homomorphe Verschlüsselung zu implementieren? Sie müssen kein neues Verfahren entwickeln, benötigen aber jemanden, der sich mit der Parameterwahl auskennt, insbesondere mit Sicherheitsniveau, Moduluskettenlänge und Rauschbudget. Falsche Parameter können nämlich entweder Informationen preisgeben oder die Berechnung unmöglich machen. Die meisten Teams arbeiten mit einem Kryptographie-Berater zusammen oder nutzen den integrierten Parametergenerator einer Bibliothek.

Ist homomorphe Verschlüsselung quantenresistent? Ja. Moderne FHE-Verfahren wie BFV, BGV, CKKS und TFHE basieren auf Ring-LWE-Gitterproblemen – derselben schwierigen Problemklasse, die auch dem ML-KEM-Standard (FIPS 203) des NIST zugrunde liegt – und gelten daher als post-quantensicher. Dennoch entfällt durch die Quantenresistenz nicht die Notwendigkeit einer sorgfältigen Parameterwahl und eines verantwortungsvollen Schlüsselmanagements.

Worin unterscheidet sich homomorphe Verschlüsselung von vertraulichem Rechnen (TEE)? Bei der homomorphen Verschlüsselung bleiben die Daten während der gesamten Berechnung in Software verschlüsselt, sodass niemand jemals den Klartext sieht. Dies geht jedoch mit einem erheblichen Leistungsverlust einher. Vertrauliches Rechnen entschlüsselt Daten innerhalb einer hardwareisolierten Enklave und vertraut dabei dem Chiphersteller und der Bestätigung der Enklave. Typischerweise ist der Leistungsverlust etwa 20 bis 2 Prozent höher, anstatt um Größenordnungen langsamer zu sein. Wählen Sie homomorphe Verschlüsselung, wenn Sie der zugrunde liegenden Hardware überhaupt nicht vertrauen können; wählen Sie vertrauliches Rechnen, wenn Sie eine nahezu native Leistung benötigen und hardwarebasiertes Vertrauen akzeptieren können.

Worin besteht der Unterschied zwischen partiell, teilweise und vollständig homomorpher Verschlüsselung? Partiell homomorphe Verschlüsselung (PHE), wie beispielsweise RSA oder Paillier, erlaubt die unbegrenzte Verwendung genau einer Operation. Teilweise homomorphe Verschlüsselung (SHE) unterstützt Addition und Multiplikation, jedoch nur für eine begrenzte Anzahl von Operationen, bevor das Rauschen im Chiffretext das Ergebnis überlagert. Vollständig homomorphe Verschlüsselung (FHE) ermöglicht unbegrenzte verkettete Additionen und Multiplikationen durch einen Bootstrapping-Schritt, der das Rauschen im Chiffretext auffrischt und somit beliebige Berechnungen erlaubt.

Referenzen

• NIST, „Vollständig homomorphe Verschlüsselung (FHE), datenschutzverbessernde Kryptographie“, CSRC: https://csrc.nist.gov/projects/pec/fhe
• HomomorphicEncryption.org, „Homomorphic Encryption Security Standard“: https://homomorphicencryption.org/standard/
• Microsoft SEAL, GitHub-Repository: https://github.com/microsoft/SEAL
• OpenFHE, offizielle Projektseite: https://openfhe.org/
• OpenFHE-Dokumentation, Schemata und Schnellstartanleitung: https://openfhe-development.readthedocs.io/en/latest/sphinx_rsts/intro/quickstart.html
• Duality Technologies, „Ist FHE immer noch zu langsam? Homomorphe Verschlüsselungs-Benchmarks 2026“: https://dualitytech.com/blog/homomorphic-encryption-performance-2026/
• Raluca Ada Popa, MC2-Projekt (UC Berkeley), „Sicheres Rechnen: Homomorphe Verschlüsselung oder Hardware-Enklaven?“ https://medium.com/mc2-project/secure-computation-homomorphic-encryption-or-hardware-enclaves-83da90102593
• Cloud Security Alliance, Arbeitsgruppe für vollständig homomorphe Verschlüsselung: https://cloudsecurityalliance.org/research/working-groups/fully-homomorphic-encryption
• ISACA, „Erforschung praktischer Überlegungen und Anwendungen für datenschutzverbessernde Technologien“ (2024): https://www.isaca.org/resources/white-papers/2024/exploring-practical-considerations-and-applications-for-privacy-enhancing-technologies
• ENISA-Bericht „Datenschutztechnik“: https://www.aepd.es/documento/enisa-report-data-protection-engineering.pdf
• IEEE Digital Privacy, „Vorteile der homomorphen Verschlüsselung“: https://digitalprivacy.ieee.org/publications/topics/advantages-of-homomorphic-encryption
• „CryptOracle: Ein modulares Framework zur Charakterisierung von FHE“, arXiv:2510.03565 (2025): https://arxiv.org/html/2510.03565v1
• „Leistungsanalyse führender Bibliotheken für homomorphe Verschlüsselung: Eine Benchmark-Studie von SEAL, HElib, OpenFHE und Lattigo“, ACM (2025): https://dl.acm.org/doi/10.1145/3729706.3729711