Authentifizierte Verschlüsselung: AES-GCM und ChaCha20-Poly1305

Authenticated Encryption (AE) löst ein grundlegendes Problem: Herkömmliche Verschlüsselung bietet nur Vertraulichkeit – sie hält Daten geheim –, überprüft jedoch nicht, ob der Chiffretext manipuliert wurde. Ein Angreifer könnte Bits im Chiffretext verändern, woraufhin der Empfänger unbrauchbare Daten entschlüsseln würde, ohne die Manipulation zu bemerken. Authenticated Encryption with Associated Data (AEAD) ergänzt gleichzeitig eine Integritäts- und Authentizitätsgarantie und erzeugt sowohl verschlüsselten Chiffretext als auch einen Authentifizierungs-Tag, der jede Änderung erkennt.

AES-GCM (Galois/Counter Mode) kombiniert zwei Komponenten: AES-CTR (Counter Mode) zur Verschlüsselung und GMAC (Galois Message Authentication Code) zur Sicherstellung der Integrität. AES-CTR erzeugt einen Schlüsselstrom, indem ein Zählerwert verschlüsselt und per XOR mit dem Klartext verknüpft wird – dadurch lässt sich die Verschlüsselung parallelisieren, anders als beim CBC-Modus. GMAC berechnet einen Authentifizierungs-Tag über den Chiffretext und alle zugehörigen Daten. Der daraus entstehende Tag (128 Bit) wird zusammen mit dem Chiffretext übertragen; bereits eine Änderung eines einzigen Bits macht den Tag ungültig.

AES-GCM erfordert eine Nonce (number used once), typischerweise mit 96 Bit (12 Byte). Die Nonce muss bei jedem einzelnen Verschlüsselungsvorgang mit demselben Schlüssel eindeutig sein – sie muss nicht geheim sein, darf sich aber niemals wiederholen. Die Wiederverwendung einer Nonce in AES-GCM ist katastrophal: Wenn zwei Nachrichten mit demselben Schlüssel und derselben Nonce verschlüsselt werden, kann ein Angreifer die Chiffrate per XOR verknüpfen und dadurch den Keystream entfernen, sodass er möglicherweise beide Klartexte wiederherstellen kann. Diese Schwachstelle wird manchmal als „Nonce-Missbrauch“ bezeichnet und hat bereits zu Angriffen zur Wiederherstellung von Schlüsseln in der Praxis geführt.

Wenn AES-GCM-Nonces wiederverwendet werden, kann der Angreifer C1 XOR C2 = P1 XOR P2 berechnen (das XOR beider Klartexte), da für beide Nachrichten derselbe Keystream verwendet wurde. Außerdem ermöglicht die Wiederverwendung der Nonce die Wiederherstellung des Authentifizierungsschlüssels H. Dadurch kann der Angreifer gültige Authentifizierungs-Tags für beliebige Nachrichten fälschen – Vertraulichkeit und Integrität sind damit vollständig kompromittiert. Systeme wie die Sony PS3 waren von genau diesem Angriff betroffen. Schutz bieten zufällige Nonces (erzeugt mit einem CSPRNG) oder ein deterministischer Zähler, der niemals zurückgesetzt wird.

ChaCha20-Poly1305 ist die andere in TLS 1.3 vorgeschriebene AEAD-Chiffre. ChaCha20 ist eine von Daniel Bernstein entwickelte Stromchiffre, die mithilfe von Add- Rotate-XOR-Operationen (ARX) einen Keystream erzeugt – ohne Lookup-Tabellen, vollständig in konstanter Zeit und äußerst schnell auf CPUs ohne Hardwarebeschleunigung für AES. Poly1305 ist ein einmaliger MAC (Message Authentication Code), der den Authentifizierungs-Tag über dem Chiffrat berechnet. Zusammen bieten beide eine gleichwertige Sicherheit wie AES-GCM, sind auf Mobil- und IoT-Geräten jedoch deutlich schneller.

Moderne Desktop- und Serverprozessoren mit x86- und ARM64-Architektur verfügen über AES-NI-Hardwarebefehle, die AES-GCM äußerst schnell machen. Viele Mobil- und IoT-Prozessoren unterstützen AES-NI jedoch nicht, wodurch softwarebasiertes AES-GCM vergleichsweise langsam ist. ChaCha20-Poly1305 wurde so konzipiert, dass es mithilfe einfacher arithmetischer Operationen in Software schnell ausgeführt werden kann. Dadurch erreichen Mobilgeräte auch ohne Hardwarebeschleunigung eine vergleichbare Leistung. Google fügte ChaCha20-Poly1305 TLS genau deshalb als Alternative für Android-Geräte hinzu; inzwischen ist es eine vollwertige Cipher-Suite in TLS 1.3.

Das „AD“ in AEAD steht für Associated Data – Klartextmetadaten, die authentifiziert, aber nicht verschlüsselt werden. So können Sie Daten authentifizieren, die lesbar bleiben müssen (etwa Paket-Header oder Felder mit dem Datensatztyp), und sie dennoch vor Manipulation schützen. In TLS 1.3 werden die Bytes des Datensatz-Headers als zugehörige Daten in die AEAD-Berechnung einbezogen. Wenn ein Angreifer den Header verändert (beispielsweise die Datensatzlänge), schlägt die Prüfung des Authentifizierungs-Tags fehl und die Verbindung wird beendet.

Bevor sich AEAD als Standard durchsetzte, empfahlen Kryptografen Encrypt-then-MAC (EtM): Zuerst wird der Klartext verschlüsselt, anschließend wird ein MAC über dem Chiffrat berechnet. Dieses Verfahren ist sicher, erfordert jedoch zwei getrennte Operationen mit zwei getrennten Schlüsseln. AEAD-Verfahren wie AES-GCM kombinieren beide Operationen mit einem einzigen Schlüssel, wodurch die Implementierung einfacher wird und eine ganze Klasse von Padding-Oracle-Angriffen entfällt, die bei MAC-then-Encrypt (MtE) auftraten – der in älteren TLS-Versionen verwendeten Reihenfolge (CBC + HMAC). TLS 1.3 vermeidet diese Probleme durch den Einsatz von AEAD vollständig.

Sowohl AES-128-GCM als auch AES-256-GCM sind von NIST zugelassen und gelten als sicher gegen klassische Computer. AES-128 bietet eine Sicherheit von 128 Bit bei etwas höherer Geschwindigkeit; AES-256 bietet eine Sicherheit von 256 Bit und damit größere Reserven gegenüber zukünftigen kryptoanalytischen und quantenbasierten Bedrohungen. Für die meisten heutigen Anwendungen ist AES-128-GCM ausreichend, für staatliche Systeme mit Geheimhaltungsstufe (NSA Suite B) ist jedoch AES-256 vorgeschrieben. TLS 1.3 bietet beide Varianten, und Server können sie entsprechend ihrer Sicherheitsrichtlinie priorisieren.

Beim Entschlüsseln eines AEAD-Chiffrats muss der Empfänger das Authentifizierungs-Tag vor dem Entschlüsseln prüfen. Der Ablauf ist wie folgt: Das erwartete Tag wird aus dem empfangenen Chiffrat, dem Schlüssel und der Nonce neu berechnet; anschließend wird es mithilfe einer Vergleichsfunktion mit konstanter Laufzeit mit dem empfangenen Tag verglichen; nur bei Übereinstimmung wird die Entschlüsselung fortgesetzt. Ein Vergleich mit konstanter Laufzeit ist entscheidend: Wenn der Vergleich beim ersten abweichenden Byte vorzeitig abbricht, kann ein Angreifer einen Timing-Seitenkanalangriff durchführen und gültige Tags Byte für Byte fälschen. Jede AEAD-Bibliothek, die einen Vergleich mit vorzeitigem Abbruch verwendet, ist anfällig.

AEAD-Algorithmen sind in der modernen IT-Sicherheit allgegenwärtig: TLS 1.3 verwendet AES-GCM und ChaCha20-Poly1305 für die Verschlüsselung aller Datensätze; WireGuard VPN verwendet ausschließlich ChaCha20-Poly1305; das Signal Protocol verwendet es zur Nachrichtenverschlüsselung; das QUIC protocol (die Grundlage von HTTP/3) verwendet AES-GCM. Wenn Sie eine Cipher-Suite wie TLS_AES_256_GCM_SHA384 sehen, bezieht sich SHA384 auf die HKDF-Hashfunktion zur Schlüsselableitung, nicht auf den Integritätsmechanismus – das GCM-Tag gewährleistet die Integrität.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: AEAD-Algorithmen gewährleisten gleichzeitig Vertraulichkeit und Integrität, indem ein Authentifizierungs-Tag jede Änderung am Chiffrat erkennt; die Wiederverwendung einer AES-GCM-Nonce ist katastrophal – sie ermöglicht die Wiederherstellung des Keystreams und die Fälschung des Authentifizierungsschlüssels –, daher muss jede Nonce pro Verschlüsselung eindeutig sein; und ChaCha20-Poly1305 ist eine leistungsfähige Alternative zu AES-GCM für Geräte ohne Hardwarebeschleunigung für AES. Als Nächstes befassen wir uns mit Schlüsselableitungsfunktionen zum Schutz von Passwörtern.