DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) — метод e-mail-аутентификации, разработанный для обнаружения подделки электронных писем. Метод даёт возможность получателю убедиться, что письмо действительно было отправлено с заявленного домена. DKIM упрощает борьбу с поддельными адресами отправителей, которые часто используются в фишинговых письмах и в почтовом спаме.

Технология объединяет несколько существующих методов антифишинга и антиспама для повышения качества классификации и идентификации легитимной электронной почты. Вместо IP-адреса, для определения отправителя сообщения DKIM добавляет в него цифровую подпись, связанную с именем домена организации. Подпись автоматически проверяется на стороне получателя, а затем для определения репутации отправителя применяются «белые списки» и «чёрные списки».

В технологии DomainKeys для аутентификации отправителей используются доменные имена, также она использует существующую систему доменных имен (DNS) для передачи открытых ключей шифрования.

История

Проект DomainKeys был запущен компанией Yahoo (20 мая 2004 была опубликована первая версия спецификации DomainKeys), а проект Identified Internet Mail инициировала Cisco Systems. Около года неформальное объединение из десятка организаций, включая Yahoo, Cisco, EarthLink, Microsoft, PGP Corporation, StrongMail Systems, VeriSign и Sendmail Inc, работало над созданием новой спецификации DKIM. В июле 2005 года она была передана в IETF для рассмотрения в качестве нового стандарта e-mail с целью борьбы с фишингом и спамом.

Структура DKIM

DKIM использует внешние модули для поиска ключей и пересылки писем. В данной схеме определяется основной набор компонентов, необходимый для развёртывания, включающий в себя DNS и SMTP.

Структура DKIM

Как показано на рисунке, основой процесс обработки писем разделён на две части: создание ЭЦП письма и её проверка.

Подпись письма

Процесс создания ЭЦП и её добавление в письмо осуществляется внутренним доверенным модулем ADMD (Administrative Management Domain), который использует извлечённый из хранилища закрытый ключ, созданный на основе информации о письме. В качестве ADMD могут выступать почтовый клиент (MUA — Mail User Agent) или почтовый сервер (MTA — Mail Transfer Agent).

Проверка ЭЦП письма

Верификация ЭЦП также выполняется доверенным модулем ADMD. Данный процесс может выполняться как на почтовом сервере, так и на стороне клиента. Этот модуль проверяет подлинность при помощи открытого ключа и определяет, требуется ли вообще подпись. Если подлинность ЭЦП подтверждена, то письмо вместе с информацией о «репутации» автора передаётся в фильтр сообщений, в котором принимается решение о том, является ли данное письмо спамом. Если для данного домена ЭЦП в письме отсутствует или не проходит проверку подлинности, то письмо передаётся в фильтр сообщений вместе с дополнительными инструкциями (например штрафными баллами для анти-спам фильтра), полученными из локального или удалённого хранилища.

Если письмо обладает более чем одной подлинной ЭЦП, то порядок применения инструкции на основании информации о доменах, которым принадлежат данные подписи, определяется вне технологии DKIM.

Описание

Каждому сообщению, циркулирующему в DKIM-системе, присваивается ЭЦП, подтверждающая отправителя и гарантирующая, что подписанная часть не была изменена. Сам же процесс обмена похож на работу с PGP. Владелец домена генерирует пару ключей — открытый и закрытый. Закрытый ключ используется на SMTP-сервере для снабжения сообщения ЭЦП, которая передаётся в заголовке DKIM-Signature и содержит в себе информацию о домене отправителя. Пример исходного сообщения:

From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game.  Are you hungry yet?

Joe.

После процедуры создания ЭЦП, подготовленное к отправке сообщение принимает следующий вид:

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
       c=simple/simple; q=dns/txt; i=joe@football.example.com;
       h=Receivede: Fromo: ToT: Subjectc: Datet: Message-ID;
       bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
       b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
       4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
       KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
       4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
       by submit server.example.com with SUBMISSION;
       Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game.  Are you hungry yet?

Joe.

Почтовый сервер, выполняющий подпись данного сообщения, должен иметь доступ к закрытому ключу, который связан со значением «brisbane» тега «s=». Открытый ключ добавляется в txt-поле DNS-записи.

В процессе проверки ЭЦП из заголовка «DKIM-Signature» извлекаются домен «example.com», хранящийся в теге «d=», и значение тега переключения «s=» — «brisbane» для формирования запроса на проверку для «brisbane._domainkey.example.com» Проверка начинается с поля «Received», потом «From» и т. д. в порядке, указанном в теге «h=». Результат запроса и проверки в данном примере записывается в заголовок «X-Authentication-Results». После успешной проверки ЭЦП сообщение выглядит следующим образом:

X-Authentication-Results: shopping.example.net
    header.from=joe@football.example.com; dkim=pass
Received: from mout23.football.example.com (192.168.1.1)
    by shopping.example.net with SMTP;
    Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
    c=simple/simple; q=dns/txt; i=joe@football.example.com;
    h=Received : From : To : Subject : Date : Message-ID;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
      4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
      KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
      4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
    by submitserver.example.com with SUBMISSION;
    Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game.  Are you hungry yet?

Joe.

В DKIM используются уже устоявшиеся криптографические инструменты. На данный момент для цифровой подписи авторы DKIM предлагают два алгоритма: RSA-SHA256 и RSA-SHA1, но в будущем возможно расширение технологии для поддержки других алгоритмов. Длина ключа ограничена значением в 4096 бит, так как больший по длине ключ не поместится в максимальный размер DNS UDP-пакета — 512 байт. Рекомендованная длина ключа составляет от 1024 до 2048 бит. Слишком большая длина создает вычислительную нагрузку на сервер для обработки каждого сообщения, а слишком малая (384 или 512 бит) — взламывается перебором за актуальное время с помощью персонального компьютера или с использованием сервиса облачных вычислений.

Данная технология совместима с существующей структурой сетей и не требует коренного изменения сервисов (кроме настройки SMTP) и изменения протоколов, поэтому может быть введена постепенно. Сообщение, подписанное DKIM полностью «автономно», позволяет функционировать DKIM независимо от PKI или каких-либо служб, так как ключ берётся напрямую из DNS-записи и не должен подтверждаться чем либо. Организация, использующая DKIM, полностью несёт ответственность за работу своего сервера, а наличие ЭЦП означает лишь то, что кто-то отвечает за конкретное сообщение.

Ограничения

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

Спамер может создать свой SMTP-сервер с поддержкой DKIM и DNS-сервер, которые с точки зрения DKIM будут легальными, но в этом случае домены с такого сервера быстро заработают «штрафные баллы» и в дальнейшем будут блокированы спам-фильтром.

См. также

• Sender Policy Framework (SPF)
• DMARC
• S/MIME
• PGP

Ссылки

• Domain Keys Identified Mail (DKIM)
• IETF DKIM working group (started 2006)
• RFC 4871 — The DKIM Base Specification
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures