AES: vad är det, den symmetriska krypteringsalgoritmen och var den tillämpas

AES-nyckelstorlekar och säkerhetsnivåer

AES stödjer tre nyckelstorlekar, som var och en motsvarar en viss nivå av kryptografisk motståndskraft. Valet av nyckelstorlek påverkar säkerheten, prestandan och kraven på enhetens resurser.

Praktisk regel: i mobila applikationer använd AES-256 som standard. Prestandaskillnaden mellan AES-128 och AES-256 på moderna enheter med AES-NI-stöd överstiger inte 10–15 %, men säkerhetsnivån fördubblas. Enligt kvantanalys (Grassl et al., 2016) krävs 2^77 kvantoperationer genom Grovers algoritm för att knäcka AES-128, och för AES-256 — 2^149, vilket gör AES-256 motståndskraftig mot kvantattacker under de kommande 20–30 åren. Även AES-128 ger tillräckligt skydd för de allra flesta kommersiella scenarier: för fullständig sökning av en 128-bitars nyckel krävs mer energi än vad som finns i universum enligt Bruce Schneiers uppskattning. Säkerhetsstandarder (GDPR, HIPAA, PCI DSS) kräver dock ofta uttryckligen AES-256, därför rekommenderas att använda maximal nyckellängd i produktionsprojekt.

AES-driftlägen

AES som blockkrypto krypterar block av fast storlek (128 bitar). För att kryptera data av godtycklig längd används driftlägen (modes of operation). Valet av läge påverkar säkerheten kritiskt: ett felaktigt läge kan upphäva AES motståndskraft.

• ECB (Electronic Codebook) — det enklaste och mest osäkra läget. Varje block krypteras oberoende med samma nyckel. Identiska klartextblock ger identiska chiffertextblock, vilket möjliggör återställning av datastrukturen. Förbjudet i alla moderna säkerhetsstandarder. Använd ALDRIG ECB i mobila applikationer.
• CBC (Cipher Block Chaining) — varje tidigare chiffertextblock används som initialiseringsvektor (IV) för nästa. Kräver slumpmässig IV för varje meddelande. Sårbar för padding oracle-attacker vid felaktig implementering. Lämplig för filkryptering men kräver MAC (HMAC) för dataintegritet.
• GCM (Galois/Counter Mode) — det rekommenderade läget för mobila applikationer. Ger autentiserad kryptering (AEAD): kryptering + integritetskontroll i en operation. Använder en räknare för att generera nyckelström och multiplikation i Galoisfältet för autentisering. GCM kräver unik nonce (12 byte) för varje meddelande. Rekommenderas av NIST, används i TLS 1.2/1.3 och Android Keystore.
• CCM (Counter with CBC-MAC) — ett alternativt AEAD-läge baserat på CTR + CBC-MAC. Långsammare än GCM och stödjer inte parallellbearbetning. Används i ZigBee- och 802.11 (Wi-Fi)-protokoll. För mobila applikationer är GCM att föredra.

För mobila projekt, använd AES-256-GCM med nonce på 12 byte. GCM löser två problem samtidigt: datakryptering och autenticitetsverifiering, vilket förhindrar padding oracle- och chosen ciphertext-attacker. Android Keystore och iOS CryptoKit stödjer AES-GCM direkt utan att ytterligare kryptografiska primitiver behöver implementeras. När du arbetar med GCM är det viktigt att aldrig upprepa nonce med samma nyckel — detta förstör helt krypteringssäkerheten. Generera en ny slumpmässig nonce för varje kryptering och spara den tillsammans med chiffertexten.

Implementering av AES i mobila applikationer

Låt oss titta på ett exempel på säker implementering av AES-256-GCM på Android med Jetpack Security. Koden nedan visar hela cykeln: skapande av AES-256-nyckel via MasterKey, kryptering och dekryptering av en sträng med ytterligare autentiserade data (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)
}

Den viktigaste egenskapen hos denna lösning är användningen av AES-256-GCM på två nivåer: för att kryptera nyckel-värdepar (PrefValueEncryptionScheme) och för att skydda själva nyckelnamnen (PrefKeyEncryptionScheme använder AES-256-SIV, som är resistent mot nonce-upprepning). MasterKey genereras med AES-256-GCM-algoritmen och lagras i Android Keystore, som är hårdvaruskyddat på enheter med Trusted Execution Environment. På enheter utan hårdvarustöd (TEE) krypteras nyckeln via Bouncy Castle, vilket fortfarande är säkrare än lagring i SharedPreferences.

För direkt kryptering av stora datamängder (t.ex. bilder eller filer) använd AES-256-GCM via EncryptedFile från AndroidX Security. För export av nycklar (t.ex. för säkerhetskopiering) använd ytterligare kryptering med användarens lösenord via PBKDF2 med 100000+ iterationer.

AES på iOS via CryptoKit

På iOS är arbetet med AES organiserat via ramverket CryptoKit (Swift 5.0+). AES-256-nyckeln skapas via SymmetricKey(size: .bits256) och lagras i Secure Enclave — en hårdvarukryptoprocessor isolerad från huvud-CPU och operativsystem. CryptoKit tillhandahåller två AES-implementeringar: AES.GCM (rekommenderad) och AES.CBC (för bakåtkompatibilitet med föråldrade format). Kryptering utförs via metoden seal(), som tar emot data, nyckel och nonce (12 byte) och returnerar en AES.GCM.SealedBox — en struktur som innehåller chiffertext och autentiseringstagg. Dekryptering — via open(). Apple rekommenderar starkt att inte använda CommonCrypto direkt: CryptoKit väljer automatiskt optimala parametrar, skyddar mot side-channel-attacker och använder hårdvaruacceleration AES-NI på Apple Silicon-processorer. På enheter med Secure Enclave lämnar nycklarna aldrig hårdvarumodulen, vilket omöjliggör stöld även vid fullständig kompromettering av applikationen. För serialisering av nyckeln används metoden withUnsafeBytes med efterföljande lagring i Keychain via SecItemAdd med attributet kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.