DomainKeys Identified Mail
DomainKeys Identified Mail — метод E-mail аутентификации, разработанный для обнаружения подделывания сообщений, пересылаемых по email. Метод дает возможность получателю проверить, что письмо действительно было отправлено с заявленного домена[1]. 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.
Как показано на рисунке, основой процесс обработки писем разделён на две части: создание ЭЦП письма и её проверка.
- Подпись письма
- Процесс создания ЭЦП и её добавление в письмо осуществляется внутренним доверенным модулем 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 будут легальными, но в этом случае домены с такого сервера быстро заработают "штрафные баллы" и в дальнейшем будут блокированы спам-фильтром.
См. также[править | править код]
Примечания[править | править код]
Ссылки[править | править код]
- Domain Keys Identified Mail (DKIM)
- IETF DKIM working group (started 2006)
- RFC 4871 — The DKIM Base Specification
- RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
В другом языковом разделе есть более полная статья DomainKeys Identified Mail (англ.). |