Думаєте, що впровадити нонсеси просто? Подумайте ще раз. Незалежно від того, чи створюєте ви ончейн-протоколи чи офчейн-інфраструктуру, правильна реалізація nonce є однією з найскладніших частин криптографічної безпеки. Давайте зануримося в те, чому захист від повторного відтворення складніший, ніж здається 👇

2. Для початку давайте розберемося з цифровими підписами. У криптовалюті з відкритим ключем (наприклад, BLS) у вас є приватний ключ, який підписує повідомлення, і публічний ключ, який їх перевіряє. В Ethereum: address = хеш відкритого ключа message = хеш транзакції підпис = 64 байти криптографічного доказу

3. Ось у чому проблема: математика в більшості криптопротоколів з відкритим ключем не обмежує, скільки разів підпис може бути перевірений за одним і тим же повідомленням. Як тільки у вас буде дійсний підпис, ви зможете відтворювати його нескінченно. Це відкриває двері для повторного проходження атак.

4. Введіть nonce: «число, використане один раз», яке запобігає повторним атакам. Коли споживач отримує повідомлення з відсутністю, він перевіряє, чи використовувався цей nonce раніше. Якщо так → відхилити. Транзакції Ethereum використовують цей шаблон.

5. Але реалізація не є оманливо складною. Ключові вимоги: - Нонти НІКОЛИ не повинні бути багаторазовими (на цьому ланцюжку або інших) - Повинен постійно запобігати повторним атакам - Потреба в механізмах для управління зростанням обсягів зберігання - Повинен бути стійким до атак з переднім бігом

6. Наївне рішення: зберігати всі нісенітниці в базі даних вічно. Це має дві основні проблеми: a) Необмежене зростання обсягу пам'яті (особливо при спам-атаках) б) Вразливість до атак на випередження Задачу (а) розв'язати легше, ніж (б). Давайте спочатку займемося зберіганням...

7/ Нонцеси на основі часових позначок вирішують зростання сховища! Використовуйте позначку часу + термін дії. Нонти старше 5 хвилин видаляються з бази. Але як щодо одночасних повідомлень з одного облікового запису? Вони мають спільну позначку часу. Рішення: мітка часу + random_bytes для деталізованої унікальності.

8/ Біг вперед – це складна частина. Зловмисники можуть перехоплювати дійсні підписи, запускати їх, щоб позначити недопущення як використане, а потім дзвінок законного користувача відхиляється. Це проблематично в ланцюжку з пакетними операціями, якщо один поганий підпис відхиляє весь пакет. Для офчейн: використовуйте шифрування TLS! Не дозволяйте зловмиснику побачити символ «нонсе» або підпис.

9/ Не забувайте про наполегливість! Якщо ваш кеш nonce знаходиться тільки в пам'яті, зловмисники можуть повторно відтворити старі нонти після перезавантаження системи. Завжди зберігайте стан nonce до тривалого зберігання та перезавантаження під час запуску. Кеш лише з пам'яттю = вікно вразливості повторного відтворення.

10/ Унікальні нонцеси на одного споживача! При трансляції для кількох користувачів кожен повинен отримати різне повідомлення/підпис. В іншому випадку ви вразливі до атак типу "людина посередині", коли один одержувач пересилає повідомлення, видаючи себе за початкового відправника.

11/ Поступові нонсеси (як Ethereum, nonce = prev nonce + 1) мають своє місце, але будьте обережні! Вони створюють величезні проблеми для офчейн-інфраструктури: повідомлення, що вийшли з ладу, проблеми з синхронізацією та складні сценарії відновлення. Використовуйте лише в тому випадку, якщо ви впевнені, що повідомлення надходитимуть (або повинні) надходити послідовно.

Підсумки - Чек-лист впровадження Nonce: ✅ Використовуйте нонцеси, щоб запобігти повторним атакам ✅ Збереження стану nonce під час перезавантаження ✅ Впровадьте механізми закінчення терміну дії (мітка часу + очищення) ✅ Зробіть нонцеси унікальними для кожного приймача ✅ Захист від фронтального запуску за допомогою зашифрованих каналів ✅ Уникайте поступових незавершень, якщо не гарантовано порядок Безпека криється в деталях! 🛡️