Александр Венедюхин - Домены. Все, что нужно знать о ключевом элементе Интернета

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

Теперь для других участников, использующих DNSSEC, доступна информация об адресации и связанная с этой информацией цифровая подпись. Для проверки подписи используется открытый ключ из пары, принадлежащей администратору, который также опубликован. Для проверки, которая выполняется по специальному, известному всем участникам DNSSEC алгоритму, используются файл данных об адресации, файл с соответствующей цифровой подписью и открытый ключ. Заметьте, что открытый ключ дает возможность проверять достоверность подписи, но не позволяет за разумное время вычислять новые подписи для измененных данных. Важная особенность цифровой подписи в том, что при изменении подписываемых данных изменяется и сама подпись, поэтому просто скопировать подпись от одних данных и «прицепить» ее к другим не получится.

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

Все бы хорошо, но, если чуть тщательнее обдумать предложенную только что схему, можно найти неприятный момент. Предположим, злоумышленник не только изменил адресную информацию, но еще и подписал ее, используя собственный секретный ключ, а соответствующий открытый ключ (для проверки подписи) подсунул ничего не подозревающей жертве вместе с обманными данными DNS. И вообще, каким образом получатель адресной информации может убедиться, что тот, кто ему эту информацию передает, действительно уполномочен управлять данным доменом? Может, отвечающий сервер подставной? Сама по себе верность цифровой подписи не гарантирует того, что достоверно и содержание заверенных этой подписью данных. Выходит, даже внедрив «хитрые» подписи, мы остались все при тех же проблемах доверия?

Так и есть: одними подписями обойтись не удается. Требуется механизм, позволяющий удостоверять полномочия источников этих подписей. В DNSSEC для создания этого механизма должна использоваться естественная иерархия прав, уже существующая в доменной системе имен. То есть на базе системы делегирования прав администраторам доменов, о которой подробно рассказано несколькими главами выше, создается механизм подписывания ключей. Так, достоверность источника ключа для какого-либо домена удостоверяется с помощью цифровой подписи, исходящей от вышестоящего «удостоверяющего центра», подпись этого центра удостоверяет другой, стоящий еще выше в иерархии, а в итоге образующаяся «цепочка доверия» сводится с корневому домену и корневому ключу. Этот ключ должен быть распространен по всем участникам DNSSEC независимо от DNS. Например, он может быть встроен в операционные системы. Корневой ключ – главный ключ всей системы, позволяющий проверить достоверность любой подписи на всех прочих уровнях, – принадлежит той организации, которая отвечает за достоверность DNS в целом, и поэтому, строго говоря, этот ключ не может являться частью DNS.

DNSSEC позволяет участникам системы самим настраивать «цепочки доверия» и решать, какому именно удостоверяющему центру они готовы верить «на слово», без дополнительных проверок. В каких-то сетевых архитектурах конечным центром доверия может являться вовсе не корневой центр всего Интернета, а, скажем, некоторый локальный сервер. Но для всего Интернета важен именно общепринятый корневой центр.

DNSSEC уже внедрена во многих доменах первого уровня. Есть немало доменов уровнем ниже, внутри которых также используется DNSSEC. Однако совершенно преждевременным было бы говорить, что DNSSEC развернута, до тех пор пока не «подписаны» корневые серверы имен, соответствующие корневому домену. (Как я рассказывал ранее, таких серверов 13, и в настоящий момент они в административном плане контролируются ICANN.)

Именно с «подписыванием» корневых серверов были связаны политические проблемы в управлении Глобальной сетью. Они сводятся к довольно простому вопросу: у кого ключ?

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

До внедрения DNSSEC контроль над верхушкой иерархии DNS был более размазан. Да, фундаментальные решения принимала ICANN после согласования с соответствующими подразделениями Минторга США. Техническую сторону обеспечивают технические службы (например, корпорация VeriSign или такая организация, как IANA). При этом сами 13 корневых серверов вовсе не являются тринадцатью физическими компьютерами, а представляют собой большое количество сложных многокомпьютерных систем, разбросанных по дата-центрам разных стран. Понятно, что в управлении этими базовыми узлами DNS так или иначе задействовано большое количество различных телекоммуникационных компаний.

После того как состоялось подписание корневых серверов, управление DNS получило еще одну строгую криптографическую процедуру, однозначно привязанную к корневому ключу. Корневую зону DNS окончательно подписали в ночь с 15 на 16 июля 2010 года. Конечно, после завершения многомесячной и довольно сложной процедуры поэтапного развертывания технологии на корневых серверах. Открытые ключи для проверки подписей DNSSEC опубликованы на сайте IANA (https:// data.iana.org/root-anchors/). Таким образом, несмотря на существенные административные сложности, Минторг США, компания VeriSign и службы ICANN в 2010 году успешно завершили развертывание DNSSEC в корневой зоне.

Споры вокруг того, кому должен достаться «главный ключ», кто будет подписывать данные, а кто станет генерировать новые ключи, шли довольно долго. В итоге утвердили следующую схему. Существует два ключа – самый главный KSK (Key Signing Key – ключ для удостоверения ключа) и чуть менее «главный» ZSK (Zone Signing Key – ключ для подписывания зоны). KSK удостоверяет ZSK, а уже последний используется для удостоверения данных в корневой доменной зоне. Достоверность ZSK можно проверить, используя открытую часть KSK.