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 автентифікує вміст і контекст, а логіка протоколу зі збереженням стану вирішує, чи прийнятне дійсне повідомлення зараз.
