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

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

Попробуем разобраться на очень простом примере. Следует иметь в виду, что этот пример лишь похож на операции в рамках DNSSEC, а не описывает их в деталях. Предположим, администратор зоны fort.test.ruхочет удостоверить с помощью цифровой подписи данные об адресации, хранящиеся на его DNS-сервере. У администратора есть пара ключей: секретный и открытый (публичный). Используя секретный ключ и данные об адресации (можно считать, что эти данные представляют собой простой компьютерный файл) в качестве исходных данных, администратор генерирует новый файл, содержащий цифровую подпись, соответствующую секретному ключу и исходным данным. Получив значение цифровой подписи (а она представима в виде набора байтов), администратор размещает эту подпись в публичном доступе вместе с адресной информацией.

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

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

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

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

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