網(wǎng)絡(luò)安全與信息加密技術(shù)-第十九章_第1頁(yè)
網(wǎng)絡(luò)安全與信息加密技術(shù)-第十九章_第2頁(yè)
網(wǎng)絡(luò)安全與信息加密技術(shù)-第十九章_第3頁(yè)
網(wǎng)絡(luò)安全與信息加密技術(shù)-第十九章_第4頁(yè)
網(wǎng)絡(luò)安全與信息加密技術(shù)-第十九章_第5頁(yè)
已閱讀5頁(yè),還剩55頁(yè)未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、q事實(shí)上,在所有的分布式環(huán)境中,電子郵件是最繁重的網(wǎng)事實(shí)上,在所有的分布式環(huán)境中,電子郵件是最繁重的網(wǎng)絡(luò)應(yīng)用。無(wú)論雙方使用何種操作系統(tǒng)和通信軟件,用戶都絡(luò)應(yīng)用。無(wú)論雙方使用何種操作系統(tǒng)和通信軟件,用戶都希望能夠直接或間接與希望能夠直接或間接與Internet連接著的對(duì)方發(fā)送電子郵連接著的對(duì)方發(fā)送電子郵件。隨著對(duì)電子郵件依賴性的爆炸式增長(zhǎng),認(rèn)證性和保密件。隨著對(duì)電子郵件依賴性的爆炸式增長(zhǎng),認(rèn)證性和保密性服務(wù)需求也在日益增長(zhǎng)。兩種被廣泛應(yīng)用的方法:性服務(wù)需求也在日益增長(zhǎng)。兩種被廣泛應(yīng)用的方法:PGP和和S/MIME脫穎而出。本章將闡述這兩種方法。脫穎而出。本章將闡述這兩種方法。主要由主要由Phil

2、 Zimmermann提出的提出的PGP提供了可用于電子郵件和文提供了可用于電子郵件和文件存儲(chǔ)應(yīng)用的保密性和認(rèn)證性?;旧?,件存儲(chǔ)應(yīng)用的保密性和認(rèn)證性?;旧?,Zimmermann做了如下做了如下工作:工作:q1.在構(gòu)建數(shù)據(jù)塊時(shí),選用了最合適、可用的密碼算法。在構(gòu)建數(shù)據(jù)塊時(shí),選用了最合適、可用的密碼算法。q2.將這些算法整合到通用應(yīng)用程序中,這些應(yīng)用程序獨(dú)立于不將這些算法整合到通用應(yīng)用程序中,這些應(yīng)用程序獨(dú)立于不同操作系統(tǒng)和處理器,并且是基于一個(gè)小規(guī)模的易用指令集。同操作系統(tǒng)和處理器,并且是基于一個(gè)小規(guī)模的易用指令集。q3.將其制作成軟件包并形成文檔,包括源代碼。這些資源都可將其制作成軟件包并

3、形成文檔,包括源代碼。這些資源都可以通過以通過Internet,廣告牌和諸如,廣告牌和諸如AOL(America On Line)的商的商用網(wǎng)絡(luò)免費(fèi)獲取。用網(wǎng)絡(luò)免費(fèi)獲取。q4.與與Viacrypt(現(xiàn)在的現(xiàn)在的Network Associates)公司達(dá)成協(xié)議,公司達(dá)成協(xié)議,提供完全兼容、低成本的商用版提供完全兼容、低成本的商用版PGP。19.1 PGPPGP的應(yīng)用迅速普及,呈爆炸式增長(zhǎng)。其原因大致可歸納如下:的應(yīng)用迅速普及,呈爆炸式增長(zhǎng)。其原因大致可歸納如下:q1.提供了在世界范圍內(nèi)的各種免費(fèi)可用的版本,可運(yùn)行于各種提供了在世界范圍內(nèi)的各種免費(fèi)可用的版本,可運(yùn)行于各種平臺(tái),包括平臺(tái),包括Wi

4、ndows,UNIX,Macintosh等。另外,其商等。另外,其商用版滿足了用戶的需求并獲得了商家的支持。用版滿足了用戶的需求并獲得了商家的支持。q2.使用的算法是經(jīng)過廣泛的使用檢驗(yàn)并被認(rèn)為是非常安全的算使用的算法是經(jīng)過廣泛的使用檢驗(yàn)并被認(rèn)為是非常安全的算法。值得指出的是,這個(gè)軟件包中包含了用于公鑰加密的法。值得指出的是,這個(gè)軟件包中包含了用于公鑰加密的RSA,DSS和和Diffie-Hellman算法,用于對(duì)稱加密的算法,用于對(duì)稱加密的CAST-128,IDEA和和3DES算法以及用算法以及用SHA-1做做Hash編碼。編碼。q3.應(yīng)用范圍廣泛,即可用于公司選擇和增強(qiáng)加密文件與消息的應(yīng)用范

5、圍廣泛,即可用于公司選擇和增強(qiáng)加密文件與消息的標(biāo)準(zhǔn)化模式,也可用于個(gè)人通過標(biāo)準(zhǔn)化模式,也可用于個(gè)人通過Internet或其他網(wǎng)絡(luò)進(jìn)行安全或其他網(wǎng)絡(luò)進(jìn)行安全通信。通信。q4.不是由政府或者是標(biāo)準(zhǔn)化組織開發(fā)或控制。對(duì)那些本能地對(duì)不是由政府或者是標(biāo)準(zhǔn)化組織開發(fā)或控制。對(duì)那些本能地對(duì)上述上述“組織組織”有不信任的人們來(lái)說(shuō),有不信任的人們來(lái)說(shuō),PGP非常有吸引力。非常有吸引力。2. 操作描述操作描述q與密鑰管理相對(duì)應(yīng),與密鑰管理相對(duì)應(yīng),PGP的實(shí)際操作由的實(shí)際操作由4類服務(wù)組成:認(rèn)證、類服務(wù)組成:認(rèn)證、保密、壓縮和電子郵件兼容性保密、壓縮和電子郵件兼容性如下表所示如下表所示:q下面我們一一介紹。下面我們

6、一一介紹。認(rèn)證:q下圖描述了下圖描述了PGP提供提供 的數(shù)字簽名服務(wù)。該數(shù)字簽名方案在第的數(shù)字簽名服務(wù)。該數(shù)字簽名方案在第13章討論過章討論過。認(rèn)證過程如下:認(rèn)證過程如下:q1.發(fā)送方生成消息。發(fā)送方生成消息。q2.用用SHA-1算法算法生成生成消息的消息的160位位Hash碼。碼。q3.用發(fā)送方的私鑰按用發(fā)送方的私鑰按RSA算法加密該算法加密該Hash碼并將結(jié)果預(yù)先加碼并將結(jié)果預(yù)先加入到消息中。入到消息中。q4.接收方用發(fā)送方的公鑰按接收方用發(fā)送方的公鑰按RSA算法解密消息并回復(fù)算法解密消息并回復(fù)Hash碼。碼。q5.接收方對(duì)該消息用相同的接收方對(duì)該消息用相同的Hash函數(shù)生成新的函數(shù)生成新

7、的Hash碼,并比碼,并比較該較該Hash碼與解密得到的碼與解密得到的Hash碼,如果兩者碼,如果兩者吻合吻合則該消息為則該消息為可信的??尚诺?。SHA-1和和RSA的結(jié)合提供了一個(gè)高效的數(shù)字簽名方案。鑒于的結(jié)合提供了一個(gè)高效的數(shù)字簽名方案。鑒于RSA的安全強(qiáng)度,接收者可以確信如果是不同的消息必定無(wú)法生成與該的安全強(qiáng)度,接收者可以確信如果是不同的消息必定無(wú)法生成與該Hash碼匹配碼匹配Hash值。于是保證了原消息簽名有效。值。于是保證了原消息簽名有效。qDSS/SHA-1也是生成數(shù)字簽名的可選方案。也是生成數(shù)字簽名的可選方案。q盡管通常情況下簽名都會(huì)附在消息或者是文件中,但也不盡然:盡管通常情

8、況下簽名都會(huì)附在消息或者是文件中,但也不盡然:簽名也可以被分離出來(lái)。一個(gè)分離式簽名可能會(huì)被同對(duì)應(yīng)的消簽名也可以被分離出來(lái)。一個(gè)分離式簽名可能會(huì)被同對(duì)應(yīng)的消息分開存儲(chǔ)或傳輸。這在一些情形下是有用的,例如某用戶可息分開存儲(chǔ)或傳輸。這在一些情形下是有用的,例如某用戶可能希望能為所有發(fā)送或接收到的消息的各分離式簽名建立并保能希望能為所有發(fā)送或接收到的消息的各分離式簽名建立并保持一個(gè)日志。一個(gè)可執(zhí)行程序的分離式簽名可用來(lái)甄別該程序持一個(gè)日志。一個(gè)可執(zhí)行程序的分離式簽名可用來(lái)甄別該程序是否被病毒感染。另外,分離式簽名還可以用于多個(gè)成員對(duì)一是否被病毒感染。另外,分離式簽名還可以用于多個(gè)成員對(duì)一份注入合法契約

9、等文件進(jìn)行簽名,每一個(gè)成員的簽名都是獨(dú)立份注入合法契約等文件進(jìn)行簽名,每一個(gè)成員的簽名都是獨(dú)立的并且只用于該文件,否則簽名可能會(huì)被嵌套,例如第二個(gè)成的并且只用于該文件,否則簽名可能會(huì)被嵌套,例如第二個(gè)成員會(huì)對(duì)文檔和第一個(gè)成員生成的簽名進(jìn)行簽名等。員會(huì)對(duì)文檔和第一個(gè)成員生成的簽名進(jìn)行簽名等。保密:qPGP提供的另一個(gè)服務(wù)是保密,這是通過對(duì)傳輸?shù)南⒒蛘呤翘峁┑牧硪粋€(gè)服務(wù)是保密,這是通過對(duì)傳輸?shù)南⒒蛘呤潜镜卮鎯?chǔ)的文件進(jìn)行加密來(lái)實(shí)現(xiàn)的。在如上兩種情形下對(duì)稱加本地存儲(chǔ)的文件進(jìn)行加密來(lái)實(shí)現(xiàn)的。在如上兩種情形下對(duì)稱加密算法密算法(CAST-128)是可用的。同時(shí),是可用的。同時(shí),IDEA和和3DES也是

10、也用也是也用的。使用的。使用64位密文反饋模式位密文反饋模式(DFB)。通常,設(shè)計(jì)加密時(shí)必須討論密鑰分配的問題。在通常,設(shè)計(jì)加密時(shí)必須討論密鑰分配的問題。在PGP中,每一個(gè)對(duì)中,每一個(gè)對(duì)稱密鑰都只使用一次,這意味著對(duì)每一個(gè)消息都會(huì)隨機(jī)生成一個(gè)稱密鑰都只使用一次,這意味著對(duì)每一個(gè)消息都會(huì)隨機(jī)生成一個(gè)128位的自然數(shù)用作新密鑰。因此,位的自然數(shù)用作新密鑰。因此, 盡管這在標(biāo)準(zhǔn)文檔中是指會(huì)盡管這在標(biāo)準(zhǔn)文檔中是指會(huì)話密鑰,其實(shí)是一次性密鑰。因?yàn)樗皇怯靡淮?,所以?huì)話密鑰會(huì)話密鑰,其實(shí)是一次性密鑰。因?yàn)樗皇怯靡淮?,所以?huì)話密鑰會(huì)和消息綁定并隨之一起傳輸。用接收者的公開密鑰加密以保護(hù)該和消息綁定并隨之一

11、起傳輸。用接收者的公開密鑰加密以保護(hù)該會(huì)會(huì)話話密鑰密鑰如上圖所示如上圖所示。用文字描述如下:。用文字描述如下:q1.發(fā)送者生成消息和僅用于加密該消息的會(huì)話密鑰,該會(huì)話密發(fā)送者生成消息和僅用于加密該消息的會(huì)話密鑰,該會(huì)話密鑰為鑰為128位隨機(jī)自然數(shù)。位隨機(jī)自然數(shù)。q2.采用采用CAST-128(或或IDEA或或3DES)算法,使用該會(huì)話密鑰加算法,使用該會(huì)話密鑰加密消息。密消息。q3.采用采用RSA算法,用接收者的公開密鑰加密該會(huì)話密鑰并預(yù)先算法,用接收者的公開密鑰加密該會(huì)話密鑰并預(yù)先發(fā)送給對(duì)方。發(fā)送給對(duì)方。q4.接收者采用接收者采用RSA算法,用自己的私鑰解密并恢復(fù)會(huì)話密鑰。算法,用自己的私鑰

12、解密并恢復(fù)會(huì)話密鑰。q5.用會(huì)話密鑰解密消息。用會(huì)話密鑰解密消息。作為用于對(duì)密鑰進(jìn)行加密的作為用于對(duì)密鑰進(jìn)行加密的RSA算法的替換,算法的替換,PGP還提供了還提供了Diffie-Hellman算法作為選擇。正如第算法作為選擇。正如第10章中所介紹的那樣,章中所介紹的那樣,Diffie-Hellman是一個(gè)密鑰交換算法。事實(shí)上,是一個(gè)密鑰交換算法。事實(shí)上,PGP使用了大量使用了大量的的Diffie-Hellman來(lái)提供加來(lái)提供加/解密。解密。q上述過程中我們會(huì)發(fā)現(xiàn)一些問題。首先,為了減少加密時(shí)間,上述過程中我們會(huì)發(fā)現(xiàn)一些問題。首先,為了減少加密時(shí)間,對(duì)稱加密和公鑰加密的結(jié)合在效率上優(yōu)于僅僅使用

13、對(duì)稱加密和公鑰加密的結(jié)合在效率上優(yōu)于僅僅使用RSA或者或者ElGamal直接對(duì)消息進(jìn)行加密:直接對(duì)消息進(jìn)行加密:CAST-128和其他對(duì)稱加密算和其他對(duì)稱加密算法遠(yuǎn)快于法遠(yuǎn)快于RSA或或ElGamal。其次,公鑰算法的使用解決了會(huì)話。其次,公鑰算法的使用解決了會(huì)話密鑰分配的問題,因?yàn)橹挥薪邮照卟拍苓€原與消息綁定的會(huì)話密鑰分配的問題,因?yàn)橹挥薪邮照卟拍苓€原與消息綁定的會(huì)話密鑰。值得注意的是,在這里我們不需要使用像在第密鑰。值得注意的是,在這里我們不需要使用像在第14章中討章中討論的會(huì)話密鑰交換協(xié)議,因?yàn)槲覀儾粫?huì)從正在進(jìn)行的會(huì)話中開論的會(huì)話密鑰交換協(xié)議,因?yàn)槲覀儾粫?huì)從正在進(jìn)行的會(huì)話中開始,而是對(duì)每

14、一個(gè)消息都是用獨(dú)立的一次性密鑰。此外,鑒于始,而是對(duì)每一個(gè)消息都是用獨(dú)立的一次性密鑰。此外,鑒于電子郵件存儲(chǔ)轉(zhuǎn)發(fā)的特性,使用握手協(xié)議來(lái)確保通信雙方擁有電子郵件存儲(chǔ)轉(zhuǎn)發(fā)的特性,使用握手協(xié)議來(lái)確保通信雙方擁有相同的會(huì)話密鑰也是不切實(shí)際的。最后,使用一次性對(duì)稱密鑰相同的會(huì)話密鑰也是不切實(shí)際的。最后,使用一次性對(duì)稱密鑰也使原本安全強(qiáng)度較高的對(duì)稱加密方法更安全。每一個(gè)密鑰都也使原本安全強(qiáng)度較高的對(duì)稱加密方法更安全。每一個(gè)密鑰都只加密少量的明文,并且密鑰與密鑰之間沒有任何關(guān)聯(lián)。因此,只加密少量的明文,并且密鑰與密鑰之間沒有任何關(guān)聯(lián)。因此,在某種意義上說(shuō)只要公鑰算法是安全的,那么整個(gè)方案就是安在某種意義上說(shuō)

15、只要公鑰算法是安全的,那么整個(gè)方案就是安全的。全的。q同時(shí),同時(shí),PGP為用戶提供了密鑰長(zhǎng)度從為用戶提供了密鑰長(zhǎng)度從768位到位到3072位范圍之位范圍之間的選擇間的選擇(用于數(shù)字簽名的用于數(shù)字簽名的DSS密鑰限制在密鑰限制在1024位位)。保密性和認(rèn)證性:q如上圖所描述,保密性和認(rèn)證性這兩種服務(wù)可能會(huì)對(duì)同一個(gè)消如上圖所描述,保密性和認(rèn)證性這兩種服務(wù)可能會(huì)對(duì)同一個(gè)消息使用。首先,生成一個(gè)明文的簽名,然后用息使用。首先,生成一個(gè)明文的簽名,然后用CAST-128(或或IDEA或或3DES)對(duì)明文消息和簽名進(jìn)行加密,然后用對(duì)明文消息和簽名進(jìn)行加密,然后用RSA(或或ElGamal)對(duì)會(huì)話密鑰加密。

16、這個(gè)流程比先加密消息然后生成對(duì)會(huì)話密鑰加密。這個(gè)流程比先加密消息然后生成密文的簽名的過程要好。這樣更便于保存明文消息的簽名。密文的簽名的過程要好。這樣更便于保存明文消息的簽名。1.生成簽名在壓縮之前進(jìn)行是由于如下兩個(gè)原因:生成簽名在壓縮之前進(jìn)行是由于如下兩個(gè)原因:qa.對(duì)未壓縮的消息進(jìn)行簽名更有利于僅存儲(chǔ)未壓縮消息和簽名對(duì)未壓縮的消息進(jìn)行簽名更有利于僅存儲(chǔ)未壓縮消息和簽名以便未來(lái)的簽名驗(yàn)證。以便未來(lái)的簽名驗(yàn)證。假如假如壓縮后對(duì)文檔簽名,那么必須要么壓縮后對(duì)文檔簽名,那么必須要么存儲(chǔ)消息的一個(gè)壓縮版或者是當(dāng)需要時(shí)對(duì)消息重新壓縮以便驗(yàn)存儲(chǔ)消息的一個(gè)壓縮版或者是當(dāng)需要時(shí)對(duì)消息重新壓縮以便驗(yàn)證簽名。證

17、簽名。qb.即使有用戶愿意為驗(yàn)證簽名動(dòng)態(tài)的生成消息的壓縮版,即使有用戶愿意為驗(yàn)證簽名動(dòng)態(tài)的生成消息的壓縮版,PGP的壓縮算法也表現(xiàn)出不合適。因?yàn)樵撍惴ㄊ遣淮_定的,在運(yùn)行的壓縮算法也表現(xiàn)出不合適。因?yàn)樵撍惴ㄊ遣淮_定的,在運(yùn)行速度和壓縮比之間權(quán)衡時(shí)會(huì)產(chǎn)生該算法各種不同形式的實(shí)現(xiàn)。速度和壓縮比之間權(quán)衡時(shí)會(huì)產(chǎn)生該算法各種不同形式的實(shí)現(xiàn)。但是,這些不同的算法實(shí)現(xiàn)是可以同時(shí)使用的,因?yàn)樵撍惴ǖ牡?,這些不同的算法實(shí)現(xiàn)是可以同時(shí)使用的,因?yàn)樵撍惴ǖ娜魏伟姹径伎梢哉_的解壓縮任何其他版本的壓縮文件。在任何版本都可以正確的解壓縮任何其他版本的壓縮文件。在Hash函數(shù)和簽名之后使用可以使所有的函數(shù)和簽名之后使用可

18、以使所有的PGP實(shí)現(xiàn)都統(tǒng)一使用實(shí)現(xiàn)都統(tǒng)一使用一種版本的壓縮算法。一種版本的壓縮算法。2.在壓縮之后對(duì)消息進(jìn)行加密是為了增強(qiáng)密碼運(yùn)算的安全性。因?yàn)樵趬嚎s之后對(duì)消息進(jìn)行加密是為了增強(qiáng)密碼運(yùn)算的安全性。因?yàn)閴嚎s后的消息比原明文的信息冗余少,這讓密碼分析更加困難。壓縮后的消息比原明文的信息冗余少,這讓密碼分析更加困難。q所使用的壓縮算法所使用的壓縮算法ZIP將在附錄將在附錄0中有介紹。中有介紹。電子郵件兼容性:q當(dāng)當(dāng)使用使用PGP時(shí),數(shù)據(jù)塊中至少被傳輸?shù)哪遣糠謺?huì)被加密時(shí),數(shù)據(jù)塊中至少被傳輸?shù)哪遣糠謺?huì)被加密。假如。假如使用了數(shù)字簽名服務(wù),那么使用了數(shù)字簽名服務(wù),那么消息的摘要會(huì)用發(fā)送者的私鑰加密。消息的

19、摘要會(huì)用發(fā)送者的私鑰加密。假如使用了保密服務(wù),那么消息和簽名假如使用了保密服務(wù),那么消息和簽名(如果有簽名的話如果有簽名的話)會(huì)用會(huì)用一次性對(duì)稱密鑰加密。因此,數(shù)據(jù)塊的整體或部分會(huì)由任意的一次性對(duì)稱密鑰加密。因此,數(shù)據(jù)塊的整體或部分會(huì)由任意的8字節(jié)流組成。但是大多數(shù)的電子郵件系統(tǒng)都只允許使用由字節(jié)流組成。但是大多數(shù)的電子郵件系統(tǒng)都只允許使用由ACSII文本組成的數(shù)據(jù)塊。為了適應(yīng)限制,文本組成的數(shù)據(jù)塊。為了適應(yīng)限制,PGP提供了將原字提供了將原字節(jié)流轉(zhuǎn)換成可打印的節(jié)流轉(zhuǎn)換成可打印的ASCII字符流的服務(wù)。字符流的服務(wù)。qRadix-64就是用于該目的的解決方案。每三個(gè)字節(jié)組成的二就是用于該目的的

20、解決方案。每三個(gè)字節(jié)組成的二進(jìn)制數(shù)據(jù)可以映射成四個(gè)進(jìn)制數(shù)據(jù)可以映射成四個(gè)ASCII字符。這種格式也附加了字符。這種格式也附加了CRC校驗(yàn)碼用來(lái)檢查傳輸錯(cuò)誤。校驗(yàn)碼用來(lái)檢查傳輸錯(cuò)誤。q下圖顯示了到目前為止討論的下圖顯示了到目前為止討論的4種服務(wù)之間的關(guān)系。種服務(wù)之間的關(guān)系。q在傳輸方,假如需要可以生產(chǎn)一個(gè)明文的在傳輸方,假如需要可以生產(chǎn)一個(gè)明文的Hash碼用作簽名。碼用作簽名。然后壓縮明文然后壓縮明文(如果有簽名就加上簽名如果有簽名就加上簽名)。接著,如果有保密性。接著,如果有保密性要求,這個(gè)數(shù)據(jù)塊要求,這個(gè)數(shù)據(jù)塊(壓縮了的明文或者是壓縮了簽名和明文的壓縮了的明文或者是壓縮了簽名和明文的集合集合

21、)就用對(duì)稱密鑰加密,而該對(duì)稱密鑰則是預(yù)先用就用對(duì)稱密鑰加密,而該對(duì)稱密鑰則是預(yù)先用公鑰公鑰加密加密的。最后,將整個(gè)數(shù)據(jù)塊轉(zhuǎn)換成的。最后,將整個(gè)數(shù)據(jù)塊轉(zhuǎn)換成Radix-64格式。格式。q在接收在接收方,首先把接收到的數(shù)據(jù)塊由方,首先把接收到的數(shù)據(jù)塊由Radix-64格式轉(zhuǎn)換成二格式轉(zhuǎn)換成二進(jìn)制。然后,假如消息是加密的,那么接收者就用自己的私鑰進(jìn)制。然后,假如消息是加密的,那么接收者就用自己的私鑰恢復(fù)出會(huì)話密鑰并用會(huì)話密鑰解密消息。然后把得到的結(jié)果解恢復(fù)出會(huì)話密鑰并用會(huì)話密鑰解密消息。然后把得到的結(jié)果解壓。假如消息是簽名的,那么接收者就恢復(fù)出傳輸過來(lái)的壓。假如消息是簽名的,那么接收者就恢復(fù)出傳輸過

22、來(lái)的Hash碼并且與自己計(jì)算的碼并且與自己計(jì)算的Hash碼進(jìn)行比較。碼進(jìn)行比較。qS/MIME(Secure/Multipurpose Internet Mail Extension)是對(duì)基于是對(duì)基于RSA數(shù)據(jù)安全的數(shù)據(jù)安全的MIME Internet電子郵件格式標(biāo)準(zhǔn)電子郵件格式標(biāo)準(zhǔn)的安全性增強(qiáng)。盡管的安全性增強(qiáng)。盡管PGP和和S/MIME都是都是IETF工作組推出的工作組推出的標(biāo)準(zhǔn),但是標(biāo)準(zhǔn),但是S/MIME傾向于推廣為商業(yè)或組織用于的工業(yè)標(biāo)準(zhǔn),傾向于推廣為商業(yè)或組織用于的工業(yè)標(biāo)準(zhǔn),而而PGP則用來(lái)為個(gè)人電子郵件安全提供服務(wù)選擇。則用來(lái)為個(gè)人電子郵件安全提供服務(wù)選擇。S/MIME在在很多的文

23、檔中被定義了,其中最重要的是很多的文檔中被定義了,其中最重要的是RFC 3370,3850, 3851和和3852。q為了理解為了理解S/MIME,我們首先得對(duì)其使用的電子郵件格式,我們首先得對(duì)其使用的電子郵件格式(即即MIME)有一個(gè)大概的理解。但是為了理解有一個(gè)大概的理解。但是為了理解MIME的重要性,又的重要性,又將回到傳統(tǒng)的電子郵件格式標(biāo)準(zhǔn)將回到傳統(tǒng)的電子郵件格式標(biāo)準(zhǔn)(RFC 822),而該標(biāo)準(zhǔn)仍然廣,而該標(biāo)準(zhǔn)仍然廣泛使用。最新版本的格式規(guī)范是泛使用。最新版本的格式規(guī)范是RFC 5322(Internet消息格消息格式式)。因此,本節(jié)將首先介紹那兩個(gè)較早的標(biāo)準(zhǔn)然后再開始討。因此,本節(jié)將

24、首先介紹那兩個(gè)較早的標(biāo)準(zhǔn)然后再開始討論論S/MIME。19.2 S/MIME1. RFC 5322qRFC 5322定義了用電子郵件發(fā)送的文本消息的格式。這已經(jīng)定義了用電子郵件發(fā)送的文本消息的格式。這已經(jīng)是基于是基于Internet的文本郵件消息的標(biāo)準(zhǔn)并且仍然在廣泛使用。的文本郵件消息的標(biāo)準(zhǔn)并且仍然在廣泛使用。在在RFC 5322中,消息被視為一個(gè)信封和內(nèi)容的組合。信封包中,消息被視為一個(gè)信封和內(nèi)容的組合。信封包含了任何用來(lái)完成傳輸和發(fā)送功能的信息。內(nèi)容則含了任何用來(lái)完成傳輸和發(fā)送功能的信息。內(nèi)容則構(gòu)成構(gòu)成了發(fā)送了發(fā)送給接收者的對(duì)象。給接收者的對(duì)象。RFC 5322標(biāo)準(zhǔn)關(guān)注的是內(nèi)容部分。但是,

25、標(biāo)準(zhǔn)關(guān)注的是內(nèi)容部分。但是,內(nèi)容標(biāo)準(zhǔn)包含了一系列內(nèi)容標(biāo)準(zhǔn)包含了一系列頭域頭域,這些頭域是由郵件系統(tǒng)用來(lái)生成,這些頭域是由郵件系統(tǒng)用來(lái)生成信封的,而該標(biāo)準(zhǔn)也致力于使程序獲取頭域信息更方便。信封的,而該標(biāo)準(zhǔn)也致力于使程序獲取頭域信息更方便。q符合符合RFC 5322的消息的大體結(jié)構(gòu)非常簡(jiǎn)單。一個(gè)消息包含了的消息的大體結(jié)構(gòu)非常簡(jiǎn)單。一個(gè)消息包含了若干行的頭部若干行的頭部(the head)和隨后的無(wú)限制的正文和隨后的無(wú)限制的正文(the body)。頭部和正文中間用一空行隔開。另外,消息是頭部和正文中間用一空行隔開。另外,消息是ASCII文本,第文本,第一個(gè)空行之上的所有行都是郵件系統(tǒng)中用戶代理部分

26、使用的頭一個(gè)空行之上的所有行都是郵件系統(tǒng)中用戶代理部分使用的頭部行。部行。q頭部行通常包含關(guān)鍵字、冒號(hào)和關(guān)鍵字的參數(shù),該格式允許將頭部行通常包含關(guān)鍵字、冒號(hào)和關(guān)鍵字的參數(shù),該格式允許將一個(gè)長(zhǎng)行分割成若干短行。使用最頻繁的關(guān)鍵字是一個(gè)長(zhǎng)行分割成若干短行。使用最頻繁的關(guān)鍵字是From,To,Subject和和Date。例如:。例如:q在在RFC 5322中常見的另一個(gè)域是消息標(biāo)志中常見的另一個(gè)域是消息標(biāo)志(Message-ID),該域包含一個(gè)與該消息關(guān)聯(lián)的唯一標(biāo)志符。該域包含一個(gè)與該消息關(guān)聯(lián)的唯一標(biāo)志符。2. MIMEMIME是是RFC 5322的擴(kuò)展,目的是解決一些因使用簡(jiǎn)單郵件傳輸?shù)臄U(kuò)展,目的

27、是解決一些因使用簡(jiǎn)單郵件傳輸協(xié)議協(xié)議(SMTP,在,在RFC 821中定義中定義)或其他一些郵件傳輸協(xié)議而產(chǎn)生或其他一些郵件傳輸協(xié)議而產(chǎn)生的限制。參考文獻(xiàn)列出了的限制。參考文獻(xiàn)列出了SMTP/5322方案的限制。方案的限制。q1.SMTP不能傳輸可執(zhí)行文件和其他二進(jìn)制對(duì)象。不能傳輸可執(zhí)行文件和其他二進(jìn)制對(duì)象。SMTP郵件郵件系統(tǒng)使用了很多用來(lái)將二進(jìn)制文件轉(zhuǎn)換為文本格式的方案,包系統(tǒng)使用了很多用來(lái)將二進(jìn)制文件轉(zhuǎn)換為文本格式的方案,包括聞名的括聞名的UNIX UUencode/UUdecode方案。但是,沒有一方案。但是,沒有一個(gè)個(gè)成成為標(biāo)準(zhǔn)或者事實(shí)上的標(biāo)準(zhǔn)。為標(biāo)準(zhǔn)或者事實(shí)上的標(biāo)準(zhǔn)。q2.SMTP

28、不能傳輸含有國(guó)際語(yǔ)言字符的文本數(shù)據(jù),因?yàn)檫@些字不能傳輸含有國(guó)際語(yǔ)言字符的文本數(shù)據(jù),因?yàn)檫@些字符是由符是由8位碼表示的,其值可能是十進(jìn)制位碼表示的,其值可能是十進(jìn)制128或者更大的數(shù),或者更大的數(shù),而而SMTP只能用只能用7位的位的ASCII碼。碼。q3.SMTP服務(wù)器會(huì)拒絕超過一定尺寸的消息。服務(wù)器會(huì)拒絕超過一定尺寸的消息。q4.ASCII碼和碼和EBCDIC碼之間轉(zhuǎn)換的碼之間轉(zhuǎn)換的SMTP網(wǎng)關(guān)并未使用一致網(wǎng)關(guān)并未使用一致的映射集,因此常會(huì)出現(xiàn)轉(zhuǎn)換錯(cuò)誤。的映射集,因此常會(huì)出現(xiàn)轉(zhuǎn)換錯(cuò)誤。q5.X.400電子郵件網(wǎng)絡(luò)的電子郵件網(wǎng)絡(luò)的SMTP網(wǎng)關(guān)不能處理網(wǎng)關(guān)不能處理X.400消息中的消息中的非文本非

29、文本數(shù)據(jù)。數(shù)據(jù)。q6.一些一些SMTP的實(shí)現(xiàn)并沒有嚴(yán)格遵守的實(shí)現(xiàn)并沒有嚴(yán)格遵守RFC 821文檔中定義的文檔中定義的SMTP標(biāo)準(zhǔn),因此會(huì)導(dǎo)致以下常見的問題:標(biāo)準(zhǔn),因此會(huì)導(dǎo)致以下常見的問題:q回車和換行的刪除、添加和重排?;剀嚭蛽Q行的刪除、添加和重排。q截?cái)嘟財(cái)嗷蛘呤窍拗瞥^或者是限制超過76個(gè)字符長(zhǎng)度的行。個(gè)字符長(zhǎng)度的行。q去除白字符去除白字符(制表符和空格符制表符和空格符)。q將將消息中的行填充為等長(zhǎng)。消息中的行填充為等長(zhǎng)。q將制表符轉(zhuǎn)換成多個(gè)空格符。將制表符轉(zhuǎn)換成多個(gè)空格符。MIME期望能解決上述這些問題并與現(xiàn)存的期望能解決上述這些問題并與現(xiàn)存的RFC 5322實(shí)現(xiàn)兼容。實(shí)現(xiàn)兼容。概述:M

30、IME規(guī)范包含以下要素:規(guī)范包含以下要素:q1.定義了定義了5個(gè)新的頭部域,這些域提供了消息正文的相關(guān)信息。個(gè)新的頭部域,這些域提供了消息正文的相關(guān)信息。q2.定義了一些新的內(nèi)容格式,標(biāo)準(zhǔn)化的表示支持了多媒體的電定義了一些新的內(nèi)容格式,標(biāo)準(zhǔn)化的表示支持了多媒體的電子郵件。子郵件。q3.定義了編碼轉(zhuǎn)換方式,以使郵件系統(tǒng)能將任何形式的內(nèi)容定義了編碼轉(zhuǎn)換方式,以使郵件系統(tǒng)能將任何形式的內(nèi)容統(tǒng)統(tǒng)一一地轉(zhuǎn)換為另一種形式。地轉(zhuǎn)換為另一種形式。在本小節(jié)中,在本小節(jié)中, 我們將介紹這我們將介紹這5個(gè)頭部域,在隨后的兩個(gè)個(gè)頭部域,在隨后的兩個(gè)小節(jié)小節(jié)將討論將討論內(nèi)容格式和編碼轉(zhuǎn)換方式:內(nèi)容格式和編碼轉(zhuǎn)換方式:q

31、MIME-Version(MIME版本版本):參數(shù)的值必須為參數(shù)的值必須為1.0,該域表,該域表明消息遵循明消息遵循RFC 2045和和RFC 2046的格式。的格式。qContent-Type(內(nèi)容類型內(nèi)容類型):詳細(xì)地描述了正文中的數(shù)據(jù)以使詳細(xì)地描述了正文中的數(shù)據(jù)以使接收方的代理能采用合適的代理或機(jī)制來(lái)為用戶展示數(shù)據(jù)或以接收方的代理能采用合適的代理或機(jī)制來(lái)為用戶展示數(shù)據(jù)或以一個(gè)合適的方法來(lái)處理數(shù)據(jù)。一個(gè)合適的方法來(lái)處理數(shù)據(jù)。qContent-Transer-Encoding(內(nèi)容轉(zhuǎn)換編碼內(nèi)容轉(zhuǎn)換編碼):指示轉(zhuǎn)換的類指示轉(zhuǎn)換的類型以使其能將消息正文的展現(xiàn)形式可為郵件傳輸所用。型以使其能將消息

32、正文的展現(xiàn)形式可為郵件傳輸所用。qContent-ID(內(nèi)容標(biāo)志內(nèi)容標(biāo)志):在多重上下文中唯一標(biāo)志在多重上下文中唯一標(biāo)志MIME實(shí)實(shí)體。體。qContent-Description(內(nèi)容描述內(nèi)容描述):正文對(duì)象的文本描述,這正文對(duì)象的文本描述,這對(duì)于對(duì)象是不可讀的情形是很有用的對(duì)于對(duì)象是不可讀的情形是很有用的(如音頻數(shù)據(jù)如音頻數(shù)據(jù))。通常在一個(gè)通常在一個(gè)RFC 5322頭中會(huì)出現(xiàn)一個(gè)或多個(gè)上述域。一個(gè)合適的頭中會(huì)出現(xiàn)一個(gè)或多個(gè)上述域。一個(gè)合適的實(shí)現(xiàn)實(shí)現(xiàn)必須支持必須支持MIME-Version,Content-Type,Content-Transfer-Encoding域,接收方的實(shí)現(xiàn)可以選擇使

33、用或忽略域,接收方的實(shí)現(xiàn)可以選擇使用或忽略Content-ID和和Content-Description域。域。MIME內(nèi)容類型:qMIME規(guī)范文檔中有很大的篇幅是關(guān)于各種內(nèi)容類型的定義。規(guī)范文檔中有很大的篇幅是關(guān)于各種內(nèi)容類型的定義。這也反映了在多媒體環(huán)境下提供處理各種信息展現(xiàn)形式的需求。這也反映了在多媒體環(huán)境下提供處理各種信息展現(xiàn)形式的需求。q下表列出了下表列出了RFC 2046中規(guī)定的內(nèi)容類型。主要有中規(guī)定的內(nèi)容類型。主要有7個(gè)不同的個(gè)不同的大類和總共大類和總共15個(gè)子類。一般而言,用內(nèi)容類型表示數(shù)據(jù)的通用個(gè)子類。一般而言,用內(nèi)容類型表示數(shù)據(jù)的通用類型,用子類型來(lái)表示該數(shù)據(jù)類型的特定格式

34、。類型,用子類型來(lái)表示該數(shù)據(jù)類型的特定格式。q若正文為文本類型若正文為文本類型(text type),則除了要支持制定字符集外,則除了要支持制定字符集外不需要特殊的軟件來(lái)獲取文字的全部意義,因此主要的子類型不需要特殊的軟件來(lái)獲取文字的全部意義,因此主要的子類型為純文本為純文本(plain text),有簡(jiǎn)單的,有簡(jiǎn)單的ASCII碼或碼或ISO 8859字符字符組成的字符串。子類型組成的字符串。子類型enriched則允許擁有更多的格式信息。則允許擁有更多的格式信息。q類型為多部分類型類型為多部分類型(multipart type)時(shí),表示正文中包含多個(gè)時(shí),表示正文中包含多個(gè)相互獨(dú)立的部分。域相

35、互獨(dú)立的部分。域Content-Type中包含一個(gè)稱為分界符的中包含一個(gè)稱為分界符的參數(shù),該分界符定義了正文中各部分的分隔符。此分隔符不能參數(shù),該分界符定義了正文中各部分的分隔符。此分隔符不能隨意出現(xiàn),而必須從一個(gè)新行開始,并在兩個(gè)連字符后跟隨意出現(xiàn),而必須從一個(gè)新行開始,并在兩個(gè)連字符后跟分界分界符值,最后一個(gè)分界符表示最后一部分的結(jié)尾,并有兩個(gè)連字符值,最后一個(gè)分界符表示最后一部分的結(jié)尾,并有兩個(gè)連字符做后綴。在每個(gè)部分,可以有一個(gè)通常的符做后綴。在每個(gè)部分,可以有一個(gè)通常的MIME頭部。頭部。q以下是一個(gè)多部分消息的簡(jiǎn)單例子,包含由簡(jiǎn)單文本組成的兩以下是一個(gè)多部分消息的簡(jiǎn)單例子,包含由簡(jiǎn)

36、單文本組成的兩個(gè)部分:個(gè)部分:qMultipart類型有類型有4種子類型,其語(yǔ)法相同。子類型種子類型,其語(yǔ)法相同。子類型multipart/mixed用于將相互獨(dú)立的各部分按一定的順序綁用于將相互獨(dú)立的各部分按一定的順序綁定。子類型定。子類型multipart/parallel表示各部分的順序無(wú)關(guān)。如果表示各部分的順序無(wú)關(guān)。如果接受系統(tǒng)合適,則各部分可以并行接收。例如,在圖片或文本接受系統(tǒng)合適,則各部分可以并行接收。例如,在圖片或文本顯示時(shí),可同時(shí)播放音頻。顯示時(shí),可同時(shí)播放音頻。q子類型子類型multipart/alternative表示這若干個(gè)部分是同一個(gè)信表示這若干個(gè)部分是同一個(gè)信息的不

37、同表示。例如:息的不同表示。例如:q在此子類型中,各部分按優(yōu)先級(jí)遞增的方式排序。例如,如果在此子類型中,各部分按優(yōu)先級(jí)遞增的方式排序。例如,如果接收方可以處理接收方可以處理text/enriched格式的信息,則按此格式處理,格式的信息,則按此格式處理,否則就使用純文本方式。否則就使用純文本方式。q子類型子類型multipart/digest用于將正文的每個(gè)部分作為一個(gè)帶用于將正文的每個(gè)部分作為一個(gè)帶頭部的頭部的RFC 5322消息,從而使得一個(gè)消息中可以包含多個(gè)獨(dú)消息,從而使得一個(gè)消息中可以包含多個(gè)獨(dú)立的消息。例如,可以用一組緩沖器搜集組中各成員的電子郵立的消息。例如,可以用一組緩沖器搜集組

38、中各成員的電子郵件消息并將其封裝到一個(gè)件消息并將其封裝到一個(gè)MIME消息中發(fā)送。消息中發(fā)送。q類型類型message提供了許多提供了許多MIME的重要特征。子類型的重要特征。子類型message/rfc822表明該正文是一個(gè)完整的消息,包含了頭和表明該正文是一個(gè)完整的消息,包含了頭和正文。除了子類型的名字外,封裝的消息即可以是正文。除了子類型的名字外,封裝的消息即可以是RFC 5322消息,也可以是任何消息,也可以是任何MIME消息。消息。q子類型子類型message/partial使得可以使得可以將將一個(gè)大消息分段為若干部一個(gè)大消息分段為若干部分,并可以在目的地重新組裝。對(duì)這個(gè)子類型而言,分

39、,并可以在目的地重新組裝。對(duì)這個(gè)子類型而言,Content-Type:Message/partial域需要說(shuō)明三個(gè)參數(shù):一域需要說(shuō)明三個(gè)參數(shù):一個(gè)對(duì)同一個(gè)消息所有分片一致的標(biāo)志個(gè)對(duì)同一個(gè)消息所有分片一致的標(biāo)志id,一個(gè)每段唯一的序列,一個(gè)每段唯一的序列號(hào)號(hào)sequence number和總的段數(shù)和總的段數(shù)total。q子類型子類型message/external-body表明消息所要表達(dá)的數(shù)據(jù)并表明消息所要表達(dá)的數(shù)據(jù)并未包含在該正文中。而是在正文中包含了對(duì)該數(shù)據(jù)的訪問。和未包含在該正文中。而是在正文中包含了對(duì)該數(shù)據(jù)的訪問。和其他消息類型一樣,子類型其他消息類型一樣,子類型message/ext

40、ernal-body也有一也有一個(gè)外頭部和包含其頭部的封裝。外頭部中唯一必須的域?yàn)閮?nèi)容個(gè)外頭部和包含其頭部的封裝。外頭部中唯一必須的域?yàn)閮?nèi)容類型類型(Content-Type)域,它指示了子類型域,它指示了子類型message/external-body。內(nèi)頭部是封裝消息的頭部。外頭。內(nèi)頭部是封裝消息的頭部。外頭部中的內(nèi)容類型部中的內(nèi)容類型(Content-Type)域必須包含一個(gè)訪問類型域必須包含一個(gè)訪問類型(access-type)參數(shù),它指示了訪問方法,例如參數(shù),它指示了訪問方法,例如FTP(文件傳輸文件傳輸協(xié)議協(xié)議)。q類型類型application是指其他類型的數(shù)據(jù),如不能解釋的二進(jìn)

41、制是指其他類型的數(shù)據(jù),如不能解釋的二進(jìn)制數(shù)據(jù)或由郵件應(yīng)用程序處理的信息。數(shù)據(jù)或由郵件應(yīng)用程序處理的信息。MIME轉(zhuǎn)換編碼:qMIME規(guī)范中另一個(gè)主要部分是定義消息正文的轉(zhuǎn)換編碼。其規(guī)范中另一個(gè)主要部分是定義消息正文的轉(zhuǎn)換編碼。其目的是在龐大的網(wǎng)絡(luò)環(huán)境中提供可靠的傳輸方式。目的是在龐大的網(wǎng)絡(luò)環(huán)境中提供可靠的傳輸方式。qMIME標(biāo)準(zhǔn)定義了兩種編碼方式,但標(biāo)準(zhǔn)定義了兩種編碼方式,但Content-Transfer-Encoding域可以取域可以取6個(gè)值,如下表所示。個(gè)值,如下表所示。q其中當(dāng)值為其中當(dāng)值為7位,位,8位和位和binary時(shí),并不進(jìn)行編碼,而是提供時(shí),并不進(jìn)行編碼,而是提供一些與數(shù)據(jù)屬

42、性相關(guān)的信息。對(duì)一些與數(shù)據(jù)屬性相關(guān)的信息。對(duì)SMTP傳輸而言,用傳輸而言,用7位比較位比較安全,而在其他郵件傳輸協(xié)議中可以使用安全,而在其他郵件傳輸協(xié)議中可以使用8位和位和binary格式。格式。qContent-Transfer-encoding域也可以取值域也可以取值x-token,用來(lái),用來(lái)表示其他編碼方式,并提供該方式的名字。這種方式可以是生表示其他編碼方式,并提供該方式的名字。這種方式可以是生產(chǎn)商規(guī)定的或應(yīng)用程序規(guī)定的方式。目前,有兩種方式:產(chǎn)商規(guī)定的或應(yīng)用程序規(guī)定的方式。目前,有兩種方式:quoted-printable和和Base64,它們都是為了提供一種將所有,它們都是為了提供

43、一種將所有數(shù)據(jù)類型的緊湊表示轉(zhuǎn)換為便于人們閱讀的形式而設(shè)計(jì)的。數(shù)據(jù)類型的緊湊表示轉(zhuǎn)換為便于人們閱讀的形式而設(shè)計(jì)的。qquoted-printable轉(zhuǎn)換編碼使用數(shù)據(jù)由大量可打印的轉(zhuǎn)換編碼使用數(shù)據(jù)由大量可打印的ASCII字符組成。其本質(zhì)上是一種不安全的十六進(jìn)制字符表示方法。字符組成。其本質(zhì)上是一種不安全的十六進(jìn)制字符表示方法。并引入軟回車來(lái)解決每行不得超過并引入軟回車來(lái)解決每行不得超過76個(gè)字符的限制。個(gè)字符的限制。qBase64轉(zhuǎn)換編碼是一種轉(zhuǎn)換編碼是一種Radix-64的編碼方式,是一種對(duì)二進(jìn)的編碼方式,是一種對(duì)二進(jìn)制數(shù)據(jù)進(jìn)行編碼的通用方法,在郵件傳輸過程中無(wú)懈可擊,也制數(shù)據(jù)進(jìn)行編碼的通用方

44、法,在郵件傳輸過程中無(wú)懈可擊,也用于用于PGP。規(guī)范格式:q規(guī)范格式是規(guī)范格式是MIME和和S/MIME的一個(gè)重要概念。規(guī)范格式指的的一個(gè)重要概念。規(guī)范格式指的是一種與內(nèi)容類型相對(duì)應(yīng)的格式,可以在系統(tǒng)中作為標(biāo)準(zhǔn)使用。是一種與內(nèi)容類型相對(duì)應(yīng)的格式,可以在系統(tǒng)中作為標(biāo)準(zhǔn)使用。下表可說(shuō)明此問題。下表可說(shuō)明此問題。3. S/MIME功能功能q就大體功能而言,就大體功能而言,S/MIME與與PGP非常非常相似。兩者都提供了簽相似。兩者都提供了簽名和加密消息的能力。在本節(jié)中我們將簡(jiǎn)要介紹名和加密消息的能力。在本節(jié)中我們將簡(jiǎn)要介紹S/MIME的功的功能,然后再?gòu)南⒏袷降南?zhǔn)備方面詳細(xì)敘述每個(gè)功能。能,然

45、后再?gòu)南⒏袷降南?zhǔn)備方面詳細(xì)敘述每個(gè)功能。功能:S/MIME有如下功能:有如下功能:q封裝數(shù)據(jù):封裝數(shù)據(jù):由任何類型的加密內(nèi)容和加密該內(nèi)容所用的加密由任何類型的加密內(nèi)容和加密該內(nèi)容所用的加密密密鑰鑰組成,組成,密鑰密鑰可以是與一個(gè)或多個(gè)接收方的秘鑰。可以是與一個(gè)或多個(gè)接收方的秘鑰。q簽名數(shù)據(jù):簽名數(shù)據(jù):數(shù)字簽名通過提取待簽名內(nèi)容的數(shù)字摘要,并用簽數(shù)字簽名通過提取待簽名內(nèi)容的數(shù)字摘要,并用簽名的私鑰加密得到。然后用名的私鑰加密得到。然后用Base64編碼方法重新對(duì)內(nèi)容和簽編碼方法重新對(duì)內(nèi)容和簽名編碼。因此,一個(gè)簽名了的數(shù)據(jù)消息只能被具有名編碼。因此,一個(gè)簽名了的數(shù)據(jù)消息只能被具有S/MIME

46、能能力的接收方處理。力的接收方處理。q透明簽名數(shù)據(jù):透明簽名數(shù)據(jù):簽名的數(shù)據(jù)形成了內(nèi)容的數(shù)字簽名。但在這種簽名的數(shù)據(jù)形成了內(nèi)容的數(shù)字簽名。但在這種情況下,只有數(shù)字簽名采用了情況下,只有數(shù)字簽名采用了Base64編碼,因此沒有編碼,因此沒有S/MIME能力的接收方雖然無(wú)法驗(yàn)證簽名但卻可以看到消息內(nèi)能力的接收方雖然無(wú)法驗(yàn)證簽名但卻可以看到消息內(nèi)容。容。q簽名并封裝數(shù)據(jù):簽名并封裝數(shù)據(jù):僅簽名實(shí)體和僅封裝實(shí)體可以嵌套,能對(duì)加僅簽名實(shí)體和僅封裝實(shí)體可以嵌套,能對(duì)加密后的數(shù)據(jù)進(jìn)行簽名和對(duì)簽名后的數(shù)據(jù)或透明簽名數(shù)據(jù)進(jìn)行加密后的數(shù)據(jù)進(jìn)行簽名和對(duì)簽名后的數(shù)據(jù)或透明簽名數(shù)據(jù)進(jìn)行加密。密。密碼算法:q下下表總結(jié)了

47、在表總結(jié)了在S/MIME中使用的密碼算法。中使用的密碼算法。S/MIME中使用了如下術(shù)語(yǔ):中使用了如下術(shù)語(yǔ):qMust:在規(guī)范說(shuō)明書中表示一定要滿足的要求,其實(shí)現(xiàn)必須在規(guī)范說(shuō)明書中表示一定要滿足的要求,其實(shí)現(xiàn)必須與規(guī)范說(shuō)明中的功能一致。與規(guī)范說(shuō)明中的功能一致。qShould:如果在特定條件下有合理的理由也可以忽略,但推如果在特定條件下有合理的理由也可以忽略,但推薦其實(shí)現(xiàn)包含該功能。薦其實(shí)現(xiàn)包含該功能。qS/MIME整合了三種公鑰算法。第整合了三種公鑰算法。第13章的章的DSS(Digital Signature Standard)是其推薦的數(shù)字簽名算法。是其推薦的數(shù)字簽名算法。Diffie-H

48、ellman是其推薦的是其推薦的密鑰密鑰交換算法。實(shí)際上,在交換算法。實(shí)際上,在S/MIME中使中使用的是其能加密解密的用的是其能加密解密的變體變體ElGamal(詳見第詳見第10章章)。第。第9章講章講述的述的RSA既可以用來(lái)做簽名,也可以用來(lái)加密會(huì)話密鑰。這些既可以用來(lái)做簽名,也可以用來(lái)加密會(huì)話密鑰。這些算法與算法與PGP中使用的算法相同,提供了高層安全性。文檔規(guī)范中使用的算法相同,提供了高層安全性。文檔規(guī)范推薦使用推薦使用160位的位的SHA-1算法作為數(shù)字簽名的算法作為數(shù)字簽名的Hash函數(shù),但函數(shù),但是要求接收方能支持是要求接收方能支持128位的位的MD5算法。第算法。第11章對(duì)章對(duì)

49、MD5安全安全性的討論指出性的討論指出SHA-1的安全性更好一些,但由于的安全性更好一些,但由于MD5已經(jīng)有已經(jīng)有了廣泛的應(yīng)用,因此必須提供相關(guān)支持。了廣泛的應(yīng)用,因此必須提供相關(guān)支持。q對(duì)對(duì)消息加密而言,推薦使用消息加密而言,推薦使用3DES。但實(shí)現(xiàn)時(shí)也必須支持。但實(shí)現(xiàn)時(shí)也必須支持40位位的的RC2,后者是一種弱加密算法,美國(guó)允許出口該算法。,后者是一種弱加密算法,美國(guó)允許出口該算法。qS/MIME文檔規(guī)范包含如何解決采用何種加密算法。從本質(zhì)上文檔規(guī)范包含如何解決采用何種加密算法。從本質(zhì)上說(shuō),一個(gè)發(fā)送方代理需要做如下兩個(gè)選擇:一是發(fā)送方代理必說(shuō),一個(gè)發(fā)送方代理需要做如下兩個(gè)選擇:一是發(fā)送方代

50、理必須確定接收方代理是否能夠使用該加密算法進(jìn)行解密。須確定接收方代理是否能夠使用該加密算法進(jìn)行解密。二是二是如如果接收方代理只能接收弱加密的內(nèi)容,發(fā)送方代理必須確定弱果接收方代理只能接收弱加密的內(nèi)容,發(fā)送方代理必須確定弱加密方法是否是可以接受的。為能達(dá)到上述要求,發(fā)送方代理加密方法是否是可以接受的。為能達(dá)到上述要求,發(fā)送方代理可以在他發(fā)送消息之前宣布他的解密能力,由接收方代理將該可以在他發(fā)送消息之前宣布他的解密能力,由接收方代理將該消息存儲(chǔ),留給將來(lái)使用。消息存儲(chǔ),留給將來(lái)使用。發(fā)送發(fā)送方代理必須按照如下順序進(jìn)行:方代理必須按照如下順序進(jìn)行:q1.如果發(fā)送方代理有一個(gè)接收方解密性能表,則他應(yīng)該

51、選擇表如果發(fā)送方代理有一個(gè)接收方解密性能表,則他應(yīng)該選擇表中的第一個(gè)中的第一個(gè)(即優(yōu)先級(jí)最高即優(yōu)先級(jí)最高)。q2.如果發(fā)送方代理沒有接收方代理的解密性能表,但曾經(jīng)接收如果發(fā)送方代理沒有接收方代理的解密性能表,但曾經(jīng)接收到一個(gè)或多個(gè)來(lái)自該接收方的消息,則應(yīng)該使用與最近接收到到一個(gè)或多個(gè)來(lái)自該接收方的消息,則應(yīng)該使用與最近接收到的消息一樣的加密算法,加密將要發(fā)送給接收方的消息。的消息一樣的加密算法,加密將要發(fā)送給接收方的消息。q3.如果發(fā)送方代理沒有接收方的任何解密性能方面的如果發(fā)送方代理沒有接收方的任何解密性能方面的知識(shí)知識(shí),并,并且想冒險(xiǎn)一試且想冒險(xiǎn)一試(接收方可能無(wú)法解密消息接收方可能無(wú)法解

52、密消息),則應(yīng)該選擇,則應(yīng)該選擇3DES。q4.如果發(fā)送方代理沒有接收方任何解密性能方面的知識(shí),并且如果發(fā)送方代理沒有接收方任何解密性能方面的知識(shí),并且不想冒險(xiǎn),則發(fā)送方代理必須使用不想冒險(xiǎn),則發(fā)送方代理必須使用RC2/40。如果消息需要發(fā)給多個(gè)接收方,并且他們沒有一個(gè)可以共同接受的如果消息需要發(fā)給多個(gè)接收方,并且他們沒有一個(gè)可以共同接受的加密算法,則發(fā)送方代理需要發(fā)送兩條消息,此時(shí),應(yīng)該特別注意加密算法,則發(fā)送方代理需要發(fā)送兩條消息,此時(shí),應(yīng)該特別注意該消息的安全性將由于弱安全性的一份副本而受到威脅。該消息的安全性將由于弱安全性的一份副本而受到威脅。4. S/MIME消息消息qS/MIME使

53、用了一系列新的使用了一系列新的MIME內(nèi)容類型,如下表所示。所內(nèi)容類型,如下表所示。所有新的類型都使用有新的類型都使用PKCS(Public-Key Cryptography Specifications)設(shè)計(jì),設(shè)計(jì),PKCS是紀(jì)念為是紀(jì)念為S/MIME做出貢獻(xiàn)的做出貢獻(xiàn)的RSA實(shí)驗(yàn)室及它們發(fā)布的一組公鑰密碼規(guī)范說(shuō)明。實(shí)驗(yàn)室及它們發(fā)布的一組公鑰密碼規(guī)范說(shuō)明。q下面逐一介紹下面逐一介紹S/MIME消息處理過程。消息處理過程。保護(hù)MIME實(shí)體:qS/MIME用簽名和用簽名和/或加密保護(hù)或加密保護(hù)MIME實(shí)體。一個(gè)實(shí)體。一個(gè)MIME實(shí)體實(shí)體可以是一個(gè)整體消息可以是一個(gè)整體消息(除除 RFC 5322

54、頭部之外頭部之外),或當(dāng),或當(dāng)MIME內(nèi)內(nèi)容類型為容類型為multipart時(shí),時(shí),MIME實(shí)體是一個(gè)或多個(gè)消息的子部實(shí)體是一個(gè)或多個(gè)消息的子部分。分。MIME實(shí)體將按照實(shí)體將按照MIME消息準(zhǔn)備規(guī)則進(jìn)行準(zhǔn)備工作。然消息準(zhǔn)備規(guī)則進(jìn)行準(zhǔn)備工作。然后將后將MIME實(shí)體和一些與安全相關(guān)的數(shù)據(jù)實(shí)體和一些與安全相關(guān)的數(shù)據(jù)(如算法標(biāo)識(shí)符、證如算法標(biāo)識(shí)符、證書書)一起用一起用S/MIME處理,得到所謂的處理,得到所謂的PKCS對(duì)象,最后,將對(duì)象,最后,將PKCS對(duì)象作為消息內(nèi)容封裝到對(duì)象作為消息內(nèi)容封裝到MIME中中(提供合適的提供合適的MIME頭頭部部)。后面我們將舉例說(shuō)明。后面我們將舉例說(shuō)明。q總之,將

55、要發(fā)送的消息轉(zhuǎn)換成規(guī)范形式。特別地,對(duì)給定的類總之,將要發(fā)送的消息轉(zhuǎn)換成規(guī)范形式。特別地,對(duì)給定的類型和子類型而言,相應(yīng)的規(guī)范形式將作為消息內(nèi)容。對(duì)一個(gè)多型和子類型而言,相應(yīng)的規(guī)范形式將作為消息內(nèi)容。對(duì)一個(gè)多部分的消息而言,合適的規(guī)范形式被用于每個(gè)子部分。部分的消息而言,合適的規(guī)范形式被用于每個(gè)子部分。q使用編碼轉(zhuǎn)換時(shí)應(yīng)注意,在大多數(shù)情況下,使用安全算法會(huì)產(chǎn)使用編碼轉(zhuǎn)換時(shí)應(yīng)注意,在大多數(shù)情況下,使用安全算法會(huì)產(chǎn)生部分或全部二進(jìn)制數(shù)據(jù)表示的對(duì)象,將該對(duì)象放入外部生部分或全部二進(jìn)制數(shù)據(jù)表示的對(duì)象,將該對(duì)象放入外部MIME消息后,一般用消息后,一般用Base64轉(zhuǎn)換編碼對(duì)其進(jìn)行轉(zhuǎn)換。而對(duì)轉(zhuǎn)換編碼對(duì)其

56、進(jìn)行轉(zhuǎn)換。而對(duì)一個(gè)多部分簽名的消息,安全處理過程并不改變字部分的消息一個(gè)多部分簽名的消息,安全處理過程并不改變字部分的消息內(nèi)容,除了內(nèi)容用內(nèi)容,除了內(nèi)容用7位位表示的以外,其他代碼轉(zhuǎn)換應(yīng)使用表示的以外,其他代碼轉(zhuǎn)換應(yīng)使用Based64或或quoted printable,使得應(yīng)用簽名的內(nèi)容不會(huì)被,使得應(yīng)用簽名的內(nèi)容不會(huì)被修改。修改。下面逐個(gè)介紹下面逐個(gè)介紹S/MIME內(nèi)容類型。內(nèi)容類型。封裝數(shù)據(jù):q子類型子類型application/pkcs7-mime擁有一個(gè)擁有一個(gè)smime-type參數(shù)。參數(shù)。其結(jié)果其結(jié)果(對(duì)象對(duì)象)采用采用ITU-T推薦的推薦的X.209中定義的中定義的BER(Bas

57、ic Encoding Rules)表示法。表示法。BER格式由格式由8位位字符串組成,即為字符串組成,即為二進(jìn)制數(shù)據(jù),因此,此對(duì)象可在外部二進(jìn)制數(shù)據(jù),因此,此對(duì)象可在外部MIME消息中使用消息中使用Base64轉(zhuǎn)換算法編碼。首先,看看封裝的數(shù)據(jù)。轉(zhuǎn)換算法編碼。首先,看看封裝的數(shù)據(jù)。MIME實(shí)體準(zhǔn)備封裝數(shù)據(jù)的步驟如下:實(shí)體準(zhǔn)備封裝數(shù)據(jù)的步驟如下:q1.為特定的對(duì)稱加密算法為特定的對(duì)稱加密算法(RC2/40或或3DES)生成偽隨機(jī)的會(huì)生成偽隨機(jī)的會(huì)話密鑰。話密鑰。q2.用每個(gè)接收方的用每個(gè)接收方的RSA公鑰分別加密會(huì)話密鑰。公鑰分別加密會(huì)話密鑰。q3.為每個(gè)接收方準(zhǔn)備一個(gè)接收方信息塊為每個(gè)接收方

58、準(zhǔn)備一個(gè)接收方信息塊(RecipientInfo),其,其中包含中包含接收方接收方的公鑰證書標(biāo)志,加密會(huì)話密鑰的算法標(biāo)志和加的公鑰證書標(biāo)志,加密會(huì)話密鑰的算法標(biāo)志和加密后的會(huì)話密鑰。密后的會(huì)話密鑰。q4.用會(huì)話密鑰加密消息內(nèi)容。用會(huì)話密鑰加密消息內(nèi)容。接收接收方信息塊方信息塊(RecipientInfo)后面緊跟著構(gòu)成封裝數(shù)據(jù)的加密內(nèi)后面緊跟著構(gòu)成封裝數(shù)據(jù)的加密內(nèi)容,然后用容,然后用Base64編碼,例如編碼,例如(不包含不包含RFC 5322):q為了恢復(fù)加密的消息,接收方首先去掉為了恢復(fù)加密的消息,接收方首先去掉Base64編碼,然后用編碼,然后用其私鑰恢復(fù)會(huì)話密鑰,最后,用會(huì)話密鑰解密得

59、到消息內(nèi)容。其私鑰恢復(fù)會(huì)話密鑰,最后,用會(huì)話密鑰解密得到消息內(nèi)容。簽名數(shù)據(jù):signed Data的簽名數(shù)據(jù)可以被一個(gè)或多個(gè)簽名者使用。為了簡(jiǎn)便的簽名數(shù)據(jù)可以被一個(gè)或多個(gè)簽名者使用。為了簡(jiǎn)便起見,我們將討論范圍限定在單個(gè)數(shù)字簽名內(nèi)。起見,我們將討論范圍限定在單個(gè)數(shù)字簽名內(nèi)。MIME實(shí)體準(zhǔn)備簽實(shí)體準(zhǔn)備簽名數(shù)據(jù)的步驟如下:名數(shù)據(jù)的步驟如下:q1.選擇消息摘要算法選擇消息摘要算法(SHA或或MD5)。q2.計(jì)算帶簽名內(nèi)容的消息摘要或計(jì)算帶簽名內(nèi)容的消息摘要或Hash函數(shù)。函數(shù)。q3.用用簽名簽名者的私鑰加密數(shù)字摘要。者的私鑰加密數(shù)字摘要。q4.準(zhǔn)備一個(gè)簽名者信息塊準(zhǔn)備一個(gè)簽名者信息塊(SignerI

60、nfo),其中包含簽名者的公,其中包含簽名者的公鑰證書,消息摘要算法的標(biāo)識(shí)符,加密消息摘要的算法標(biāo)識(shí)符鑰證書,消息摘要算法的標(biāo)識(shí)符,加密消息摘要的算法標(biāo)識(shí)符和加密的消息摘要。和加密的消息摘要。q簽名數(shù)據(jù)實(shí)體包含一系列塊,包含一個(gè)消息摘要算法標(biāo)識(shí)符,簽名數(shù)據(jù)實(shí)體包含一系列塊,包含一個(gè)消息摘要算法標(biāo)識(shí)符,被簽名的消息和簽名者信息塊被簽名的消息和簽名者信息塊(signerInfo),簽名數(shù)據(jù)實(shí)體可,簽名數(shù)據(jù)實(shí)體可以包含一組公鑰證書,該證書可以構(gòu)成從上級(jí)認(rèn)證機(jī)構(gòu)或更高以包含一組公鑰證書,該證書可以構(gòu)成從上級(jí)認(rèn)證機(jī)構(gòu)或更高級(jí)的認(rèn)證機(jī)構(gòu)到該簽名者的一條鏈路。最后將這些數(shù)據(jù)用級(jí)的認(rèn)證機(jī)構(gòu)到該簽名者的一條鏈路

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論