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.