域密钥识别邮件技术综述 - 中国互联网络信息中心

第25卷第1期2008年1月计算机应用研究App licati on Research of Computers Vol . 25, No . 1Jan .2008域密钥识别邮件技术综述王昕溥1, 2

第25卷第1期2008年1月

计算机应用研究

App licati on Research of Computers Vol . 25, No . 1Jan .

2008

域密钥识别邮件技术综述

王昕溥

1, 2

, 姚健康, 李晓东, 王　峰, 毛　伟

1111

(1. 中国科学院计算机网络信息中心, 北京100080; 2. 中国科学院研究生院, 北京100049)

摘　要:介绍了DKI M 的基本概念和框架结构, 分析了DKI M 的工作原理, 并且重点讨论了DKI M 面临的威胁以及发展前景。

关键词:域密钥识别邮件; 垃圾邮件; 域名; 认证

中图分类号:TP393108　　　文献标志码:A 　　　文章编号:100123695(2008) 0120033204

Survey of domain keys identified mail

WANG Xin 2pu

Sciences, B eijing 100049, China )

1, 2

, Y AO J ian 2kang , L I Xiao 2dong , WANG Feng , MAO W ei

1111

(1. Co m puter N et w ork Infor m ation Center , Chinese A cade m y of Sciences, B eijing 100080, China; 2. Graduate School, Chinese A cade m y of

Abstract:This paper intr oduced the concep ti on and fra me work of DKI M , expatiating the working fl ow with exa mp les and dis 2

cussed threats and the p r os pect of DKI M . Key words:DKI M (domain keys identified mail ) ; s pa m mail; DNS; authenticati on

　　随着互联网的发展, 电子邮件早已成为人们彼此互通信息最主要的工具之一。然而目前垃圾邮件约占据全部邮件总数的88之多。其所引发的网络频宽负荷, 以及病毒、网络钓鱼攻击等事件的严重性是非常巨大的隐藏真实发信来源地址的技术, 址, 送内藏有网络钓鱼() (backdoor ) 的垃圾邮件, , 甚至沦为垃圾邮件发送僵尸以及远端遥控的跳板。在这种情况下, 电子邮件验证技术就显得尤为重要。本文所介绍的DKI M 技术就是其中的一种。

M 允许一个机构对邮件, 可以, 。通常, 签名会(ADMD ) 的授权下, 由这个环境中的任何一个功能组件来执行, 包括邮件客户端(MUA ) 、邮件提交代理(MS A ) 、网界邮件传输代理

(MT A ) 。DKI M 也允许签名由授权第三方来进行。邮件签名

后, 在邮件传输途径中的任何代理均可被选择用来执行对签名的验证。通常验证会由邮件接收者的行政管理域代理完成。与签名时相同, 可以由这个环境中的任何功能组件来完成。特别地, 这样意味着签名可以由邮件接收者的行政管理域的过滤软件来处理, 而不是要求邮件接收者的用户终端来进行判断。用来进行数字签名的域名所有者是以其信誉为基础的。接收者成功验证签名后可以利用签名者的身份信息作为限制垃圾邮件、欺骗、钓鱼网站或其他不受欢迎行为的软件的一部分。

　背景与基本概念

一直以来, 许多知名厂商均在建立电子邮件验证技术。其中最著名的包括Yahoo 的DomainKeys 技术、微软的SenderI D 技术与思科系统的identified internet mail 技术。其中, Domain 2

Keys 技术受到S BC 、英国电信与Google G mail 的支持; 而MS N Hot m ail 、AOL 、美国银行及e Bay 皆响应SenderI D 技术。微软曾

一度打算说服I ETF 工作小组通过SenderI D 技术成为业界标准, 最后却因为各家担心全球通用的技术为一家完全垄断而使微软的愿望落空。如今, 由Yahoo 与思科系统合作发表的

DKI M 技术, 既结合两家各自的技术, 也不会有垄断于一家的

　特点

基于对DKI M 概念的介绍, 可以发现DKI M 利用以下几点定义了一个邮件认证机制:公共密钥加密、基于DNS 的公共密钥发布服务、域名标志符。

DKI M 所采用的途径与传统的邮件签名方法(如S/M I M E

[2]

争议。DKI M 技术是现阶段在I ETF 内部讨论的方案, 并且有望在今后成为国际标准。

域密钥识别邮件定义了一种机制, 通过对邮件信息加密并签名, 从而允许实施签名的域名对将该邮件引入邮件传输流负责[1]。邮件接收者可以通过直接查询签名者的域名得到相应的公共密钥, 进而校验邮件的签名, 以此验证邮件是否属于拥

收稿日期:2007202207; 修回日期:2007204215

、OpenPGP

[3]

) 相比, 有以下一些主要特点:

a ) DKI M 不修改邮件正文, 而是将邮件签名参数信息放在

一般不显示给接收者的邮件头部。S/MI M E 和OpenPGP 同时要求对邮件正文进行修改, 将正文部分作为M I M E 类型进行封装。因此签名邮件对于软件不支持DKI M 的终端用户是透明

作者简介:王昕溥(19842) , 男, 辽宁大连人, 硕士, 主要研究方向为计算机网络应用技术、计算机网络(wangxinpu@cnnic . cn ) ; 姚健康(19782) , 男, 硕士, 主要研究方向为计算机网络应用技术; 李晓东(19762) , 男, 博士研究生, 主要研究方向为计算机网络资源寻址技术; 王峰(19772) , 男, 博士研究生, 主要研究方向为计算机网络应用技术; 毛伟(19682) , 男, 主任, 研究员, 硕导, 博士, 主要研究方向为计算机网络系统、互联网寻址技术.

・34・计算机应用研究第25

卷

的, 而不像S/MI M E 和OpenPGP 由于修改了正文会造成邮件内容在不支持协议的客户端上无法识别。

b ) 没有对分发公有/私有密钥对的可信证书权威的依赖。

范化的方法; d 表示签名实体的域名; s 表示选择器用来细分域名; h 表示在邮件头中选定的用于产生签名的部分; l 表示选去邮件正文的截断长度; b 表示邮件头部数字签名的内容; bh 表示邮件数字签名的内容; q 表示得到公共密钥的查询方式。1签名者动作

1) 判断邮件是否应该加密　签名者只应该对含有私有公

签名程序要求一定级别确保验证时采用的公共密钥是与声称的签名者相关联。许多程序通过一个可信第三方的证书授予来实现这一点。但是由于DKI M 的使用范围有限, 并不需要通用的、强大的、长期的由独立权威颁发的证书。DKI M 通过使验证者简单地向签名者的DNS 发出查询来获取公共密钥, 实现了一个足够的安全级别。这样就使得它使用的成本更低。

c ) 没有对任何新的有关公共密钥分发撤回的互联网协议或服务部署的依赖。现在已经定义的是一种单一绑定的利用

DNS TXT 记录来分发密钥, 其他的方式可能会在以后被定义。

d ) DKI M 是基于域名的, 而不是整个邮件地址。签名是由

有密钥对以及选择器信息的域名所负责的邮件加密。除了缺少上述条件外, 也有一些其他的原因使得签名者选择不对邮件签名。

2) 选择一个私有密钥和相应选择器　选择器用来在同一个管理域名下实现多重密钥。这可以给为域名拥有者工作的部门、数据区域或第三方提供各自的签名管理。验证者利用选择器作为一个附加的域名部分, 用来划分DNS 查询的域名。在同一个域名下, 不同的选择器代表不同的DKI M DNS 记录。

DKI M 并不规定签名者应该根据什么来选择哪个密钥和选择

域名的管理者控制而不是单独的邮件用户。

e ) 签名的校验失败不会导致邮件被拒绝。DKI M 没有规定收件人必需的操作, 可以将对邮件的判断提交给邮件过滤的其他组件。

f ) 机制中不包括加密算法。DKI M 支持多种数字签名算法。目前主要采用的是RS A 2S HA [4, 5]。可以随着算法的进步而采用新的加密算法。

g ) 存档并不是设计目标。DKI M 是为了满足邮件传输认证的短期需求。

器信息。就目前来讲, DKI M 规范对待所有的选择器都是一样的。所以采用选择器时考虑的重点可能是管理上的方便。在加密者对邮件头的选定部分利用私有密钥加密之后, 一个选择器被指定为DKI M 签名的一个属性记录在DKI M 签名的头部域, 用来向验证者提供找到DKI M 的公共密钥的信息。

3) 规范化　, 8bit 字符的邮件, 7bit 的形式。这种转, 签名M I M E 传输编[实际上这种转换并不是DKI M 的范畴, 而是应该在邮件传送给DKI M 算法之前由MUA 或MS A 进行处理。

如果传送给签名者的邮件包含任何在传输过程中会被修改的本地编码, 那么在签名前必须进行规范化修改[7]。特别是单独的CR 或LF (有些系统中用于本地换行符) 必须在签名之前转换为S M TP 标准的CRLF 序列。对于修改有两种不同的态度。对大多数签名者, 适度地修改邮件对于邮件认证有效性的状态不会有实质性的影响, 因此签名者倾向于采用能够经受传输中适当修改的规范化算法。其他一些签名者要求对邮件的任何修改均会导致签名的认证失败。这样的签名者要采用的签名算法不能容忍签名邮件在传输过程中的任何修改。一些签名者可能会接收在邮件标准下[7]对邮件头部域的修改但是不愿意接收对邮件正文的任何修改。

为了满足各种需求, 邮件头部和邮件正文定义了两种规范化算法。一种简单算法不允许传输过程中对邮件作任何修改; 另一种不严格算法允许普通的修改, 如空格的替换和邮件头部的重新封装。签名者可以对邮件头部或正文指定任意一种规范化算法, 如果没有指定, 邮件头部和正文的简单算法为默认。

签名者可以选择签名邮件正文的长度。实际上进行签名的邮件正文长度应插入到DKI M 签名头部的l 属性中。因此在规范化中, 签名者根据c 属性中指定的算法和l 属性中指定的截断长度来进行规范化。规范化只是用来对邮件内容进行调整以方便签名或验证, 而并不对邮件的传输产生任何影响。

4) 决定邮件头部要加密的部分　邮件头部的fr om 域是必

　架构

图1给出了DKI M 以允许创建DKI M 验证者。将结果提供给邮件部署系统需要的部分, 如过滤引擎。因为仅仅是经过验证的签名并不能够表示邮件是可以接收的, 仍然需要转送给其他评估阶段。在评估阶段签名的有效性以及签名域名的信誉均可能成为评估的条件, 但是DKI M 并不对评估行为进行定义

。

邮件的签名储存在DKI M 2Signature 头部域。这个部分包括所有的签名以及提供给验证者获取密钥的相关属性。

在DKI M 签名部分包括的主要属性信息有a 表示产生签名所采用的算法; i 表示用户或者代理的标志符; c 表示正文规

须被签名的; 同时可以选择任何其他在签名时存在的头部域。签名者不应该对有可能在传输过程中被合法修改和去除的域进行签名, 尤其是在邮件协议中被明确允许修改或去除的re 2

turn 2path 邮件头部域

[8]

。

第1期王昕溥, 等:域密钥识别邮件技术综述

・　　　35・

DKI M 签名头部域隐含规定为必须被签名的, 并且不能被

添加在h 属性中。除非为了表明其他已经存在的DKI M 签名也再次被签名。签名者可以声称对不存在的邮件头部域进行

了签名(在h 属性中包含的邮件头部域在邮件中并不存在) 。当计算签名时, 不存在的邮件头部域必须被当做空字符串来处理。

5) 签名　签名邮件签名的第一步是通过hash 算法计算邮

件的两个hash 值。一个是对邮件正文; 另一个是对邮件头部选择的部分。签名者必须按照这个顺序计算hash 值, 而验证者可以按照任意方便的顺序。首先, 签名者对规范化后的邮件正文进行hash, 其结果被转换为base64形式插入到DKI M 签名头部的bh 属性; 然后, 签名者根据h 属性所指定的要进行签名的邮件头部域以及顺序, 对已经规范化的邮件头部进行hash, 以base64形式插入到b 属性。签名者第二步通过选定的RS A 算法(实际上是PKCS#1[9]) 采用签名者的私有密钥对得到的

hash 值进行加密签名。

6) 插入DKI M 签名头部　签名者必须在传输邮件之前插

Fr om:Si m p le W ∫si m p le@f ootball . examp le . com

To:Julyseven X ∫julyseven@shopp ing . exa mp le . net Subject:Je t ′ai m e

Date:Wed, 18Oct 200621:00:0020700(P DT ) Message 2I D :∫20061018040037@football. exa mp le . com DKI M 2Signature:

a =rsa 2sha256; s =dalian; d =exa mp le . com; c =si m p le; q =dns/txt; i =si m p le@football. exa mp le . com;

h =Received:Fr om:To:Subject:Date:Message2I D ; bh =ZS VEYuq4ri3LR9S qjlzCP LxvJrI fr O I 2g5hxp5 MI =; b =dzdVy Of AKCdLXdJOc9G2q8LoXSlEniSbav yuU4zGeeruD00lszZ VoG4ZHRN iYz R;

Received:fr om dsl 210. 2. 3. 4. f ootball . exa mp le . com [10. 2. 3. 4]　by server . exa mp le . com with S UBM I SSI O N; 　W ed, 18Oct 200621:00:4520700(P DT )

在这个例子中, 验证程序利用从“d =”标记中提取的域名“exa mp le . com ”, 以及从“s =”标记中提取的选择器“dalian ”形成了一个DKI M 查询:dalian . _domainkey. examp le . com 。

签名的验证结果储存在“Authenticati on 2Results ”头部中。经过验证成功, 邮件被转换成:

X 2Authenticati on 2Results:shopp ing . examp le . net header . fr om =si m p le@football. exa mp le . com; dki m =pass Received:fr om mout23. football . exa mp le . com (192. 168. 1. 1) by shopp ing . exa mp le . net with S MTP; DKI M 2Signature:

a =rsa 2sha256; s =dalian; d com; c =si m p le; q =dns/txt; i =si m p . mp h =Fr To:2I D ; LxvJrI fr O I 2g5hxp5 MI =; lszZ VoG4ZHRN iYz R;

Received:fr om dsl 210. 2. 3. 4. f ootball . exa mp le . com [10. 2. 3. 4]by server . exa mp le . com with S UBM I SSI O N; Fr om:Si m p le W ∫si m p le@football. exa mp le . com To:Julyseven X ∫julyseven@shopp ing . exa mp le . net Subject:Je t ′ai m e

Date:Wed, 18Oct 200621:00:0020700(P DT ) Message 2I D :∫20061018040037. 46341. 5F8J@football. exa mp le . com

入DKI M 签名头部域。关键字DKI M 2Signature 必须在所有

DKI M 签名属性插入前写入邮件头部。

1　验证者动作

1) 确认签名头部域　验证者必须确认DKI M 签名头部域

的格式和值的有效性。如果存在任何不一致和未知数值以及缺少必需的属性, 头部域均会整体被忽略并且验证者返回

PER MF A I L (签名语法错误) 。但是在DKI M 未知的额外属性是允许的。

2) 获得公有密钥　。M q 属性定义的查询类型。TXT RR 记录。

密钥查询算法的参数是查询类型(q 属性) 、签名者的域名

(d 属性) 和选择器(s 属性) :public _key=dki m _find_key(q _

[1]

val, d_val,s_val) 。

3) 计算验证　给定一个签名者和公共密钥。验证首先根

5　D KI M 面临的威胁和发展前景

就像其他任何试图阻止垃圾邮件传播的机制一样, DKI M 也会受到各种攻击。一方面有针对DKI M 协议本身的攻击, 比

如错误的邮件长度限制(l 属性) 、错误的私有密钥、DKI M 签名头部域格式错误等无意或有意的属性赋值错误, 均可能造成的认证失败; 另一方面, DKI M 机制所依赖的DNS 服务本身也具有很多不安全的因素[12]。各种针对DNS 的攻击均有可能使得DKI M 签名失效甚至被伪造。对于这些可能的攻击, DKI M 工作组发表了针对各种攻击行为的分析[10]。如何完善DKI M 协议以应对对于协议本身的攻击也是DKI M 今后改进的重要内容。对于通过DNS 服务所进行的攻击, 已经超出了DKI M

[13]本身所考虑的范畴。因此DKI M 一方面寄希望于DNSSEC

据c 属性定义的规范化算法、l 属性定义的邮件正文签名长度和h 属性定义的邮件头部签名部分, 对邮件进行规范化处理。根据a 属性定义的算法以及得到的公共密钥, 计算规范化后的邮件加密hash 值; 然后验证邮件正文的加密hash 值是否与bh 属性所传递的hash 值相同。类似地, 利用a 属性定义的算法和公共密钥值, 根据邮件头部的hash 值验证b 属性传递的签名。

4) 传递验证结果　验证者希望通过任何合适的方法将验证结果传递给邮件系统的其他部分。比如在向邮件添加一个邮件头部。所有这种头部应该插入到任何存在的DKI M 签名或已经存在的验证状态头部域之前。

　举例

用一个例子来简单介绍DKI M 的流程。原始邮件头如下:

Fr om:Si m p le W ∫si m p le@football . exa mp le . com T o:Julyseven X ∫julyseven@shopp ing . examp le . net Subject:Je t ′ai m e

Date:Wed, 18Oct 200621:00:0020700(P DT ) Message 2I D :∫20061018040037@f ootball . exa mp le . com

的出现和使用解决现有的一部分问题; 另一方面DKI M 的设计初衷认为各种通过DNS 的针对DKI M 的攻击行为相对于攻击建立在DNS 基础上的其他应用成本高且回报很少。想要系统性地威胁DKI M 的设计目标, 攻击者必须在DNS 服务的多个部分进行长时间高成本的攻击。这种行为的非经济性会在某种程度上阻止对DKI M 的攻击。

DKI M 只是为了实现一定程度上足够的认证, 而并不是为

加密传输后, 在邮件头部添加了DKI M 签名域, 验证者得到的邮件头如下:

了提供一种强大的加密认证机制[10]。这种在安全性上的不完全可靠, 对于网络钓鱼等涉及隐私程度高可能造成巨大损失的

・36・计算机应用研究第25卷

欺骗行为, DKI M 所得出的结论是具有风险和不可信赖的。因此DKI M 的主要应用前景是在即使被攻击或认证失败也不会有很大损失的反垃圾邮件等低危险性领域。在反垃圾邮件方面, DKI M 能够有效地限制垃圾邮件发送者盗用其他机构或域名的名义, 为邮件过滤提供鉴别手段, 并且能够在现有邮件体系下快速进行低成本的部署。I ETF DKI M 工作组正在致力于完善DKI M 协议, 积极推动DKI M 草案成为正式的RFC 标准, 并且已经取得了阶段性的成果。在开发部署上面, 已经有

Send mail 、Postfix 、Apache 等多家公司和组织参与开发了可用的

[4]Nati onal I nstitute of Standards and Technol ogy . N I ST F I PS P UB 186:

digital signature standard [S ].[S . l . ]:Depart m ent of Commerce, 1994. [5]

R I V EST R L, SHAM I R A, ADLE MAN L M. A method of obtaining digital signatures and public 2key cryp t osystem s [J ].Comm un i ca 2ti o n s o f the ACM , 1978, 21(2) :1202126. [6]

FREED N, BORENSTE I N N. RFC 2045, Multi pur pose I nternet mail extensi ons (M I M E ) part one:for mat of I nternet message bodies[S ].[S . l . ]:I ETF, 1996.

[7]RES N I CK P . RFC 2822, I nternet message f or mat[S].[S . l . ]:I ETF,

2001.

[8]K LENSI N J. RFC 2821, Si m p le mail transfer p r ot ocol[S ].[S . l . ]:

I ETF, 2001. [9]

JONSS ON J, K AL I SKI B. RFC 3447, Public 2key cryp t ography stan 2dards (PKCS ) #1:RS A cryp t ography s pecificati ons versi on 2. 1[S].[S . l . ]:I ETF, 2003.

[10]FENT ON J. RFC 4686, Analysis of threats motivating domain keys

identified mail (DKI M ) [S].[S . l . ]:I ETF, 2006.

[11]HANSEN T, CROCKER D, HALLAM 2BAKER P . DomainKeys identi 2

fied mail (DKI M ) service overvie w [S].[S . l . ]:I ETF, 2006. [12]ATKI N S D, AUSTE I N R. RFC 3833, Threat analysis of the domain

name system (DNS ) [S].[S . l . I 2004.

[13]ARE R, M, et al . RFC 4033, DNS secu 2

rity on [S . l . ]:I ETF, 2005.

]for a DKI M signing p ractices p r ot ocol

l . ]:I ETF, 2006.

]ALLMAN E, DELANY M, FENT ON J. DKI M sender signing p ractices

[S].[S . l . ]:I ETF, 2006.

Los A la m it os:I EEE Computer Society Press, 1997:2042210.

[11]LUOT ONEN A. The common l og file for mat [EB /OL].(19952092

27) . htt p://www. w3. org/pub/www/.[12]FastStats l og analyzer [E B /OL].

mach5. com /fast/.

[13]Z A I A NE O, X I N M , HAN J. D iscovering W eb access patterns and