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 использует внешние модули для поиска ключей и пересылки писем. В данной схеме определяется основной набор компонентов, необходимый для развертывания, включающий в себя DNS и SMTP.
Как показано на рисунке, основой процесс обработки писем разделён на две части: создание ЭЦП письма и её проверка.
Когда случается, что письмо имеет более одной подлинной ЭЦП, то порядок, в котором применяются инструкции на основании информации о доменах, которым принадлежат данные подписи, уже определяется вне технологии 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 будут легальными, но в этом случае домены с такого сервера быстро заработают "штрафные баллы" и в дальнейшем будут блокированы спам-фильтром.
Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".
Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.
Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .