AES-256-GCM: Der authentifizierte Verschlüsselungsstandard, der Ihre iPhone-Dateien schützt

TL;DR

AES-256-GCM ist ein authentifizierter Verschlüsselungsalgorithmus, der Daten verschlüsselt und deren Integrität mit einem einzigen Schlüssel und einer einmaligen Nonce pro Nachricht prüft. Er ist durch NIST-Standards definiert, auf modernen iPhones hardwarebeschleunigt und wird von TLS 1.3, WireGuard und Signal verwendet. AppVault setzt AES-256-GCM mit einer eindeutigen 96-Bit-Nonce pro Datei, einem PBKDF2-abgeleiteten und von der Secure Enclave umhüllten Schlüssel sowie ohne Netzwerkaufrufe ein.

AES-256-GCM ist nicht nur ein einzelner Algorithmus. Es ist die Kombination zweier Standards: des Advanced Encryption Standard (AES) mit einem 256-Bit-Schlüssel und des Galois/Counter Mode (GCM) als Betriebsart. Zusammen bilden sie ein authentifiziertes Verschlüsselungsschema, das Vertraulichkeit und Integritätsprüfung in einem Durchgang bietet. Es ist die Standardchiffre in TLS 1.3, WireGuard, Signal und der iOS-Dateiverschlüsselung. Zu verstehen, wie es funktioniert, ist wichtig, weil die meisten Sicherheitslücken bei AES-256-GCM auf Implementierungsfehler zurückgehen – nicht auf das Knacken der Chiffre selbst.

Für eine nicht-technische Einführung in die zugrundeliegende Blockchiffre – was „256-Bit-Schlüssel“ bedeutet, warum der Schlüsselraum durch Brute-Force nicht knackbar ist, wie AES im Jahr 2001 von NIST ausgewählt wurde – lesen Sie zuerst den verständlichen Leitfaden Was ist AES-256-Verschlüsselung?. Dieser Artikel geht speziell tiefer auf den GCM-Modus ein.

Die Blockchiffre: AES-256

AES ist eine symmetrische Blockchiffre, die von NIST in FIPS 197 standardisiert wurde. Sie arbeitet mit 128-Bit-Blöcken und unterstützt Schlüssellängen von 128, 192 und 256 Bit. AES-256 verwendet einen 256-Bit-Schlüssel und führt 14 Runden von Substitutions-Permutations-Operationen durch. Jede Runde wendet vier Transformationen an: SubBytes (nichtlineare Substitution via S-Box), ShiftRows (Byte-Transposition), MixColumns (Matrixmultiplikation über GF(2^8)) und AddRoundKey (XOR mit dem aus dem Masterschlüssel abgeleiteten Rundenschlüssel).

Die Sicherheitsmarge von AES-256 ist hoch. Die bekanntesten kryptanalytischen Angriffe betreffen Varianten mit reduzierten Runden (z. B. 7-Runden-AES-128) oder verwandte Schlüsselschemata, die in der Praxis nicht vorkommen. Für das vollständige 14-Runden-AES-256 existiert kein praktischer Angriff, der die effektive Schlüssellänge unter 256 Bit senkt. Aus diesem Grund ist AES-256 von der US-amerikanischen National Security Agency für Geheimdaten der Stufe „Top Secret“ zugelassen.

AES-256 ist auf praktisch allen modernen CPUs hardwarebeschleunigt. Intel- und AMD-Prozessoren enthalten AES-NI-Befehle. Apple Silicon (M-Serie und A-Serie) enthält ARM Crypto Extensions, die AES-, SHA- und GCM-Operationen beschleunigen. Auf einem iPhone ist die AES-256-Verschlüsselung einer 10 MB großen Datei in Millisekunden abgeschlossen.

Die Betriebsart: Galois/Counter Mode (GCM)

Eine Blockchiffre verschlüsselt immer nur einen Block auf einmal. Um Nachrichten zu verschlüsseln, die länger als 128 Bit sind, benötigt man eine Betriebsart. GCM, spezifiziert in NIST SP 800-38D, ist eine authentifizierte Verschlüsselungsbetriebsart, die eine Counter-Mode-Variante zur Verschlüsselung mit einer universellen Hash-Funktion (GHASH) zur Authentifizierung kombiniert. Derselbe Aufbau ist als AEAD-Primitiv in IETF RFC 5116 registriert.

GCM arbeitet in zwei Phasen. Zuerst wird der Klartext mit AES im Counter-Mode verschlüsselt: Ein 128-Bit-Counter wird für jeden Block erhöht, mit AES verschlüsselt und mit dem Klartext XOR-verknüpft, um den Chiffretext zu erzeugen. Der anfängliche Counter-Wert wird aus einer Nonce („number used once“) plus einem ab 1 zählenden Counter abgeleitet. Zweitens werden der Chiffretext und die assoziierten Daten (Metadaten, die authentifiziert, aber nicht verschlüsselt werden müssen) in GHASH eingespeist – eine Polynomauswertung in GF(2^128). Die GHASH-Ausgabe wird dann mit AES verschlüsselt, um den Authentifizierungstoken zu erzeugen.

Das Ergebnis ist eine einzige Ausgabe: Chiffretext plus ein 128-Bit-Authentifizierungstoken (Standardlänge, kann gekürzt werden). Der Empfänger entschlüsselt, indem er den Token neu berechnet und vergleicht. Wenn der Token übereinstimmt, sind die Daten authentisch. Wenn nicht, muss der Empfänger die Daten verwerfen.

GCM ist parallelisierbar. Der Counter-Mode erlaubt die gleichzeitige Verschlüsselung mehrerer Blöcke, weshalb Hardwarebeschleunigung einen hohen Durchsatz erzielen kann. Auf einem iPhone mit ARM Crypto Extensions kann AES-256-GCM mit mehreren Gigabit pro Sekunde verschlüsseln.

Nonce-Disziplin: Der häufigste Fehlerpunkt

AES-256-GCM benötigt eine Nonce. Der Standard spezifiziert eine 96-Bit-Nonce. Die Nonce muss bei jeder Verschlüsselung mit demselben Schlüssel einmalig sein. Die Wiederverwendung einer Nonce mit demselben Schlüssel erlaubt es einem Angreifer, den GHASH-Authentifizierungsschlüssel (H) wiederherzustellen und anschließend beliebige Nachrichten zu fälschen.

Die Mathematik ist unerbittlich: Wenn zwei Chiffretexte dieselbe Nonce und denselben Schlüssel teilen, gibt das XOR der beiden GHASH-Ausgaben das XOR der Klartexte preis. Von dort aus kann ein Angreifer H wiederherstellen und gültige Tokens für beliebige Chiffretexte erzeugen. Dies ist kein theoretischer Angriff. Er wurde in der Praxis ausgenutzt, am bekanntesten im Fachartikel „Nonce-Disrespecting Adversaries“ von 2015, der Sicherheitslücken durch Nonce-Wiederverwendung in mehreren TLS-Implementierungen aufdeckte.

Die richtige Gegenmaßnahme ist, eine Nonce unter demselben Schlüssel nie wiederzuverwenden. In der Praxis bedeutet das entweder, eine zufällige Nonce zu erzeugen (96 Bit ergeben 2^96 Möglichkeiten, aber die Geburtstagsschranke besagt, dass man nicht mehr als 2^32 Nachrichten mit zufälligen Nonces verschlüsseln sollte, um eine vernachlässigbare Kollisionswahrscheinlichkeit zu gewährleisten) oder einen deterministischen Zähler zu verwenden, der garantiert pro Nachricht eindeutig ist.

AppVault verwendet eine eindeutige 96-Bit-Nonce pro Datei. Die Nonce wird mit einem kryptografisch sicheren Zufallszahlengenerator (SecRandomCopyBytes auf iOS) erzeugt und zusammen mit dem Chiffretext gespeichert. Da jede Datei ihre eigene Nonce erhält und der Schlüssel pro Installation abgeleitet und von der Secure Enclave umhüllt wird, ist das Risiko einer Nonce-Wiederverwendung ausgeschlossen.

Hardwarebeschleunigung: Warum sie wichtig ist

AES-256-GCM ist in reiner Software rechenintensiv. Besonders die GHASH-Multiplikation in GF(2^128) ist ohne Hardwareunterstützung aufwändig. Moderne CPUs enthalten spezielle Befehle, die AES-Runden und GHASH-Operationen in einem einzigen Taktzyklus ausführen.

Auf einem iPhone umfassen die ARM Crypto Extensions:

• AES-Befehle (AESE, AESD, AESMC, AESIMC), die eine Runde AES-Verschlüsselung oder -Entschlüsselung durchführen.
• GHASH-Befehle (PMULL/PMULL2 für Polynommultiplikation), die die GHASH-Berechnung beschleunigen.

Die Secure Enclave in Apple Silicon enthält eine dedizierte AES-Engine, die Daten verschlüsseln kann, ohne den Schlüssel der Haupt-CPU zugänglich zu machen. AppVault nutzt die Secure Enclave, um den Dateiverschlüsselungsschlüssel zu umhüllen, sodass selbst bei einer Kompromittierung der Haupt-CPU der Schlüssel geschützt bleibt.

Ohne Hardwarebeschleunigung wäre AES-256-GCM für Echtzeitanwendungen wie TLS-Handshakes oder Videostreaming zu langsam. Mit ihr ist der Aufwand vernachlässigbar.

Wo AES-256-GCM eingesetzt wird

AES-256-GCM ist die Standard-Chiffrewahl in TLS 1.3 (TLS_AES_256_GCM_SHA384). Jede HTTPS-Verbindung, die TLS 1.3 verwendet, verlässt sich darauf. WireGuard, das moderne VPN-Protokoll, verwendet AES-256-GCM (oder ChaCha20-Poly1305 auf Geräten ohne Hardware-AES). Signal, der verschlüsselte Messenger, verwendet AES-256-GCM für die Verschlüsselung von Mediendateien. iOS verwendet AES-256-GCM für die Dateiverschlüsselung auf Dateiebene (Data Protection).

Die Allgegenwärtigkeit von AES-256-GCM ist kein Zufall. Es ist ein NIST-Standard, hardwarebeschleunigt und von der Kryptografiegemeinschaft gut verstanden. Es ist der sichere Standard für jede Anwendung, die authentifizierte Verschlüsselung benötigt.

Vergleich mit anderen authentifizierten Verschlüsselungsbetriebsarten

AES-256-GCM ist nicht die einzige AEAD-Betriebsart. ChaCha20-Poly1305 ist eine beliebte Alternative, besonders auf Geräten ohne Hardware-AES-Beschleunigung. ChaCha20 ist eine Stromchiffre, keine Blockchiffre, und Poly1305 ist ein Polynom-Hash ähnlich GHASH. ChaCha20-Poly1305 ist in reiner Software schneller als AES-256-GCM, aber auf Hardware mit AES-NI ist AES-256-GCM schneller.

AES-256-CCM (Counter with CBC-MAC) ist eine weitere NIST-standardisierte AEAD-Betriebsart, jedoch nicht parallelisierbar und langsamer als GCM. CCM wird in einigen IoT- und Funkprotokollen verwendet, aber TLS und die meisten modernen Anwendungen bevorzugen GCM.

AES-256-GCM-SIV ist eine nonce-fehlerresistente Variante, die bei einer Nonce-Wiederverwendung nur preisgibt, dass zwei Nachrichten gleich sind, nicht den Klartext. Sie ist langsamer als normales GCM und weniger verbreitet.

Für die meisten Anwendungen ist AES-256-GCM die richtige Wahl. Es ist schnell, standardisiert und sicher, wenn es korrekt implementiert wird.

Wie AppVault AES-256-GCM implementiert

AppVault verwendet AES-256-GCM für jede im Schließfach gespeicherte Datei. Die Implementierung erfolgt in folgenden Schritten:

1. Schlüsselableitung. Das Musterschloss des Benutzers wird mit PBKDF2-SHA256, 600.000 Iterationen und einem installationsspezifischen 128-Bit-Salz in einen 256-Bit-Masterschlüssel umgewandelt. Dieser Schlüssel wird nie direkt zur Verschlüsselung verwendet.
2. Secure-Enclave-Umhüllung. Der Masterschlüssel wird an die Secure Enclave gesendet, die einen neuen Schlüssel (den „Umhüllungsschlüssel“) erzeugt, der den Chip nie verlässt. Die Enclave verschlüsselt den Masterschlüssel mit dem Umhüllungsschlüssel und gibt den umhüllten Schlüssel an die Haupt-CPU zurück. Der Klartext-Masterschlüssel wird anschließend aus dem Speicher gelöscht.
3. Dateiverschlüsselung. Für jede Datei wird eine neue 96-Bit-Nonce mit SecRandomCopyBytes erzeugt. Der umhüllte Schlüssel wird innerhalb der Secure Enclave enthüllt und zur Verschlüsselung der Datei mit AES-256-GCM verwendet. Der Chiffretext und die Nonce werden gespeichert. Der Authentifizierungstoken wird an den Chiffretext angehängt.
4. Katalogverschlüsselung. Selbst die Liste der Dateien (Namen, Daten, Größen) wird mit AES-256-GCM unter einem separaten, vom selben Masterschlüssel abgeleiteten Schlüssel verschlüsselt. Das bedeutet, dass ein Angreifer mit direktem Gerätezugriff nicht ermitteln kann, wie viele Dateien vorhanden sind.

Das Ergebnis ist, dass keine zwei Dateien denselben Chiffretext erzeugen – selbst wenn sie identischen Klartext enthalten. Die Secure Enclave stellt sicher, dass der Verschlüsselungsschlüssel niemals dem Hauptbetriebssystem ausgesetzt wird. Und da AppVault keinerlei Netzwerkaufrufe tätigt, gibt es keinen Server, der kompromittiert werden könnte, um Schlüssel oder Chiffretexte preiszugeben.

Grenzen von AES-256-GCM

AES-256-GCM schützt nicht gegen alles. Es ist anfällig für Seitenkanalangriffe, wenn die Implementierung Timing- oder Leistungsinformationen preisgibt. Die GHASH-Berechnung reagiert besonders empfindlich auf Timing-Angriffe; konstante Implementierungen sind erforderlich. Apples CoreCrypto-Bibliothek bietet eine konstante AES-256-GCM-Implementierung, und AppVault verwendet diese Bibliothek.

AES-256-GCM bietet keine Vorwärtssicherheit (Forward Secrecy). Wenn der Schlüssel kompromittiert wird, können alle vergangenen Chiffretexte entschlüsselt werden. Vorwärtssicherheit wird auf Protokollebene erreicht (z. B. verwendet TLS 1.3 ephemeren Diffie-Hellman-Schlüsselaustausch) und ist keine Eigenschaft der Chiffre selbst. AppVault mildert dies, indem der Schlüssel auf dem Gerät verbleibt und niemals übertragen wird.

AES-256-GCM ist nicht quantensicher. Grovers Algorithmus reduziert die effektive Schlüssellänge von AES-256 von 256 Bit auf 128 Bit. Ein ausreichend großer Quantencomputer könnte es knacken. Ein solcher Quantencomputer existiert jedoch nicht und wird nicht innerhalb des nächsten Jahrzehnts erwartet. Für langfristige Geheimnisse werden Post-Quanten-Chiffren wie CRYSTALS-Kyber standardisiert.

AES-256-GCM schützt nicht vor Gummischlauch-Kryptanalyse oder physischer Gerätebeschlagnahme. Wenn ein Angreifer physischen Zugriff auf Ihr iPhone hat und Sie zwingen kann, es zu entsperren, kann keine Verschlüsselung Ihre Dateien schützen. Das Bedrohungsmodell von AppVault geht davon aus, dass sich das Gerät unter Ihrer Kontrolle befindet.

Warum AppVault AES-256-GCM gewählt hat

AppVault hat sich für AES-256-GCM entschieden, weil es der am weitesten verbreitete authentifizierte Verschlüsselungsalgorithmus mit Hardwarebeschleunigung auf jedem modernen iPhone ist. Es ist standardisiert, begutachtet und von den größten Sicherheitsprotokollen der Welt vertrauenswürdig eingesetzt. Es ermöglicht AppVault, Dateien schnell zu verschlüsseln, ohne den Akku zu belasten, und seine Integritätsprüfung stellt sicher, dass gespeicherte Dateien nicht manipuliert wurden.

Die Alternative, ChaCha20-Poly1305, ist ebenfalls sicher und wird von AppVault für bestimmte Operationen verwendet, bei denen Hardware-AES nicht verfügbar ist (z. B. auf älteren Geräten). Für die Dateiverschlüsselung unter iOS ist AES-256-GCM jedoch die natürliche Wahl.

Jede Datei in AppVault wird mit AES-256-GCM, einer eindeutigen Nonce und einem Schlüssel verschlüsselt, der aus Ihrem Musterschloss abgeleitet und von der Secure Enclave umhüllt wird. Der vollständige kryptografische Stack ist auf der Seite AES-256-GCM-Verschlüsselung dokumentiert, mit Verweisen auf NIST FIPS 197, NIST SP 800-38D und Apples Platform Security Guide. Die Seite Bedrohungsmodell erklärt, wogegen diese Architektur schützt und wogegen nicht. Die Seite Zero-Knowledge-Architektur erklärt, warum AppVault Ihre Daten niemals sieht.