AES: co to jest, algorytm szyfrowania symetrycznego i gdzie jest stosowany

Rozmiary kluczy AES i poziomy bezpieczeństwa

AES obsługuje trzy rozmiary klucza, z których każdy odpowiada określonemu poziomowi odporności kryptograficznej. Wybór rozmiaru klucza wpływa na bezpieczeństwo, wydajność i wymagania dotyczące zasobów urządzenia.

Praktyczna zasada: w aplikacjach mobilnych używaj domyślnie AES-256. Różnica w wydajności między AES-128 a AES-256 na nowoczesnych urządzeniach z obsługą AES-NI wynosi nie więcej niż 10–15%, ale poziom bezpieczeństwa podwaja się. Według analizy kwantowej (Grassl et al., 2016), do złamania AES-128 potrzeba 2^77 operacji kwantowych przez algorytm Grovera, a dla AES-256 — 2^149, co czyni AES-256 odpornym na ataki kwantowe przez najbliższe 20–30 lat. Nawet AES-128 zapewnia wystarczającą ochronę dla zdecydowanej większości scenariuszy komercyjnych: do pełnego przeglądu 128-bitowego klucza potrzeba więcej energii, niż istnieje we Wszechświecie według szacunków Bruce’a Schneiera. Jednak standardy bezpieczeństwa (GDPR, HIPAA, PCI DSS) często wyraźnie wymagają AES-256, dlatego w projektach produkcyjnych zaleca się używanie maksymalnej długości klucza.

Tryby pracy AES

AES jako szyfr blokowy szyfruje bloki o stałym rozmiarze (128 bitów). Do szyfrowania danych o dowolnej długości używa się trybów pracy (modes of operation). Wybór trybu krytycznie wpływa na bezpieczeństwo: nieprawidłowy tryb może zniweczyć odporność AES.

• ECB (Electronic Codebook) — najprostszy i najbardziej niebezpieczny tryb. Każdy blok jest szyfrowany niezależnie tym samym kluczem. Identyczne bloki tekstu jawnego dają identyczne bloki szyfrogramu, co pozwala odtworzyć strukturę danych. Zakazany do użycia we wszystkich nowoczesnych standardach bezpieczeństwa. NIGDY nie używaj ECB w aplikacjach mobilnych.
• CBC (Cipher Block Chaining) — każdy poprzedni blok szyfrogramu jest używany jako wektor inicjujący (IV) dla następnego. Wymaga losowego IV dla każdej wiadomości. Podatny na ataki padding oracle przy nieprawidłowej implementacji. Nadaje się do szyfrowania plików, ale wymaga MAC (HMAC) do zapewnienia integralności danych.
• GCM (Galois/Counter Mode) — zalecany tryb dla aplikacji mobilnych. Zapewnia uwierzytelnione szyfrowanie (AEAD): szyfrowanie + sprawdzanie integralności w jednej operacji. Używa licznika do generowania strumienia klucza i mnożenia w ciele Galois do uwierzytelniania. GCM wymaga unikalnego nonce (12 bajtów) dla każdej wiadomości. Zalecany przez NIST, stosowany w TLS 1.2/1.3 i Android Keystore.
• CCM (Counter with CBC-MAC) — alternatywny tryb AEAD oparty na CTR + CBC-MAC. Wolniejszy niż GCM i nie obsługuje przetwarzania równoległego. Stosowany w protokołach ZigBee i 802.11 (Wi-Fi). W aplikacjach mobilnych preferowany jest GCM.

W projektach mobilnych używaj AES-256-GCM z nonce o długości 12 bajtów. GCM rozwiązuje dwa problemy jednocześnie: szyfrowanie danych i sprawdzanie autentyczności, co zapobiega atakom typu padding oracle i chosen ciphertext. Android Keystore i iOS CryptoKit obsługują AES-GCM od razu po wyjęciu z pudełka bez konieczności implementacji dodatkowych prymitywów kryptograficznych. Podczas pracy z GCM ważne jest, aby nigdy nie powtarzać nonce z tym samym kluczem — całkowicie niszczy to bezpieczeństwo szyfrowania. Generuj nowy losowy nonce dla każdego szyfrowania i przechowuj go razem z szyfrogramem.

Implementacja AES w aplikacjach mobilnych

Rozważmy przykład bezpiecznej implementacji AES-256-GCM na Androidzie z użyciem Jetpack Security. Poniższy kod demonstruje pełny cykl: utworzenie klucza AES-256 przez MasterKey, szyfrowanie i deszyfrowanie ciągu znaków z dodatkowymi uwierzytelnionymi danymi (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)
}

Kluczową cechą tego rozwiązania jest AES-256-GCM używany na dwóch poziomach: do szyfrowania par klucz-wartość (PrefValueEncryptionScheme) i do ochrony samych nazw kluczy (PrefKeyEncryptionScheme używa AES-256-SIV, odpornego na powtarzanie nonce). MasterKey jest generowany z użyciem algorytmu AES-256-GCM i przechowywany w Android Keystore, zabezpieczonym sprzętowo na urządzeniach z Trusted Execution Environment. Na urządzeniach bez obsługi sprzętowej (TEE) klucz jest szyfrowany przez Bouncy Castle, co i tak jest bezpieczniejsze niż przechowywanie w SharedPreferences.

Do bezpośredniego szyfrowania dużych ilości danych (np. obrazów lub plików) używaj AES-256-GCM przez EncryptedFile z AndroidX Security. Do eksportu kluczy (np. do tworzenia kopii zapasowej) użyj dodatkowego szyfrowania z hasłem użytkownika przez PBKDF2 z 100000+ iteracjami.

AES na iOS przez CryptoKit

W iOS praca z AES jest zorganizowana przez framework CryptoKit (Swift 5.0+). Klucz AES-256 jest tworzony przez SymmetricKey(size: .bits256) i przechowywany w Secure Enclave — sprzętowym kryptoprocesorze odizolowanym od głównego CPU i systemu operacyjnego. CryptoKit udostępnia dwie implementacje AES: AES.GCM (zalecany) i AES.CBC (dla zgodności wstecznej z przestarzałymi formatami). Szyfrowanie odbywa się przez metodę seal(), która przyjmuje dane, klucz i nonce (12 bajtów), a zwraca AES.GCM.SealedBox — strukturę zawierającą szyfrogram i tag uwierzytelnienia. Deszyfrowanie — przez open(). Apple stanowczo nie zaleca bezpośredniego używania CommonCrypto: CryptoKit automatycznie wybiera optymalne parametry, chroni przed atakami side-channel i używa sprzętowego przyspieszenia AES-NI na procesorach Apple Silicon. Na urządzeniach z Secure Enclave klucze nigdy nie opuszczają modułu sprzętowego, co uniemożliwia ich kradzież nawet przy całkowitej kompromitacji aplikacji. Do serializacji klucza używana jest metoda withUnsafeBytes z następnym zapisem w Keychain przez SecItemAdd z atrybutem kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.