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

У класичних протоколах (таких як IPsec IKEv2 або традиційний OpenVPN) отримання пакета рукостискання змушує сервер виділяти структури пам'яті, перевіряти ланцюжки сертифікатів і здійснювати затратні модульні обчислення. Хвиля повторно надісланих пакетів (replay attack) швидко виснажує ресурси процесора та пам'яті, спричиняючи стан відмови в обслуговуванні (DoS).

Протокол WireGuard нейтралізує цю небезпеку завдяки продуманій архітектурі. До автентифікованого корисного навантаження кожного пакета ініціалізації додано 12-байтну монотонно зростаючу мітку часу за стандартом TAI64N. Перевіряючи цю мітку за константний час ще до створення стану сесії, WireGuard миттєво відкидає повторні пакети без помітного навантаження на систему.

Загроза повторного відтворення початкових рукостискань

Щоб зрозуміти значення зашифрованих монотонних міток, розглянемо початковий обмін повідомленнями за шаблоном Noise_IK:

Схема ініціалізації сесії у WireGuard (Noise_IKpsk2):
Клієнт (Ініціатор)                                    Сервер (Відповідач)
  |                                                           |
  |--- Пакет типу 1: Ініціалізація рукостискання ------------->|
  |    - відкритий ефемерний ключ (32 байти)                  |
  |    - зашифрований статичний ключ (48 байтів AEAD)         |
  |    - зашифрована мітка часу TAI64N (28 байтів AEAD)       |
  |    - теги автентифікації mac1 (16 байтів), mac2 (16 байтів)|
  |                                                           |
  |<-- Пакет типу 2: Відповідь на рукостискання --------------|

У пакеті першого типу довготривала ідентичність клієнта та мітка часу зашифровані алгоритмом ChaCha20-Poly1305 за допомогою ключа, отриманого через операції Діффі-Геллмана.

Якщо сторонній спостерігач перехопить такий пакет на лінії зв'язку, він не зможе модифікувати його вміст через захист тегом Poly1305. Проте за відсутності механізму перевірки свіжості даних зловмисник міг би продублювати цей пакет мільйони разів:

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

Ця диспропорція витрат ресурсів робить вузли вразливими до вичерпання обчислювальної потужності.

Двійкова структура мітки часу TAI64N

WireGuard відмовився від звичайного системного часу UNIX на користь стандарту TAI64N, розробленого криптографом Деніелом Бернштейном. Час UNIX зазнає стрибків через секунди координації (високосні секунди), що може зміщувати системний годинник назад і створювати немонотонні проміжки часу.

Міжнародний атомний час (TAI) пропонує безперервну шкалу секунд, яка ніколи не робить кроків назад. Формат TAI64N фіксує цей час із наносекундною деталізацією у компактній 12-байтній структурі:

Двійковий формат TAI64N у WireGuard (12 байтів):
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Секунди TAI64 (Старша частина)           |
|                   (64-бітне ціле Big-Endian)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Секунди TAI64 (Молодша частина)          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Зсув у наносекундах                       |
|                   (32-бітне ціле Big-Endian)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1. Секунди TAI64 (8 байтів): Відображають неперервну кількість секунд від точки відліку ($2^{62}$ відповідає 01.01.1970 00:00:10 TAI), усуваючи проблему переповнення 2038 року.
  2. Наносекунди (4 байти): Значення в діапазоні від $0$ до $999,999,999$. Наносекундна точність гарантує, що навіть при швидких повторних спробах підключення згенеровані значення будуть суворо зростати.

Усередині пакета першого типу ці 12 байтів шифруються за допомогою ChaCha20-Poly1305, перетворюючись на 28 байтів шифротексту. Завдяки шифруванню спостерігачі не можуть аналізувати часові мітки для визначення характеристик апаратного таймера клієнта.

Перевірка в ядрі та відкидання пакетів за константний час

Під час отримання пакета ініціалізації модуль ядра WireGuard виконує перевірку за чітким алгоритмом:

Надходження пакета ініціалізації (Тип 1)
         |
         v
[Перевірка MAC1: хеш SipHash пакета з відкритим ключем сервера]
         |
         +--> Помилка? Миттєве відкидання (Пам'ять не виділяється)
         v
[Обчислення ключа DH: ефемерний * статичний]
         |
         v
[Дешифрування статичного ключа та мітки TAI64N через AEAD]
         |
         +--> Тег аутентифікації не збігається? Відкидання
         v
[Порівняння за константний час зі значенням last_sent_handshake]
         |
         +--> Отримана мітка <= last_sent_handshake?
         |         |
         |         v
         |    Миттєве відкидання (Повтор! Сесія не створюється)
         v
[Оновлення запису: last_sent_handshake = Отримана мітка]
         |
         v
[Формування відповіді типу 2]

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

Порівняння реалізоване за строго постійний час (constant-time), унеможливлюючи атаки через аналіз часу обробки.

Параметр зіставлення Звичайний час UNIX Мітка TAI64N WireGuard Механізм запит-відповідь (Nonce)
Накладні витрати на розмір 4–8 байтів 12 байтів 16–32 байти
Затримка для перевірки свіжості 1 RTT 0 RTT (перевірка у 1-му пакеті) 1 повний цикл RTT (обмін токеном)
Стійкість до високосних секунд Вразливий через зміщення годинника Повна стійкість (шкала TAI) Стійкий (випадкові дані)
Захист від відстеження годинника Відкритий заголовок у пакеті Приховано всередині блоку AEAD Відсутня прив'язка до часу
Навантаження на пам'ять сервера Високе (списки використаних nonce) Нульове (одна мітка на пір) Помірне (кешування токенів)

Граничні випадки: розсинхронізація, режим сну та збій живлення

Оскільки WireGuard перевіряє умову нове_значення > старе_значення, нетипові сценарії функціонують за такими принципами:

Відхилення годинника клієнта та сервера

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

Вихід мобільних пристроїв із глибокого сну

Коли телефон чи ноутбук перебуває в режимі сну, апаратний таймер може тимчасово зупинитися. Після пробудження система синхронізує час за протоколом NTP. Якщо час зсувається вперед, наступна спроба формує мітку з вищим значенням і з'єднання відновлюється без перешкод.

Випадкове скидання системного годинника

Якщо в пристрої повністю розрядився резервний елемент живлення годинника (RTC) і час повернувся до 1970 року, сервер відхилятиме ініціалізації, доки клієнт не скоригує час через мережу до актуального стану.

Надійна синхронізація часу в інфраструктурі RiceGuard

Щоб унеможливити перебої у корпоративних тунелях через апаратні збої часу на мобільних пристроях, у ядрі RiceGuard передбачено спеціальні алгоритми:

  • Захищений монотонний лічильник: На смартфонах RiceGuard веде облік часу через захищені таймери системи. У разі стрибка системного годинника назад алгоритм автоматично додає зміщення, гарантуючи зростання вихідних міток TAI64N.
  • Синхронізація під час міграції між вузлами: Під час обслуговування шлюзів та переведення трафіку на резервні сервери система безпечно передає реєстр міток, виключаючи блокування клієнтів через дрібні відмінності між серверами.
  • Взаємодія із захистом Cookie MAC2: Під час інтенсивних атак розподіленої відмови в обслуговуванні (DDoS) перевірка міток TAI64N комбінується з механізмом безстатусових cookie, відсікаючи мільйони підроблених пакетів на швидкості мережі без навантаження на процесор.

Завдяки впровадженню стандарту TAI64N рішення WireGuard та RiceGuard забезпечують незламний захист від повторного відтворення пакетів, гарантуючи миттєве встановлення зв'язку та стабільну роботу мереж.

Завантажити VPNRice.\n