Аутентифицированное шифрование: AES-GCM и ChaCha20-Poly1305

Аутентифицированное шифрование (AE) решает фундаментальную проблему: традиционное шифрование обеспечивает только конфиденциальность — сохраняет данные в тайне, — но не проверяет, не были ли зашифрованные данные изменены. Злоумышленник может изменить отдельные биты шифротекста, а получатель расшифрует искажённые данные, не заметив изменений. Аутентифицированное шифрование с дополнительными данными (AEAD) одновременно обеспечивает целостность и подлинность, создавая зашифрованный шифротекст и тег аутентификации, который обнаруживает любые изменения.

AES-GCM (режим Галуа/счётчика) объединяет два компонента: AES-CTR (режим счётчика) для шифрования и GMAC (код аутентификации сообщений Галуа) для обеспечения целостности. AES-CTR создаёт гамму, шифруя значение счётчика и выполняя операцию XOR с открытым текстом, благодаря чему шифрование можно распараллелить, в отличие от режима CBC. GMAC вычисляет тег аутентификации для шифротекста и любых дополнительных данных. Полученный тег длиной 128 бит передаётся вместе с шифротекстом; изменение даже одного бита делает тег недействительным.

AES-GCM требует nonce (число, используемое один раз), обычно длиной 96 бит (12 байт). Nonce должен быть уникальным для каждой отдельной операции шифрования с одним и тем же ключом — его не нужно скрывать, но он никогда не должен повторяться. Повторное использование nonce в AES-GCM приводит к катастрофическим последствиям: если два сообщения зашифрованы с одним ключом и одним nonce, злоумышленник может применить XOR к шифротекстам и устранить поток ключа, потенциально восстановив оба исходных текста. Эту уязвимость иногда называют «неправильным использованием nonce»; она уже приводила к атакам с восстановлением ключей в реальных системах.

При повторном использовании nonce в AES-GCM злоумышленник может вычислить C1 XOR C2 = P1 XOR P2 (результат операции XOR над обоими исходными текстами), поскольку для обоих сообщений использовался один и тот же поток ключа. Кроме того, повторное использование nonce позволяет восстановить ключ аутентификации H, после чего злоумышленник может подделывать корректные теги аутентификации для произвольных сообщений, полностью нарушая конфиденциальность и целостность. Именно такой атаке подверглась, например, система Sony PS3. Защитой служат случайные nonce (сгенерированные с помощью CSPRNG) или детерминированный счётчик, который никогда не сбрасывается.

ChaCha20-Poly1305 — ещё один шифр AEAD, обязательный в TLS 1.3. ChaCha20 — потоковый шифр, разработанный Дэниелом Бернстайном. Он генерирует поток ключа с помощью операций сложения, циклического сдвига и XOR (ARX), не использует таблицы подстановки, работает за постоянное время и чрезвычайно быстр на CPU без аппаратного ускорения AES. Poly1305 — одноразовый MAC (код аутентификации сообщения), вычисляющий тег аутентификации для шифротекста. Вместе они обеспечивают безопасность, сопоставимую с AES-GCM, но значительно быстрее работают на мобильных устройствах и устройствах IoT.

Современные настольные и серверные процессоры x86 и ARM64 оснащены аппаратными инструкциями AES-NI, благодаря которым AES-GCM работает чрезвычайно быстро. Однако во многих мобильных процессорах и процессорах устройств IoT нет AES-NI, поэтому программная реализация AES-GCM работает сравнительно медленно. ChaCha20-Poly1305 изначально создавался для быстрой работы в программном обеспечении с использованием простых арифметических операций, поэтому мобильные устройства получают сопоставимую производительность без аппаратного ускорения. Google добавила ChaCha20-Poly1305 в TLS как альтернативу именно для устройств Android, и теперь этот набор шифров является одним из основных в TLS 1.3.

«AD» в AEAD означает Associated Data — незашифрованные метаданные, подлинность которых проверяется. Это позволяет аутентифицировать данные, которые должны оставаться доступными для чтения, например заголовки пакетов или поля типа записи, и одновременно защищать их от подмены. В TLS 1.3 байты заголовка записи включаются в вычисление AEAD как связанные данные. Если злоумышленник изменит заголовок, например длину записи, проверка тега аутентификации завершится ошибкой, и соединение будет разорвано.

До того как AEAD стал стандартом, криптографы рекомендовали схему Encrypt-then-MAC (EtM): сначала зашифровать исходный текст, а затем вычислить MAC для шифротекста. Это безопасно, но требует двух отдельных операций с двумя разными ключами. Схемы AEAD, такие как AES-GCM, объединяют обе операции с одним ключом, упрощая реализацию и устраняя целый класс атак с оракулом дополнения, которым были подвержены схемы MAC-then-Encrypt (MtE) — порядок операций, использовавшийся в старых версиях TLS (CBC + HMAC). TLS 1.3 с AEAD полностью избегает этих проблем.

И AES-128-GCM, и AES-256-GCM одобрены NIST и считаются безопасными против классических компьютеров. AES-128 обеспечивает 128-битный уровень безопасности и работает немного быстрее; AES-256 обеспечивает 256-битный уровень безопасности, создавая больший запас прочности против будущего криптоанализа и квантовых угроз. Для большинства современных приложений AES-128-GCM достаточно, однако для государственных систем с секретной информацией требуется AES-256 (NSA Suite B). TLS 1.3 поддерживает оба варианта, а серверы могут выбирать приоритет на основе своей политики безопасности.

При расшифровании шифротекста AEAD получатель должен проверить тег аутентификации до расшифрования. Процесс выглядит так: заново вычислить ожидаемый тег на основе полученного шифротекста, ключа и nonce; сравнить его с полученным тегом с помощью функции сравнения за постоянное время; продолжить расшифрование только при совпадении. Сравнение за постоянное время критически важно: если оно прекращается сразу после обнаружения первого несовпадающего байта, злоумышленник может провести атаку по побочному каналу, связанному со временем выполнения, и подделать корректные теги побайтно. Любая библиотека AEAD, использующая сравнение с досрочным выходом, уязвима.

Алгоритмы AEAD повсеместно используются в современных системах безопасности: TLS 1.3 применяет AES-GCM и ChaCha20-Poly1305 для шифрования всех записей; WireGuard VPN использует исключительно ChaCha20-Poly1305; протокол Signal применяет его для шифрования сообщений; протокол QUIC, лежащий в основе HTTP/3, использует AES-GCM. Если Вы видите набор шифров вроде TLS_AES_256_GCM_SHA384, SHA384 обозначает хеш-функцию HKDF для выработки ключей, а не механизм обеспечения целостности — за целостность отвечает тег GCM.

Проверьте, насколько хорошо Вы усвоили концепции CompTIA Security+ (SY0-701) из этого урока.

В этом уроке Вы узнали, что алгоритмы AEAD одновременно обеспечивают конфиденциальность и целостность с помощью тега аутентификации, обнаруживающего любое изменение шифротекста; повторное использование nonce в AES-GCM приводит к катастрофическим последствиям, позволяя восстановить поток ключа и подделать ключ аутентификации, поэтому nonce должен быть уникальным для каждого шифрования; а ChaCha20-Poly1305 является эффективной с точки зрения производительности альтернативой AES-GCM для устройств без аппаратного ускорения AES. Далее мы рассмотрим функции выработки ключа, предназначенные для защиты паролей.