AES-GCM vs AES-CBC: Welchen Modus verwenden und warum

AES verschlüsselt 16 Byte. Alles Längere braucht einen Betriebsmodus darum herum, und im Modus liegen die eigentlichen Sicherheitseigenschaften.

Zwei davon begegnen einem ständig: CBC und GCM. Sie sind nicht austauschbar, und die falsche Wahl ergibt Code, der jeden Test besteht und still eine Eigenschaft verliert, deren Fehlen niemandem auffällt.

Wozu Modi überhaupt

Daten in 16-Byte-Blöcke teilen, jeden einzeln verschlüsseln, aneinanderhängen. Das ist ECB, und es scheitert sichtbar: Gleiche Klartextblöcke ergeben gleiche Chiffratblöcke, Struktur überlebt also die Verschlüsselung.

Jeder andere Modus existiert, um das zu beheben, und dann das, was danach kommt.

• CBC XORt jeden Klartextblock mit dem vorherigen Chiffratblock vor dem Verschlüsseln. Ein Initialisierungsvektor bricht das Muster für den ersten Block.
• GCM betreibt AES als Stromchiffre im Counter-Modus und berechnet ein Authentifizierungs-Tag über das Ergebnis.

Was jeder Modus auf die Leitung legt

CBC braucht drei Dinge, um sicher zu sein, und liefert zwei. Der IV muss unvorhersehbar sein, nicht nur einmalig, denn ein vorhersehbarer IV erlaubt einen Angriff mit gewähltem Klartext. Der Klartext muss auf ein Vielfaches von 16 aufgefüllt werden, üblicherweise mit PKCS#7. Und das Chiffrat muss von einem separaten HMAC in einer Encrypt-then-MAC-Konstruktion authentifiziert werden, mit eigenem Schlüssel, in einem Schritt, zu dem Sie nichts zwingt.

Daraus folgen zwei Fehlerbilder:

Padding-Orakel. Verrät der Entschlüsselungspfad, ob das Padding gültig war, über eine Fehlermeldung, einen Statuscode oder einen Zeitunterschied, stellt ein Angreifer den Klartext Byte für Byte ohne Schlüssel wieder her. Der kanonische Produktionsfall ist die ASP.NET-Schwachstelle von 2010³, und sie war nicht die erste.

Formbarkeit. Ohne MAC kippt ein gekipptes Bit im Chiffrat das entsprechende Bit im Klartext. Die Empfängerseite entschlüsselt etwas, das die Absenderin nie geschrieben hat, und kann es nicht bemerken.

GCM hat ein bewegliches Teil weniger. Counter-Modus heisst, das Chiffrat ist genau so lang wie der Klartext, es gibt also kein Padding zum Angreifen. Das Tag entsteht im selben Aufruf wie das Chiffrat, es kann also nicht vergessen werden. Und auf jeder modernen CPU ist es schneller als CBC plus HMAC-SHA-256, weil beide Hälften hardwarebeschleunigt sind.

Für eine laufende Implementierung: Unser AES verschlüsseln/entschlüsseln beherrscht GCM, CBC und CTR mit 128, 192 oder 256 Bit, vollständig in der Seite. Es nimmt Text statt Dateien, leitet den Schlüssel per PBKDF2 aus Ihrer Passphrase ab und gibt einen einzelnen base64-Block zurück, der Salt, IV und Chiffrat enthält, statt die Felder einzeln anzuzeigen.

Die eine scharfe Kante

Verschlüsseln Sie zwei verschiedene Nachrichten mit demselben Schlüssel und derselben Nonce, wird GCM nicht schwächer. Es fällt in sich zusammen.

Weil der Schlüsselstrom nur vom Schlüssel und der Nonce abhängt, heisst beides wiederzuverwenden, zwei Klartexte mit demselben Schlüsselstrom zu XORen. Das XOR der Chiffrate ist damit das XOR der Klartexte, der Schlüssel kürzt sich vollständig heraus. Wir haben "Transfer 100 EUR to Alice" und "Transfer 900 EUR to Mallory" unter einem Schlüssel und einer Nonce verschlüsselt: Die Chiffrate kamen identisch heraus bis auf das eine Byte, an dem sich die Beträge unterscheiden, und das Einrechnen der ersten Nachricht gab die zweite im Klartext zurück.

Fälschung kommt dazu. Eine wiederverwendete Nonce gibt genug über den GHASH-Teilschlüssel preis, dass ein Angreifer neue Nachrichten erzeugen kann, die die Tag-Prüfung bestehen.

NIST formuliert die Anforderung nüchtern: Die Wahrscheinlichkeit, die Verschlüsselung je mit demselben IV und Schlüssel aufzurufen, darf nicht grösser als 2^-32 sein, und "in practice this requirement is almost as important as the secrecy of the key"¹.

Der entsprechende CBC-Fehler ist schlimm und überlebbar: Ein wiederverwendeter IV verrät, ob zwei Nachrichten einen gemeinsamen Anfang haben, mehr nicht.

Auf der richtigen Seite bleiben

Zwei Konstruktionen, und je Schlüssel muss man sich für genau eine entscheiden¹.

Zufällige 96-Bit-Nonces aus einem echten CSPRNG. Kollisionen folgen der Geburtstagsschranke, die Obergrenze ist also nicht "wenn es sich unwohl anfühlt": NIST begrenzt die Gesamtzahl der Aufrufe je Schlüssel auf 2^32¹. Das ist eine harte Grenze, keine vorsichtige, und sie gehört auf den Auslöser für den Schlüsselwechsel.

Zählerbasierte Nonces, bei denen ein festes Feld das Gerät benennt und ein Aufruffeld je Nachricht hochzählt. Den Zähler nie ohne Schlüsselwechsel zurücksetzen. Für Clients, die über schlechte Netze erneut senden, ist das die belastbarere Wahl, denn ein erneuter Versuch, der neu verschlüsselt, ist genau der Weg, auf dem Systeme mit Zufalls-Nonces versehentlich eine wiederholen.

Erzeugen Sie Schlüssel und Nonces aus einer kryptografischen Quelle: crypto.randomBytes in Node, secrets.token_bytes in Python, SecureRandom in Ruby. Unser Zufalls-String-Generator nutzt crypto.getRandomValues, dieselbe Primitive, die WebCrypto intern verwendet.

Die Wahl

• GCM für Neues. Netzwerkprotokolle, Dateiverschlüsselung, alles, wo Vertraulichkeit und Integrität aus einer Primitive kommen sollen.
• CBC plus HMAC-SHA-256 nur zur Kompatibilität mit etwas, das es schon spricht, oder wo Regularien Sie festlegen.
• Nie CBC allein über eine Vertrauensgrenze hinweg.
• Nie ECB.

Die ehrliche Zusammenfassung ist eine Zählung der Fussangeln. CBC hat drei: vorhersehbare IVs, Padding-Orakel und ein vergessener MAC. GCM hat eine, und anders als die anderen ist sie laut, sobald man weiss, worauf man achtet.

Schlüssellängen

AES nimmt Schlüssel mit 128, 192 oder 256 Bit, und beide Modi akzeptieren jede davon unverändert. AES-128 ist gegen klassische Angriffe solide. Grovers Algorithmus würde die effektive symmetrische Sicherheit halbieren, was AES-128 nominell auf 64 Bit und AES-256 auf 128 setzt, gegenüber einem grossen Quantenrechner, den es noch nicht gibt. Der Kostenunterschied ist klein genug, dass AES-256 die vernünftige Vorgabe ist, und mehrere Regelwerke verlangen es ohnehin.

Wechseln Sie den Schlüssel, wenn die Aufrufgrenze näher rückt, wenn ein Gerät oder Zugangsdatum kompromittiert ist, oder nach Plan. Ein Jahr ist für langlebige Schlüssel üblich; Sitzungsschlüssel sollten kurzlebig sein.

Zum Vergleichen von Fingerabdrücken, statt etwas zu entschlüsseln, deckt der Hash-Generator SHA-256 und Verwandte ab. Andere Primitive, benachbarte Aufgabe.

Was die Protokolle entschieden haben

Sie wählen den Modus selten von Hand, weil das Protokoll schon gewählt hat.

• TLS 1.3 hat CBC vollständig entfernt. Jede definierte Cipher Suite ist AEAD².
• TLS 1.2 erlaubt AES-CBC-Suites weiterhin, und sie werden stetig abgeschaltet.
• OpenSSH nutzt für moderne Verbindungen standardmässig GCM und ChaCha20-Poly1305.
• Cloud-KMS-Dienste verwenden intern authentifizierte Modi.

Jedes Protokoll, das diese Frage neu gestellt hat, ist bei authentifizierter Verschlüsselung gelandet. Diese Konvergenz ist ein besseres Argument als jede einzelne Eigenschaft.

Das Fazit

CBC ist ein Modus, der drei Dinge richtig verlangt und Sie mit zweien ausliefern lässt. GCM verlangt eines richtig und beschwert sich über den Rest lautstark. Nehmen Sie GCM, setzen Sie die Nonce-Verwaltung auf dieselbe Checkliste wie den Schlüsselwechsel, und lassen Sie funktionierenden CBC-plus-HMAC-Code in Ruhe, bis ein geplanter Wechsel einen sauberen Moment zum Migrieren bietet.