Movatterモバイル変換


[0]ホーム

URL:


Перейти до вмісту
Вікіпедія
Пошук

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=passReceived: 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 біт, оскільки більший за довжиною ключ не поміститься у максимальний розмір DNSUDP-пакета — 512 байтів. Рекомендована довжина ключа становить від 1024 до 2048 біт. Занадто велика довжина створює обчислювальне навантаження на сервер, для обробки кожного повідомлення, а надто мала (384 або 512 біт) — зламується перебором за актуальний час за допомогою ПК або з використанням сервісу хмарних обчислень.

Дана технологія сумісна з існуючою структурою мереж і не вимагає докорінної зміни сервісів (крім налаштування SMTP) і змінипротоколів, тому може бути введена поступово. Повідомлення, підписане DKIM є повністю «автономномне», функціонування DKIM не залежить відPKI або яких-небудь служб, оскільки ключ береться безпосередньо з DNS-запису і не повинен підтверджуватися чим-небудь. Організація, яка використовує DKIM, повністю несе відповідальність за роботу свого сервера, наявність ЕЦП означає лише те, що хтось відповідає за конкретне повідомлення.

Обмеження

[ред. |ред. код]

В описі даної технології розробники підкреслюють, що наявність ЕЦП в повідомленні ні до чого не зобов'язує приймаючу сторону, не забезпечує захист після перевірки підпису і не може ніяк вплинути у разі повторної передачі повідомлення, якщо відправник і одержувач змінилися. ТомуRFC рекомендують повідомлення зі звичайних серверів, які не підтримують DKIM, обробляти стандартним чином.

Слід зазначити, що ніхто не заважає спамеру створити свій SMTP-сервер, з підтримкою DKIM, іDNS-сервер, які з точки зору DKIM будуть легальними, але в цьому випадку домени з такого сервера швидко отримають «штрафні бали» і надалі будуть заблоковані спам-фільтром.

Див. також

[ред. |ред. код]

Посилання

[ред. |ред. код]
Отримано зhttps://uk.wikipedia.org/w/index.php?title=DomainKeys_Identified_Mail&oldid=43583921
Категорії:
Прихована категорія:

[8]ページ先頭

©2009-2026 Movatter.jp