專利名稱：基于域名層次認(rèn)證機(jī)構(gòu)的郵件傳輸代理原發(fā)抗抵賴方法
技術(shù)領(lǐng)域：
本發(fā)明涉及互聯(lián)網(wǎng)電子郵件安全技術(shù)，特別指一種基于域名(DomainName System，DNS)層次認(rèn)證機(jī)構(gòu)(Certificate Authority，CA)的郵件傳輸代理(Mail Transfer Agent，MTA)原發(fā)抗抵賴方法。
背景技術(shù)：
電子郵件是Internet上使用最廣泛的服務(wù)之一，但電子郵件也是Internet上最不安全的服務(wù)之一。一方面，電子郵件在電子政務(wù)、電子商務(wù)等方面的大量應(yīng)用使電子郵件進(jìn)行安全通信的需求正在以驚人的速度增長；另一方面，垃圾郵件，惡意郵件、郵件的仿冒和抵賴等一系列的郵件安全問題影響著郵件的正常使用。因此，電子郵件的安全問題越來越得到人們的重視。
電子郵件用戶必須對其的通信行為承擔(dān)社會責(zé)任，電子郵件系統(tǒng)也必須考慮承擔(dān)社會責(zé)任的問題。新華網(wǎng)消息，美國總統(tǒng)布什2003年12月16日在白宮簽署了一項旨在應(yīng)對垃圾電子郵件的聯(lián)邦法案，并已于今年1月1日起正式生效。如果郵件系統(tǒng)能夠做到事后的責(zé)任追查和審計，為司法調(diào)查提供足夠的證據(jù)證實郵件的真實發(fā)送者，即郵件的原發(fā)抗抵賴(郵件發(fā)送方不可否認(rèn)性)，則會給垃圾郵件發(fā)送者以威懾作用而不敢發(fā)送。有了郵件的原發(fā)抗抵賴服務(wù)，可以解決電子郵件的假冒、否認(rèn)、惡意郵件、垃圾郵件等相關(guān)安全問題。
國內(nèi)外在電子郵件的原發(fā)抗抵賴的研究已開展了許多工作，目前采用的主要方法是通過數(shù)字簽名技術(shù)來解決。
在郵件的原發(fā)抗抵賴系統(tǒng)中，應(yīng)用比較廣泛的是PGP(Pretty GoodPrivacy)和S/MIME(Secure/Multipurpose Internet Mail Extension)。PGP是Pretty Good Privacy的簡稱，其特點是對郵件內(nèi)容進(jìn)行簽名，以保證信件內(nèi)容無法修改，使用公鑰和私鑰技術(shù)保證郵件內(nèi)容保密且不可否認(rèn)。發(fā)信人與收信人的公鑰都分布在公開的地方，如TFP站點，而公鑰本身的權(quán)威性則可以由第三方、特別是收信人所熟悉或信任的第三方進(jìn)行簽名認(rèn)證，沒有統(tǒng)一的集中的機(jī)構(gòu)進(jìn)行公鑰/私鑰的簽發(fā)。在PGP系統(tǒng)中，信任是雙方之間的直接關(guān)系，或是通過第三者、第四者的間接關(guān)系，但任意兩方之間是對等的。S/MIME是從PEM(Privacy Enhanced Mail)和MIME發(fā)展而來的。同PGP一樣，S/MIME也利用單向散列算法和公鑰與私鑰的加密體系。與PGP不同的主要有兩點首先，它的認(rèn)證機(jī)制依賴于層次結(jié)構(gòu)的證書認(rèn)證機(jī)構(gòu)，所有下一級的組織和個人的證書由上一級的組織負(fù)責(zé)認(rèn)證，而最上一級的組織(根證書)之間相互認(rèn)證，整個信任關(guān)系基本是樹狀的。
PGP和S/MIME是端到端的安全電子郵件技術(shù)，即通過郵件的最初發(fā)送者對郵件內(nèi)容進(jìn)行簽名和加密，郵件的最終接收者驗證簽名和解密來保證端到端的郵件發(fā)送方不可否認(rèn)性。此項技術(shù)和具體的通訊機(jī)制相獨立開來，靈活性比較好，實現(xiàn)也比較方便，所有的工作只是在應(yīng)用層上對現(xiàn)有郵件用戶代理(UA)添加相應(yīng)的安全功能插件。但仍存在以下問題(1)端到端的電子郵件發(fā)送方不可否認(rèn)性問題依賴于發(fā)送者是否對其發(fā)送的郵件進(jìn)行簽名，端到端的方法中郵件傳輸系統(tǒng)無法強(qiáng)制發(fā)送方履行不可否認(rèn)性的責(zé)任。若發(fā)送者對郵件內(nèi)容進(jìn)行了簽名，則郵件的接收者可以驗證郵件的發(fā)送者身份以實現(xiàn)郵件發(fā)送方的不可否認(rèn)性。但在現(xiàn)實中，垃圾郵件發(fā)送者不需要對信件的內(nèi)容保密，它本身就是具有散發(fā)性，而且也不愿意為自己的行為負(fù)責(zé)。這時，垃圾郵件的發(fā)送者不對郵件內(nèi)容進(jìn)行加密和簽名，郵件接收者則無法判定郵件的完整性和發(fā)送郵件者的真實身份。(2)本地MTA對發(fā)送者UA沒有做身份認(rèn)證，也就意味著攻擊者可以冒用合法的UA身份發(fā)送大量垃圾郵件。這樣，既會造成MTA資源的大量浪費，也會占用大量的網(wǎng)絡(luò)帶寬資源。
要強(qiáng)制實現(xiàn)郵件的原發(fā)抗抵賴，根據(jù)電子郵件的傳輸過程，可采取原發(fā)抗抵賴權(quán)標(biāo)鏈的方式，即層層負(fù)責(zé)制，用逐級追責(zé)任的方法。本地MTA在接收UA的郵件時，必須驗證UA是否對其所發(fā)的郵件進(jìn)行的數(shù)字簽名是否正確，只有驗證簽名正確的郵件才被接收，并將簽名信息做日志，作為發(fā)送端UA發(fā)送此封郵件的原發(fā)抗抵賴權(quán)標(biāo)。在接收端MTA接收發(fā)送端MTA發(fā)送的郵件時，也同樣驗證發(fā)送端MTA對郵件的簽名信息的正確性，只有驗證通過的郵件才被接收。在接收端UA接收MTA發(fā)的郵件時，也同樣驗證數(shù)字簽名的信息。本地MTA是擁有該服務(wù)器的所有用戶的標(biāo)識和相關(guān)信息，所以很容易通過相關(guān)的信息進(jìn)行認(rèn)證，即MTA與UA之間的原發(fā)抗抵賴較容易實現(xiàn)，而MTA之間的通信則，MTA的身份不是預(yù)先所能知道的，可能要與很多未知的MTA通信。所以MTA之間的原發(fā)抗抵賴是重點同時也是一個難點。
某MTA要與很多未知的MTA通信，MTA的身份不是預(yù)先所能知道的，如何安全地、正確地獲得這些公鑰又是另外一個難點和關(guān)鍵點。最初的公鑰分配(即一方獲得另一方的公鑰)是基于私人之間的信任關(guān)系。然而隨著公鑰密碼技術(shù)在網(wǎng)絡(luò)安全的應(yīng)用規(guī)模不斷擴(kuò)大，這種分配方式已不能適應(yīng)了，這時就需要PKI(Public Key Infrastructure)來解決大量的密鑰分配和管理。PKI是一種完全符合X.509標(biāo)準(zhǔn)的密鑰管理平臺，它能夠為所有網(wǎng)絡(luò)應(yīng)用透明地提供采用加密和數(shù)字簽名等密碼服務(wù)所必須地密鑰和證書管理。在PKI中，公鑰一般是采取證書的形式存放，所以證書的信任模型和證書的認(rèn)證是關(guān)鍵技術(shù)。而域名有以下特點(1)郵件在Internet上傳輸時，郵件路由是通過接收者郵件地址的域名進(jìn)行路由的。
(2)在國際互聯(lián)網(wǎng)中，網(wǎng)絡(luò)中心所管理的DNS域和IP范圍都是經(jīng)申請后授權(quán)的，網(wǎng)絡(luò)中心控制這個域就必須要對其負(fù)責(zé)任，正式的DNS域名具有嚴(yán)格的層次關(guān)系和責(zé)任關(guān)系。
(3)DNS域名在Internet中是唯一的。
DNS的優(yōu)勢已經(jīng)是不言而喻的了，而建立基于DNS域的CA結(jié)構(gòu)，不但具有了DNS已有的優(yōu)點，而且可以充分利用已有的資源、技術(shù)。

發(fā)明內(nèi)容
本發(fā)明的技術(shù)解決問題是克服現(xiàn)有技術(shù)的不足，提供一種可以實現(xiàn)郵件MTA之間通信的原發(fā)抗抵賴方法，以實現(xiàn)MTA與MTA之間強(qiáng)制不可否認(rèn)性。
本發(fā)明的技術(shù)解決方案是基于DNS域?qū)哟蜟A的郵件傳輸代理原發(fā)抗抵賴方法，該方法包括基于DNS域?qū)哟蔚腃A建立步驟、郵件發(fā)送步驟和郵件接收步驟，其中，基于DNS域?qū)哟蔚腃A建立步驟，包括(1)根據(jù)需要選擇一個DNS域作為根域建立對應(yīng)的根CA以充當(dāng)信任的根或“信任錨(trust anchor)”，也就是認(rèn)證的起點或終點。根域是可自定義的，即部署者可以自行決定自己的根域。
(2)根據(jù)DNS的層次模型，在根CA下建立與DNS根域的一級子域相應(yīng)的一級子CA，在一級CA下再建立與DNS二級子域相對應(yīng)的二級CA，同樣可根據(jù)需要再建立與DNS三級子域相對應(yīng)的三級CA等，依此類推，最終建立一個與整個DNS域?qū)哟谓Y(jié)構(gòu)對應(yīng)的層次結(jié)構(gòu)的CA。
在根CA下建立一級子CA，如EDU-CA、CN-CA、COM-CA等(如圖2所示)。在一級CA下再建立二級CA，如EDU.CN-CA。同樣可根據(jù)需要再建立三級CA等。與非CA的PKI實體相對應(yīng)的樹葉通常稱作終端實體(endentities)或被稱作終端用戶(end users)，例SINA.COM和GXNU.EDU.CN終端實體。層次結(jié)構(gòu)中的所有實體都信任唯一的根CA，而倒數(shù)第二層CA認(rèn)證終端實體。
(3)DNS域所對應(yīng)的CA負(fù)責(zé)產(chǎn)生、分配并管理該域下的所有MTA的數(shù)字證書。
數(shù)字證書，采用ISO和CCITT/ITU-T(國際電信聯(lián)盟的電信標(biāo)準(zhǔn)化部門)的X.509 v3證書協(xié)議。這是目前眾多數(shù)字證書協(xié)議中應(yīng)用最為廣泛的一個。
圖1是X.509 v3證書的結(jié)構(gòu)定義。
身份標(biāo)識，數(shù)字證書中的身份標(biāo)識采用DNS域名作為MTA的身份標(biāo)識，將MTA與域名捆綁在一起。即X.509數(shù)字證書結(jié)構(gòu)中的主體用DNS域名來標(biāo)識證書擁有者的信息。
證書的生產(chǎn)方法，根據(jù)Internet的DNS域的申請流程，以及基于DNS域?qū)哟蔚腃A結(jié)構(gòu)，本發(fā)明采用集中式生產(chǎn)方法，每個EE(終端實體)在申請域名時，由上一級CA直接產(chǎn)生該EE的證書。
證書的分發(fā)方式，本方法推薦帶外分發(fā)的形式，使用軟盤、光盤等物理介質(zhì)對證書進(jìn)行分發(fā)。這種分發(fā)的優(yōu)越性在于對證書分發(fā)時的安全性有比較好的保障；是一種集中式的分發(fā)管理模式。
證書的驗證，在認(rèn)證機(jī)構(gòu)的嚴(yán)格層次結(jié)構(gòu)模型中進(jìn)行證書驗證的過程為一個持有根CA公鑰的終端實體A可以通過下述方法檢驗另一個終端實體B的證書。假設(shè)B的證書是由CA2簽發(fā)的，而CA2的證書是由CA1簽發(fā)的，CA1的證書又是由根CA簽發(fā)的。A(擁有根CA的公鑰KR)能夠驗證CA1的公鑰K1，因此它可以提取出可信的CA1的公鑰。然后，這個公鑰可以被用作驗證CA2的公鑰，類似地就可以得到CA2的可信公鑰K2。公鑰K2能夠被用來驗證B的證書，從而得到B的可信公鑰KB。A現(xiàn)在就可以根據(jù)密鑰的類型來使用密鑰KB，如對發(fā)給B的消息加密或者用來驗證據(jù)稱是B的數(shù)字簽名，從而實現(xiàn)A和B之間的安全通信。
每個MTA的證書庫中必須有兩類證書，分別是(1)本MTA被CA簽名的MTA證書和MTA所在域以及上層域直到根域的所有這些域的證書所構(gòu)成的證書鏈。這些證書的獲得是在申請域名時，由上級域名授權(quán)機(jī)構(gòu)用安全的方式分發(fā)下來的。
(2)本MTA所信任的證書，這些證書是通過證書驗證的，被本MTA所信任。
如圖2所示的CA結(jié)構(gòu)中，SINA.COM郵件服務(wù)器中的證書庫中應(yīng)該有根CA、COM-CA和終端實體SINA.COM的證書；GXNU.EDU.CN郵件服務(wù)器中的證書庫中應(yīng)該有根CA、CN-CA、EDU.CN-CA和終端實體SINA.COM的證書。
當(dāng)SINA.COM的MTA發(fā)郵件給GXNU.EDU.CN的MTA時，同時將COM-CA和SINA.COM的證書發(fā)給GXNU.EDU.CN的MTA，GXNU.EDU.CN的MTA對SINA.COM的證書進(jìn)行驗證(1)首先查看當(dāng)前時間是否還在證書的有效期內(nèi)，如果不是，說明該證書已經(jīng)過期，驗證失敗，否則繼續(xù)第二步。
(2)查看本MTA的證書庫中是否已有SINA.COM的證書(該證書已被驗證過)，根據(jù)如果有，則比較證書的頒發(fā)時間，如果接收到的證書比證書庫中的頒發(fā)時間早或一樣，則用證書庫中的證書進(jìn)行數(shù)字簽名的驗證即可。否則，繼續(xù)第三步。
(3)用本地根CA的證書驗證COM-CA的證書，再用COM-CA的證書驗證SINA.COM的證書，若其中有一個驗證失敗，則整個驗證過程失敗。如果，驗證成功，則說明GXNU.ED U.CN的MTA已經(jīng)信任，SINA.COM的MTA所發(fā)過來的SINA.COM的證書。在驗證證書的過程中，每一次驗證通過的證書都將其寫入證書庫，可提高下一次證書驗證效率。
郵件發(fā)送步驟，包括(1)源MTA將要發(fā)送的郵件M計算哈希值H＝h(M)，然后用自己的私鑰對H進(jìn)行數(shù)字簽名，數(shù)字簽名信息為sig。
(2)源MTA將本域一直到根域下一層次域的證書，形成證書鏈，記做mcerts；所謂證書鏈，就是將源MTA本域一直到根域下一層次域的證書看成一個整體，記為mcerts，這些證書的獲得是在申請域名時，由上級域名授權(quán)機(jī)構(gòu)用安全的方式分發(fā)下來的。
(3)源MTA發(fā)送{M，sig，mcerts}到下一MTA，其中，mcerts指附在郵件后面。
郵件接收步驟，包括(1)接收端MTA收到后，根據(jù)證書驗證算法，驗證源MTA的證書，若驗證不通過，將證書驗證的相關(guān)信息做日志并將郵件M拋棄，若驗證通過進(jìn)行下一步，具體步驟如下接收端MTA首先查看當(dāng)前時間是否還在證書的有效期內(nèi)，如果不是，說明該證書已經(jīng)過期，驗證失敗，否則繼續(xù)第二步；其次查看本MTA的證書庫中是否已有源MTA的證書(該證書已被驗證過)，根據(jù)如果有，則比較證書的頒發(fā)時間，如果接收到的證書比證書庫中的頒發(fā)時間早或一樣，則用證書庫中的證書進(jìn)行數(shù)字簽名的驗證即可；否則，繼續(xù)第三步；最后，用本地根CA的證書驗證源MTA證書鏈最上一層CA的證書，再用后者的證書驗證證書鏈下一層的證書，直至驗證完源MTA的證書為止，若其中有一個驗證失敗，則整個驗證過程失??；如果，驗證成功，則說明接收端MTA已經(jīng)信任源MTA所發(fā)過來源MTA的證書。在驗證證書的過程中，每一次驗證通過的證書都將其寫入證書庫，可提高下一次證書驗證效率。
(2)接收端MTA從經(jīng)過證書驗證的源MTA的證書中提取公鑰，用公鑰驗證源MTA對M的數(shù)字簽名信息sig，如驗證不通過，將簽名驗證的相關(guān)信息做日志并將郵件M拋棄，若驗證通過進(jìn)行下一步。由于本發(fā)明的證書ISO和CCITT/ITU-T的X.509標(biāo)準(zhǔn)系列的X.509 v3證書，接收端MTA從經(jīng)過證書驗證的源MTA的證書中提取公鑰將也采用X.509 v3系統(tǒng)提供的公鑰提取方法；(3)將郵件M直接寫用戶郵箱或發(fā)往下一MTA，若發(fā)往下一MTA，又從郵件發(fā)送步驟開始。
本發(fā)明與現(xiàn)有的電子郵件抗抵賴類似技術(shù)相比的優(yōu)點在于以下(1)它實現(xiàn)了MTA與MTA之間的強(qiáng)制不可否認(rèn)性。
(2)具有可縮放層次的CA結(jié)構(gòu)?；贒NS域?qū)哟蔚腃A結(jié)構(gòu)，它是一種可縮放層次的CA結(jié)構(gòu)。一方面，設(shè)立CA的個數(shù)可根據(jù)用戶的數(shù)量，如在cn.域已設(shè)立了CA，而在cn.域下的一個子域用戶數(shù)很少，我們可不在該子域設(shè)立CA，該子域用戶下的證書可直接由CN-CA簽發(fā)。當(dāng)該子域中用戶數(shù)量逐漸增加，這時可考慮在該子域下建立CA。另一方面，如果要將郵件的抗抵賴應(yīng)用于整個Internet，則根CA就對應(yīng)著Internet的DNS根，如果只是要應(yīng)用于某個域，如只想在中國教育科研網(wǎng)內(nèi)提供郵件的原發(fā)抗抵賴服務(wù)，則根CA就對應(yīng)著中國教育科研網(wǎng)所在的域edu.cn.
(3)驗證證書時，不需要CA的在線參與。從證書驗證算法知，驗證證書時，不需要在線的去CA查詢證書，也就不需要通常的目錄服務(wù)器，易于實現(xiàn)。
(4)證書認(rèn)證與其有關(guān)證書的應(yīng)用相獨立。前面提出的證書算法，不僅可用于電子郵件中，還可應(yīng)用于其它的很多有關(guān)證書的應(yīng)用。
(5)郵件的抗抵賴和和機(jī)密性是獨立的系統(tǒng)，可只提供單項服務(wù)，也很容易和其他服務(wù)相結(jié)合，提供綜合的服務(wù)。
如有些郵件系統(tǒng)的需求只是抗抵賴，不希望提供機(jī)密性服務(wù)。由于本方法不是建立在郵件機(jī)密性之上的，只是提供了抗抵賴，所以直接用此方法即可。若有些郵件系統(tǒng)在要求抗抵賴服務(wù)的同時，還要求提供機(jī)密性，則可以在執(zhí)行方法的第1步前，先對郵件進(jìn)行加密即可。


圖1為本發(fā)明的證書格式，即X.509 v3證書結(jié)構(gòu)；圖2為本發(fā)明基于DNS域?qū)哟蔚腃A結(jié)構(gòu)例圖；圖3為本發(fā)明實現(xiàn)的系統(tǒng)0層數(shù)據(jù)流圖；圖4為本發(fā)明的系統(tǒng)程序流程圖；圖5為本發(fā)明的證書驗證和簽名驗證的數(shù)據(jù)流圖；圖6為本發(fā)明的匹配證書和驗證證書的算法圖；圖7為本發(fā)明的數(shù)字簽名模塊的數(shù)據(jù)流圖；圖8為本發(fā)明的日志模塊的數(shù)據(jù)流圖。
圖3、5、7、8中所用數(shù)據(jù)流說明M0000M-郵件第1個0-證書驗證是否通過標(biāo)識(T通過，F(xiàn)未通過)第2個0-簽名驗證是否通過標(biāo)識(T通過，F(xiàn)未通過)第3個0-接收者標(biāo)識(L本地，R非本地)第4個0-郵件來源標(biāo)識(U來自UA，M來自MTA)
sig簽名；Icert本地MTA證書；mcerts證書鏈；郵件標(biāo)識符；DNS域名信息；pass驗證通過與否；SM要發(fā)送的郵件；signature本地MTA簽名；publickey公鑰；privatekey私鑰；Hash對郵件內(nèi)容的哈希值。
具體實施例方式
本發(fā)明的實施方式將在上述發(fā)明內(nèi)容的基礎(chǔ)上設(shè)計一套郵件傳輸代理原發(fā)抗抵賴系統(tǒng)并對其予以實現(xiàn)。
OpenCA是互聯(lián)網(wǎng)上廣為使用的證書發(fā)放軟件，Sendmail是互聯(lián)網(wǎng)上目前使用得最為廣泛的郵件傳輸代理軟件，有鑒于此，本發(fā)明的系統(tǒng)使用OpenCA作為證書認(rèn)證系統(tǒng)發(fā)放CA的軟件，Sendmail作為消息傳輸代理軟件。在本發(fā)明實施過程中，使用到了OpenSSL-0.9.7軟件包，該軟件包所包含的加密庫、規(guī)范數(shù)字證書、數(shù)據(jù)封裝等功能，為系統(tǒng)的實現(xiàn)提供了最底層的API。
對電子郵件傳輸原發(fā)抗抵賴系統(tǒng)的設(shè)計和實現(xiàn)，遵循以下原則(1)不改變原有電子郵件系統(tǒng)中相關(guān)的SMTP協(xié)議、RFC822文本協(xié)議和MIME協(xié)議；(2)證書采用X.509V3標(biāo)準(zhǔn)格式的證書；(3)該系統(tǒng)對電子郵件用戶來說應(yīng)該是透明的；(4)郵件的發(fā)送方和接收方都進(jìn)行詳細(xì)的日志記錄，為事后的責(zé)任追查和審計提供服務(wù)；(5)對試圖冒充的攻擊者，保持沉默，不給出顯示的答復(fù)，以防止攻擊者采用反復(fù)試探的方式竊取信息。同時將攻擊者的攻擊情況及時記錄下來，以便管理員分析以及采取相應(yīng)得防范對策；(6)系統(tǒng)的模塊化分盡可能清晰，有較強(qiáng)的可重用性。
證書認(rèn)證系統(tǒng)的搭建如前面發(fā)明內(nèi)容部分描述，本實現(xiàn)中我們僅搭建了根CA，并將經(jīng)過該根CA簽名的MTA證書發(fā)放給兩個MTA。CA發(fā)放證書的方法可參閱相關(guān)文檔，這里不作詳細(xì)說明。
下面詳細(xì)說明郵件接收和發(fā)送步驟在一個郵件傳輸代理中的實現(xiàn)，事實上，為了對本專利提出的方法進(jìn)行驗證，我們在兩個MTA上同時作了該實現(xiàn)。
根據(jù)軟件工程的方法，對郵件傳輸代理系統(tǒng)設(shè)計了系統(tǒng)數(shù)據(jù)流圖，系統(tǒng)的模塊圖和系統(tǒng)流程圖。
系統(tǒng)0層數(shù)據(jù)流圖如圖3所示，源MTA發(fā)送{M，sig，mcerts}到下一MTA，其中，mcerts指附在郵件后面。MTA接收源MTA傳來的{M，sig，mcerts}，進(jìn)入加工Verify。加工Verify的加工邏輯為判斷所接收郵件是UA還是MTA發(fā)送。如果是UA，則將郵件流向加工Classify。如果是MTA則驗證其證書信息和簽名信息(證書驗證的詳細(xì)算法步驟見后面圖6及其說明)。驗證通過將郵件流向加工Classify，驗證不通過將其寫入本地垃圾郵件管理信箱，通過驗證的證書寫入到本地證書庫，驗證的結(jié)果做相應(yīng)的日志記錄。加工Classify的加工邏輯為判斷所接收的郵件的接收者為本地還是非本地，如果為本地直接寫用戶郵箱；如果為非本地，將郵件進(jìn)行數(shù)字簽名，再將郵件和數(shù)字簽名信息流給加工Send。加工Log的加工邏輯為將來自加工Verify的郵件ID號、郵件域名、證書驗證與簽名驗證通過與否信息和當(dāng)前時間存入到文件ReceiveLog。對加工Sign中的郵件簽名信息、郵件ID號、當(dāng)前時間存入到文件SendLog。加工Sign的加工邏輯為對要法往下一個MTA的郵件進(jìn)行數(shù)字簽名。加工Send的加工邏輯為將郵件、郵件的簽名信息、本MTA以及所有上級CA(不包括根CA)的證書所構(gòu)成的證書鏈發(fā)給下一MTA，即將{M，sig，mcerts}又發(fā)送給下一MTA。如此在每一個MTA上都進(jìn)行上述處理。
本發(fā)明實現(xiàn)的系統(tǒng)程序流程圖如4所示(1)每個MTA在工作前，都已經(jīng)通過安全方式獲得了本MTA的私鑰和所在DNS域的證書鏈。
(2)MTA對所接收的郵件進(jìn)行判斷，判斷郵件是來自UA還是MTA，如果來自UA，則直接傳遞給簽名模塊，將郵件簽名發(fā)往下一MTA或是直接寫用戶郵箱。
(3)如果郵件來自MTA，則對郵件內(nèi)容后面所附的證書鏈和簽名信息進(jìn)行驗證(證書驗證的詳細(xì)算法步驟見后面圖4及其說明)。驗證不通過將其寫入本地垃圾郵件管理信箱，通過驗證的證書寫入到本地證書庫，驗證的結(jié)果做相應(yīng)的日志記錄。
(4)將通過證書和簽名驗證的郵件或由本地UA發(fā)送的郵件進(jìn)行判斷，判斷郵件的接收者為本地還是非本地。
(5)如果為本地直接寫用戶郵箱；如果為非本地，將郵件進(jìn)行數(shù)字簽名，再將郵件和數(shù)字簽名信息以及本MTA所在DNS域的簽名鏈信息一起發(fā)給下一MTA，并做相應(yīng)的日志記錄。
本發(fā)明實施的硬件環(huán)境選擇主要從系統(tǒng)的開發(fā)成本考慮，選用intel X86的計算機(jī)作為硬件平臺。
MTA軟件的選擇由于sendmail是使用很廣泛的一種電子報文傳輸代理軟件(MTA)，并且該軟件是開放源碼的軟件，所以選擇sendmail作為MTA軟件。
操作系統(tǒng)的選擇選擇Solaris.該操作系統(tǒng)非常穩(wěn)定，是Unix的一種。
開發(fā)工具的選擇美國國家標(biāo)準(zhǔn)化協(xié)會根據(jù)各種版本對C的發(fā)展和擴(kuò)充，制定了新的標(biāo)準(zhǔn)ANIS C。在核心方法的實現(xiàn)中選用符合ANSI C標(biāo)準(zhǔn)的gcc(GUN C)作為開發(fā)語言，有利于系統(tǒng)的移植。系統(tǒng)的開發(fā)中使用到了OpenSSL-0.9.7軟件包。該軟件包所包含的加密庫、規(guī)范數(shù)字證書、數(shù)據(jù)封裝等功能，為系統(tǒng)的實現(xiàn)提供了底層的API。
證書驗證和簽名驗證模塊的數(shù)據(jù)流圖如圖5所示，證書驗證和簽名驗證模塊的功能是判斷所接收郵件是UA還是MTA發(fā)送。如果是UA，則將郵件流向加工Classify；如果是MTA則驗證其證書信息和簽名信息，驗證通過將郵件流向加工Classify，驗證不通過將其寫入本地垃圾郵件管理信箱，通過驗證的證書寫入到本地證書庫，驗證的結(jié)果做相應(yīng)的日志記錄。
匹配證書和驗證證書的算法如圖6所示(1)首先查看當(dāng)前時間是否還在證書的有效期內(nèi)，如果不是，說明該證書已經(jīng)過期，驗證失敗，否則繼續(xù)第二步。
(2)查看本MTA的證書庫中是否已有源MTA的證書(該證書已被驗證過)，根據(jù)如果有，則比較證書的頒發(fā)時間，如果接收到的證書比證書庫中的頒發(fā)時間早或一樣，則用證書庫中的證書進(jìn)行數(shù)字簽名的驗證即可。否則，繼續(xù)第三步。
(3)用本地根CA的證書驗證源MTA證書鏈最上一層CA的證書，再用后者的證書驗證證書鏈下一層的證書，直至驗證完源MTA的證書為止，若其中有一個驗證失敗，則整個驗證過程失敗。如果，驗證成功，則說明接收端MTA已經(jīng)信任源MTA所發(fā)過來源MTA的證書。在驗證證書的過程中，每一次驗證通過的證書都將其寫入證書庫，可提高下一次證書驗證效率。驗證簽名用上一MTA證書中的公鑰來驗證簽名，用公鑰解密郵件的簽名信息，將解密后的值與郵件的HASH值匹配，如果匹配，則說明簽名驗證成功，如果不匹配，則說明簽名驗證失敗。同時，將簽名驗證的相關(guān)信息做日志。
數(shù)字簽名模塊的功能是報文傳輸代理用其私鑰對所發(fā)出的郵件進(jìn)行數(shù)字簽名。數(shù)字簽名模塊的數(shù)據(jù)流圖如圖7所示MTA對將要發(fā)往下一MTA的郵件用哈希算法算出一個哈希值，然后讀取本MTA的私鑰文件，從私鑰文件里獲取私鑰，用該私鑰對哈希值加密，即對郵件做了數(shù)字簽名。該模塊將郵件的ID號，郵件的簽名信息以及時間等相關(guān)信息傳給日志模塊。其中的哈希算法采用MD5，數(shù)字簽名算法采用RSA，私鑰的位數(shù)為1024位。
日志模塊日志模塊的功能是記錄報文傳輸代理所接收的上一MTA所發(fā)送郵件的證書驗證和簽名驗證信息和報文傳輸代理發(fā)往下一個MTA(報文傳輸代理)的簽名信息。日志模塊的數(shù)據(jù)流圖如圖8所示，對接收郵件的證書、證書驗證信息、發(fā)送該郵件的MTA的域名、郵件的ID號和所接收郵件的數(shù)字簽名信息及記錄到Receive Log文件；對發(fā)送郵件的ID號、數(shù)字簽名信息記錄到Send Log文件。
以上實現(xiàn)，僅為本發(fā)明的較佳實現(xiàn)而已，并非用于限定本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.基于域名層次認(rèn)證機(jī)構(gòu)的郵件傳輸代理原發(fā)抗抵賴方法，其特征在于包括基于DNS域?qū)哟蔚腃A建立步驟、郵件發(fā)送步驟和郵件接收步驟，其中基于DNS域?qū)哟蔚腃A建立步驟(1)根據(jù)需要選擇一個DNS域作為根域建立對應(yīng)的根CA以充當(dāng)信任的根；(2)根據(jù)DNS的層次模型，在根CA下建立與DNS根域的一級子域相應(yīng)的一級子CA，在一級CA下再建立與DNS二級子域相對應(yīng)的二級CA，同樣可根據(jù)需要再建立與DNS三級子域相對應(yīng)的三級CA等，依此類推，最終建立一個與整個DNS域?qū)哟谓Y(jié)構(gòu)對應(yīng)的層次結(jié)構(gòu)的CA；(3)DNS域所對應(yīng)的CA負(fù)責(zé)產(chǎn)生、分配并驗證該域下的所有MTA的證書；郵件發(fā)送步驟(4)源MTA將要發(fā)送的郵件M計算哈希值H＝h(M)，然后用自己的私鑰對H進(jìn)行數(shù)字簽名，數(shù)字簽名信息為sig；(5)源MTA將本域一直到根域下一層次域的證書，形成證書鏈，記做mcerts；(6)源MTA發(fā)送{M，sig，mcerts}到下一MTA，其中，mcerts指附在郵件后面；郵件接收步驟(7)接收端MTA收到后，根據(jù)證書驗證算法，驗證源MTA的證書，若驗證不通過，將證書驗證的相關(guān)信息做日志并將郵件M拋棄，若驗證通過進(jìn)行下一步；(8)接收端MTA從經(jīng)過證書驗證的源MTA的證書中提取公鑰，用公鑰驗證源MTA對M的數(shù)字簽名信息sig，如驗證不通過，將簽名驗證的相關(guān)信息做日志并將郵件M拋棄，若驗證通過進(jìn)行下一步；(9)將郵件M直接寫用戶郵箱或發(fā)往下一MTA，若發(fā)往下一MTA，又從步驟(4)開始。
2.根據(jù)權(quán)利要求1所述的基于DNS域?qū)哟蜟A的郵件傳輸代理原發(fā)抗抵賴方法，其特征在于所述步驟(3)中的數(shù)字證書采用ISO和CCITT/ITU-T的X.509 v3標(biāo)準(zhǔn)格式，并且證書中的身份標(biāo)識采用DNS域名作為MTA的身份標(biāo)識。
3.根據(jù)權(quán)利要求1所述的基于DNS域?qū)哟蜟A的郵件傳輸代理原發(fā)抗抵賴方法，其特征在于所述步驟(3)中證書的生產(chǎn)方法為每個終端實體在申請域名時，由上一級CA直接產(chǎn)生其證書，并且通過安全渠道將MTA被CA簽名的證書和MTA所在域以及上層域直到根域的所有域的證書所構(gòu)成的證書鏈分發(fā)給對應(yīng)MTA。
4.根據(jù)權(quán)利要求1所述的基于DNS域?qū)哟蜟A的郵件傳輸代理原發(fā)抗抵賴方法，其特征在于所述的步驟(5)是將源MTA本域一直到根域下一層次域的證書看成一個整體，記為mcerts。
5.根據(jù)權(quán)利要求1所述的基于DNS域?qū)哟蜟A的郵件傳輸代理原發(fā)抗抵賴方法，其特征在于所述的步驟(7)接收端MTA收到后，根據(jù)證書驗證算法，驗證源MTA的證書的步驟如下(1)首先查看當(dāng)前時間是否還在證書的有效期內(nèi)，如果不是，說明該證書已經(jīng)過期，驗證失敗，否則繼續(xù)第二步；(2)查看本MTA的證書庫中是否已有源MTA的證書，根據(jù)如果有，則比較證書的頒發(fā)時間，如果接收到的證書比證書庫中的頒發(fā)時間早或一樣，則用證書庫中的證書進(jìn)行數(shù)字簽名的驗證即可，否則，繼續(xù)第三步；(3)用本地根CA的證書驗證源MTA證書鏈最上一層CA的證書，再用后者的證書驗證證書鏈下一層的證書，直至驗證完源MTA的證書為止，若其中有一個驗證失敗，則整個驗證過程失敗；如果，驗證成功，則說明接收端MTA已經(jīng)信任源MTA所發(fā)過來源MTA的證書，在驗證證書的過程中，每一次驗證通過的證書都將其寫入證書庫，提高下一次證書驗證效率。
全文摘要
基于域名層次認(rèn)證機(jī)構(gòu)的郵件傳輸代理原發(fā)抗抵賴方法，包括下列步驟基于DNS域?qū)哟蔚腃A建立步驟(1)建立根CA；(2)建立與整個DNS域?qū)哟谓Y(jié)構(gòu)對應(yīng)的層次結(jié)構(gòu)CA；(3)產(chǎn)生、分配MTA證書；郵件發(fā)送步驟(4)源MTA將要發(fā)送的郵件M計算哈希值H，用私鑰對H進(jìn)行數(shù)字簽名，簽名信息為sig；(5)將本域一直到根域下一層次域的證書形成證書鏈mcerts；(6)發(fā)送{M，sig，mcerts}到下一MTA；郵件接收步驟(7)接收端MTA收到后，驗證源MTA證書；(8)從經(jīng)過證書驗證的源MTA證書中提取公鑰，用公鑰驗證源MTA對M的數(shù)字簽名sig；(9)將郵件M直接寫用戶郵箱或發(fā)往下一MTA。本發(fā)明實現(xiàn)MTA與MTA之間強(qiáng)制的原發(fā)抗抵賴性，且具有可縮放的層次CA結(jié)構(gòu)。
文檔編號H04L9/28GK1783848SQ200410009919
公開日2006年6月7日 申請日期2004年12月2日 優(yōu)先權(quán)日2004年12月2日
發(fā)明者李肖堅, 夏春和, 彭紅艷 申請人:北京航空航天大學(xué)