DomainKeys Identified Mail

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

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

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

В технологии DomainKeys, являющейся основой DKIM, для аутентификации отправителей используются доменные имена, также она использует существующую систему доменных имен (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, полностью несёт ответственность за работу своего сервера, а наличие ЭЦП означает лишь то, что кто-то отвечает за конкретное сообщение.

Ограничения[править | править код]

DKIM имеет следующие недостатки и ограничения технологии[1]:

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

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

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

См. также[править | править код]

Примечания[править | править код]

  1. ↑ 1 2 Hansen, T. DomainKeys Identified Mail (DKIM) Service Overview : RFC 5585 / T. Hansen, D. Crocker, P. Hallam-Baker. — IETF, 2009. — Июль. — 24 p.

Ссылки[править | править код]

Источник — https://ru.wikipedia.org/w/index.php?title=DomainKeys_Identified_Mail&oldid=136867839