域密鑰識別郵件技術綜述

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

關鍵詞：域密鑰識別郵件;垃圾郵件;域名;認證

中圖分類號：TP393．08文獻標志碼：A

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

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

1DKIM背景與基本概念 

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

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

2DKIM特點

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

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

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

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

c)沒有對任何新的有關公共密鑰分發撤回的互聯網協議或服務部署的依賴?，F在已經定義的是一種單一綁定的利用DNS TXT記錄來分發密鑰，其他的方式可能會在以后被定義。

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

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

f)機制中不包括加密算法。DKIM支持多種數字簽名算法。目前主要采用的是RSA SHA[4，5]?？梢噪S著算法的進步而采用新的加密算法。

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

3DKIM架構

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

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

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

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

3．1簽名者動作

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

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

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

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

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

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

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

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

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

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

3．2驗證者動作

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

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

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

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

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

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=”標記中提取的域名“example.com”，以及從“s=”標記中提取的選擇器“dalian”形成了一個DKIM查詢：dalian._domainkey.example.com。

簽名的驗證結果儲存在“Authentication Results”頭部中。經過驗證成功，郵件被轉換成：

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面臨的威脅和發展前景

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

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

6結束語

本文以基于DKIM的框架結構為主，分析了DKIM技術的概念、流程和發展趨勢。雖然DKIM技術還處在發展中，尚未形成標準，但是它已經能夠在反垃圾郵件的工作中起到一定的積極作用，值得關注。國內目前關于DKIM的介紹還不是很多，希望本文系統化的介紹和分析能夠對反垃圾郵件工作提供一些參考。

參考文獻：

［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，FINNEY 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，FENTON J.DKIM sender signing practices[S].[S.l.]:IETF，2006.

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