AES: ce este, algoritmul de criptare simetrică și unde se aplică

Dimensiunile cheilor AES și nivelurile de securitate

AES suportă trei dimensiuni de cheie, fiecare corespunzând unui anumit nivel de rezistență criptografică. Alegerea dimensiunii cheii influențează securitatea, performanța și cerințele de resurse ale dispozitivului.

Regula practică: în aplicațiile mobile utilizați AES-256 în mod implicit. Diferența de performanță între AES-128 și AES-256 pe dispozitivele moderne cu suport AES-NI nu depășește 10–15%, dar nivelul de securitate se dublează. Conform analizei cuantice (Grassl et al., 2016), pentru spargerea AES-128 sunt necesare 2^77 de operații cuantice prin algoritmul lui Grover, iar pentru AES-256 — 2^149, ceea ce face AES-256 rezistent la atacurile cuantice pentru următorii 20–30 de ani. Chiar și AES-128 asigură protecție suficientă pentru marea majoritate a scenariilor comerciale: pentru căutarea completă a unei chei de 128 de biți este necesară mai multă energie decât există în Univers, conform estimării lui Bruce Schneier. Cu toate acestea, standardele de securitate (GDPR, HIPAA, PCI DSS) solicită adesea explicit AES-256, de aceea în proiectele de producție se recomandă utilizarea lungimii maxime a cheii.

Modurile de operare AES

AES ca cifru în bloc criptează blocuri de dimensiune fixă (128 de biți). Pentru criptarea datelor de lungime arbitrară se utilizează modurile de operare (modes of operation). Alegerea modului influențează critic securitatea: un mod incorect poate anula rezistența AES.

• ECB (Electronic Codebook) — cel mai simplu și cel mai nesigur mod. Fiecare bloc este criptat independent cu aceeași cheie. Blocurile identice de text clar produc blocuri identice de text criptat, ceea ce permite recuperarea structurii datelor. Interzis în toate standardele moderne de securitate. NU utilizați niciodată ECB în aplicațiile mobile.
• CBC (Cipher Block Chaining) — fiecare bloc anterior de text criptat este utilizat ca vector de inițializare (IV) pentru următorul. Necesită un IV aleator pentru fiecare mesaj. Vulnerabil la atacurile padding oracle în cazul implementării incorecte. Potrivit pentru criptarea fișierelor, dar necesită MAC (HMAC) pentru asigurarea integrității datelor.
• GCM (Galois/Counter Mode) — modul recomandat pentru aplicațiile mobile. Asigură criptare autentificată (AEAD): criptare + verificare integritate într-o singură operație. Utilizează un contor pentru generarea fluxului de cheie și înmulțirea în câmpul Galois pentru autentificare. GCM necesită un nonce unic (12 octeți) pentru fiecare mesaj. Recomandat de NIST, utilizat în TLS 1.2/1.3 și Android Keystore.
• CCM (Counter with CBC-MAC) — un mod AEAD alternativ bazat pe CTR + CBC-MAC. Mai lent decât GCM și nu suportă procesarea paralelă. Utilizat în protocoalele ZigBee și 802.11 (Wi-Fi). Pentru aplicațiile mobile, GCM este preferat.

Pentru proiectele mobile utilizați AES-256-GCM cu un nonce de 12 octeți. GCM rezolvă două probleme simultan: criptarea datelor și verificarea autenticității, ceea ce previne atacurile de tip padding oracle și chosen ciphertext. Android Keystore și iOS CryptoKit suportă AES-GCM din cutie, fără a necesita implementarea de primitive criptografice suplimentare. Când lucrați cu GCM, este important să nu repetați niciodată nonce-ul cu aceeași cheie — aceasta distruge complet securitatea criptării. Generați un nou nonce aleator pentru fiecare criptare și păstrați-l împreună cu textul criptat.

Implementarea AES în aplicațiile mobile

Să examinăm un exemplu de implementare sigură a AES-256-GCM pe Android folosind Jetpack Security. Codul de mai jos demonstrează ciclul complet: crearea cheii AES-256 prin MasterKey, criptarea și decriptarea unui șir cu date autentificate suplimentare (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)
}

Caracteristica cheie a acestei soluții este utilizarea AES-256-GCM la două niveluri: pentru criptarea perechilor cheie-valoare (PrefValueEncryptionScheme) și pentru protejarea numelor cheilor în sine (PrefKeyEncryptionScheme utilizează AES-256-SIV, rezistent la repetarea nonce-ului). MasterKey este generat folosind algoritmul AES-256-GCM și stocat în Android Keystore, protejat hardware pe dispozitivele cu Trusted Execution Environment. Pe dispozitivele fără suport hardware (TEE), cheia este criptată prin Bouncy Castle, ceea ce este totuși mai sigur decât stocarea în SharedPreferences.

Pentru criptarea directă a volumelor mari de date (de exemplu, imagini sau fișiere) utilizați AES-256-GCM prin EncryptedFile din AndroidX Security. Pentru exportul cheilor (de exemplu, pentru backup) utilizați criptare suplimentară cu parola utilizatorului prin PBKDF2 cu 100000+ de iterații.

AES pe iOS prin CryptoKit

Pe iOS, lucrul cu AES este organizat prin framework-ul CryptoKit (Swift 5.0+). Cheia AES-256 este creată prin SymmetricKey(size: .bits256) și stocată în Secure Enclave — un criptoprocesor hardware izolat de CPU-ul principal și de sistemul de operare. CryptoKit oferă două implementări AES: AES.GCM (recomandat) și AES.CBC (pentru compatibilitate cu formatele vechi). Criptarea se realizează prin metoda seal(), care primește datele, cheia și nonce-ul (12 octeți) și returnează AES.GCM.SealedBox — o structură care conține textul criptat și tag-ul de autentificare. Decriptarea — prin open(). Apple nu recomandă utilizarea directă a CommonCrypto: CryptoKit selectează automat parametrii optimi, protejează împotriva atacurilor side-channel și utilizează accelerarea hardware AES-NI pe procesoarele Apple Silicon. Pe dispozitivele cu Secure Enclave, cheile nu părăsesc niciodată modulul hardware, ceea ce exclude furtul lor chiar și în cazul compromiterii totale a aplicației. Pentru serializarea cheii se utilizează metoda withUnsafeBytes cu stocarea ulterioară în Keychain prin SecItemAdd cu atributul kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.