DomainKeys Identified Mail

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

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

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

История

Проект DomainKeys начала компания Yahoo (20 мая 2004 была опубликована первая версия спецификации DomainKeys), а проект Identified Internet Mail инициировала Cisco Systems. Около года неформальное объединение из десятка организаций, включая Yahoo, Cisco, EarthLink Inc., Microsoft Corp., PGP Corp., StrongMail Systems Inc., VeriSign Inc. и 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=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.

Почтовый сервер, который выполняет подпись данного сообщения, должен иметь доступ к закрытому ключу, который связан с значением "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