AES-GCM может защищать конфиденциальность сообщения и обнаруживать несанкционированные изменения. Сам по себе он не сообщает получателю, было ли уже обработано в остальном действительное сообщение.
Легко перепутать три требования: уникальные пары ключ/nonce для шифрования, аутентификация сообщения и его контекста и обработка воспроизведения на уровне протокола. HKDF помогает выводить ключи, но не выполняет автоматически все три требования.
Повторное использование nonce и воспроизведение — разные события
| Событие | Что происходит | Необходимая защита |
|---|---|---|
| Повтор nonce при шифровании | Разные открытые тексты шифруются одним ключом GCM и nonce | Надёжная стратегия выделения пар ключ/nonce |
| Подмена | Меняется шифротекст или аутентифицируемый контекст | Аутентифицированное расшифрование и отказ при неуспехе |
| Воспроизведение | Ранее действительное зашифрованное сообщение доставляется снова | Состояние и правила приложения, распознающие дубликаты или устаревшие сообщения |
| Изменение порядка | Действительные сообщения приходят в другом порядке | Определённый протоколом порядок и ограниченная обработка сообщений вне очереди |
Повторно доставленный шифротекст всё ещё может иметь действительный тег аутентификации. Ничего не изменилось. Поэтому неверно утверждать, что каждый дубликат автоматически не проходит аутентификацию AES-GCM. RFC 5116 явно отделяет интерфейс AEAD от средств защиты от воспроизведения.
Почему пара ключа и nonce не должна повторяться
Nonce GCM не обязан быть секретным, но должен соответствовать требованиям уникальности схемы при данном ключе. Часто используется nonce длиной 96 бит, или 12 байт; выбор такой длины не гарантирует правильной генерации.
Повторное использование одного ключа и nonce для разных открытых текстов повторно использует шифрующую гамму, раскрывая связи между этими текстами. Оно также может подорвать подлинность и сделать возможной подделку. Последствия серьёзны, но их нельзя описывать как автоматическое раскрытие всех старых ключей или каждого сообщения аккаунта. Масштаб зависит от повторно использованного ключа и протокола.
NIST SP 800-38D определяет GCM и его требования. Реализации должны соблюдать применимые ограничения числа вызовов и правила генерации nonce, а не упрощённое правило «безопасно до такого-то числа сообщений».
Что даёт HKDF
HKDF, определённая в RFC 5869, выводит ключевой материал из входного секретного материала с помощью этапов извлечения и расширения. Протоколы могут использовать метки контекста и разные входные данные, чтобы разделять ключи для разных целей.
HKDF детерминирована. Если клиент после сбоя или отката повторяет то же состояние и входные данные, он может снова получить тот же результат. Поэтому добавление HKDF в архитектуру не делает повтор nonce невозможным.
Отдельные ключи сообщений могут уменьшить объём содержимого, защищаемого одним ключом, но безопасное продвижение состояния, разделение ключей и удаление остаются важными. Одинаковое значение nonce при действительно разных ключах — не тот же сбой, что повтор пары ключ/nonce; протокол должен устанавливать, что ключи действительно различаются.
Защита от воспроизведения относится к протоколу
Получатель может отслеживать идентификаторы сообщений, позиции в последовательности, эпохи сеанса или использованные ключи ratchet. Соответствующие поля должны аутентифицироваться, чтобы злоумышленник не мог переобозначить старое сообщение как новое.
Затем приложение должно решить, что означает дубликат. Повторный пузырь сообщения в чате неудобен; выполнение одного действия дважды может быть серьёзнее. Сетевые повторные попытки нормальны, поэтому наряду с криптографическими проверками часто нужна идемпотентная обработка.
Не требуйте, чтобы каждое действительное сообщение приходило строго по порядку, если протокол этого не предусматривает. Мобильные клиенты регулярно переподключаются, повторяют попытки и получают задержанные сообщения. Безопасная обработка отличает законное позднее сообщение от уже обработанного сообщения или сообщения с неверным контекстом.
Что проверять, прежде чем заявлять о защите
- Перезапуск после выделения nonce, но до записи отправки: может ли выделение повториться?
- Восстановление старого снимка состояния: могут ли ключи, счётчики или записи о воспроизведении откатиться?
- Одновременная отправка двумя рабочими процессами или устройствами: разделены ли их пространства ключей/nonce?
- Доставка одного действительного сообщения дважды: выполняется ли действие приложения один раз?
- Изменение идентификатора сеанса или заголовка: привязан ли контекст криптографически?
- Доставка действительных сообщений вне очереди: обрабатываются ли поддерживаемые задержки без принятия устаревшего состояния?
API аутентифицированного расшифрования должны возвращать открытый текст приложению только после успешной проверки. Это требование к интерфейсу, а не утверждение, что ни одна реализация никогда не вычисляет внутри временный буфер открытого текста.
Как правильно читать заявления Livara
Документация по безопасности Livara называет AES-256-GCM, цепочки ключей сообщений и контекст LVR1/LGS1. Эти примитивы сами по себе не доказывают правильность восстановления после сбоя, выделения nonce или отклонения воспроизведённых сообщений. Такие заявления требуют деталей протокола с указанием версии и результатов тестов.
Надёжная архитектура явно распределяет задачи: вывод ключей создаёт нужные ключи, AEAD аутентифицирует содержимое и контекст, а логика протокола с сохранением состояния решает, допустимо ли действительное сообщение сейчас.
