DomainKeys Identified Mail
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=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» Перевірка починається з поля «From», потім «To» і так далі, в порядку зазначеному в тезі "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=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 будуть легальними, але в цьому випадку домени з такого сервера швидко отримають «штрафні бали» і надалі будуть заблоковані спам-фільтром.