AES: какво е това, алгоритъм за симетрично криптиране и къде се прилага

Размери на ключовете на AES и нива на сигурност

AES поддържа три размера на ключа, всеки от които съответства на определено ниво на криптоустойчивост. Изборът на размер на ключа влияе на сигурността, производителността и изискванията към ресурсите на устройството.

Практическо правило: в мобилните приложения използвайте AES-256 по подразбиране. Разликата в производителността между AES-128 и AES-256 на съвременни устройства с поддръжка на AES-NI не надвишава 10–15%, но нивото на сигурност се удвоява. Според квантов анализ (Grassl et al., 2016), за разбиване на AES-128 са необходими 2^77 квантови операции чрез алгоритъма на Гровър, а за AES-256 — 2^149, което прави AES-256 устойчив на квантови атаки за следващите 20–30 години. Дори AES-128 осигурява достатъчна защита за огромното мнозинство от търговски сценарии: за пълно търсене на 128-битов ключ е необходима повече енергия, отколкото съществува във Вселената според оценката на Брус Шнайер. Въпреки това, стандартите за сигурност (GDPR, HIPAA, PCI DSS) често изрично изискват AES-256, затова в продукционни проекти се препоръчва използването на максималната дължина на ключа.

Режими на работа на AES

AES като блоков шифър криптира блокове с фиксиран размер (128 бита). За криптиране на данни с произволна дължина се използват режими на работа (modes of operation). Изборът на режим критично влияе на сигурността: неправилният режим може да анулира устойчивостта на AES.

• ECB (Electronic Codebook) — най-простият и най-несигурният режим. Всеки блок се криптира независимо с един и същ ключ. Идентичните блокове открит текст дават идентични блокове шифрован текст, което позволява възстановяване на структурата на данните. Забранен за използване във всички съвременни стандарти за сигурност. НИКОГА не използвайте ECB в мобилни приложения.
• CBC (Cipher Block Chaining) — всеки предишен блок шифрован текст се използва като инициализиращ вектор (IV) за следващия. Изисква случаен IV за всяко съобщение. Уязвим на padding oracle атаки при неправилна имплементация. Подходящ за криптиране на файлове, но изисква MAC (HMAC) за осигуряване на цялостност на данните.
• GCM (Galois/Counter Mode) — препоръчителен режим за мобилни приложения. Осигурява удостоверено криптиране (AEAD): криптиране + проверка на цялостността в една операция. Използва брояч за генериране на ключов поток и умножение в полето на Галоа за удостоверяване. GCM изисква уникален nonce (12 байта) за всяко съобщение. Препоръчан от NIST, използва се в TLS 1.2/1.3 и Android Keystore.
• CCM (Counter with CBC-MAC) — алтернативен AEAD режим, основан на CTR + CBC-MAC. По-бавен от GCM и не поддържа паралелна обработка. Използва се в протоколите ZigBee и 802.11 (Wi-Fi). За мобилни приложения GCM е за предпочитане.

За мобилни проекти използвайте AES-256-GCM с nonce с дължина 12 байта. GCM решава два проблема едновременно: криптиране на данни и проверка на автентичност, което предотвратява атаки от тип padding oracle и chosen ciphertext. Android Keystore и iOS CryptoKit поддържат AES-GCM веднага след изваждане от кутията, без необходимост от имплементиране на допълнителни криптографски примитиви. При работа с GCM е важно никога да не повтаряте nonce с един и същ ключ — това напълно унищожава сигурността на криптирането. Генерирайте нов случаен nonce за всяко криптиране и го съхранявайте заедно с шифрования текст.

Имплементация на AES в мобилни приложения

Нека разгледаме пример за сигурна имплементация на AES-256-GCM на Android, използвайки Jetpack Security. Кодът по-долу демонстрира пълния цикъл: създаване на AES-256 ключ чрез MasterKey, криптиране и дешифриране на низ с допълнителни удостоверени данни (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)
}

Ключовата особеност на това решение е използването на AES-256-GCM на две нива: за криптиране на двойки ключ-стойност (PrefValueEncryptionScheme) и за защита на самите имена на ключовете (PrefKeyEncryptionScheme използва AES-256-SIV, устойчив на повторение на nonce). MasterKey се генерира с помощта на алгоритъма AES-256-GCM и се съхранява в Android Keystore, защитен хардуерно на устройства с Trusted Execution Environment. На устройства без хардуерна поддръжка (TEE) ключът се криптира чрез Bouncy Castle, което все още е по-сигурно от съхранението в SharedPreferences.

За директно криптиране на големи обеми данни (например изображения или файлове) използвайте AES-256-GCM чрез EncryptedFile от AndroidX Security. За експорт на ключове (например за архивиране) използвайте допълнително криптиране с потребителска парола чрез PBKDF2 със 100000+ итерации.

AES на iOS чрез CryptoKit

На iOS работата с AES е организирана чрез рамката CryptoKit (Swift 5.0+). Ключът AES-256 се създава чрез SymmetricKey(size: .bits256) и се съхранява в Secure Enclave — хардуерен криптопроцесор, изолиран от основния CPU и операционната система. CryptoKit предоставя две имплементации на AES: AES.GCM (препоръчителен) и AES.CBC (за обратна съвместимост с остарели формати). Криптирането се извършва чрез метода seal(), който приема данни, ключ и nonce (12 байта) и връща AES.GCM.SealedBox — структура, съдържаща шифрования текст и маркер за удостоверяване. Дешифрирането — чрез open(). Apple силно не препоръчва директно използване на CommonCrypto: CryptoKit автоматично избира оптималните параметри, защитава от side-channel атаки и използва хардуерно ускорение AES-NI на процесорите Apple Silicon. На устройства с Secure Enclave ключовете никога не напускат хардуерния модул, което изключва тяхната кражба дори при пълно компрометиране на приложението. За сериализация на ключа се използва методът withUnsafeBytes с последващо съхранение в Keychain чрез SecItemAdd с атрибут kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.