AES: cos'è, algoritmo di crittografia simmetrica e dove viene utilizzato

Dimensioni delle chiavi AES e livelli di sicurezza

AES supporta tre dimensioni di chiave, ciascuna corrispondente a un livello specifico di forza crittografica. La scelta della dimensione della chiave influisce sulla sicurezza, sulle prestazioni e sui requisiti di risorse del dispositivo.

Regola pratica: per le applicazioni mobili utilizzare AES-256 per impostazione predefinita. La differenza di prestazioni tra AES-128 e AES-256 sui dispositivi moderni con supporto AES-NI non supera il 10–15%, ma il livello di sicurezza raddoppia. Secondo l'analisi quantistica (Grassl et al., 2016), violare AES-128 richiederebbe 2^77 operazioni quantistiche tramite l'algoritmo di Grover, mentre AES-256 ne richiederebbe 2^149, rendendo AES-256 resistente agli attacchi quantistici per i prossimi 20–30 anni. Anche AES-128 fornisce protezione sufficiente per la stragrande maggioranza degli scenari commerciali: la forza bruta di una chiave a 128 bit richiederebbe più energia di quanta ne esista nell'universo secondo la stima di Bruce Schneier. Tuttavia, gli standard di sicurezza (GDPR, HIPAA, PCI DSS) spesso richiedono esplicitamente AES-256, quindi i progetti in produzione dovrebbero utilizzare la lunghezza massima della chiave.

Modalità di funzionamento AES

AES come cifrario a blocchi crittografa blocchi di dimensione fissa (128 bit). Per crittografare dati di lunghezza arbitraria, vengono utilizzate modalità di funzionamento. La selezione della modalità influisce criticamente sulla sicurezza: la modalità sbagliata può annullare la forza di AES.

• ECB (Electronic Codebook) — la modalità più semplice e più insicura. Ogni blocco viene crittografato indipendentemente con la stessa chiave. Blocchi di testo in chiaro identici producono blocchi di testo cifrato identici, consentendo di recuperare la struttura dei dati. Vietata in tutti gli standard di sicurezza moderni. Non utilizzare MAI ECB nelle applicazioni mobili.
• CBC (Cipher Block Chaining) — ogni blocco di testo cifrato precedente viene utilizzato come vettore di inizializzazione (IV) per il successivo. Richiede un IV casuale per ogni messaggio. Vulnerabile agli attacchi padding oracle se implementato in modo errato. Adatto per la crittografia di file ma richiede MAC (HMAC) per l'integrità dei dati.
• GCM (Galois/Counter Mode) — la modalità consigliata per le applicazioni mobili. Fornisce crittografia autenticata (AEAD): crittografia + verifica dell'integrità in un'unica operazione. Utilizza un contatore per la generazione del flusso di chiave e la moltiplicazione nel campo di Galois per l'autenticazione. GCM richiede un nonce univoco (12 byte) per ogni messaggio. Raccomandato dal NIST, utilizzato in TLS 1.2/1.3 e Android Keystore.
• CCM (Counter with CBC-MAC) — una modalità AEAD alternativa basata su CTR + CBC-MAC. Più lenta di GCM e non supporta l'elaborazione parallela. Utilizzata nei protocolli ZigBee e 802.11 (Wi-Fi). Per le applicazioni mobili, GCM è preferibile.

Per i progetti mobili utilizzare AES-256-GCM con un nonce di 12 byte. GCM risolve due problemi contemporaneamente: crittografia dei dati e autenticazione, prevenendo attacchi padding oracle e chosen ciphertext. Android Keystore e iOS CryptoKit supportano AES-GCM nativamente senza bisogno di primitive crittografiche aggiuntive. Quando si lavora con GCM, è fondamentale non riutilizzare mai il nonce con la stessa chiave — questo distrugge completamente la sicurezza della crittografia. Generare un nuovo nonce casuale per ogni crittografia e memorizzarlo insieme al testo cifrato.

Implementazione di AES nelle applicazioni mobili

Vediamo un esempio di implementazione sicura di AES-256-GCM su Android utilizzando Jetpack Security. Il codice seguente mostra il ciclo completo: creazione di una chiave AES-256 tramite MasterKey, crittografia e decifratura di una stringa con dati autenticati aggiuntivi (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)
}

La caratteristica principale di questa soluzione è che AES-256-GCM viene utilizzato a due livelli: per crittografare le coppie chiave-valore (PrefValueEncryptionScheme) e per proteggere i nomi delle chiavi stessi (PrefKeyEncryptionScheme utilizza AES-256-SIV, resistente al riutilizzo del nonce). MasterKey viene generato utilizzando l'algoritmo AES-256-GCM e memorizzato in Android Keystore, protetto hardware sui dispositivi con Trusted Execution Environment. Sui dispositivi senza supporto hardware (TEE), la chiave viene crittografata tramite Bouncy Castle, che è comunque più sicuro della memorizzazione in SharedPreferences.

Per la crittografia diretta di grandi volumi di dati (ad esempio, immagini o file), utilizzare AES-256-GCM tramite EncryptedFile di AndroidX Security. Per l'esportazione delle chiavi (ad esempio, per backup), utilizzare una crittografia aggiuntiva con una password utente tramite PBKDF2 con 100000+ iterazioni.

AES su iOS tramite CryptoKit

Su iOS, le operazioni AES sono organizzate tramite il framework CryptoKit (Swift 5.0+). Una chiave AES-256 viene creata tramite SymmetricKey(size: .bits256) e memorizzata nel Secure Enclave — un crittoprocessore hardware isolato dalla CPU principale e dal sistema operativo. CryptoKit fornisce due implementazioni di AES: AES.GCM (consigliato) e AES.CBC (per compatibilità con formati legacy). La crittografia viene eseguita tramite il metodo seal(), che accetta dati, chiave e nonce (12 byte), e restituisce AES.GCM.SealedBox — una struttura contenente il testo cifrato e il tag di autenticazione. La decifratura avviene tramite open(). Apple raccomanda vivamente di non utilizzare CommonCrypto direttamente: CryptoKit seleziona automaticamente i parametri ottimali, protegge dagli attacchi side-channel e utilizza l'accelerazione hardware AES-NI sui processori Apple Silicon. Sui dispositivi con Secure Enclave, le chiavi non lasciano mai il modulo hardware, impedendo il furto anche in caso di compromissione totale dell'applicazione. Per la serializzazione della chiave, utilizzare il metodo withUnsafeBytes seguito dall'archiviazione in Keychain tramite SecItemAdd con l'attributo kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.