AES: wat is het, het symmetrische versleutelingsalgoritme en waar het wordt toegepast

AES-sleutelgroottes en beveiligingsniveaus

AES ondersteunt drie sleutelgroottes, die elk overeenkomen met een bepaald niveau van cryptografische weerstand. De keuze van de sleutelgrootte beïnvloedt de beveiliging, prestaties en vereisten voor apparaatbronnen.

Praktische regel: gebruik in mobiele apps standaard AES-256. Het prestatieverschil tussen AES-128 en AES-256 op moderne apparaten met AES-NI-ondersteuning is niet meer dan 10–15%, maar het beveiligingsniveau verdubbelt. Volgens kwantumanalyse (Grassl et al., 2016) zijn er 2^77 kwantumbewerkingen via het algoritme van Grover nodig om AES-128 te kraken, en voor AES-256 — 2^149, wat AES-256 bestand maakt tegen kwantumaanvallen voor de komende 20–30 jaar. Zelfs AES-128 biedt voldoende bescherming voor de overgrote meerderheid van commerciële scenario's: voor volledige doorzoeking van een 128-bits sleutel is meer energie nodig dan er in het heelal bestaat, volgens de schatting van Bruce Schneier. Beveiligingsnormen (GDPR, HIPAA, PCI DSS) vereisen echter vaak expliciet AES-256, daarom wordt in productieprojecten aanbevolen de maximale sleutellengte te gebruiken.

AES-werkingsmodi

AES als blokcijfer versleutelt blokken van vaste grootte (128 bits). Voor het versleutelen van gegevens van willekeurige lengte worden werkingsmodi (modes of operation) gebruikt. De keuze van de modus heeft een kritieke invloed op de beveiliging: een verkeerde modus kan de weerstand van AES tenietdoen.

• ECB (Electronic Codebook) — de eenvoudigste en meest onveilige modus. Elk blok wordt onafhankelijk versleuteld met dezelfde sleutel. Identieke blokken leesbare tekst geven identieke blokken cijfertekst, waardoor de gegevensstructuur kan worden hersteld. Verboden in alle moderne beveiligingsnormen. Gebruik NOOIT ECB in mobiele apps.
• CBC (Cipher Block Chaining) — elk vorig cijfertekstblok wordt gebruikt als initialisatievector (IV) voor het volgende. Vereist een willekeurige IV voor elk bericht. Kwetsbaar voor padding oracle-aanvallen bij onjuiste implementatie. Geschikt voor bestandsversleuteling, maar vereist MAC (HMAC) voor gegevensintegriteit.
• GCM (Galois/Counter Mode) — de aanbevolen modus voor mobiele apps. Biedt geverifieerde versleuteling (AEAD): versleuteling + integriteitscontrole in één bewerking. Gebruikt een teller voor het genereren van de sleutelstroom en vermenigvuldiging in het Galois-veld voor authenticatie. GCM vereist een unieke nonce (12 bytes) voor elk bericht. Aanbevolen door NIST, gebruikt in TLS 1.2/1.3 en Android Keystore.
• CCM (Counter with CBC-MAC) — een alternatieve AEAD-modus op basis van CTR + CBC-MAC. Langzamer dan GCM en ondersteunt geen parallelle verwerking. Gebruikt in ZigBee- en 802.11 (Wi-Fi)-protocollen. Voor mobiele apps heeft GCM de voorkeur.

Gebruik voor mobiele projecten AES-256-GCM met een nonce van 12 bytes. GCM lost twee problemen tegelijk op: gegevensversleuteling en authenticiteitscontrole, wat padding oracle- en chosen ciphertext-aanvallen voorkomt. Android Keystore en iOS CryptoKit ondersteunen AES-GCM out-of-the-box zonder dat er aanvullende cryptografische primitieven hoeven te worden geïmplementeerd. Bij het werken met GCM is het belangrijk om nooit een nonce met dezelfde sleutel te herhalen — dit vernietigt de versleutelingsbeveiliging volledig. Genereer een nieuwe willekeurige nonce voor elke versleuteling en bewaar deze samen met de cijfertekst.

Implementatie van AES in mobiele apps

Laten we een voorbeeld bekijken van een veilige implementatie van AES-256-GCM op Android met behulp van Jetpack Security. De onderstaande code demonstreert de volledige cyclus: het maken van een AES-256-sleutel via MasterKey, het versleutelen en ontsleutelen van een tekenreeks met aanvullende geverifieerde gegevens (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)
}

Het belangrijkste kenmerk van deze oplossing is het gebruik van AES-256-GCM op twee niveaus: voor het versleutelen van sleutel-waardeparen (PrefValueEncryptionScheme) en voor de bescherming van de sleutelnamen zelf (PrefKeyEncryptionScheme gebruikt AES-256-SIV, bestand tegen nonce-herhaling). MasterKey wordt gegenereerd met het AES-256-GCM-algoritme en opgeslagen in Android Keystore, dat hardwarematig wordt beschermd op apparaten met Trusted Execution Environment. Op apparaten zonder hardwareondersteuning (TEE) wordt de sleutel versleuteld via Bouncy Castle, wat nog steeds veiliger is dan opslag in SharedPreferences.

Voor directe versleuteling van grote hoeveelheden gegevens (bijvoorbeeld afbeeldingen of bestanden) gebruikt u AES-256-GCM via EncryptedFile van AndroidX Security. Voor het exporteren van sleutels (bijvoorbeeld voor back-up) gebruikt u extra versleuteling met een gebruikerswachtwoord via PBKDF2 met 100000+ iteraties.

AES op iOS via CryptoKit

Op iOS is het werken met AES georganiseerd via het CryptoKit-framework (Swift 5.0+). De AES-256-sleutel wordt gemaakt via SymmetricKey(size: .bits256) en opgeslagen in Secure Enclave — een hardware-cryptoprocessor die geïsoleerd is van de hoofd-CPU en het besturingssysteem. CryptoKit biedt twee AES-implementaties: AES.GCM (aanbevolen) en AES.CBC (voor achterwaartse compatibiliteit met verouderde formaten). Versleuteling gebeurt via de methode seal(), die gegevens, sleutel en nonce (12 bytes) ontvangt en een AES.GCM.SealedBox retourneert — een structuur met de cijfertekst en de authenticatietag. Ontsleuteling — via open(). Apple raadt het direct gebruik van CommonCrypto ten zeerste af: CryptoKit kiest automatisch de optimale parameters, beschermt tegen side-channel-aanvallen en gebruikt hardwareversnelling AES-NI op Apple Silicon-processors. Op apparaten met Secure Enclave verlaten sleutels nooit de hardwaremodule, waardoor diefstal zelfs bij volledige compromittering van de app onmogelijk is. Voor serialisatie van de sleutel wordt de methode withUnsafeBytes gebruikt, gevolgd door opslag in Keychain via SecItemAdd met het attribuut kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.