La crittografia AES-256-GCM: quadro normativo e tecnico per la protezione dei dati sanitari personali (DPI)
Nel contesto italiano, dove la tutela dei dati personali sensibili è disciplinata dal D.Lgs. 196/2003 e dal GDPR, la protezione dei dati sanitari richiede soluzioni crittografiche di alto livello. AES-256-GCM emerge come standard tecnico di riferimento per la cifratura autenticata in transito e a riposo, garantendo confidenzialità e integrità attraverso la modalità GCM (Galois/Counter Mode), che combina cifratura simmetrica e validazione parallela del messaggio.
| Caratteristica | Dimensione blocco | 128 bit |
|---|---|---|
| Chiave crittografica | 256 bit | |
| Modalità di cifratura | GCM | |
| Funzione di autenticazione | Hash Esteso Galois (GHASH) su 256 bit | |
| Resistenza agli attacchi | AES-256-GCM è resistente a attacchi brute-force, side-channel e manipolazione grazie alla generazione dinamica del tag di autenticazione |
Il Tier 1 fornisce il contesto normativo: la normativa italiana richiede misure tecniche adeguate alla protezione dei DPI, e AES-256-GCM rappresenta la modalità raccomandata per garantire conformità a GDPR e D.Lgs. 196/2003. Il Tier 2 approfondisce i dettagli operativi, dalla generazione del nonce alla validazione del tag, essenziali per la sicurezza pratica in ambienti mobili.
Il nonce deve essere unico per sessione, tipicamente 12 byte, generato tramite un PRNG crittograficamente sicuro (Cryptographically Secure PRNG). L’uso di valori sequenziali con offset basati su UUID + timestamp è una pratica diffusa in applicazioni mobili italiane, per evitare duplicati e garantire unicità. Un nonce ripetuto compromette la sicurezza del tag MAC, esponendo a rischi legali (es. violazioni GDPR con sanzioni fino al 4% del fatturato globale).
La chiave AES-256 non deve mai essere statica. Si utilizza il metodo HKDF (HMAC-Based Key Derivation Function 2) con HMAC-SHA256 per derivare una chiave sessione unica dal master key, basato su una password o token derivato (es. derivato da un’autenticazione biometrica o password dell’utente). Questo processo garantisce unicità per sessione, eliminando vulnerabilità legate alla riusabilità e all’estrazione di chiavi deboli, conforme alle linee guida NIST SP 800-108 e rafforzato nel Tier 2.
Fase 1: Generazione e validazione del nonce, unico e casuale, evitando duplicati mediante timestamp o contatore incrementale. Fase 2: Derivazione della chiave sessione AES-256-GCM tramite HKDF, usando HMAC-SHA256 con un seed derivato da una password autenticata e un counter opzionale. Fase 3: Cifratura dei dati con cifratura contatore (CTR) GCM, generando un tag di autenticazione di 128 bit in parallelo. Fase 4: Invio del ciphertext, nonce e tag al destinatario, con validazione del tag all’accettazione per rilevare manipolazioni. Fase 5: Archiviazione sicura del key material tramite Android Keystore o iOS Keychain, evitando estrazione in memoria non protetta.
Un errore frequente in app sanitarie italiane è la derivazione della chiave con salt mai unici o uso di chiavi statiche, violando le best practice del Tier 2. L’implementazione in Kotlin (Android) o Swift deve includere controlli rigorosi: generazione nonce con `SecureRandom`, validazione esplicita del tag e gestione degli errori crittografici che interrompono la sessione in caso di tag invalido, prevenendo attacchi di forzatura.
Esempio pratico in Kotlin: generazione sicura del nonce e derivazione chiave
import javax.crypto.KeyAgreement
import javax.crypto.SecretKeyFactory
import javax.crypto.spec.PBKDF2ParameterSpec
import java.security.SecureRandom
import java.security.spec.KeySpec
import java.util.*
// Generazione nonce 12 byte randomizzato
fun generateNonce(): ByteArray {
val nonce = ByteArray(12)
SecureRandom.getInstanceStr().nextBytes(nonce)
return nonce
}
// Derivazione chiave sessione con PBKDF2-HMAC-SHA256
fun deriveKey(masterKey: ByteArray, password: ByteArray, salt: ByteArray = ByteArray(16)): SecretKey {
val iterations = 100_000
val keySpec: KeySpec = PBKDF2ParameterSpec(
password, salt, iterations, 256
)
val keyFactory = SecretKeyFactory.getInstance("HKDF")
val derivedKey = keyFactory.generateSecret(keySpec)
return KeyAgreement.getInstance("HKDF").setSeed(derivedKey).generateSecret(256).encoded
}
// Validazione tag GCM
fun validateTag(ciphertext: ByteArray, nonce: ByteArray, tag: ByteArray): Boolean {
try {
val cipher = Cipher.getInstance("AES/GCM/NoPadding")
cipher.init(Cipher.DECRYPT_MODE, SecretKeyFactory.getInstance("HKDF").generateSecret(256),
GCMParameterSpec(128, nonce))
cipher.doFinal(ciphertext)
return Arrays.equals(tag, cipher.getTag())
} catch (e: Exception) {
return false // Tag invalido = session compromessa
}
}
L’uso di un PRNG basato su `SecureRandom` (non `Random`) è fondamentale per prevenire attacchi di previsione del nonce. In contesti mobili italiani, si raccomanda di combinare l’ID utente, un timestamp e un counter incrementale (es. 64 bit) per generare nonce univoci a livello di sessione. Esempio: nonce = (timestamp * 1000) + (utenteHash % 1024) + (counter++), con reset periodico del contatore per sicurezza. Un rilevatore attivo di duplicati, integrato nel backend, blocca immediatamente sessioni sospette.
Il Tier 2 evidenzia che il controllo del tag è non negoziabile: un tag invalido implica immediatamente la terminazione della sessione e l’eventuale audit del tentativo. Questo principio è centrale nella protezione dei DPI ai sensi GDPR, dove la “sicurezza adeguata” richiede non solo crittografia robusta ma anche validazione attiva e ripetuta del messaggio autenticato.
| Aspetto | Android | iOS | Critica per DPI |
|---|---|---|---|
| Generazione nonce | SecureRandom.getInstanceStr().nextBytes(12) | CryptographicallyRandomGenerator() | Prevenzione duplicati con timestamp + salt |
| Derivazione chiave | HKDF con PBKDF2-HMAC-SHA256 | HMAC-SHA256 con PBKDF2 | Unicità per sessione garantita |
| Validazione tag | try-catch su doFinal + confronto tag | try-catch su cipher.doFinal + verifica tag | Obbligatoria per conformità GDPR |
Le ottimizzazioni avanzate includono il batching di dati sanitari critici in una sola operazione GCM per ridurre overhead di inizializzazione, bilanciando sicurezza e prestazioni su dispositivi mobili. La cache sicura dei nonce, protetta da crittografia leggera e rotata quotidianamente, previene attacchi side-channel senza esporre chiavi in memoria.
“La protezione dei dati sanitari non è solo una questione tecnica, ma un impegno etico e legale. Un tag invalido non è solo un errore: è