Двойная подпись фрагментированного DNSSEC для противодействия квантовой угрозе

Основная информация

• ID статьи: 2411.07535
• Название: Double-Signed Fragmented DNSSEC for Countering Quantum Threat
• Авторы: Syed W. Shah, Lei Pan, Dinh Duc Nha Nguyen, Robin Doss, Warren Armstrong, Praveen Gauravaram
• Учреждения: Deakin Cyber Research and Innovation Centre (Австралия), Cyber Security Cooperative Research Centre (Австралия), Quintessence Labs (Канберра), Tata Consultancy Services (Брисбен)
• Классификация: cs.CR (Криптография и безопасность)
• Конференция: C'25, ноябрь 2025 (предварительная версия принята на ITNAC 2025)
• Ссылка на статью: https://arxiv.org/abs/2411.07535

Аннотация

DNSSEC как расширение безопасности DNS критически важен для точного преобразования доменных имён в IP-адреса. Цифровые подписи обеспечивают основу для такого надёжного преобразования, однако развитие квантовых вычислений делает традиционные цифровые подписи уязвимыми. NIST недавно выбрал постквантовые цифровые подписи, которые работают на классических компьютерах и устойчивы к атакам квантовых компьютеров. Поскольку эти постквантовые цифровые подписи всё ещё находятся на ранней стадии разработки, замена доквантовых цифровых подписей в DNSSEC постквантовыми кандидатами до тщательного анализа безопасности сопряжена с риском. В данном исследовании рассматривается целесообразность применения «двойной подписи» в DNSSEC, объединяющей постквантовую и классическую подписи. Двойная подпись будет одновременно обеспечивать защиту от квантовых угроз и неизвестных неквантовых атак. Однако включение двух подписей конфликтует с максимально допустимым размером ответа DNSSEC (1232 байта, ограниченным MTU физического канала). Для решения этой проблемы в статье используется метод фрагментации на уровне приложения для обработки ответов DNSSEC с двойной подписью. Решение, реализованное на OQS-BIND, показывает, что двойная подпись и фрагментация на уровне приложения оказывают минимальное влияние на эффективность процесса разрешения имён и подходят для использования в переходный период до полной реализации квантовых компьютеров.

Исследовательский контекст и мотивация

1. Основная проблема

DNSSEC обеспечивает подлинность и целостность ответов DNS через цифровые подписи, но сталкивается с тройной дилеммой квантовой эпохи:

• Квантовая угроза: криптографически релевантные квантовые компьютеры (CRQC) могут за полиномиальное время взломать традиционные подписи, основанные на факторизации целых чисел и дискретном логарифме, используя алгоритм Шора
• Незрелость постквантовых решений: постквантовые подписи, выбранные NIST (FALCON, DILITHIUM, SPHINCS+), ещё не прошли достаточный криптографический анализ и могут содержать недостатки, которые можно использовать на классических компьютерах
• Риск переходного периода: в период от настоящего времени до полной реализации CRQC полагаться исключительно на традиционные или постквантовые подписи небезопасно

2. Значимость проблемы

• DNS является ядром интернет-инфраструктуры; любая уязвимость безопасности может направить пользователей на вредоносные серверы
• Согласно рекомендациям ENISA, простая замена криптографических алгоритмов в переходный период может снизить общую безопасность
• Неопубликованный прорыв в CRQC или недостаток в постквантовом алгоритме могут сделать DNSSEC неэффективным

3. Ограничения существующих подходов

• Только традиционные подписи: не могут противостоять будущим квантовым атакам
• Только постквантовые подписи: могут содержать неизвестные векторы атак на классических компьютерах
• Существующие схемы фрагментации: ARRF использует нестандартные RR, что может привести к проблемам совместимости с промежуточными устройствами; QBF не учитывает сценарий двойной подписи
• Механизм отката на TCP: многие серверы имён не поддерживают TCP, и TCP менее эффективен, чем UDP

4. Исследовательская мотивация

Применение стратегии «двойной подписи» (интерфейс отделённого сообщения):

• Если безопасна хотя бы одна подпись, вся система остаётся безопасной
• Обеспечивает максимальную защиту в переходный период
• Требует решения проблемы превышения размера сообщения двойной подписью (>1232 байта вызывает фрагментацию на уровне IP)

Основные вклады

1. Полная реализация двойной подписи DNSSEC: разработана платформа тестирования DNSSEC на основе Docker, использующая коммерческое ПО BIND9, способная обрабатывать доквантовые и постквантовые подписи и открытые ключи в одном UDP-ответе
2. Механизм фрагментации и переассемблирования на уровне приложения: для сценария двойной подписи разработана улучшенная схема фрагментации QBF:
   • Использование z-битов для идентификации типа постквантового алгоритма
   • Применение смещения TTL для сохранения исходного порядка RR и предотвращения ошибок указателей сжатия
   • Поддержка всех комбинаций доквантовых (ECDSA256, RSASHA256) и постквантовых (FALCON512, DILITHIUM2, SPHINCS+) алгоритмов
3. Модификация исходного кода BIND9: глубокое исследование и изменение компонента разрешителя BIND9 для проверки двух подписей перед пометкой ответа как аутентифицированного
4. Оценка производительности: эмпирический анализ показывает, что двойная подпись оказывает незначительное влияние на время разрешения DNSSEC (<9% увеличение), подтверждая её пригодность для переходного периода

Подробное описание методов

Определение задачи

Входные данные: DNS-запрос (например, запись A для test.example.com)
Выходные данные: IP-адрес с проверкой двойной подписи
Ограничения:

• Размер UDP-сообщения ≤1232 байта (предотвращение фрагментации на уровне IP)
• Одновременная проверка доквантовой и постквантовой подписей
• Совместимость с существующей инфраструктурой DNS

Архитектура двойной подписи

1. Генерация подписей (сторона сервера имён)

Применяется интерфейс отделённого сообщения:

• Использование инструментов BIND9 для генерации двух пар ключей (ZSK и KSK)
• Независимая генерация двух подписей для одного RRSet:
  • Доквантовая подпись X (ECDSA256 или RSASHA256)
  • Постквантовая подпись Y (FALCON512/DILITHIUM2/SPHINCS+)
• Обе RRSIG и DNSKEY хранятся в файле подписанной зоны

Пример (рисунок 13):
test0.socratescrc. 3600 IN RRSIG A 13 ... (подпись ECDSA)
test0.socratescrc. 3600 IN RRSIG A 249 ... (постквантовая подпись)

2. Стратегия проверки (сторона разрешителя)

Модификация логики проверки BIND9:

• Независимая проверка двух подписей
• Ответ принимается только если обе подписи проходят проверку
• Обеспечивает двойную защиту от квантовых и классических атак

Механизм фрагментации на уровне приложения

Основная проблема

Типичный размер ответа с двойной подписью:

• Ответ A-записи: ~2500 байт (минимальная комбинация ECDSA+FALCON512)
• Ответ DNSKEY: 4462 байта (RSASHA256+FALCON512)
• Значительно превышает порог 1232 байта

Стратегия фрагментации

Основные принципы:

• Доквантовые RRSIG и DNSKEY всегда полностью отправляются в первом фрагменте (меньший размер)
• Постквантовые подписи/ключи фрагментируются по мере необходимости

Фрагментация ответа A-записи (рисунок 8a):

1. Первый фрагмент содержит: Header + Question + полная доквантовая RRSIG/DNSKEY + часть постквантовой RRSIG
2. Разрешитель из первого фрагмента определяет общее количество фрагментов
3. Параллельный запрос оставшихся фрагментов (формат: ?n?domain_name)

Фрагментация ответа DNSKEY (рисунок 8b):

• Некоторые комбинации (например, RSASHA256) приводят к тому, что первый фрагмент не может вместить никакие постквантовые данные
• Инновационное решение:

Метод идентификации z-битов:

Использование z-битов (3 бита) из RFC 1035:
- Кодирование типа постквантового алгоритма (FALCON/DILITHIUM/SPHINCS+)
- Разрешитель на основе z-битов и полученных доквантовых RR определяет общий размер

Механизм смещения TTL:

Проблема: указатели сжатия DNS зависят от порядка RR
Решение: добавление смещения в поле TTL ответа DNSKEY
Назначение: восстановление исходного положения RR при переассемблировании, 
предотвращение ошибки "bad compression pointer"

Рабочий процесс (рисунок 10)

Демон сервера имён:

1. Перехват ответа DNS, проверка размера >1232 байта
2. Расчёт требуемого количества фрагментов
3. Установка z-битов (если необходимо) и смещения TTL
4. Установка флага TC=1, отправка первого фрагмента
5. Кэширование оставшихся фрагментов

Демон разрешителя:

1. Получение первого фрагмента, проверка флага TC
2. Анализ z-битов для определения постквантового алгоритма
3. Использование информации доквантовых RR для определения общего количества фрагментов
4. Параллельный запрос всех оставшихся фрагментов (?2?test.socrates, ?3?test.socrates...)
5. После получения всех фрагментов переассемблирование:
   • Использование смещения TTL для восстановления исходного порядка RR
   • Сброс флага TC и других значений заголовка
6. Передача полного сообщения в OQS-BIND для проверки

Технические инновации

1. Совместимость со стандартными RR: в отличие от ARRF с пользовательскими RR, использование стандартного формата DNS обеспечивает совместимость с промежуточными устройствами
2. Повторное использование z-битов: инновационное использование недостаточно используемых битов заголовка для решения проблемы недостаточности информации в ответе DNSKEY
3. Схема смещения TTL: решение конфликта между механизмом сжатия DNS и переассемблированием фрагментов, уникальное для сценария двойной подписи
4. Параллельные запросы фрагментов: разрешитель параллельно получает все фрагменты, минимизируя задержку
5. Независимость от алгоритма: поддержка любой комбинации всех выбранных NIST постквантовых алгоритмов и распространённых доквантовых алгоритмов

Экспериментальная установка

Архитектура тестовой платформы

Инфраструктура:

• Экземпляр Amazon EC2 t2.xlarge (4 ядра Intel Xeon 2.3 ГГц, 16 ГБ ОЗУ)
• Развёртывание в контейнерах Docker (Docker 25.0.3)
• Компоненты: Client, Resolver, Root Server, Authoritative Server

Программный стек:

• OQS-BIND: версия BIND9 с поддержкой постквантовых алгоритмов
  • OpenSSL 1.1.1
  • OQS liboqs 0.7.2
  • Поддержка FALCON512, DILITHIUM2-AES, SPHINCS+-SHA256-128S (128-битный уровень безопасности)
• Модифицированный демон QBF: реализация логики фрагментации/переассемблирования двойной подписи

Топология сети (рисунок 11):

Client → Resolver → Root Server → Authoritative Server
        ↑                            ↓
        └────────────────────────────┘

Конфигурация набора данных

• Тестовые доменные имена: 10 A-записей (test0.socratescrc - test9.socratescrc)
• Комбинации подписей: 6 конфигураций двойной подписи
  • Доквантовые: ECDSA256, RSASHA256
  • Постквантовые: FALCON512, DILITHIUM2, SPHINCS+-SHA256-128S
• Цепь доверия: правильная конфигурация записей DS, установление полной цепи доверия

Метрики оценки

1. Время разрешения: сквозная задержка от отправки запроса до получения проверенного ответа
2. Количество фрагментов: требуемое количество фрагментов для ответов A-записи и DNSKEY
3. Накладные расходы производительности: процентное увеличение времени двойной подписи относительно одной постквантовой подписи

Моделирование сетевых условий

Использование инструмента Linux tc для моделирования:

• Пропускная способность: 50 Мбит/с
• Задержка: 10 мс
• Моделирование реальных интернет-условий

Методология экспериментов

1. Итеративные запросы разрешителя для каждого доменного имени
2. Запись времени разрешения для каждого запроса
3. Расчёт среднего времени разрешения для 10 запросов
4. Сравнение производительности двойной подписи с одной постквантовой подписью

Результаты экспериментов

Анализ количества фрагментов (таблица 1)

Ключевые выводы:

• Комбинации FALCON и DILITHIUM увеличивают количество фрагментов только на 1
• Комбинации SPHINCS+ не добавляют дополнительные фрагменты (оптимизация демона удаляет некритичные RR)
• Увеличение количества фрагментов управляемо, не приводит к экспоненциальному росту

Среднее время разрешения

Комбинации FALCON (таблица 2):

Комбинации DILITHIUM (таблица 3):

Комбинации SPHINCS+ (таблица 4):

Основные результаты

1. Приемлемые накладные расходы производительности:
   • Накладные расходы всех комбинаций двойной подписи <9%
   • Значительно ниже накладных расходов отката на TCP (обычно >50%)
2. Оптимальные конфигурации:
   • FALCON+RSASHA: 204.5 мс (самая быстрая двойная подпись)
   • DILITHIUM+RSASHA: 220.7 мс
   • На 14-22% быстрее, чем одна подпись SPHINCS+ (245.6 мс)
3. RSA превосходит ECDSA:
   • Во всех комбинациях проверка RSA выполняется быстрее
   • Например: DILITHIUM+RSA (220.7 мс) против DILITHIUM+ECDSA (225.6 мс)
4. Успешность проверки двойной подписи:
   • Все комбинации двойной подписи корректно проверены
   • Модифицированный разрешитель BIND9 успешно проверил обе подписи (рисунок 14)

Экспериментальные выводы

1. Преимущество алгоритмов на основе решёток:
   • FALCON и DILITHIUM (на основе решёток) имеют меньший размер подписи
   • Время разрешения значительно лучше, чем SPHINCS+ (на основе хеша)
2. Недостатки SPHINCS+:
   • Максимальный размер подписи (23 фрагмента для A-записи)
   • NIST выбрал его в основном для избежания чрезмерной зависимости от алгоритмов на основе решёток
   • Не является оптимальным выбором в сценарии двойной подписи
3. Надёжность переассемблирования фрагментов:
   • Механизм смещения TTL эффективно решает проблему указателей сжатия
   • Схема z-битов точно передаёт информацию об алгоритме
   • Отсутствие потери сообщений или ошибок проверки
4. Прирост безопасности:
   • Двойная подпись обеспечивает механизм "отказоустойчивости"
   • Даже если алгоритм на основе решёток взломан, RSA/ECDSA обеспечивают классическую безопасность
   • Даже если реализован квантовый компьютер, постквантовый алгоритм обеспечивает защиту

Связанные работы

Исследования постквантового DNSSEC

1. Müller et al. (2020):
   • Анализ требований кандидатов третьего раунда NIST для DNSSEC
   • Не рассматривает схему двойной подписи
2. Beernink (2022):
   • Предложение метода внеполосной передачи больших ключей
   • Не решает проблему размера сообщения двойной подписи
3. Goertzen & Stebila (2022) - ARRF:
   • Фрагментация на уровне приложения по запросу
   • Введение псевдо-RR RRFRAGS (нестандартный)
   • Риск атак истощения памяти
4. Rawat & Jhanwar (2024) - QBF:
   • Фрагментация на основе QName, использование стандартных RR
   • Параллельные запросы фрагментов повышают эффективность
   • Не поддерживает двойную подпись

Сравнение вклада

Исследования криптографических комбинаторов

• ENISA (2022) рекомендует использование гибридных криптографических систем в переходный период
• Данная работа — первая, реализующая и оценивающая двойную подпись в DNSSEC
• Применение интерфейса отделённого сообщения (более простая интеграция)

Заключение и обсуждение

Основные выводы

1. Техническая осуществимость: двойная подпись DNSSEC полностью осуществима на существующей инфраструктуре без модификации протокола
2. Приемлемая производительность: накладные расходы <9%, значительно ниже отката на TCP, не окажут существенного влияния на пользовательский опыт
3. Повышение безопасности: обеспечивает двойную защиту от квантовых и классических атак, подходит для развёртывания в переходный период
4. Лучшие практики: рекомендуется использовать комбинацию FALCON или DILITHIUM с RSA, балансируя безопасность и производительность

Ограничения

1. Ограниченный масштаб тестирования:
   • Тестирование только на одном экземпляре EC2
   • Отсутствие моделирования крупномасштабного развёртывания в интернете
   • Отсутствие тестирования на реальном сетевом трафике
2. Упрощённые сетевые условия:
   • Моделирование только пропускной способности 50 Мбит/с и задержки 10 мс
   • Отсутствие учёта потери пакетов, дрожания и других сложных явлений
   • Отсутствие тестирования в различных окружениях MTU
3. Накладные расходы демона:
   • Логика фрагментации/переассемблирования реализована в отдельном демоне
   • Межпроцессное взаимодействие может вносить дополнительную задержку
   • Отсутствие прямой интеграции в ядро BIND9
4. Совместимость с промежуточными устройствами:
   • Отсутствие полного тестирования поведения брандмауэров, NAT и других промежуточных устройств
   • Повторное использование z-битов может вызвать проблемы в некоторых реализациях
5. Влияние на кэширование:
   • Отсутствие анализа влияния фрагментации на эффективность кэширования DNS
   • Несколько фрагментов могут усложнить кэширование
6. Недостаточный анализ безопасности:
   • Отсутствие формального доказательства безопасности
   • Отсутствие оценки устойчивости к DoS-атакам
   • Отсутствие анализа побочных каналов при переассемблировании фрагментов

Направления будущих исследований

1. Прямая интеграция в BIND9:
   • Интеграция логики фрагментации в ядро BIND9
   • Ожидается дальнейшее снижение времени разрешения
2. Тестирование крупномасштабного развёртывания:
   • Пилотное тестирование на реальной инфраструктуре DNS
   • Оценка совместимости с различными типами промежуточных устройств
3. Оптимизация выбора алгоритма:
   • Динамический выбор комбинации алгоритмов в зависимости от типа запроса
   • Исследование адаптивных стратегий фрагментации
4. Продвижение стандартизации:
   • Подача черновика в IETF
   • Продвижение двойной подписи как стандартной практики переходного периода
5. Повышение безопасности:
   • Добавление механизмов защиты от DoS
   • Исследование защиты от атак по времени при переассемблировании фрагментов

Глубокая оценка

Преимущества

1. Точное определение проблемы:
   • Чёткое выявление безопасностной дилеммы переходного периода
   • Стратегия двойной подписи соответствует рекомендациям авторитетных организаций, таких как ENISA
   • Решение критических технических препятствий для практического развёртывания
2. Полнота технического решения:
   • z-биты и смещение TTL — инновационные инженерные решения
   • Баланс производительности, совместимости и безопасности
   • Достаточное описание деталей реализации (модификация исходного кода, проектирование демона)
3. Разумное проектирование экспериментов:
   • Использование коммерческого ПО BIND9 повышает практическую ценность
   • Тестирование всех основных комбинаций алгоритмов
   • Моделирование сетевых условий соответствует реальным сценариям
4. Убедительность результатов:
   • Ясные данные о производительности (<9% накладных расходов)
   • Проверка корректности всех комбинаций
   • Чёткие рекомендации по развёртыванию (FALCON/DILITHIUM+RSA)
5. Высокая инженерная ценность:
   • Основано на открытом ПО OQS-BIND с хорошей воспроизводимостью
   • Развёртывание в Docker облегчает распространение
   • Предоставляет практический путь для реального развёртывания

Недостатки

1. Отсутствие теоретического анализа:
   • Отсутствие формального доказательства безопасности схемы двойной подписи
   • Отсутствие обсуждения криптографической стойкости комбинации подписей
   • Отсутствие строгого обоснования предположения "одна подпись остаётся безопасной, если другая нарушена"
2. Ограниченный масштаб оценки:
   • Только 10 тестовых доменных имён, небольшой размер выборки
   • Отсутствие тестирования при высокой нагрузке и высокой параллелизме
   • Отсутствие долгосрочных тестов стабильности
3. Недостаточное сравнение с существующими решениями:
   • Отсутствие прямого сравнения производительности с откатом на TCP
   • Отсутствие оценки преимуществ относительно альтернативных решений, таких как EDNS(0) padding
   • Отсутствие анализа сравнения безопасности с развёртыванием чистого FALCON, чистого DILITHIUM
4. Неполное рассмотрение практических аспектов:
   • Отсутствие обсуждения сложности управления ключами (две пары ключей)
   • Отсутствие анализа затрат на модернизацию существующей инфраструктуры DNSSEC
   • Отсутствие тестирования обратной совместимости (старые версии разрешителей)
5. Возможные улучшения в представлении:
   • Некоторые технические детали многословны (раздел 2 о основах DNS)
   • Диаграммы могут быть более ясными (рисунки 8, 10 сложные)
   • Отсутствие псевдокода алгоритма

Влияние

Вклад в область:

• Новаторство: первая работа, реализующая и оценивающая двойную подпись DNSSEC
• Своевременность: своевременный ответ на процесс стандартизации NIST PQC
• Практичность: предоставляет решение переходного периода, готовое к немедленному развёртыванию

Практическая ценность:

• Краткосрочная: предоставляет операторам DNS решение для повышения безопасности в переходный период
• Среднесрочная: предоставляет эмпирические данные для стандартизации IETF
• Долгосрочная: служит справочным материалом для переходов на квантовую безопасность других протоколов

Воспроизводимость:

• ✓ Основано на открытом ПО (OQS-BIND)
• ✓ Подробное описание реализации
• ✗ Исходный код не опубликован (в статье не указана ссылка на GitHub)
• ✓ Развёртывание в Docker снижает сложность воспроизведения

Потенциальное влияние:

• Может способствовать принятию стратегии двойной подписи сообществом DNS
• Служит справочным материалом для стратегий фрагментации в других протоколах приложений (TLS, SSH)
• Способствует ускорению практического развёртывания постквантовой криптографии

Применимые сценарии

Идеальные сценарии применения:

1. DNS критической инфраструктуры: доменные имена финансовых, государственных и других организаций с высокими требованиями безопасности
2. Развёртывание в переходный период: 2025-2030 годы, когда угроза CRQC растёт, но постквантовые алгоритмы ещё требуют проверки
3. Высокоценные цели: организации, подверженные угрозам от государственных субъектов

Неприменимые сценарии:

1. Среды с ограниченными ресурсами: устройства IoT, встроенные системы (вычислительные и накопительные расходы)
2. Требования низкой задержки: системы реального времени (дополнительная 8% задержка может быть неприемлема)
3. Постквантовая эпоха: после полной зрелости постквантовых алгоритмов необходимость двойной подписи снижается

Рекомендации по развёртыванию:

• Приоритет развёртывания на корневых серверах и серверах TLD
• Использование комбинации FALCON+RSA или DILITHIUM+RSA
• Сосуществование с существующей инфраструктурой DNSSEC (постепенное обновление)
• Установление механизмов мониторинга для отслеживания производительности и безопасности

Ключевые источники (справочная литература)

1. Shor (1994): "Algorithms for quantum computation" — теоретическая основа квантовой угрозы
2. NIST PQC Standardization: спецификации алгоритмов FALCON, DILITHIUM, SPHINCS+
3. RFC 4034: спецификация записей ресурсов DNSSEC
4. RFC 6891: механизм расширения EDNS(0)
5. ENISA (2022): "Post-Quantum Cryptography Integration Study" — политическая основа стратегии двойной подписи
6. Goertzen & Stebila (2022): схема фрагментации ARRF
7. Rawat & Jhanwar (2024): схема фрагментации QBF (прямая основа данной работы)

Резюме

Данная работа решает уникальную безопасностную дилемму переходного периода DNSSEC путём предложения инженерно осуществимого решения двойной подписи. Благодаря умному проектированию фрагментации на уровне приложения (идентификация z-битами, смещение TTL) успешно решена проблема превышения размера сообщения двойной подписью. Эксперименты показывают управляемые накладные расходы производительности (<9%), подходящие для практического развёртывания. Это типичный пример "исследования, ориентированного на инженерию", где инновация в теории ограничена, но инженерная ценность значительна, что одинаково важно в области прикладной криптографии. Основная ценность статьи заключается в первой реализации и проверке, а не в теоретическом прорыве. Рекомендуется авторам в последующих работах дополнить формальный анализ безопасности и крупномасштабное тестирование развёртывания, а также способствовать открытому доступу к исходному коду для повышения влияния.