域密鑰識別郵件技術(shù)綜述

摘要：介紹了DKIM的基本概念和框架結(jié)構(gòu)，分析了DKIM的工作原理，并且重點討論了DKIM面臨的威脅以及發(fā)展前景。

關(guān)鍵詞：域密鑰識別郵件;垃圾郵件;域名;認證

中圖分類號：TP393．08文獻標(biāo)志碼：A

文章編號：1001－3695(2008)01－0033－04

隨著互聯(lián)網(wǎng)的發(fā)展，電子郵件早已成為人們彼此互通信息最主要的工具之一。然而目前垃圾郵件約占據(jù)全部郵件總數(shù)的88%之多。其所引發(fā)的網(wǎng)絡(luò)頻寬負荷，以及病毒、網(wǎng)絡(luò)釣魚攻擊等事件的嚴重性是非常巨大的。由于垃圾郵件多半采用隱藏真實發(fā)信來源地址的技術(shù)，不但很難找出真正的來源地址，而且垃圾郵件發(fā)信者常常冒用許多公司、銀行的名義來發(fā)送內(nèi)藏有網(wǎng)絡(luò)釣魚(phishing)或后門程序(backdoor)的垃圾郵件，造成個人重要信息被竊取，甚至淪為垃圾郵件發(fā)送僵尸以及遠端遙控的跳板。在這種情況下，電子郵件驗證技術(shù)就顯得尤為重要。本文所介紹的DKIM技術(shù)就是其中的一種。

1DKIM背景與基本概念 

一直以來，許多知名廠商均在建立電子郵件驗證技術(shù)。其中最著名的包括Yahoo的 DomainKeys技術(shù)、微軟的SenderID技術(shù)與思科系統(tǒng)的identified internet mail技術(shù)。其中，DomainKeys技術(shù)受到SBC、英國電信與Google Gmail的支持;而MSN Hotmail、AOL、美國銀行及eBay皆響應(yīng)SenderID技術(shù)。微軟曾一度打算說服IETF工作小組通過SenderID技術(shù)成為業(yè)界標(biāo)準(zhǔn)，最后卻因為各家擔(dān)心全球通用的技術(shù)為一家完全壟斷而使微軟的愿望落空。如今，由Yahoo與思科系統(tǒng)合作發(fā)表的DKIM技術(shù)，既結(jié)合兩家各自的技術(shù)，也不會有壟斷于一家的爭議。DKIM技術(shù)是現(xiàn)階段在IETF內(nèi)部討論的方案，并且有望在今后成為國際標(biāo)準(zhǔn)。

域密鑰識別郵件定義了一種機制，通過對郵件信息加密并簽名，從而允許實施簽名的域名對將該郵件引入郵件傳輸流負責(zé)[1]。郵件接收者可以通過直接查詢簽名者的域名得到相應(yīng)的公共密鑰，進而校驗郵件的簽名，以此驗證郵件是否屬于擁有簽名域名的私有密鑰的一方。DKIM允許一個機構(gòu)對郵件負責(zé)。這個負責(zé)的機構(gòu)是一個郵件傳輸過程中的處理者，可以是郵件的發(fā)起者或中介。負責(zé)的機構(gòu)在郵件中添加一個數(shù)字簽名，并把這個簽名與機構(gòu)的一個域名相關(guān)聯(lián)。通常，簽名會由一個服務(wù)代理在郵件發(fā)起人的行政管理域（ADMD）的授權(quán)下，由這個環(huán)境中的任何一個功能組件來執(zhí)行，包括郵件客戶端 (MUA)、郵件提交代理 (MSA)、網(wǎng)界郵件傳輸代理（MTA）。DKIM 也允許簽名由授權(quán)第三方來進行。郵件簽名后，在郵件傳輸途徑中的任何代理均可被選擇用來執(zhí)行對簽名的驗證。通常驗證會由郵件接收者的行政管理域代理完成。與簽名時相同，可以由這個環(huán)境中的任何功能組件來完成。特別地，這樣意味著簽名可以由郵件接收者的行政管理域的過濾軟件來處理，而不是要求郵件接收者的用戶終端來進行判斷。用來進行數(shù)字簽名的域名所有者是以其信譽為基礎(chǔ)的。接收者成功驗證簽名后可以利用簽名者的身份信息作為限制垃圾郵件、欺騙、釣魚網(wǎng)站或其他不受歡迎行為的軟件的一部分。

2DKIM特點

基于對DKIM概念的介紹，可以發(fā)現(xiàn)DKIM利用以下幾點定義了一個郵件認證機制：公共密鑰加密、基于DNS的公共密鑰發(fā)布服務(wù)、域名標(biāo)志符。

DKIM所采用的途徑與傳統(tǒng)的郵件簽名方法（如S/MIME[2]、OpenPGP[3]）相比，有以下一些主要特點：

a)DKIM 不修改郵件正文，而是將郵件簽名參數(shù)信息放在一般不顯示給接收者的郵件頭部。S/MIME和OpenPGP同時要求對郵件正文進行修改，將正文部分作為MIME類型進行封裝。因此簽名郵件對于軟件不支持DKIM的終端用戶是透明的，而不像S/MIME和OpenPGP由于修改了正文會造成郵件內(nèi)容在不支持協(xié)議的客戶端上無法識別。

b)沒有對分發(fā)公有/私有密鑰對的可信證書權(quán)威的依賴。簽名程序要求一定級別確保驗證時采用的公共密鑰是與聲稱的簽名者相關(guān)聯(lián)。許多程序通過一個可信第三方的證書授予來實現(xiàn)這一點。但是由于DKIM的使用范圍有限，并不需要通用的、強大的、長期的由獨立權(quán)威頒發(fā)的證書。DKIM通過使驗證者簡單地向簽名者的DNS發(fā)出查詢來獲取公共密鑰，實現(xiàn)了一個足夠的安全級別。這樣就使得它使用的成本更低。

c)沒有對任何新的有關(guān)公共密鑰分發(fā)撤回的互聯(lián)網(wǎng)協(xié)議或服務(wù)部署的依賴。現(xiàn)在已經(jīng)定義的是一種單一綁定的利用DNS TXT記錄來分發(fā)密鑰，其他的方式可能會在以后被定義。

d)DKIM是基于域名的，而不是整個郵件地址。簽名是由域名的管理者控制而不是單獨的郵件用戶。

e)簽名的校驗失敗不會導(dǎo)致郵件被拒絕。DKIM沒有規(guī)定收件人必需的操作，可以將對郵件的判斷提交給郵件過濾的其他組件。

f)機制中不包括加密算法。DKIM支持多種數(shù)字簽名算法。目前主要采用的是RSA SHA[4，5]。可以隨著算法的進步而采用新的加密算法。

g)存檔并不是設(shè)計目標(biāo)。DKIM是為了滿足郵件傳輸認證的短期需求。

3DKIM架構(gòu)

圖1給出了DKIM系統(tǒng)的基本框架。首先簽名者需要在相應(yīng)的代理處增加代碼執(zhí)行簽名并且需要修改DNS管理工具以允許創(chuàng)建DKIM密鑰記錄。被簽名的郵件通過網(wǎng)絡(luò)傳輸?shù)津炞C者。驗證者需要在相應(yīng)的代理處增加代碼執(zhí)行驗證并且將結(jié)果提供給郵件部署系統(tǒng)需要的部分，如過濾引擎。因為僅僅是經(jīng)過驗證的簽名并不能夠表示郵件是可以接收的，仍然需要轉(zhuǎn)送給其他評估階段。在評估階段簽名的有效性以及簽名域名的信譽均可能成為評估的條件，但是DKIM并不對評估行為進行定義。

郵件的簽名儲存在DKIM Signature頭部域。這個部分包括所有的簽名以及提供給驗證者獲取密鑰的相關(guān)屬性。

在DKIM簽名部分包括的主要屬性信息有a表示產(chǎn)生簽名所采用的算法；i表示用戶或者代理的標(biāo)志符；

c表示正文規(guī)范化的方法；d表示簽名實體的域名；s表示選擇器用來細分域名；h表示在郵件頭中選定的用于產(chǎn)生簽名的部分；l表示選去郵件正文的截斷長度；b表示郵件頭部數(shù)字簽名的內(nèi)容；bh表示郵件數(shù)字簽名的內(nèi)容；q表示得到公共密鑰的查詢方式。

3．1簽名者動作

1)判斷郵件是否應(yīng)該加密簽名者只應(yīng)該對含有私有公有密鑰對以及選擇器信息的域名所負責(zé)的郵件加密。除了缺少上述條件外，也有一些其他的原因使得簽名者選擇不對郵件簽名。

2)選擇一個私有密鑰和相應(yīng)選擇器選擇器用來在同一個管理域名下實現(xiàn)多重密鑰。這可以給為域名擁有者工作的部門、數(shù)據(jù)區(qū)域或第三方提供各自的簽名管理。驗證者利用選擇器作為一個附加的域名部分，用來劃分DNS查詢的域名。在同一個域名下，不同的選擇器代表不同的DKIM DNS記錄。DKIM并不規(guī)定簽名者應(yīng)該根據(jù)什么來選擇哪個密鑰和選擇器信息。就目前來講，DKIM規(guī)范對待所有的選擇器都是一樣的。所以采用選擇器時考慮的重點可能是管理上的方便。在加密者對郵件頭的選定部分利用私有密鑰加密之后，一個選擇器被指定為DKIM簽名的一個屬性記錄在DKIM簽名的頭部域，用來向驗證者提供找到DKIM的公共密鑰的信息。

3)規(guī)范化對于一些郵件，尤其是使用8 bit字符的郵件，在傳輸過程中容易被修改，如被轉(zhuǎn)換成7 bit的形式。這種轉(zhuǎn)換會破壞DKIM簽名。為了將這種破壞的可能性最小化，簽名者應(yīng)該在簽名前將郵件內(nèi)容轉(zhuǎn)換成一種合適的MIME傳輸編碼[6]。實際上這種轉(zhuǎn)換并不是DKIM的范疇，而是應(yīng)該在郵件傳送給DKIM算法之前由MUA或MSA進行處理。

如果傳送給簽名者的郵件包含任何在傳輸過程中會被修改的本地編碼，那么在簽名前必須進行規(guī)范化修改[7]。特別是單獨的CR或LF（有些系統(tǒng)中用于本地換行符）必須在簽名之前轉(zhuǎn)換為SMTP標(biāo)準(zhǔn)的CRLF序列。對于修改有兩種不同的態(tài)度。對大多數(shù)簽名者，適度地修改郵件對于郵件認證有效性的狀態(tài)不會有實質(zhì)性的影響，因此簽名者傾向于采用能夠經(jīng)受傳輸中適當(dāng)修改的規(guī)范化算法。其他一些簽名者要求對郵件的任何修改均會導(dǎo)致簽名的認證失敗。這樣的簽名者要采用的簽名算法不能容忍簽名郵件在傳輸過程中的任何修改。一些簽名者可能會接收在郵件標(biāo)準(zhǔn)下[7]對郵件頭部域的修改但是不愿意接收對郵件正文的任何修改。

為了滿足各種需求，郵件頭部和郵件正文定義了兩種規(guī)范化算法。一種簡單算法不允許傳輸過程中對郵件作任何修改；另一種不嚴格算法允許普通的修改，如空格的替換和郵件頭部的重新封裝。簽名者可以對郵件頭部或正文指定任意一種規(guī)范化算法，如果沒有指定，郵件頭部和正文的簡單算法為默認。

簽名者可以選擇簽名郵件正文的長度。實際上進行簽名的郵件正文長度應(yīng)插入到DKIM簽名頭部的l屬性中。因此在規(guī)范化中，簽名者根據(jù)c屬性中指定的算法和l屬性中指定的截斷長度來進行規(guī)范化。規(guī)范化只是用來對郵件內(nèi)容進行調(diào)整以方便簽名或驗證，而并不對郵件的傳輸產(chǎn)生任何影響。

4)決定郵件頭部要加密的部分郵件頭部的from域是必須被簽名的；同時可以選擇任何其他在簽名時存在的頭部域。簽名者不應(yīng)該對有可能在傳輸過程中被合法修改和去除的域進行簽名，尤其是在郵件協(xié)議中被明確允許修改或去除的return path郵件頭部域[8]。

DKIM簽名頭部域隱含規(guī)定為必須被簽名的，并且不能被添加在h屬性中。除非為了表明其他已經(jīng)存在的DKIM簽名也再次被簽名。簽名者可以聲稱對不存在的郵件頭部域進行了簽名（在h屬性中包含的郵件頭部域在郵件中并不存在）。當(dāng)計算簽名時，不存在的郵件頭部域必須被當(dāng)做空字符串來處理。

5)簽名簽名郵件簽名的第一步是通過hash算法計算郵件的兩個hash值。一個是對郵件正文；另一個是對郵件頭部選擇的部分。簽名者必須按照這個順序計算hash值，而驗證者可以按照任意方便的順序。首先，簽名者對規(guī)范化后的郵件正文進行hash，其結(jié)果被轉(zhuǎn)換為base64形式插入到DKIM簽名頭部的bh屬性；然后，簽名者根據(jù)h屬性所指定的要進行簽名的郵件頭部域以及順序，對已經(jīng)規(guī)范化的郵件頭部進行hash，以base64形式插入到b屬性。簽名者第二步通過選定的RSA算法(實際上是 PKCS#1[9])采用簽名者的私有密鑰對得到的hash值進行加密簽名。

6)插入DKIM簽名頭部簽名者必須在傳輸郵件之前插入DKIM簽名頭部域。關(guān)鍵字DKIM Signature必須在所有DKIM簽名屬性插入前寫入郵件頭部。

3．2驗證者動作

1)確認簽名頭部域驗證者必須確認DKIM簽名頭部域的格式和值的有效性。如果存在任何不一致和未知數(shù)值以及缺少必需的屬性，頭部域均會整體被忽略并且驗證者返回PERMFAIL(簽名語法錯誤)。但是在DKIM簽名頭部域存在未知的額外屬性是允許的。

2)獲得公有密鑰驗證簽名需要得到簽名的公共密鑰。獲得公共密鑰的方法依賴于DKIM簽名頭部域中的q屬性定義的查詢類型。目前主要是查詢簽名者域名的TXT RR記錄。

密鑰查詢算法的參數(shù)是查詢類型（q屬性）、簽名者的域名（d屬性）和選擇器（s屬性）：public_key=dkim_find_key(q_val，d_val， s_val)[1]。

3)計算驗證給定一個簽名者和公共密鑰。驗證首先根據(jù)c屬性定義的規(guī)范化算法、l屬性定義的郵件正文簽名長度和h屬性定義的郵件頭部簽名部分，對郵件進行規(guī)范化處理。根據(jù)a屬性定義的算法以及得到的公共密鑰，計算規(guī)范化后的郵件加密hash值；然后驗證郵件正文的加密hash值是否與bh屬性所傳遞的hash值相同。類似地，利用a屬性定義的算法和公共密鑰值，根據(jù)郵件頭部的hash值驗證b屬性傳遞的簽名。

4)傳遞驗證結(jié)果驗證者希望通過任何合適的方法將驗證結(jié)果傳遞給郵件系統(tǒng)的其他部分。比如在向郵件添加一個郵件頭部。所有這種頭部應(yīng)該插入到任何存在的DKIM簽名或已經(jīng)存在的驗證狀態(tài)頭部域之前。

4舉例

用一個例子來簡單介紹DKIM的流程。原始郵件頭如下：

From:Simple Wsimple@football.example.com

To:Julyseven X julyseven@shopping.example.net

Subject:Je t′aime

Date:Wed，18 Oct 2006 21:00:00－0700 (PDT)

Message ID:20061018040037@football.example.com

加密傳輸后，在郵件頭部添加了DKIM簽名域，驗證者得到的郵件頭如下：

From: Simple Wsimple@football.example.com

To:Julyseven Xjulyseven@shopping.example.net

Subject:Je t′aime

Date:Wed， 18 Oct 2006 21:00:00－0700 (PDT)

Message ID:20061018040037@football.example.com

DKIM Signature:

a=rsa sha256;s=dalian;d=example.com;c=simple;q=dns/txt;

i=simple@football.example.com; 

h=Received:From:To:Subject: Date:Message ID;

bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=;

b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR;

Received: from dsl 10.2.3.4.football.example.com[10.2.3.4]

by server.example.com with SUBMISSION;

Wed， 18 Oct 2006 21:00:45－0700 (PDT)

在這個例子中，驗證程序利用從“d=”標(biāo)記中提取的域名“example.com”，以及從“s=”標(biāo)記中提取的選擇器“dalian”形成了一個DKIM查詢：dalian._domainkey.example.com。

簽名的驗證結(jié)果儲存在“Authentication Results”頭部中。經(jīng)過驗證成功，郵件被轉(zhuǎn)換成：

X Authentication Results: shopping.example.net

header.from=simple@football.example.com; dkim=pass

Received: from mout23.football.example.com (192.168.1.1)

by shopping.example.net with SMTP;

DKIM Signature:

a=rsa sha256;s=dalian;d=example.com;c=simple;q=dns/txt;

i=simple@football.example.com; 

h=Received:From:To:Subject:Date:Message ID;

bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=;

b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR;

Received: from dsl 10.2.3.4.football.example.com [10.2.3.4]

by server.example.com with SUBMISSION;

From:Simple Wsimple@football.example.com

To:Julyseven Xjulyseven@shopping.example.net

Subject:Je t′aime

Date:Wed，18 Oct 2006 21:00:00－0700 (PDT)

Message ID:20061018040037.46341.5F8J@football.example.com

5DKIM面臨的威脅和發(fā)展前景

就像其他任何試圖阻止垃圾郵件傳播的機制一樣，DKIM也會受到各種攻擊。一方面有針對DKIM協(xié)議本身的攻擊，比如錯誤的郵件長度限制（l屬性）、錯誤的私有密鑰、DKIM簽名頭部域格式錯誤等無意或有意的屬性賦值錯誤，均可能造成的認證失敗；另一方面，DKIM機制所依賴的DNS服務(wù)本身也具有很多不安全的因素[12]。各種針對DNS的攻擊均有可能使得DKIM簽名失效甚至被偽造。對于這些可能的攻擊，DKIM工作組發(fā)表了針對各種攻擊行為的分析[10]。如何完善DKIM協(xié)議以應(yīng)對對于協(xié)議本身的攻擊也是DKIM今后改進的重要內(nèi)容。對于通過DNS服務(wù)所進行的攻擊，已經(jīng)超出了DKIM本身所考慮的范疇。因此DKIM一方面寄希望于DNSSEC[13]的出現(xiàn)和使用解決現(xiàn)有的一部分問題；另一方面DKIM的設(shè)計初衷認為各種通過DNS的針對DKIM的攻擊行為相對于攻擊建立在DNS基礎(chǔ)上的其他應(yīng)用成本高且回報很少。想要系統(tǒng)性地威脅DKIM的設(shè)計目標(biāo)，攻擊者必須在DNS服務(wù)的多個部分進行長時間高成本的攻擊。這種行為的非經(jīng)濟性會在某種程度上阻止對DKIM的攻擊。

DKIM只是為了實現(xiàn)一定程度上足夠的認證，而并不是為了提供一種強大的加密認證機制[10]。這種在安全性上的不完全可靠，對于網(wǎng)絡(luò)釣魚等涉及隱私程度高可能造成巨大損失的欺騙行為，DKIM所得出的結(jié)論是具有風(fēng)險和不可信賴的。因此DKIM的主要應(yīng)用前景是在即使被攻擊或認證失敗也不會有很大損失的反垃圾郵件等低危險性領(lǐng)域。在反垃圾郵件方面，DKIM能夠有效地限制垃圾郵件發(fā)送者盜用其他機構(gòu)或域名的名義，為郵件過濾提供鑒別手段，并且能夠在現(xiàn)有郵件體系下快速進行低成本的部署。IETF DKIM工作組正在致力于完善DKIM協(xié)議，積極推動DKIM草案成為正式的RFC標(biāo)準(zhǔn)，并且已經(jīng)取得了階段性的成果。在開發(fā)部署上面，已經(jīng)有Sendmail、Postfix、Apache等多家公司和組織參與開發(fā)了可用的穩(wěn)定版本，并且正在繼續(xù)進行改進和標(biāo)準(zhǔn)化工作。

6結(jié)束語

本文以基于DKIM的框架結(jié)構(gòu)為主，分析了DKIM技術(shù)的概念、流程和發(fā)展趨勢。雖然DKIM技術(shù)還處在發(fā)展中，尚未形成標(biāo)準(zhǔn)，但是它已經(jīng)能夠在反垃圾郵件的工作中起到一定的積極作用，值得關(guān)注。國內(nèi)目前關(guān)于DKIM的介紹還不是很多，希望本文系統(tǒng)化的介紹和分析能夠?qū)Ψ蠢]件工作提供一些參考。

參考文獻：

［1］ALLMAO E，CALLAS J，DELAOY M，et al.Domain keys identified mail(DKIM) signatures[S].[S.l.]:IETF，2006.

[2]GALVIN J，MURPHY S，CROCKER S，et al.RFC 1847， Security multiparts for MIME:multipart/signed and multipart/encrypted[S].[S.l.]:IETF，1995.

[3]CALLAS J，DONNERHACKE L，F(xiàn)INNEY H，et al.RFC 2440， OpenPGP message format[S].[S.l.]:IETF，1998.

[4]National Institute of Standards and Technology.NIST FIPS PUB 186:digital signature standard[S].[S.l.]:Department of Commerce，1994.

[5]RIVEST R L，SHAMIR A，ADLEMAN L M.A method of obtaining digital signatures and public key cryptosystems[J].Communications of the ACM，1978，21(2):120 126.

[6]FREED N，BORENSTEIN N.RFC 2045， Multipurpose Internet mail extensions (MIME) part one:format of Internet message bodies[S].[S.l.]:IETF，1996.

[7]RESNICK P.RFC 2822， Internet message format[S].[S.l.]:IETF，2001.

[8]KLENSIN J.RFC 2821， Simple mail transfer protocol[S].[S.l.]:IETF，2001.

[9]JONSSON J，KALISKI B.RFC 3447， Public key cryptography stan dards (PKCS) #1: RSA cryptography specifications version 2.1[S].[S.l.]:IETF，2003.

[10]FENTON J.RFC 4686， Analysis of threats motivating domain keys identified mail (DKIM)[S].[S.l.]:IETF，2006.

[11]HANSEN T，CROCKER D，HALLAM BAKER P.DomainKeys identified mail(DKIM) service overview[S].[S.l.]:IETF，2006.

[12]ATKINS D， AUSTEIN R.RFC 3833， Threat analysis of the domain name system (DNS)[S].[S.l.]:IETF， 2004.

[13]ARENDS R， AUSTEIN R， LARSON M，et al.RFC 4033， DNS security introduction and requirements[S].[S.l.]:IETF，2005.

[14]THOMAS M.Requirements for a DKIM signing practices protocol[S].[S.l.]:IETF，2006.

[15]ALLMAN E，DELANY M，F(xiàn)ENTON J.DKIM sender signing practices[S].[S.l.]:IETF，2006.

“本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文”