Поддержка инфраструктур открытых ключей в DNS

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

Проблема распространения ключей

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

Существующие подходы к решению проблемы

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

Репозитории PKI традиционно основывались на облегченном протоколе доступа к каталогам (LDAP). LDAP — это протокол доступа, совместимый с моделью каталогов X.500, имеющий одно важное преимущество: он не зависит от конкретной технологии, используемой базой данных каталогов.

Протокол передачи файлов FTP также предлагает жизнеспособное решение для публикации и распространения сертификатов и CRL, являясь привлекательной альтернативой традиционным протоколам доступа к каталогам. Центр сертификации может использовать FTP-сервер для публикации сертификатов и CRL, чтобы конечные объекты могли получить доступ к этим данным посредством анонимного FTP.

Протокол HTTP представляет собой еще одно частное решение для реализации хранилища PKI. Идея похожа на ранее описанную для FTP. Веб-сервер может представлять для центра сертификации средства для публикации специфичных для PKI данных. Конечные объекты могут извлекать эти данные с помощью клиентов, поддерживающих HTTP (например, интернет-браузеров).

Поддержка DNS распространения ключей

Система доменных имен (DNS) представляет собой набор протоколов и служб в сети TCP/IP, который позволяет использовать понятные для пользователя имена при поиске других хостов вместо того, чтобы запоминать и использовать их IP-адреса.

Хранение сертификатов открытых ключей в DNS

RFC 2538 предлагает следующий формат ресурсной записи CERT для хранения сертификатов открытых ключей в DNS:

Тип - Тэг ключа - Алгоритм - Сертификат

Поле типа сертификата используется для идентификации формата сертификата, хранящегося в ресурсной записи. В настоящее время DNS может хранить сертификаты, соответствующие стандарту X.509, SPKI и PGP. Следовательно, поле типа может быть представлено в виде целого беззнакового числа, которое соответствует конкретному формату сертификата. Поле тега ключа идентично полю, определенному в спецификации DNSSEC. В DNSSEC тэг ключа используется для различения нескольких открытых ключей при необходимости проверки подписи DNSSEC. Чтобы уменьшить вычислительные затраты, связанные с процессом проверки, поле тега ключа используется для эффективного выбора подходящего открытого ключа. Алгоритм вычисления двухоктетного тега ключа реализован с помощью следующей функции языка Си:

 int compute_keytag (unsigned char *key, unsigned int size_key)
 {
  long int ac;
  unsigned int i;
  for(ac = 0, i = 0; i < size_key; ++i)
      ac += (i & 1) ? key[i] : key[i] << 8;
  ac += (ac >> 16) & 0xFFFF;
  return ac & 0xFFFF;
 }

Схема именования

Ресурсная запись CERT позволяет отображать сертификаты открытых ключей на доменные имена. Такое сопоставление создает возможность преобразования DNS в глобально доступный репозиторий PKI. Основное требование DNS заключается в том, что с каждой записью должно быть связано имя домена. Стандарт требует, чтобы ресурсные записи CERT хранились под доменным именем, связанным с их субъектом, то есть идентификатором объекта, предназначенного для управления закрытым ключом, соответствующим сертифицированному открытому ключу. Перевод уникального имени (Distinguish Name) субъекта в доменное имя часто является довольно сложной задачей. Невозможно найти единственное и окончательное решение этой проблемы. Поэтому стандарт предоставляет набор альтернативных решений, которые могут соответствовать вышеуказанному требованию. Эти решения должны использоваться на практике в следующем порядке:

1. Если доменное имя используется для идентификации субъекта сертификата, то следует использовать это доменное имя.

2. Если доменное имя не используется, но имеется IP-адрес, то следует использовать перевод этого IP-адреса в соответствующее доменное имя (при помощи обратного просмотра DNS).

3. Если ничего из вышеперечисленного не используется, но присутствует URI, содержащий доменное имя, то следует использовать это доменное имя.

4. Если нет ничего из вышеперечисленного, но имеется имя из строки символов, указывающее адрес электронной почты субъекта, то следует использовать стандартный перевод адреса электронной почты субъекта в доменное имя.

5. Если не имеется ничего из вышеперечисленного, то уникальное имя должно быть сопоставлено с именем домена, как указано в RFC 2247.

Анализ подхода

Масштабируемость

Исследователи с кафедры автоматизации и информатики Туринского политехнического университета сравнили работу поддержки инфраструктур с открытыми ключами репозиториями на основе LDAP с подходом на основе DNS. Тесты проводились с использованием реализаций с открытым исходным кодом LDAP и DNS. Для анализа LDAP была выбрана конкретная реализация OpenLDAP, в то время как для DNS использовалась реализация BIND. Исследователи утверждают, что одним из недостатков LDAP по сравнению с DNS является тот факт, что в настоящее время LDAP не проходит проверку развертывания в глобальном масштабе. Более того, поиск сертификата может оказаться чрезвычайно трудным, если проверяющая сторона не знает, какой именно сервер LDAP может ответить на потенциальный запрос поиска. Обычно проверяющая сторона, которая ищет сертификат другого объекта, хранит только частичный набор информации, идентифицирующий целевой объект: адрес электронной почты или просто имя хоста. В свою очередь резолверы (англ. resolver), программы, которые извлекают информацию с серверов имен в ответ на запросы клиентов, могут анализировать все дерево DNS (используя ссылки от промежуточных серверов имен), чтобы найти авторитетный сервер.

В настоящее время реализации серверов LDAP позволяют администраторам настраивать переходы на другие серверы LDAP в тех случаях, когда запросы поступают для данных вне авторитетного домена. Однако до сих пор не реализована глобальная инфраструктура LDAP (как в случае с DNS) и нет глобального стандарта, предназначенного для связи серверов LDAP друг с другом. Поэтому конечный объект, имеющий лишь небольшую часть информации о своем партнере, будет иметь проблемы при определении авторитетного сервера LDAP, который может предоставить сертификат партнера. Таким образом, в LDAP трудно обнаружить полномочия, и это невозможно сделать динамическим и простым способом (как в настоящее время это делается в DNS). Более того, разделение информационного дерева каталогов возможно в LDAP, но разбиение дерева обычно приводит к неравномерному распределению данных, и каждый запрос все равно должен проходить через корень дерева. Таким образом, поиск в дереве всегда будет ограничен производительностью любого отдельного сервера каталогов.

Производительность

Проведённый анализ вышеупомянутыми исследователями из Туринского политехнического университета привёл также к следующим аргументам в пользу подхода на основе DNS. Запрос LDAP всегда будет требовать соединения TCP, поэтому издержки протокола TCP всегда будут присутствовать с присущей ему задержкой. С другой стороны DNS способен работать как по TCP, так и по UDP. Преимущество использования UDP состоит в том, что клиент всегда делает один запрос и получает один ответ. В ходе практических испытаний, выполненными исследователями, было замечено, что запрос на основе DNS выполняет меньше циклов, чем запрос на основе LDAP, даже если запрос на основе DNS производился через TCP.

Традиционно размер сообщений DNS в UDP ограничивался максимальным размером 512 байт. Ограничение в 512 байт было введено в первую очередь для уменьшения вероятности фрагментации ответов DNS. В последнее время были предприняты усилия для повышения производительности DNS-серверов имен для поддержки DNS-сообщений размером более 512 байт. Механизм расширения DNS EDNS0 [13] позволяет резолверам сообщать серверам имен, что они могут обрабатывать ответы DNS размером более 512 байт. Таким образом, если ожидаемый ответ находится между 512 октетами и максимальным размером, который может принять клиент, то можно избежать дополнительных издержек соединения TCP. Используя этот механизм расширения в серии тестов, было замечено, что DNS может без проблем использовать UDP для сообщений DNS длиной до 4096 байт в сети Ethernet.

Предполагаемые трудности реализации

Помимо продемонстрированных преимуществ подхода на основе DNS, исследователи из Туринского Политехнического Университета отмечают также возможные проблемы, которые могут возникнуть в ходе реализации данного подхода. Во-первых, переход от характерных имен X.500 к DNS-именам не всегда так прост, как в проведённых исследователями экспериментах. Во-вторых, известно, что брандмауэры вмешиваются в протокол UDP (даже если предполагается, что трафик DNS будет разрешен), следовательно, может случиться так, что иногда запросы и ответы DNS будут блокироваться.

Кроме того, более ранний анализ подхода поддержки PKI, основанного на использовании DNS, выполненный исследователем из организации CommerceNet, показал, что способность реализаций данного подхода к масштабируемости не определена. Также он отмечает, что использование DNS в качестве системы распространения и управления открытым ключом потребует внесения изменений в прикладные программы.

Ссылки

• Криптосистема с открытым ключом