AES: Was es ist, Algorithmus der symmetrischen Verschlüsselung und wo er eingesetzt wird

AES-Schlüsselgrößen und Sicherheitsstufen

AES unterstützt drei Schlüsselgrößen, die jeweils einer bestimmten kryptografischen Stärke entsprechen. Die Wahl der Schlüsselgröße beeinflusst Sicherheit, Leistung und Geräteressourcenanforderungen.

Praktische Regel: Für mobile Anwendungen standardmäßig AES-256 verwenden. Der Leistungsunterschied zwischen AES-128 und AES-256 auf modernen Geräten mit AES-NI-Unterstützung beträgt nicht mehr als 10–15%, aber die Sicherheitsstufe verdoppelt sich. Laut Quantenanalyse (Grassl et al., 2016) würde das Knacken von AES-128 2^77 Quantenoperationen über Grovers Algorithmus erfordern, während AES-256 2^149 benötigen würde, was AES-256 für die nächsten 20–30 Jahre resistent gegen Quantenangriffe macht. Selbst AES-128 bietet ausreichenden Schutz für die überwältigende Mehrheit kommerzieller Szenarien: Das Brute-Forcen eines 128-Bit-Schlüssels würde nach Bruce Schneiers Schätzung mehr Energie erfordern, als im Universum existiert. Allerdings verlangen Sicherheitsstandards (GDPR, HIPAA, PCI DSS) oft explizit AES-256, daher sollten Produktionsprojekte die maximale Schlüssellänge verwenden.

AES-Betriebsmodi

AES als Blockchiffre verschlüsselt Blöcke fester Größe (128 Bit). Zur Verschlüsselung von Daten beliebiger Länge werden Betriebsmodi verwendet. Die Modusauswahl beeinflusst die Sicherheit kritisch: Der falsche Modus kann die Stärke von AES zunichtemachen.

• ECB (Electronic Codebook) — der einfachste und unsicherste Modus. Jeder Block wird unabhängig mit demselben Schlüssel verschlüsselt. Identische Klartextblöcke erzeugen identische Chiffretextblöcke, was die Wiederherstellung der Datenstruktur ermöglicht. In allen modernen Sicherheitsstandards verboten. Verwenden Sie NIEMALS ECB in mobilen Anwendungen.
• CBC (Cipher Block Chaining) — jeder vorherige Chiffretextblock wird als Initialisierungsvektor (IV) für den nächsten verwendet. Erfordert einen zufälligen IV für jede Nachricht. Angreifbar durch Padding-Oracle-Angriffe bei falscher Implementierung. Geeignet für Dateiverschlüsselung, erfordert aber MAC (HMAC) für Datenintegrität.
• GCM (Galois/Counter Mode) — der empfohlene Modus für mobile Anwendungen. Bietet authentifizierte Verschlüsselung (AEAD): Verschlüsselung + Integritätsprüfung in einer einzigen Operation. Verwendet einen Zähler zur Schlüsselstromerzeugung und Galois-Feld-Multiplikation zur Authentifizierung. GCM erfordert eine eindeutige Nonce (12 Byte) für jede Nachricht. Von NIST empfohlen, verwendet in TLS 1.2/1.3 und Android Keystore.
• CCM (Counter with CBC-MAC) — ein alternativer AEAD-Modus basierend auf CTR + CBC-MAC. Langsamer als GCM und unterstützt keine parallele Verarbeitung. Verwendet in ZigBee- und 802.11-Protokollen (Wi-Fi). Für mobile Anwendungen ist GCM vorzuziehen.

Verwenden Sie für mobile Projekte AES-256-GCM mit einer 12-Byte-Nonce. GCM löst zwei Probleme gleichzeitig: Datenverschlüsselung und Authentifizierung, wodurch Padding-Oracle- und Chosen-Ciphertext-Angriffe verhindert werden. Android Keystore und iOS CryptoKit unterstützen AES-GCM nativ ohne zusätzliche kryptografische Primitive. Bei der Arbeit mit GCM ist es kritisch, die Nonce niemals mit demselben Schlüssel wiederzuverwenden — dies zerstört die Verschlüsselungssicherheit vollständig. Generieren Sie für jede Verschlüsselung eine neue zufällige Nonce und speichern Sie sie zusammen mit dem Chiffretext.

Implementierung von AES in mobilen Anwendungen

Sehen wir uns ein Beispiel für eine sichere AES-256-GCM-Implementierung auf Android mit Jetpack Security an. Der folgende Code zeigt den vollständigen Zyklus: Erstellen eines AES-256-Schlüssels über MasterKey, Ver- und Entschlüsseln einer Zeichenfolge mit zusätzlichen authentifizierten Daten (AAD).

import androidx.security.crypto.MasterKey
import androidx.security.crypto.EncryptedSharedPreferences

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val securePrefs = EncryptedSharedPreferences.create(
    context,
    "secure_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

fun storeSecureData(key: String, value: String) {
    securePrefs.edit().putString(key, value).apply()
}

fun readSecureData(key: String): String? {
    return securePrefs.getString(key, null)
}

Das Hauptmerkmal dieser Lösung ist, dass AES-256-GCM auf zwei Ebenen verwendet wird: zur Verschlüsselung von Schlüssel-Wert-Paaren (PrefValueEncryptionScheme) und zum Schutz der Schlüsselnamen selbst (PrefKeyEncryptionScheme verwendet AES-256-SIV, resistent gegen Nonce-Wiederverwendung). MasterKey wird mit dem AES-256-GCM-Algorithmus generiert und im Android Keystore gespeichert, der auf Geräten mit Trusted Execution Environment hardwaregeschützt ist. Auf Geräten ohne Hardwareunterstützung (TEE) wird der Schlüssel über Bouncy Castle verschlüsselt, was immer noch sicherer ist als die Speicherung in SharedPreferences.

Zur direkten Verschlüsselung großer Datenmengen (z. B. Bilder oder Dateien) verwenden Sie AES-256-GCM über EncryptedFile aus AndroidX Security. Für den Schlüsselexport (z. B. für Backups) verwenden Sie eine zusätzliche Verschlüsselung mit einem Benutzerpasswort über PBKDF2 mit 100000+ Iterationen.

AES auf iOS via CryptoKit

Auf iOS werden AES-Operationen über das CryptoKit-Framework (Swift 5.0+) organisiert. Ein AES-256-Schlüssel wird über SymmetricKey(size: .bits256) erstellt und in der Secure Enclave gespeichert — einem Hardware-Kryptoprozessor, der von der Haupt-CPU und dem Betriebssystem isoliert ist. CryptoKit bietet zwei AES-Implementierungen: AES.GCM (empfohlen) und AES.CBC (für Abwärtskompatibilität mit Legacy-Formaten). Die Verschlüsselung erfolgt über die seal()-Methode, die Daten, Schlüssel und Nonce (12 Byte) entgegennimmt und AES.GCM.SealedBox zurückgibt — eine Struktur, die Chiffretext und Authentifizierungstag enthält. Die Entschlüsselung erfolgt über open(). Apple empfiehlt dringend, CommonCrypto nicht direkt zu verwenden: CryptoKit wählt automatisch optimale Parameter, schützt vor Seitenkanalangriffen und nutzt AES-NI-Hardwarebeschleunigung auf Apple-Silicon-Prozessoren. Auf Geräten mit Secure Enclave verlassen Schlüssel niemals das Hardwaremodul, was Diebstahl selbst bei vollständiger Kompromittierung der Anwendung verhindert. Zur Schlüsselserialisierung verwenden Sie die withUnsafeBytes-Methode, gefolgt von der Speicherung in der Keychain über SecItemAdd mit dem Attribut kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.