網(wǎng)絡(luò)安全與信息加密技術(shù)-第十九章

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

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

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

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

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

6、一一介紹。認證：q下圖描述了下圖描述了PGP提供提供 的數(shù)字簽名服務(wù)。該數(shù)字簽名方案在第的數(shù)字簽名服務(wù)。該數(shù)字簽名方案在第13章討論過章討論過。認證過程如下：認證過程如下：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.接收方對該消息用相同的接收方對該消息用相同的Hash函數(shù)生成新的函數(shù)生成新

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

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

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

10、也用也是也用的。使用的。使用64位密文反饋模式位密文反饋模式(DFB)。通常，設(shè)計加密時必須討論密鑰分配的問題。在通常，設(shè)計加密時必須討論密鑰分配的問題。在PGP中，每一個對中，每一個對稱密鑰都只使用一次，這意味著對每一個消息都會隨機生成一個稱密鑰都只使用一次，這意味著對每一個消息都會隨機生成一個128位的自然數(shù)用作新密鑰。因此，位的自然數(shù)用作新密鑰。因此， 盡管這在標準文檔中是指會盡管這在標準文檔中是指會話密鑰，其實是一次性密鑰。因為它只是用一次，所以會話密鑰會話密鑰，其實是一次性密鑰。因為它只是用一次，所以會話密鑰會和消息綁定并隨之一起傳輸。用接收者的公開密鑰加密以保護該和消息綁定并隨之一

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

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

13、對稱加密和公鑰加密的結(jié)合在效率上優(yōu)于僅僅使用RSA或者或者ElGamal直接對消息進行加密：直接對消息進行加密：CAST-128和其他對稱加密算和其他對稱加密算法遠快于法遠快于RSA或或ElGamal。其次，公鑰算法的使用解決了會話。其次，公鑰算法的使用解決了會話密鑰分配的問題，因為只有接收者才能還原與消息綁定的會話密鑰分配的問題，因為只有接收者才能還原與消息綁定的會話密鑰。值得注意的是，在這里我們不需要使用像在第密鑰。值得注意的是，在這里我們不需要使用像在第14章中討章中討論的會話密鑰交換協(xié)議，因為我們不會從正在進行的會話中開論的會話密鑰交換協(xié)議，因為我們不會從正在進行的會話中開始，而是對每

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

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

16、這個流程比先加密消息然后生成對會話密鑰加密。這個流程比先加密消息然后生成密文的簽名的過程要好。這樣更便于保存明文消息的簽名。密文的簽名的過程要好。這樣更便于保存明文消息的簽名。1.生成簽名在壓縮之前進行是由于如下兩個原因：生成簽名在壓縮之前進行是由于如下兩個原因：qa.對未壓縮的消息進行簽名更有利于僅存儲未壓縮消息和簽名對未壓縮的消息進行簽名更有利于僅存儲未壓縮消息和簽名以便未來的簽名驗證。以便未來的簽名驗證。假如假如壓縮后對文檔簽名，那么必須要么壓縮后對文檔簽名，那么必須要么存儲消息的一個壓縮版或者是當需要時對消息重新壓縮以便驗存儲消息的一個壓縮版或者是當需要時對消息重新壓縮以便驗證簽名。證

17、簽名。qb.即使有用戶愿意為驗證簽名動態(tài)的生成消息的壓縮版，即使有用戶愿意為驗證簽名動態(tài)的生成消息的壓縮版，PGP的壓縮算法也表現(xiàn)出不合適。因為該算法是不確定的，在運行的壓縮算法也表現(xiàn)出不合適。因為該算法是不確定的，在運行速度和壓縮比之間權(quán)衡時會產(chǎn)生該算法各種不同形式的實現(xiàn)。速度和壓縮比之間權(quán)衡時會產(chǎn)生該算法各種不同形式的實現(xiàn)。但是，這些不同的算法實現(xiàn)是可以同時使用的，因為該算法的但是，這些不同的算法實現(xiàn)是可以同時使用的，因為該算法的任何版本都可以正確的解壓縮任何其他版本的壓縮文件。在任何版本都可以正確的解壓縮任何其他版本的壓縮文件。在Hash函數(shù)和簽名之后使用可以使所有的函數(shù)和簽名之后使用可

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

19、摘要會用發(fā)送者的私鑰加密。假如使用了保密服務(wù)，那么消息和簽名假如使用了保密服務(wù)，那么消息和簽名(如果有簽名的話如果有簽名的話)會用會用一次性對稱密鑰加密。因此，數(shù)據(jù)塊的整體或部分會由任意的一次性對稱密鑰加密。因此，數(shù)據(jù)塊的整體或部分會由任意的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就是用于該目的的解決方案。每三個字節(jié)組成的二就是用于該目的的

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

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

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

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

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

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

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

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

28、不能傳輸含有國際語言字符的文本數(shù)據(jù)，因為這些字不能傳輸含有國際語言字符的文本數(shù)據(jù)，因為這些字符是由符是由8位碼表示的，其值可能是十進制位碼表示的，其值可能是十進制128或者更大的數(shù)，或者更大的數(shù)，而而SMTP只能用只能用7位的位的ASCII碼。碼。q3.SMTP服務(wù)器會拒絕超過一定尺寸的消息。服務(wù)器會拒絕超過一定尺寸的消息。q4.ASCII碼和碼和EBCDIC碼之間轉(zhuǎn)換的碼之間轉(zhuǎn)換的SMTP網(wǎng)關(guān)并未使用一致網(wǎng)關(guān)并未使用一致的映射集，因此常會出現(xiàn)轉(zhuǎn)換錯誤。的映射集，因此常會出現(xiàn)轉(zhuǎn)換錯誤。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的實現(xiàn)并沒有嚴格遵守的實現(xiàn)并沒有嚴格遵守RFC 821文檔中定義的文檔中定義的SMTP標準，因此會導(dǎo)致以下常見的問題：標準，因此會導(dǎo)致以下常見的問題：q回車和換行的刪除、添加和重排?；剀嚭蛽Q行的刪除、添加和重排。q截斷截斷或者是限制超過或者是限制超過76個字符長度的行。個字符長度的行。q去除白字符去除白字符(制表符和空格符制表符和空格符)。q將將消息中的行填充為等長。消息中的行填充為等長。q將制表符轉(zhuǎn)換成多個空格符。將制表符轉(zhuǎn)換成多個空格符。MIME期望能解決上述這些問題并與現(xiàn)存的期望能解決上述這些問題并與現(xiàn)存的RFC 5322實現(xiàn)兼容。實現(xiàn)兼容。概述：M

30、IME規(guī)范包含以下要素：規(guī)范包含以下要素：q1.定義了定義了5個新的頭部域，這些域提供了消息正文的相關(guān)信息。個新的頭部域，這些域提供了消息正文的相關(guān)信息。q2.定義了一些新的內(nèi)容格式，標準化的表示支持了多媒體的電定義了一些新的內(nèi)容格式，標準化的表示支持了多媒體的電子郵件。子郵件。q3.定義了編碼轉(zhuǎn)換方式，以使郵件系統(tǒng)能將任何形式的內(nèi)容定義了編碼轉(zhuǎn)換方式，以使郵件系統(tǒng)能將任何形式的內(nèi)容統(tǒng)統(tǒng)一一地轉(zhuǎn)換為另一種形式。地轉(zhuǎn)換為另一種形式。在本小節(jié)中，在本小節(jié)中， 我們將介紹這我們將介紹這5個頭部域，在隨后的兩個個頭部域，在隨后的兩個小節(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)容類型)：詳細地描述了正文中的數(shù)據(jù)以使詳細地描述了正文中的數(shù)據(jù)以使接收方的代理能采用合適的代理或機制來為用戶展示數(shù)據(jù)或以接收方的代理能采用合適的代理或機制來為用戶展示數(shù)據(jù)或以一個合適的方法來處理數(shù)據(jù)。一個合適的方法來處理數(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)容標志內(nèi)容標志)：在多重上下文中唯一標志在多重上下文中唯一標志MIME實實體。體。qContent-Description(內(nèi)容描述內(nèi)容描述)：正文對象的文本描述，這正文對象的文本描述，這對于對象是不可讀的情形是很有用的對于對象是不可讀的情形是很有用的(如音頻數(shù)據(jù)如音頻數(shù)據(jù))。通常在一個通常在一個RFC 5322頭中會出現(xiàn)一個或多個上述域。一個合適的頭中會出現(xiàn)一個或多個上述域。一個合適的實現(xiàn)實現(xiàn)必須支持必須支持MIME-Version，Content-Type，Content-Transfer-Encoding域，接收方的實現(xiàn)可以選擇使

33、用或忽略域，接收方的實現(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個不同的個不同的大類和總共大類和總共15個子類。一般而言，用內(nèi)容類型表示數(shù)據(jù)的通用個子類。一般而言，用內(nèi)容類型表示數(shù)據(jù)的通用類型，用子類型來表示該數(shù)據(jù)類型的特定格式

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

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

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

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

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

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

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

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

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

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

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

45、后再從消息格式的消息準備方面詳細敘述每個功能。功能：S/MIME有如下功能：有如下功能：q封裝數(shù)據(jù)：封裝數(shù)據(jù)：由任何類型的加密內(nèi)容和加密該內(nèi)容所用的加密由任何類型的加密內(nèi)容和加密該內(nèi)容所用的加密密密鑰鑰組成，組成，密鑰密鑰可以是與一個或多個接收方的秘鑰?？梢允桥c一個或多個接收方的秘鑰。q簽名數(shù)據(jù)：簽名數(shù)據(jù)：數(shù)字簽名通過提取待簽名內(nèi)容的數(shù)字摘要，并用簽數(shù)字簽名通過提取待簽名內(nèi)容的數(shù)字摘要，并用簽名的私鑰加密得到。然后用名的私鑰加密得到。然后用Base64編碼方法重新對內(nèi)容和簽編碼方法重新對內(nèi)容和簽名編碼。因此，一個簽名了的數(shù)據(jù)消息只能被具有名編碼。因此，一個簽名了的數(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能力的接收方雖然無法驗證簽名但卻可以看到消息內(nèi)能力的接收方雖然無法驗證簽名但卻可以看到消息內(nèi)容。容。q簽名并封裝數(shù)據(jù)：簽名并封裝數(shù)據(jù)：僅簽名實體和僅封裝實體可以嵌套，能對加僅簽名實體和僅封裝實體可以嵌套，能對加密后的數(shù)據(jù)進行簽名和對簽名后的數(shù)據(jù)或透明簽名數(shù)據(jù)進行加密后的數(shù)據(jù)進行簽名和對簽名后的數(shù)據(jù)或透明簽名數(shù)據(jù)進行加密。密。密碼算法：q下下表總結(jié)了

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

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

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

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

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

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

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

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

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

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

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

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

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

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