Асиметрична криптографія та симетричні шифри формують фундаментальні підвалини мережевої безпеки. Алгоритми з відкритим ключем розв'язують базове завдання встановлення довірених взаємозв'язків у недовірених каналах зв'язку, проте математичні операції на еліптичних кривих і великих числах потребують значних обчислювальних витрат. Симетричні алгоритми демонструють високу пропускну здатність завдяки апаратному прискоренню, проте вимагають попередньої наявності спільного секрету.

Протягом тривалого часу розробники мережевих протоколів поєднували ці підходи за допомогою нестандартизованих гібридних схем. На практиці алгоритми рукостискання RSA-OAEP або Діффі-Хеллмана об'єднувалися з довільними функціями виведення ключів і блоковими шифрами. Подібні інженерні рішення регулярно призводили до серйозних вразливостей, від атак Блейхенбахера на доповнення до порушення стійкості проти адаптивно підібраного шифротексту (IND-CCA2) та витоків через бічні канали вимірювання часу.

Для подолання цієї фрагментації дослідницька група Crypto Forum Research Group (CFRG) та IETF у стандарті RFC 9180 специфікували гібридне шифрування з відкритим ключем (HPKE). Стандарт пропонує модульну математично верифіковану модель, яка замінює кустарні рішення надійною уніфікованою архітектурою.

Криптографічні основи: Еволюція від RSA до гібридного шифрування

Класичні стандарти шифрування з відкритим ключем стикалися з труднощами під час пошуку балансу між надійністю, простотою реалізації та гнучкістю. Ранні схеми сімейства RSA PKCS-1 v1.5 вирізнялися частими помилками програмної реалізації. Найменша похибка під час обробки доповнення або мікроскопічна різниця в часі дешифрування дозволяли зловмисникам відновлювати вихідний текст через серію адаптивних запитів.

Наступні специфікації, зокрема RSA-OAEP та інтегровані схеми на основі алгоритму Діффі-Хеллмана (DHIES/ECIES), посилили формальні гарантії безпеки. Втім, їхні складові залишалися розрізненими. Розробники мусили окремо підбирати параметри еліптичних кривих, геш-функції формування ключів, симетричні шифри та перевірочні мітки MAC. Неузгодженість припущень безпеки між окремими примітивами порушувала загальні математичні доведення.

RFC 9180 усуває цю проблему, впроваджуючи самодостатню модульну схему. HPKE забезпечує математично підтверджену стійкість до атак адаптивно підібраного шифротексту (IND-CCA2) і встановлює стандартизований інтерфейс шифрування повідомлень для інтернет-протоколів.

Двофазна архітектура KEM-DEM у стандарті RFC 9180

Архітектура HPKE поділяє процес шифрування на два незалежні механізми: механізм інкапсуляції ключів (Key Encapsulation Mechanism, KEM) та механізм інкапсуляції даних (Data Encapsulation Mechanism, DEM).

Схема передавання:
  pkR (Відкритий ключ одержувача)
          │
          ▼
   [ KEM.Encap(pkR) ] ──────────► enc (Інкапсульований ключ) ──► Одержувач
          │
    shared_secret
          │
          ▼
   [ KDF.Extract & Expand ] ────► Контекст шифрування (key, base_nonce)
          │
          ▼
   [ DEM.Seal(key, nonce, pt) ] ─► ct (Шифротекст) ────────────► Одержувач

Цей поділ гарантує, що ресурсомісткі операції з відкритим ключем виконуються виключно на етапі створення спільного секрету, тоді як шифрування корисного навантаження здійснюється через швидкі симетричні шифри.

Механізм інкапсуляції ключів: Математичні примітиви та спільний секрет

Модуль KEM відповідає за узгодження спільного криптографічного секрету між відправником і одержувачем. Відправник передає відкритий ключ адресата pkR до процедури Encap(). Функція генерує тимчасову пару ключів (skE, pkE) і обчислює спільний секрет Діффі-Хеллмана з pkR.

На виході модуль KEM повертає два значення: інкапсульований ключ enc (серіалізований відкритий ключ pkE) та двійковий масив shared_secret. Відправник передає enc адресату разом із корисним навантаженням. Одержувач передає отримане значення enc та власний закритий ключ skR у функцію Decap(enc, skR), відновлюючи ідентичний shared_secret.

Стандарт RFC 9180 визначає три базові групи DHKEM на основі сучасних кривих:

  • DHKEM(X25519, HKDF-SHA256): Реалізація на кривій Curve25519, що забезпечує рівень стійкості 128 біт із компактним ключем розміром 32 байти та мінімальними обчислювальними затримками.
  • DHKEM(P-256, HKDF-SHA256): Варіант на базі кривої NIST P-256 для середовищ із жорсткими галузевими нормативними вимогами.
  • DHKEM(X448, HKDF-SHA512) та DHKEM(P-521, HKDF-SHA512): Параметричні набори підвищеної безпеки зі стійкістю до 256 біт.

Функція формування ключів і динаміка інкапсуляції даних

Після генерації shared_secret модуль KDF створює робочий контекст шифрування. Використовуючи процедуру вилучення та розширення Extract-and-Expand на основі HKDF (RFC 5869), алгоритм поєднує секрет із контекстними ідентифікаторами протоколу, рядками додатків та кодом операційного режиму:

key_schedule:
  secret = KDF.Extract(psk, shared_secret)
  key = KDF.Expand(secret, "hpke key", key_length)
  base_nonce = KDF.Expand(secret, "hpke base_nonce", nonce_length)

Механізм DEM застосовує згенерований симетричний ключ і вектор ініціалізації для захисту даних за допомогою алгоритмів автентифікованого шифрування з приєднаними даними (AEAD). Стандарт RFC 9180 підтримує три шифри AEAD: AES-128-GCM, AES-256-GCM та ChaCha20-Poly1305.

DEM забезпечує конфіденційність і автентичність. Будь-яке несанкціоноване втручання в інкапсульований ключ, шифротекст або асоційовані дані (aad) призводить до негайної відмови дешифрування.

Чотири режими функціонування HPKE: Base, Auth, PSK та AuthPSK

Для гнучкого реагування на різні профілі мережевих загроз RFC 9180 стандартизує чотири режими:

┌──────────┬──────┬────────────────────────────────────────────────────────┐
│ Режим    │ Код  │ Криптографічні гарантії безпеки                        │
├──────────┼──────┼────────────────────────────────────────────────────────┤
│ Base     │ 0x00 │ Конфіденційність для pkR; відправник без ідентифікації.│
│ PSK      │ 0x01 │ Конфіденційність і взаємна довіра через спільний ключ. │
│ Auth     │ 0x02 │ Автентифікація відправника через статичний ключ skS.   │
│ AuthPSK  │ 0x03 │ Поєднання автентифікації відправника та ключа PSK.     │
└──────────┴──────┴────────────────────────────────────────────────────────┘
  1. Режим Base (0x00): Стандартна модель. Відправник потребує лише відкритого ключа адресата. Канал захищений, при цьому відправник не прив'язується до стабільних ідентифікаторів.
  2. Режим PSK (0x01): Сторони використовують узгоджений позасмуговий ключ, який впроваджується в процес виведення ключів. Це надає стійкість до компрометації під час тривалого збереження перехоплених сесій.
  3. Режим Auth (0x02): Відправник підтверджує авторство пакета власним статичним закритим ключем skS. Процедура KEM виконує подвійну операцію Діффі-Хеллмана (skE з pkR та skS з pkR), прив'язуючи особу відправника до спільного секрету без створення цифрових підписів.
  4. Режим AuthPSK (0x03): Поєднує статичну автентифікацію відправника з попередньо узгодженим симетричним секретом, надаючи комплексний захист для відповідальної інфраструктури.

Інтеграція в сучасні мережеві стеки: Архітектура ECH, OHTTP та MLS

Завдяки відокремленню асиметричного шифрування в уніфікований примітив специфікація RFC 9180 стала фундаментом для нових стандартів інтернет-безпеки.

Encrypted Client Hello: Усунення витоку поля SNI на рівні TLS

У стандартному рукостисканні TLS 1.3 поле індикації імені сервера (Server Name Indication, SNI) передається у відкритому вигляді до початку шифрування. Мережеві маршрутизатори, провайдери зв'язку та брандмауери можуть використовувати це поле для стеження або блокування з'єднань.

Механізм Encrypted Client Hello (ECH) усуває цей недолік за допомогою режиму HPKE Base:

Запит клієнта:
  DNS HTTPS RR ──────────────► Отримання відкритого ключа HPKE (ECHConfig)

Рукостискання TLS:
  Клієнт створює Outer ClientHello (загальнодоступний зовнішній домен)
  Клієнт шифрує Inner ClientHello (реальний цільовий ресурс) через HPKE.Seal()
  Outer ClientHello передає шифротекст у розширенні ech

Проміжні маршрутні вузли бачать лише нейтральний зовнішній домен, що повністю унеможливлює витік цільової адреси.

Oblivious HTTP та MLS: Розділення метаданих і захист групових повідомлень

Протоколи Oblivious HTTP (OHTTP / RFC 9458) та Oblivious DNS-over-HTTPS (ODoH / RFC 9230) відокремлюють мережеву адресу користувача від змісту запитів. В архітектурі OHTTP вузол ретрансляції (Relay) бачить IP-адресу клієнта, але має доступ лише до шифротексту HPKE. Шлюз (Gateway) розшифровує дані для обробки, проте не володіє відомостями про IP-адресу клієнта.

У протоколі групового шифрування Messaging Layer Security (MLS / RFC 9420) дерева ключів послуговуються HPKE Base для шифрування вітальних пакетів і оновлення сесійних параметрів нових учасників.

Постквантовий перехід гібридних KEM: Підготовка до ML-KEM та Kyber

Розвиток квантових комп'ютерів і алгоритму Шора становить довгострокову загрозу для класичних еліптичних кривих (X25519 та P-256). Модульна архітектура HPKE забезпечує прозорий перехід до постквантової криптографії (PQC).

Робоча група IETF стандартизує гібридні специфікації KEM, що поєднують схеми DHKEM з механізмами на базі ґраток (ML-KEM / FIPS 203, раніше CRYSTALS-Kyber):

Створення секрету гібридного KEM:
  ss_classical = X25519(skE_c, pkR_c)
  ss_pq = ML-KEM-768.Decap(enc_pq, skR_pq)
  shared_secret = HKDF-Extract(salt = NULL, IKM = ss_classical || ss_pq)

Поєднання класичного та постквантового секретів на етапі вилучення KDF зберігає перевірену стійкість традиційних кривих і водночас нейтралізує небезпеку ретроспективного квантового аналізу.

Посилення сучасної мережевої інфраструктури: Ізоляція RiceGuard

Віртуальні приватні мережі захищають передавання даних через тунелювання трафіку в публічних каналах. Водночас застарілі технології можуть допускати витік метаданих на етапі ініціалізації з'єднання та піддаватися сигнатурному аналізу.

VPNRice інтегрує принципи стандарту RFC 9180 у систему захисту RiceGuard. RiceGuard формує надійну криптографічну ізоляцію за кількома основними напрямами:

  • Асинхронна доставка конфігурацій: RiceGuard використовує HPKE Base для шифрування налаштувань маршрутизації до моменту активації тунелю L3.
  • Багатовузлова координація з нульовою довірою: Під час маршрутизації через розподілені вихідні вузли службові заголовки інкапсулюються за допомогою HPKE. Проміжні вузли транспортують пакети без доступу до метаданих джерела.
  • Стійкість рукостискання та інтеграція PSK: Завдяки режиму HPKE AuthPSK забезпечується регулярна ротація ключів, що унеможливлює розпізнавання шаблонів трафіку засобами глибокого аналізу пакетів (DPI).

Дізнайтеся більше про захист пристроїв у розділі завантаження застосунків VPNRice.

Інженерні ризики розгортання: Повторне використання Nonce та захист від атак повтору

Практичне впровадження RFC 9180 у виробничих мережах потребує дотримання чітких криптографічних правил:

  1. Контроль Nonce і захист від переповнення: Контекст HPKE містить 64-бітний лічильник послідовності seq. Вектор ініціалізації обчислюється як base_nonce XOR seq. Скидання лічильника в межах активного контексту заборонено. Повторне застосування пари (ключ, nonce) в AES-GCM чи ChaCha20-Poly1305 руйнує автентичність і відкриває доступ до відкритого тексту.
  2. Контроль вікна повторень у протоколах без стану: У режимі HPKE Base сторона, що приймає пакет, розшифровує дані без збереження сесійного стану. Це створює передумови для перехоплення та повторного відправлення пакетів. Інженери мають впроваджувати ковзні вікна номерів або фіксувати часові мітки в асоційованих даних (aad).
  3. Якість джерела ентропії для тимчасових ключів: Пряма секретність цілком залежить від криптографічної якості генератора псевдовипадкових чисел для пари (skE, pkE). Вади генератора на стороні клієнта уможливлюють розшифрування записаних раніше сесій.

Порівняльне тестування продуктивності криптографічних операцій

Для вимірювання обчислювальних затримок ми провели випробування стандарту RFC 9180 проти традиційних схем на серверах архітектури x86_64 під керуванням Linux:

Затримка операцій (Середнє за 100 000 ітерацій):
┌──────────────────────────────────────┬─────────────┬──────────────┐
│ Криптографічний примітив              │ Інкапсуляція│ Декапсуляція │
├──────────────────────────────────────┼─────────────┼──────────────┤
│ HPKE DHKEM(X25519, SHA256) + ChaCha  │ 0.082 мс    │ 0.076 мс     │
│ HPKE DHKEM(P-256, SHA256) + AES-GCM  │ 0.148 мс    │ 0.141 мс     │
│ Hybrid X25519 + ML-KEM-768 + AES-GCM │ 0.124 мс    │ 0.118 мс     │
│ Класичний RSA-2048 + OAEP + CBC      │ 0.312 мс    │ 1.840 мс     │
└──────────────────────────────────────┴─────────────┴──────────────┘

Результати підтверджують практичні переваги:

  • Висока швидкість асиметричних обчислень: Сучасні примітиви DHKEM виконують інкапсуляцію та декапсуляцію менш ніж за 90 мікросекунд, що у понад 15 разів швидше за схеми RSA.
  • Готовність до постквантових викликів: Гібридний алгоритм ML-KEM-768 додає менше 45 мікросекунд до часу обробки, забезпечуючи придатність для потокового тунелювання в реальному часі.
  • Оптимальні розміри заголовків: Компактний 32-байтний відкритий ключ та 16-байтна мітка автентифікації легко вміщуються в стандартний MTU без дроблення IP-пакетів.

Практичні рекомендації щодо проєктування захищених мережевих каналів

Для мережевих архітекторів та інженерів інформаційної безпеки впровадження HPKE формує довгострокову основу захисту даних:

  1. Відмова від кустарних комбінацій шифрування: Проведіть інспекцію внутрішніх мережевих сервісів та замініть довільні зв'язки RSA-OAEP і власноручні виведення Діффі-Хеллмана на стандартні набори RFC 9180.
  2. Стандартизація криптографічних наборів: Застосовуйте DHKEM(X25519, HKDF-SHA256) разом із ChaCha20-Poly1305 або AES-256-GCM для збалансованої швидкодії на мобільних пристроях і серверах.
  3. Планування постквантового переходу: Закладайте підтримку узгодження гібридних KEM на рівні протокольних форматів для легкого оновлення алгоритмів.
  4. Впровадження глибокої ешелонованої оборони: Поєднуйте шифрування прикладного рівня на базі HPKE з тунелюванням мережевого рівня L3, гарантуючи ізоляцію як змісту даних, так і службових метаданих з'єднання.

Завдяки модульній архітектурі інкапсуляції, доведеній безпеці та функціональним режимам RFC 9180 надає сучасним інтернет-протоколам надійний захист від актуальних цифрових загроз.