dxdt.blog: занимательный интернет-журнал

Вновь попадаются утверждения, что, применительно к реализациям протокола Диффи-Хеллмана, “секретные ключи никогда не покидают устройство”. Естественно, это совсем не так. В реальности – такое невозможно. Казалось бы, очевидно: симметричные секретные ключи обязательно должны “покинуть устройство”, иначе этими ключами не сможет воспользоваться другое устройство, для расшифрования или для зашифрования. Покидают устройство ключи и в случае использования протокола Диффи-Хеллмана (DH).

Да, с DH связана неверная контринтуитивная идея, в рамках которой производится сильное обобщение возможностей протокола: дело в том, что DH позволяет сторонам безопасно вычислить общий секрет, обмениваясь сообщениями через открытый канал; это верно; однако вот это понятие – “безопасно вычислить” – основано на некоторых допущениях, то есть, работает лишь в какой-то модели, от свойств которой заивисит реальный уровень безопасности. Ни в коем случае обмен ключами по DH не означает, что “секретные ключи не покидают устройство” или ” ключи есть только у клиента”! Естественно, это особенность протокола, и она всегда прямо учитывается в прикладной криптографии (там есть разные модели стойкости, в том числе, для DH).

Рассмотрим в качестве примера классический вариант DH, работающий “в остатках от деления” (“мультипликативный”). Здесь общий секрет вычисляется при помощи возведения в степень натурального числа. Общий секрет может быть получен после того, как стороны передали открытые параметры друг другу. Открытые параметры – это числа, которые каждая сторона получила на основе собственного асимметричного секрета DH. Открытые параметры – на то и открытые, что передаются через открытый канал. Обратите внимание: каждый из этих параметров содержит полную информацию, нужную для восстановления асимметричного секрета, а сеанс обмена DH – содержит полную информацию для восстановления симметричного секрета (если такой секрет генерируется только по DH, конечно). Более того, значение открытого параметра позволяет однозначно проверить, что третья сторона угадала секрет.

Стойкость протокола DH основана лишь на предположении, что третья сторона, прослушивающая канал, потратит слишком много вычислительных ресурсов на восстановление этого секрета из открытого параметра. Но если у этой третьей стороны такие вычислительные ресурсы есть, то ничто ей не мешает получить секрет – секрет содержится в открытом параметре и передаётся “за пределы устройства”. Это базовый принцип. Иначе работать схема не будет: получить тут общий секрет, не передавая тем или иным способом ключ, невозможно.

Я раньше несколько раз подробно описывал особенности DH и применение этого протокола в разных сценариях.

В свежей версии 149 браузера Firefox добавлен встроенный VPN-сервис, заворачивающий трафик к веб-узлам в туннель, проходящий через “прокси-сеть” Mozilla. Такой сервис был обещан некоторое время назад, теперь его постепенно внедряют в основную ветку браузера.

Тут как раз очень важно то, что вся обработка и перенаправление трафика – происходят в браузере. То есть, веб-узел видит только IP-адрес оконечного узла туннеля. А промежуточные сетевые узлы, находящиеся между браузером и входным узлом наложенной “прокси-сети”, не видят IP-адрес веб-узла, с которым соединяется браузер. Добавьте сюда защищённый DoH/DoT резолвинг DNS и – получается закрытая специализированная сеть доступа, привязанная к браузеру. Но пока что такой VPN-доступ не для всех, а только для пользователей в США, Великобритании, Германии и Франции.

В 2023 году я писал на dxdt.ru об одном из эффективных, для DNSSEC, способов динамического удостоверения факта отсутствия DNS-записи (или DNS-имени), который, в частности, применяют в Cloudflare. В конце 2025 года этот способ, с некоторыми добавлениями и обновлениями, получил спецификацию RFC 9824.

В частности, RFC 9824 вводит “мнимую” DNS-запись NXNAME (TYPE128) – это запись-сигнал об отсутствии в DNS-зоне запрошенного имени. Причина для введения такого сигнала в том, что упомянутый способ в принципе не позволяет отвечать со штатным для DNS статусом NXDOMAIN. Почему? Потому что весь смысл состоит в “подделывании” состава ответа, но, так сказать, с благими целями: при получении запроса о несуществующем имени, авторитативный сервер отвечает так, как если бы для этого имени нет DNS-записей в зоне: ANSWER: 0 и флаг NOERROR. В терминах DNS такой ответ называется NODATA – то есть, это корректный DNS-ответ без статуса ошибки, но пустой – не содержащий никаких ответных, – в блоке ANSWER, грубо говоря, – записей (естественно, это не означает, что DNS-ответ в целом не содержит записей: пуст только блок ANSWER, но записи в ответе есть, это дополнительные, “авторитативные” записи – SOA, NSEC и т.д.).

Однако, логически, NODATA – это не NXDOMAIN. Статус NXDOMAIN специально предназначен для указания на отсутствие самого имени. Действительно, если нет имени, то для него не может быть и никаких DNS-записей. Понятно, что и NODATA укладывается в схему, но с той лишь точностью, что NODATA – это отсутствие записи конкретного типа, пусть для несуществующего имени и нельзя разместить никакую запись, никакого типа. То есть, NXDOMAIN – мощнее, поскольку указывает на отстутствие самого имени. (Это всё может показаться сложным. Если так, то это не кажется: DNS вообще весьма и весьма непростая система. Зато, заметьте, что здесь очередной раз обыгрываются различные трактовки понятия “пустое множество”.)

Для того, чтобы в новой схеме отличить ситуацию, когда действительно нет записей, от ситуации, когда нет имени, как раз и служит новая запись-сигнал NXNAME. Авторитативный сервер указывает NXNAME в составе полей NSEC-записи, если нет DNS-имени. NSEC – это запись, обозначающая “границу” зоны (в данном случае – фиктивную границу), NSEC нужна для того, чтобы было что подписывать, так как нельзя подписывать пустое значение. Технически, подписать-то можно, но такую подпись легко скопировать и применять к отсутствию любых записей в DNSSEC, то есть в безопасной DNS-зоне: это как раз пример того, что все пустые множества одинаковые, а окрашивать можно только пустые коробки, вот как в случае с NXNAME/NODATA и NXDOMAIN.

Здесь играет роль ещё одна нетривиальная особенность DNS, которую мало кто понимает. А именно: в DNS распространены ситуации, когда возникают заведомо пустые, но поименованные, фрагменты имени. Предположим, что есть имя a.b.c.example.com, для которого указана A-запись. Это имя находится в зоне example.com, но A-запись указана только для a.b.c. Как трактовать имя b.c.example.com (без a.)? Оно, вроде как, есть, потому что в DNS полное имя строится в форме иерархии лейблов, разделяемых точками. Но, не менее “вроде как”, этого имени и “нет”, потому что для него в принципе не указаны никакие записи: из “полных” имён тут будет только example.com и a.b.c.example.com. Для корректной обработки такого случая, в схеме, где NXDOMAIN-ответ невозможен, нужен сигнал, позволяющий отличить несуществование имени от несуществования записи для этого имени. Это и есть NXNAME.

Конечно, занимательно. Но, другое дело, что, с одной стороны, новый подход позволяет быстро, в онлайн-режиме генерировать подписанные DNS-ответы, удостоверяющие отсутствие запрошенной записи или отсутствие имени. С другой стороны, логика DNS очередной раз усложняется, а клиент, резолвер – должен подерживать обработку NXNAME, иначе для него разные пустые коробки склеиваются в одну (отсутствие записи склеивается с отсутствием имени).

Кстати, что касается URL (URI), как носителя “секрета”, установленного в составе адреса документа или параметров URL: ещё в 2015 году, десять лет назад, “Яндекс.Браузер” собирал URL, которые посещает пользователь, и отправлял их поисковому роботу “Яндекса”, чтобы тот индексировал контент для всех пользователей поисковой системы (этот подход сильно напоминает теперешнее “обучение ИИ”, кстати). Так что, полагаясь на “секретность” URL (что само по себе очень плохо), браузеры-то как-то неправильно вычёркивать из перечня каналов утечки. Браузер исполняет веб-интерфейс, а не пользователь “на бумажке”, так что URL могут уходить куда угодно именно потому, что это URL.

Заметьте, что URL – это не авторизационный куки-файл, который браузеру тоже известен, но который передаётся в составе заголовков HTTP-запроса, поэтому чётко отделяется в любом браузере от URL, и браузер, всё же, этот файл будет пытаться отправлять только тем узлам, которым он прямо предназначен (на сей счёт есть очень много спецификаций и требований, а про URL – подобных требований нет).

В продолжение записки о том, что появится новый тип УЦ (Удостоверяющих Центров) для выпуска TLS-сертификатов, базирующихся на хеш-деревьях (деревьях Меркла). Речь в этой заметке не про технические детали (про них, возможно, будет отдельно в другой заметке), а про изменение технологических и административных процессов в работе УЦ, которые с новым подходом связаны. Сейчас пока что всё существует в виде тестов и черновиков RFC, но можно ожидать быстрого перехода УЦ на описанную схему. Примерно так же, как было с внедрением обязательных SCT-меток (от логов Cetrificate Transparency) в сертификаты: браузеры начинают верить только в сертификаты с правильными SCT-метками – УЦ для веба вынуждены подстроиться.

Новая схема работы радикально переиначивает логику деятельности УЦ. Дело в том, что полностью меняется фундаментальный процесс: УЦ должны вести собственный лог выпуска сертификатов, который лог становится необходимым источником сертификатов. Да, именно так. Потому что сертификаты, в новой схеме, образуются в результате корректного ведения лога. Это весьма существенное изменение: фактически, то, что сейчас реализуется Certificate Transparency, заносится внутрь УЦ и становится строго первичным, фундаментальным процессом.

Сейчас набор технологий и сервисов, который называется Certificate Transparency, реализуется внешним, относительно деятельности УЦ по выпуску сертификатов, образом. В новом варианте, при штатной работе, УЦ не сможет выпустить сертификат, не внеся прежде соответствующие записи в свой лог сертификатов и не получив на этих изменениях подписей от третьих сторон – эти третьи стороны выступают гарантами всего процесса, их подписи – необходимы для валидации сертификата.

Собственный лог УЦ как раз и ведётся в форме хеш-дерева. В сертификат нового типа обязательно должны быть добавлены артефакты из лога (доказательство включения в дерево), что и ставит внесение записей в лог выше процесса выпуска сертификата.

Да, сейчас УЦ должны получать SCT-метки с подписями логов Certificate Transparency (CT), чтобы внести эти метки в сертификат. То есть, процесс выпуска сертификата уже завязан на те или иные CT-логи, что, конечно, делает его похожим на предлагаемый новый вариант. Однако в новом варианте есть целых три существенных отличия:
1) УЦ обязательно ведёт свой лог, который необходим для формирования сертификатов (но это не отменяет других логов);
2) вводится два типа сертификатов, и даже в “полный” сертификат включаются сведения из лога, с подписями нескольких строн, а не просто подпись УЦ на конкретных данных (как сейчас);
3) основной метод оптимизации – сертификаты без подписи, которые содержат только доказательства включения в лог.

И вот главное из этих трёх нововведений – это сертификаты без подписи (“бесподписные”).

Почему весь смысл в сертификатах без подписи? Потому что только такие сертификаты позволяют отказаться от больших подписей криптосистем с постквантовой стойкостью. В этом смысл оптимизации. Да, тут нетрудно заметить ещё один занятный момент: речь про ML-DSA, а там, действительно, подпись занимает несколько килобайтов; казалось бы, и квантовые компьютеры выглядят теоретическим построением, и никто не доказал, что большой размер подписи является необходимым условием постквантовой стойкости – тем не менее, именно многокилобайтные подписи оказываются существенным фактором внедрения сертификатов без подписи и новой схемы работы УЦ. Впрочем, необходимо отметить и то, что схема с хеш-деревьями позволяет существенно экономить трафик уже и для RSA-подписей (с разрядностью 4096 бит и больше).

Чтобы работать с сертификатами без подписи, чтобы валидировать их, нужны свежие копии узлов доверенных деревьев (поддеревьев, если точнее), которые покрывают эти сертификаты. То есть, получается, что валидирующая сторона (браузер, предположим) будет достаточно часто скачивать обновления деревьев для валидации сертификатов. И если обновление получить не удалось, то сертификат без подписи будет считаться невалидным. Но, естественно, можно использовать “полный сертификат”. (Тут ещё есть отдельная история про то, как с новой схемой соотносится отзыв сертификатов, но её оставим для другой записки.)

Узел, запрашивающий выпуск нового сертификата у УЦ, может получить практически сразу же “полный сертификат” и, с некоторой задержкой, оптимизированный сертификат без подписей. Соответственно, TLS-сервер, при установлении TLS-соединения, мог бы выбирать, какой сертификат отправить клиенту, в зависимости от сигналов в начальном сообщении клиента. В TLS планируется добавить расширения, которые позволят информировать сервер о списке доверенных состояний деревьев (логов), которые известны клиенту. Так что, если сервер видит, что клиент не сможет валидировать оптимизированный сертификат (без подписей), то сервер присылает полный сертификат.

Понятно, что если сертификат полный, то нет ни экономии трафика, ни экономии вычислительных затрат на проверку подписей – то есть, довольно сомнительная затея: поэтому, конечно, основной расчёт на то, что большинство клиентов (веб-браузеры) будут оперативно обновлять списки доверия, скачивая их из каких-то точек раздачи, и принимать “бесподписные” сертификаты при соединении с веб-узлами. Получаем привязку к новой технологии и её провайдерам, в форме токенов доступа: если ваш клиент вдруг отстал от обновления дереьвев, то, как минимум, приходят “медленные” большие сертификаты, а как максимум – невозможно штатно заходить на веб-сайты и подключаться к TLS-узлам, потому что они все перешли исключительно на “бесподписные” сертификаты, в целях оптимизации. Если сейчас нужная для валидации информация, кроме статуса отзыва, есть в самом сертификате, то с “бесподписными” сертификатами – это окажется совсем не так.

То есть, в схеме с хеш-деревом и “бесподписными” сертификатами нужно регулярно скачивать обновления хеш-дерева. Заметьте, кстати, что TLS-расширение с поддерживаемым списком – может использоваться для профилирования и распознавания клиентского ПО по составу трафика. Хуже того, если забанят доступ к точкам раздачи обновлений хеш-деревьев, то перестанут работать веб-сайты с “бесподписными” сертификатами, и обойтись отключением “онлайн-проверки” статуса, как в случае с OCSP, уже не выйдет.

В Google планируют уже в следующем году начать строить в браузере новую инфраструктуру УЦ для TLS, используя схему с доказательствами на деревьях Меркла (хеш-деревьях) в оконечных сертификатах.

Это, технически, совсем другая история, по сравнению с действующими сейчас способами выпуска и публикации TLS-сертификатов. Доказательства принадлежности к дереву используются вместо подписи в сертификате. Это, фактически, перенос технических идей Certificate Transparency внутрь самих сертификатов. Я писал об этом новом подходе не так давно. С одной стороны – довольно интересная, изящная технология. С другой стороны – тут просматривается ещё большая технологическая привязка к тому же Google (потому что нужен будет совместимый TLS-стек в браузере, а реализовать такие технологии независимо – мало кому сейчас по силам; посмотрите хоть бы на внедрение ACME: там практически везде “готовые библиотеки/скрипты”, на обоих концах, что называется – мало кто понимает, как работает, но все используют и встраивают в свои системы на правах “чёрного ящика”). Но интересно, факт.

Основное обоснование для внедрения этой новой схемы – использование криптосистем электронной подписи с заявленной постквантовой стойкостью: в таких криптосистемах, обычно, очень длинные подписи (это, естественно, не является обязательным требованием для постквантовой стойкости, но реальность такова – сейчас предлагаются очень длинные и ключи, и подписи). Использование доказательств включения в хеш-дерево вместо подписи – сильно сокращает количество байтов, нужное для записи: доказательства строятся на хеш-функциях, а их выдача достаточно короткая.

В сообщении Google (по ссылке выше) есть ещё интересный момент: там пишут, что к концу этого года ожидают (возможно, в Chrome/Chromium) поддержку X.509-сертификатов с “обычными” “постквантовыми подписями” для непубличных PKI (для УЦ, которые не входят в “коробочный” список доверия браузера). То есть, в браузере может появиться поддержка криптосистем подписи с постквантовой стойкостью в сертификатах. Это довольно занятно, так как позволит использовать такие сертификаты хоть в каких-то браузерах. (Но это ещё нужно посмотреть, что там реально будет.)

C доверенными TLS-сертификатами для IP-адресов связан интересный аспект, касающийся проверки права управления адресом. Так как через DNS проверять право управления IP-адресом нельзя, то проверка проводится путём отправки запроса и получения ответа непосредственно и только по IP-адресу, для которого запрашивается сертификат. Конечно, нельзя забывать, что в IP-сетях всегда фактический обмен данными происходит по IP-адресам. Вот только, в зависимости от схемы проверки, разными могут быть и задействованные адреса, и физические узлы, которые адресам соответствуют. Но в схеме с подтверждением IP-адреса – адрес один, по определению. При этом свойство сети таково, что по заданному IP-адресу может ответить практически любой промежуточный узел – то есть, вовсе не тот узел, которому, как ожидается, предназначен пакет с запросом. В Интернете промежуточные узлы есть почти всегда, обычно – их много.

Это означает, что пройти проверку и получить доверенный сертификат для IP-адреса может любой промежуточный узел. Пример. Пусть проверка права управления происходит по HTTP. Проверяющий сервис направляет HTTP-запрос по IP-адресу, который указан в запросе на выпуск сертификата. Но этот HTTP-запрос обрабатывается на каком-то транзитном, промежуточном узле и этот же узел отправляет нужный ответ. Откуда узел узнал нужный ответ? Ну, например, сертификат для подмены IP-адреса был запрошен этим же узлом (возможны варианты: не обязательно заказывать сертификат с того же узла, который будет делать подмену).

Тут необходимо учитывать, что сам трафик, между двумя узлами, но в обе разные стороны, может ходить разными маршрутами. Однако промежуточный узел может отправить ответы и от себя – это уже технические детали подключения. При этом промежуточный узел даже может все прочие запросы – транслировать прозрачно на сторону настоящего узла.

Таким образом, получается, это промежуточный узел прошёл проверку и получил доверенный сертификат для другого, с административной точки зрения, IP-адреса. Заметьте, что статус промежуточного узла вовсе не означает, что этот узел как-то связан с администрацией блока адресов, к которому относится “настоящий” IP (может быть связан, но это не является строгим требованием).

Естественно, нетрудно заметить, что при HTTP-проверке промежуточный узел точно так же может подтвердить право управления и для DNS-имени, перехватив HTTP. Запросы всё равно ведь отправляются по IP-сети. Так что, если промежуточный узел умеет перехватывать HTTP-трафик, адресованный IP-узлу под проверяемым DNS-именем, то схема подмены не будет отличаться. Более того, сертификат по такой схеме будет получен для доменного имени, а это означает, что перехватывать трафик в дальнейшем, используя подменный сертификат, можно уже с другими IP-адресами. Перехват же с “IP-адресным” сертификатом – потребует продолжения подмены/перехвата части IP-маршута. Другое дело, что так как для поиска IP-адреса в случае HTTP-проверки для DNS-имени УЦ должен использовать DNS, то есть слабая надежда на то, что можно воспользоваться дополнительными мерами защиты: например, CAA-записью.

А вот проверка через DNS, то есть, с размещением кода подтверждения в DNS, – отличается. Здесь перехватывать и подменять уже нужно DNS-ответы, а они, скорее всего, проходят через другие промежуточные узлы. В идеале, для доставки кодов подтверждения через DNS используется несколько совсем разных маршрутов. Более того, если используется DNSSEC, то такая подмена DNS вообще не сработает.

Поэтому “проверка по IP”, в каком-то смысле, играет по собственным правилам, иногда оказываясь довольно слабой.

Даниэль Бернштейн (Daniel Bernstein) опубликовал сводную страницу (англ.) с информацией о “структуре спора” в IETF, который спор уже некоторое время идёт вокруг спецификаций, предлагающих использование в TLS негибридных криптосистем с постквантовой стойкостью (а именно – ML-KEM без дополнительных классических схем). Письма от Бернштейна, в рамках этой дискуссии, даже поставили на отдельную премодерацию в списках рассылки IETF – то есть, ограничили возможность что-то публиковать в этих списках. Там, на странице, предполагается, что продвижение негибридных вариантов ML-KEM через IETF – это “атака со стороны АНБ на уровне спецификаций”. Основные пункты, в поддержку и против, – организованы в виде дерева ссылок, по которому несложно понять, какие идеи/возражения есть, как они продвигаются; что весьма содержательно даже само по себе.

Например, есть интересный момент о том, что спецификации IETF не должны влиять на “внутренние реализации TLS”, потому что смысл деятельности IETF состоит в разработке спецификаций для Интернета в целом. Это в качестве ответа на предположение, что возможность “сломать совместимость TLS”, оставив там только негибридные схемы ML-KEM и полностью убрав ECC, не повлияет на “внутренние реализации”, где, мол, такое могло бы использоваться. Тут фокус в том, что спецификация TLS 1.3 делает поддержку криптосистем на эллиптических кривых обязательной, поэтому реализации, в которых такой поддержки нет (типа, для “экономии ресурсов”), не соответствуют спецификации (это будут дефектные реализации). Поэтому внедрение негибридных криптосистем, при наличии гибридных, – реально усложняет TLS (отмечу ещё раз, что TLS 1.3 – гораздо понятнее и логичнее, чем предыдущие версии спецификаций TLS; и странно это редкое для IETF преимущество ломать).

Не менее занимательно и странное утверждение в поддержку негибридных систем, основанное на размере ключей: мол, “отказ от части ECC в гибриде экономит место для ключей, что актуально для сред, где вычислительные ресурсы сильно ограничены”. Это странно потому, что, например, ключ ML-KEM имеет размер более килобайта (1184 байта), а та же схема X25519 (ECC) добавляет к ним только 32 байта. То есть, как справедливо замечено в возражении: “затраты на передачу и вычисление части X25519 пренебрежимо малы в сравнении с затратами на передачу ключей и шифротекста ML-KEM”. И верно: не нужно же забывать про чисто сетевые затраты, поскольку отправка и получение нескольких килобайт по TCP – это затраты на формирование заголовков пакетов, на копирование массивов, – которые, по размеру, будут за пределами возможностей быстрого преобразования, – затраты на переключение контекста, и так далее; поэтому разница в вычислениях между длиной 32+32 байта и длиной 1184 + 1568 байтов – может быть весьма разительна на некоторой аппаратуре, особенно, если говорить о средах с малой вычислительной мощностью.

В Let’s Encrypt собираются внедрить (англ.) новый метод проверки права управления доменом (DCV), который, при помощи публикации специальной TXT-записи, привязывает DNS-зону к ACME-аккаунту, а не к коду валидации, и при этом такая привязка становится “постоянной” – видимо, с точностью до того, как сервер будет запрашивать TXT-записи и фиксировать факт удаления соответствующего кода. Метод называется DNS-PERSIST-01.

Довольно занятное начинание. Например, в описании от Let’s Encrypt (по ссылке выше) имеется пространная “мотивировочная часть”, где несколько раз утверждается, что, мол, “во многих конфигурациях реквизиты доступа к DNS API распределяются через “пайплайны” выпуска и обновления [сертификатов], увеличивая количество мест, в которых атакующий может их [реквизиты] скомпрометировать”. Так, конечно, делать нельзя – нельзя раздавать реквизиты доступа к DNS “пайплайнами” по многим местам – ACME этого не требует. Но забавный момент тут в другом: предлагаемая схема, предположим, уходит от “раздачи реквизитов” от DNS, но зато привязывает всю защиту и безопасность к ключу от ACME-аккаунта!

То есть, ACME-аккаунт в этой схеме строго привязывается к DNS-имени, поэтому, если атакующая сторона получила доступ к ACME-аккаунту, то доступ к DNS уже вообще не нужен. Многие ли DevOps и системные администраторы вообще знают, что в ACME-клиенте есть секретный ключ от аккаунта, которым подписываются запросы, и о том, где этот ключ хранится? Не раздаётся ли этот ключ через “пайплайны” по резервным копиям? Вопросы, впрочем, риторические. Но должно же быть очевидно, что замена одной потенциальной “точки взлома” (доступы к DNS) на единственную другую (ACME-ключ клиента) – не даёт каких-то новых преимуществ с точки зрения безопасности. Но нет – приводят в пример. (Все эти моменты, кстати, описаны в черновике RFC для DNS-PERSIST-01. Но это – и черновик, и вряд ли многие прочитают.)

ACME-аккаунт – контролируется УЦ; можно предположить, что это не важно – УЦ и так выпускает какие хочет сертификаты; однако на практике, если используется одноразовый код подтверждения через DNS, есть небольшая надежда, что модуль проверки права управления доменом – как-то отвязан от модуля авторизации ACME-запросов; в случае же нового варианта – достаточно контроля над обработкой ACME-запросов.

И если, на практике, на стороне, которая заказывает TLS-сертификаты, управление DNS ещё как-то понятно администраторам, то ACME-клиент – совсем мутная вода.

Естественно, для того, чтобы публиковать коды ACME-подтверждения в DNS, не требуется раздавать реквизиты от этой DNS по куче мест. То есть, понятно, что такое регулярно происходит на практике, тут у Let’s Encrypt всё верно написано: это, как раз, один из побочных эффектов всей этой “автоматической истории” с ACME – раскидывание CNAME и тому подобные нехорошие варианты. Но управление DNS проще реализовать правильно и надёжно, чем управление ACME-клиентом: например, машина, которая является источником обновлений DNS-зоны, может сама ходить за кодами на точку раздачи, подтверждая потом публикацию ACME-клиенту, и так далее – вариантов много. В теории, наверное, и для ACME-ключа можно придумать серьёзную защиту. Проблема тут совсем в другом: многие знают, что DNS нужно защищать, а то будут проблемы; о том, что защищать нужно ACME-аккаунт – ну, может, кто-то и подумал, но даже если и подумал, то, скорее всего, решил: “а зачем? всё равно же DNS-доступ нужен для выпуска сертификата”. И не забывайте, что доступ к DNS, действительно, всё так же позволяет выпустить TLS-сертификат, только теперь ещё и доступа только к ACME-аккаунту становится достаточно.

Кстати, про схемы генерирования криптографических параметров и при чём здесь NUMS (Nothing Up My Sleeve – “Ничего в моём рукаве”). Опасения всегда связаны вот с чем: предположим, что сильный атакующий разработал специальные “секретные теоремы высшей алгебры” и, например, может эффективно взламывать асимметричные криптосистемы для чисел специального вида, но какой там “вид” – это секрет. Те, кто “секретные теоремы” ещё не узнал, взламывать не могут. Но чтобы схема работала, стандартные параметры должны состоять из тех самых чисел специального вида. (Конечно, схема имеет фундаментальную проблему: как только “секретные теоремы” перстают быть “секретными” – криптосистема ломается для всех. С одной стороны – это очень плохо. С другой стороны – сейчас уже обстановка достаточно странная для того, чтобы подумать: “кому какая разница? просто возьмите другую криптосистему”.)

Использование специальных параметров, если они подобраны хорошо и в соответствии с математикой криптосистемы, – это не обязательно бэкдор в самой криптосистеме, как ни странно. Дело в том, что и так есть много требований к выбору параметров, чтобы эти параметры были стойкими. Например, в “мультипликативном” варианте протокола Диффи-Хеллмана модуль P должен быть простым числом, но таким, что (P-1)/2 – тоже простое число. Или, для классических схем на эллиптических кривых, с дискретным логарифмом, нельзя выбирать кривые определённого вида, например, суперсингулярные с малой степенью вложения. И так далее, и тому подобное: есть много требований к RSA, есть требования к ML-DSA и пр. Начать с того, что элементарное требование на минимальную битовую длину записи – это требование к стойкости числового параметра, которое является универсальным и для симметричных, и для асимметричных криптосистем. Другими словами – у конкретных реализаций криптосистем есть типовые параметры, эти параметры должны быть выбраны так, чтобы не было “сомнений в добрых намерениях”. “Специальный” же вид – лишь добавляет “секретное” свойство, которое прямо в требованиях не указано.

Почему же не подходит “чисто случайный выбор” значений? Прежде всего потому, что если это чисто случайный выбор, то про его чистую случайность ничего нельзя строго доказать – всегда будут сомнения (за исключением, возможно, некоторых сложных квантовых схем, но они базируются на физических экспериментах, так что, скорее всего, там вопросов с сомнениями едва ли не больше).

То есть, случайное число может только выглядеть выбранным случайно, а на самом деле – это и есть число заданного специального вида. Проверить это абсолютно строго нельзя (опять же, оставляем физические квантовые схемы за скобками): можно предложить варианты, когда доверенные люди бросают игральные кости, а потом подписывают документ, подтверждающий выбор (сертификат), но и тут нетрудно возразить, что стол, на котором бросали – магнитный, а сами кубики – специально подобранные под нужные параметры. Но главное, как доказать случайность с кубиками через год или два? Ведь в такой схеме с игральными костями исчезает возможность для независимого повторения результата: сертификация будет одноразовой – если кубики настоящие, то выбросить повторно такое же число должно быть практически невозможно (ну, маловероятно должно быть). Какой смысл? Никакого смысла.

Конечно, существуют сложные детерминированные схемы с хеш-функциями, цифровыми подписями, доказательствами с нулевым разглашением и заголовками новостей в газетах, взятыми на день генерации параметров по модулю вершины блокчейна биткойнов. Но это именно что сложные схемы. А вот в упоминавшемся недавно RFC 7919 – описана простая схема получения неслучайных и надёжных простых чисел. В этой схеме используется запись числа e (основание натурального логарифма). Чем такая схема хороша?

Во-первых, в полученных таким способом числах есть дополнительная структура. Это важный момент: нельзя говорить, что это числа, в которых дополнительной структуры быть не может. Структура там есть, и она как раз состоит в том, что часть битов двоичной записи соответствует цифрам записи числа e с определённой позиции, согласно опубликованной формуле. В этом и смысл: конечно, e – иррациональное, а в его бесконечной записи можно найти запись любого простого числа (возможно, потребуется подобрать систему счисления, но это совсем технические детали, оставим их); однако формула выбора гарантирует, что будет взято первое слева подходящее число. Это число вполне конкретное, предопределённое. Его нельзя заранее подогнать под требования закладки. Да, данное число определяется структурой, но эту структуру заложили давно, когда определяли математическую константу e. Сложно предположить, что Бернулли и Эйлер придумали алгоритмы вычисления e с учётом непростых криптографических реалий начала 21 века.

Во-вторых, имеющаяся публичная структура (см. формулу с e) гарантирует, – в какой-то мере, конечно, – что число нельзя снабдить другой, скрытой произвольной структурой. Естественно, строго гарантировать тут можно то, что выдача алгоритма вычисления e не была приспособлена под требования закладки, но не обратное – требования закладки, всё же, можно приспособить под запись константы e. То есть, такую вторичную структуру нужно будет согласовать с уже имеющимся алгоритмом. Это, скорее всего, возможно проделать, но всё равно – какая-то фантастика. Если уж допускать такие возможности по созданию закладок в параметрах, то что тогда вообще помешает реализовать закладку любым другим теоретическим способом?

Поэтому схемы выбора параметров криптосистем, когда являются публичными, должны быть строго детерминированными и предсказуемыми, а не “случайными”: это гарантирует повторяемость и отсутствие дополнительной структуры, кроме заложенной в публичную формулу.

Кстати, когда пишут, что “квантовая криптография”, якобы, “позволяет создавать абсолютно защищённые каналы передачи данных, в которых принципиальная невозможность перехвата гарантируется законами физики”, то повторяют сразу несколько неверных “обратных обобщений”.

Многолетний хайп вокруг квантовой криптографии даёт тут хороший пример того, как можно всё перепутать, решив, что модель, используемая в вычислениях, обращается и обобщается максимально сильным образом. Например, какие-нибудь учебные задачи по физике решаются в режиме “трением пренебречь”, но из этого не следует, что трения действительно нет в реальной конфигурации, соответствующей задаче. Вообще, из того, что при построении вычислительной модели были сделаны какие-то допущения, но модель позволяет получать достаточно точные предсказания, не следует, что допущения модели перестали быть допущениями модели и превратились уже в явления исходного феномена.

Во-первых, применительно к квантовой криптографии, квантовая механика предоставляет способ подсчёта вероятностей исхода эксперимента (например, результат измерения при приёме фотона с той или иной поляризацией). Однако из этого не следует обратное утверждение: что распределение вероятностей – это и есть фундаментальное, “физическое” свойство. То есть, “переворот” вывода инструмента подсчёта вероятностей – это слишком сильное действие.

Во-вторых, концепция тут же предполагает, что атакующая сторона может действовать только в строго определённых рамках. То есть, атакующий, прослушивающий канал, якобы может делать это только перехватом фотонов-носителей, да ещё и таким способом, который “гарантированно нарушит состояние системы”. Но ведь атакующий может прослушивать электромагнитные утечки, возникающие при работе оборудования, которое эти самые фотоны-носители генерирует и принимает. В описываемой схеме квантовой криптографии, так или иначе, но информация о том, какую конфигурацию имело оборудование, сохраняется в электромагнитных полях, генерируемых оборудованием. Необходимая защита от таких утечек – только подчёркивает то, что квантовая “криптография” – это технический метод защиты каналов передачи информации, а не настоящая криптография (несмотря на название). Но почему-то постоянно постулируется, что атакующий должен пытаться перехватывать “квантовые носители” строго так, как задумано в теории. Это тоже слишком сильное действие, которое отличает предмет от чисто математической криптографии: нельзя заранее выносить за скобки неустранимый технологический эффект (побочные излучения), искусственно сужая возможности атакующего в физической реализации. Очень похоже на то, как в задаче про “скользящий брусок” предлагается пренебречь трением, только масштабы пренебрежения сильно больше.

Да, в настоящей, математической криптографии, тоже есть допущения, но тут необходимо делать акцент на обсуждаемой “физической невозможности”, якобы гарантированной “законами физики”. К математике это “физическое” отношения не имеет. Кроме того, никакие “законы” физики вообще ничего не “гарантируют”, по определению. Это всё лишь способ описания результатов экспериментов, использующий язык, предоставленный математикой.

Более того, – это в-третьих, – в описаниях сценариев применения квантовой криптографии рутинно пропускают момент аутентификации полученных по “квантовому каналу” ключей: ведь для этого потребуется вполне себе классическая схема цифровой подписи, с асимметричной криптосистемой.

Так что нельзя забывать о том, что “квантовая криптография” – только называется “криптографией”, но является техническим методом защиты информации. Это, так сказать, более продвинутый способ создания системы сигнализации о вторжении в канал передачи данных, снижающий, на некоторых направлениях, доступный атакующему уровень скрытности утчеки.