Wie AES-256 und Public-Key-Kryptographie gemeinsam sensible Daten schützen

AES-256-Verschlüsselung gilt weithin als der stärkste verfügbare symmetrische Verschlüsselungsalgorithmus. Doch es gibt ein Problem, das sie allein nicht lösen kann: Wie tauschen zwei Parteien sicher den Schlüssel aus, der die Daten überhaupt erst entschlüsselt? Würde man einen AES-256-Schlüssel über einen ungeschützten Kanal senden, wäre der gesamte Zweck der Datenverschlüsselung hinfällig.

Hier kommt die Public-Key-Kryptografie ins Spiel. Beide Verfahren arbeiten als eingespieltes Team – AES-256 übernimmt die Hauptarbeit bei der Verschlüsselung von Daten im Ruhezustand und bei der Übertragung, während Public-/Private-Key-Paare den sicheren Schlüsselaustausch und die Identitätsauthentifizierung übernehmen. Zu verstehen, wie beide zusammenwirken, ist grundlegend, um die Verschlüsselungsversprechen einer Plattform beurteilen zu können – und es ist unmittelbar relevant für Compliance-Anforderungen wie CMMC, FedRAMP und HIPAA.

Zusammenfassung

Kernaussage: AES-256 (symmetrische Verschlüsselung) und Public-/Private-Key-Kryptografie (asymmetrische Verschlüsselung) stehen nicht in Konkurrenz zueinander – sie sind sich ergänzende Schichten, die gemeinsam Leistung und Sicherheit für den Austausch sensibler Daten gewährleisten.

Warum das wichtig ist: Compliance-Rahmenwerke wie CMMC 2.0 und FedRAMP verlangen nicht einfach nur Verschlüsselung – sie verlangen FIPS-validierte Verschlüsselung mit solidem Schlüsselmanagement. Ein Unternehmen kann AES-256 korrekt implementieren und trotzdem bei einem Audit durchfallen, wenn die Schlüsselverwaltung mangelhaft ist. Wer versteht, wie diese beiden Verschlüsselungsarten zusammenwirken, kann besser beurteilen, ob die Verschlüsselungsarchitektur einer Plattform tatsächlich solide ist oder nur auf dem Papier Haken abhakt.

Die wichtigsten Erkenntnisse

1. AES-256 ist symmetrische Verschlüsselung – derselbe Schlüssel ver- und entschlüsselt die Daten.

AES-256 verwendet einen einzigen 256-Bit-Schlüssel sowohl für die Ver- als auch für die Entschlüsselung. Seine Geschwindigkeit und Recheneffizienz machen ihn zum richtigen Werkzeug für die Verschlüsselung großer Datenmengen im Ruhezustand und bei der Übertragung. Das NIST hat AES als föderalen Verschlüsselungsstandard ausgewählt, und er bleibt der Algorithmus, den FIPS 140-3 vorschreibt – der aktuelle Maßstab für die Validierung kryptografischer Module in Behörden und regulierten Branchen.

2. Public-Key-Kryptografie löst das Schlüsselverteilungsproblem, an dem AES-256 scheitert.

Einen AES-256-Schlüssel kann man nicht über einen unverschlüsselten Kanal senden. Public-Key-Kryptografie (auch asymmetrische Verschlüsselung genannt) löst dieses Problem: Eine Partei verschlüsselt den AES-Sitzungsschlüssel mit dem öffentlichen Schlüssel der anderen Partei, und nur der dazugehörige private Schlüssel kann ihn entschlüsseln. So baut TLS eine sichere Verbindung auf, bevor überhaupt Daten übertragen werden.

3. Die beiden Verschlüsselungsarten arbeiten nacheinander, nicht isoliert voneinander.

In der Praxis übernimmt die Public-Key-Kryptografie den Handshake – die Authentifizierung der Identität und den Austausch des symmetrischen Schlüssels. AES-256 übernimmt dann die eigentliche Datenübertragung. Dieser hybride Ansatz vereint die Sicherheitsvorteile der asymmetrischen mit den Leistungsvorteilen der symmetrischen Verschlüsselung.

4. Verschlüsselung ist nur so stark wie ihr Schlüsselmanagement.

AES-256 mit schwachem Schlüsselmanagement ist kein sicheres System. Werden die Verschlüsselungsschlüssel auf demselben Server gespeichert wie die verschlüsselten Daten, legt eine einzige Kompromittierung beides offen. CMMC-Prüfer untersuchen Schlüsselerzeugung, -speicherung, -rotation und -vernichtung – nicht nur, ob überhaupt verschlüsselt wird. Wer die Schlüssel besitzt und kontrolliert, bestimmt die tatsächliche Sicherheitsgrenze.

5. Kundenseitig verwaltete Verschlüsselungsschlüssel sind das entscheidende Unterscheidungsmerkmal – nicht der Algorithmus selbst.

Die meisten Enterprise-Plattformen bieten AES-256. Der Unterschied liegt darin, wer die Schlüssel kontrolliert. Kundenseitig verwaltete Verschlüsselungsschlüssel bedeuten, dass der Anbieter technisch nicht in der Lage ist, Ihre Daten zu entschlüsseln – selbst wenn eine behördliche Anfrage vorliegt. Dieser Unterschied ist unter CMMC Level 3, FedRAMP High und den DSGVO-Anforderungen nach Schrems II von erheblichem Gewicht.

Was AES-256 leistet – und was nicht

AES-256 ist eine symmetrische Blockchiffre. Sie nimmt den Klartext, führt ihn durch 14 Runden aus Substitutions-, Transpositions- und Mischoperationen mit einem 256-Bit-Schlüssel und erzeugt einen Chiffretext, der ohne diesen Schlüssel rechnerisch praktisch nicht umkehrbar ist. Derselbe Schlüssel entschlüsselt die Daten wieder.

Der Algorithmus ist schnell, gründlich getestet und wurde von der NSA zum Schutz eingestufter Informationen zugelassen. FIPS 140-3 – der aktuelle föderale Standard für kryptografische Module – schreibt AES für Daten im Ruhezustand vor. Jedes ernstzunehmende Compliance-Rahmenwerk verweist darauf.

Doch AES-256 hat eine strukturelle Einschränkung: Beide Parteien benötigen denselben Schlüssel. Solange Sie Daten auf Ihrem eigenen Server verschlüsseln, auf den nur Sie zugreifen, ist das kein Problem. Sobald Sie verschlüsselte Daten jedoch mit jemand anderem teilen müssen, stehen Sie vor dem Schlüsselverteilungsproblem: Wie übermitteln Sie den Schlüssel an die andere Partei, ohne ihn während der Übertragung offenzulegen?

Genau hier setzt die Public-Key-Kryptografie an.

Wie Public-Key-Kryptografie funktioniert

Public-Key-Kryptografie verwendet ein mathematisch verknüpftes Schlüsselpaar. Der öffentliche Schlüssel wird frei verteilt – jeder kann ihn besitzen. Der private Schlüssel wird von seinem Inhaber geheim gehalten. Mit dem öffentlichen Schlüssel verschlüsselte Daten können nur mit dem dazugehörigen privaten Schlüssel entschlüsselt werden.

Das löst das Verteilungsproblem. Wenn Sie einem Geschäftspartner einen sensiblen Schlüssel übermitteln möchten, verschlüsseln Sie ihn mit dessen öffentlichem Schlüssel. Nur der Partner kann ihn entschlüsseln, da nur er den passenden privaten Schlüssel besitzt. Der öffentliche Schlüssel kann gefahrlos über einen ungeschützten Kanal übertragen werden – wird er abgefangen, nützt das einem Angreifer nichts.

Der RSA-Algorithmus ist die am weitesten verbreitete Implementierung der Public-Key-Kryptografie. Er beruht auf der mathematischen Schwierigkeit, sehr große Zahlen zu faktorisieren – ein Problem, das bei den heute verwendeten Schlüsselgrößen mit aktueller Technologie rechnerisch nicht lösbar ist.

Public-Key-Kryptografie ermöglicht zudem digitale Signaturen: Ein Absender verschlüsselt einen Hashwert einer Nachricht mit seinem privaten Schlüssel. Jeder Empfänger kann die Signatur mit dem öffentlichen Schlüssel des Absenders überprüfen und so sowohl die Identität des Absenders als auch die Unversehrtheit der Nachricht während der Übertragung bestätigen. Dies ist die Grundlage für die TLS-Zertifikatsvalidierung, die Codesignierung und die S/MIME-E-Mail-Authentifizierung.

Wie beide Verfahren in der Praxis zusammenwirken

Jedes Mal, wenn Ihr Browser eine Verbindung zu einer HTTPS-Website herstellt, läuft eine Version dieses Ablaufs ab:

1. Der Server präsentiert sein digitales Zertifikat, das seinen öffentlichen Schlüssel enthält und von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde.
2. Der Client überprüft das Zertifikat und verwendet den öffentlichen Schlüssel des Servers, um sicher einen gemeinsamen symmetrischen Schlüssel auszuhandeln.
3. Ab diesem Zeitpunkt werden alle Daten der Sitzung mit AES verschlüsselt – schnell, effizient und geschützt durch einen Schlüssel, den nur die beiden Parteien kennen.

Dies ist der Diffie-Hellman-Schlüsselaustausch, und Varianten davon bilden praktisch die Grundlage jedes heute genutzten sicheren Kommunikationsprotokolls: TLS, IPsec, SSH und S/MIME folgen alle demselben Muster. Public-Key-Kryptografie authentifiziert und tauscht aus. AES-256 verschlüsselt die eigentlichen Daten.

Der Grund für diese Übergabe liegt in der Performance. Asymmetrische Verschlüsselung ist rechenintensiv – für die Verschlüsselung großer Dateien oder kontinuierlicher Datenströme ist sie nicht praktikabel. AES-256 verarbeitet Massendaten um Größenordnungen schneller. Das hybride Modell vereint die Sicherheitsvorteile beider Verfahren.

Wo Schlüsselmanagement zur Compliance-Frage wird

Sobald man versteht, dass Verschlüsselung auf zwei Ebenen abläuft – Schlüsselaustausch und Datenverschlüsselung –, wird klar, warum Compliance-Rahmenwerke nicht einfach fragen: „Verwenden Sie AES-256?“ Sie fragen, wer die Schlüssel kontrolliert, wie sie gespeichert werden, wie sie rotiert werden und was bei ihrer Vernichtung geschieht.

Unter CMMC 2.0 verlangen die Kontrollen SC.L2-3.13.8 und SC.L2-3.13.16 den kryptografischen Schutz von CUI (Controlled Unclassified Information) bei der Übertragung und im Ruhezustand mittels FIPS-validierter Module. CMMC-Prüfer untersuchen die Dokumentation zum Schlüsselmanagement im System Security Plan – nicht nur den verwendeten Algorithmus. Ein System, das CUI mit AES-256 verschlüsselt, die Verschlüsselungsschlüssel jedoch in einer Konfigurationsdatei auf demselben Server speichert, ist kein sicheres System und wird einer genauen Prüfung nicht standhalten.

Dieselbe Logik gilt unter FedRAMP und HIPAA. Die HIPAA-Safe-Harbor-Regelung zur Verletzungsmeldung greift nur, wenn PHI (Protected Health Information) verschlüsselt war und die Verschlüsselungsschlüssel sicher blieben. Verwaltet ein Cloud-Anbieter Ihre Verschlüsselungsschlüssel, kann deren Kompromittierung – oder eine an den Anbieter gerichtete behördliche Anordnung – Ihre Daten offenlegen, selbst wenn AES-256 im Einsatz war.

Deshalb sind kundenseitig verwaltete Verschlüsselungsschlüssel kein Premium-Feature. Für Unternehmen in regulierten Branchen sind sie eine Compliance-Voraussetzung.

Was eine wirklich solide Verschlüsselungsarchitektur ausmacht

Um die Verschlüsselungsversprechen einer Plattform zu bewerten, muss man über „AES-256 im Ruhezustand, TLS bei der Übertragung“ hinausblicken. Die entscheidenden Fragen lauten:

Wer besitzt die Schlüssel? Vom Anbieter verwaltete Schlüssel bedeuten, dass dieser Ihre Daten entschlüsseln kann. Kundenseitig verwaltete Schlüssel bedeuten, dass er es nicht kann – technisch, nicht nur vertraglich. Wird dem Anbieter eine behördliche Vorladung zugestellt, kann er bei kundenseitig verwalteten Schlüsseln schlicht nichts vorlegen.

Welche Validierung kryptografischer Module hält die Plattform? FIPS 140-2 wurde durch FIPS 140-3 abgelöst. Eine Plattform, die noch immer nur eine 140-2-Validierung vorweist, erfüllt möglicherweise nicht die aktuellen föderalen Anforderungen für Systeme, die CUI oder PHI in höheren Sensibilitätsstufen verarbeiten.

Ist die Schlüsselaustauschebene geschützt? TLS 1.0 und 1.1 weisen bekannte Schwachstellen auf. Die aktuellen NIST-Richtlinien schreiben mindestens TLS 1.2 vor, TLS 1.3 wird bevorzugt. Plattformen, die keine Mindest-TLS-Versionen erzwingen, setzen die Schlüsselaustauschebene Risiken aus – selbst wenn AES-256 die Daten selbst schützt.

Wird die Verschlüsselung über alle Kanäle hinweg konsistent angewendet? Eine Plattform, die Dateifreigaben verschlüsselt, aber E-Mails im Klartext versendet, oder die Uploads verschlüsselt, nicht jedoch API-Datenverkehr, weist Lücken auf, die unabhängig vom Algorithmus auf geschützten Kanälen echte Angriffsflächen schaffen.

Wie Kiteworks Verschlüsselung über den gesamten Stack hinweg umsetzt

Kiteworks implementiert AES-256-Verschlüsselung für Daten im Ruhezustand und TLS 1.2 (mit der Möglichkeit, TLS 1.3 zu erzwingen) für Daten bei der Übertragung über alle Kanäle hinweg – sichere E-Mail, sichere Dateifreigabe, Managed File Transfer, SFTP und sichere Datenformulare. Das kryptografische Modul der Plattform verfügt über eine FIPS 140-3 Level 1-Validierung – den aktuellen Standard, nicht das überholte 140-2.

Kiteworks setzt auf doppelte Verschlüsselung: Daten werden sowohl auf Datei- als auch auf Festplattenebene verschlüsselt. E-Mails werden über das Email Protection Gateway automatisch ver- und entschlüsselt; Empfänger nutzen ihre gewohnten E-Mail-Clients, ohne zusätzliche Software oder Schulung. Alle Dateiübertragungen enthalten eine Integritätsprüfung mittels digitalem MD5-Hash-Fingerabdruck.

Zur Schlüsselhoheit: Kiteworks-Kunden besitzen ihre Verschlüsselungsschlüssel selbst. Kiteworks verfügt zu keinem Zeitpunkt über die Schlüssel und kann nicht dazu gezwungen werden, Kundendaten herauszugeben – weil das Unternehmen technisch nicht in der Lage ist, sie zu entschlüsseln. Diese Architektur adressiert genau jene Compliance-Szenarien, in denen die Schlüsselkontrolle darüber entscheidet, ob Verschlüsselung überhaupt etwas bedeutet: CMMC Level 3, FedRAMP High und die DSGVO-Anforderungen zur Datensouveränität nach Schrems II.

Für Unternehmen, die zusätzlichen Schlüsselschutz benötigen, bindet Kiteworks Hardware-Sicherheitsmodule (HSMs) von Thales und den AWS Key Management Service ein – manipulationssichere Hardware, die die Extraktion von Schlüsseln selbst bei einem vollständig kompromittierten Server verhindert.

Das Ergebnis ist eine Plattform, deren Verschlüsselungsarchitektur – nicht nur der Algorithmus – auf regulierte Branchen ausgelegt ist. Kiteworks erfüllt nahezu 90 % der CMMC-Level-2-Anforderungen von Haus aus und verfügt über eine FedRAMP-Moderate-Autorisierung mit High-Ready-Status.

Um zu erfahren, wie Kiteworks Verschlüsselung im Hinblick auf Ihre spezifischen Compliance-Anforderungen umsetzt, vereinbaren Sie eine individuelle Demo.