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

事實(shí)上，在所有的分布式環(huán)境中，電子郵件是最繁重的網(wǎng)絡(luò)應(yīng)用。無(wú)論雙方使用何種操作系統(tǒng)和通信軟件，用戶都希望能夠直接或間接與Internet連接著的對(duì)方發(fā)送電子郵件。隨著對(duì)電子郵件依賴性的爆炸式增長(zhǎng)，認(rèn)證性和保密性服務(wù)需求也在日益增長(zhǎng)。兩種被廣泛應(yīng)用的方法：PGP和S/MIME脫穎而出。本章將闡述這兩種方法。第19章電子郵件主要由PhilZimmermann提出的PGP提供了可用于電子郵件和文件存儲(chǔ)應(yīng)用的保密性和認(rèn)證性?；旧希琙immermann做了如下工作：1.在構(gòu)建數(shù)據(jù)塊時(shí)，選用了最合適、可用的密碼算法。2.將這些算法整合到通用應(yīng)用程序中，這些應(yīng)用程序獨(dú)立于不同操作系統(tǒng)和處理器，并且是基于一個(gè)小規(guī)模的易用指令集。3.將其制作成軟件包并形成文檔，包括源代碼。這些資源都可以通過(guò)Internet，廣告牌和諸如AOL(AmericaOnLine)的商用網(wǎng)絡(luò)免費(fèi)獲取。4.與Viacrypt(現(xiàn)在的NetworkAssociates)公司達(dá)成協(xié)議，提供完全兼容、低成本的商用版PGP。19.1PGP第19章電子郵件PGP的應(yīng)用迅速普及，呈爆炸式增長(zhǎng)。其原因大致可歸納如下：1.提供了在世界范圍內(nèi)的各種免費(fèi)可用的版本，可運(yùn)行于各種平臺(tái)，包括Windows，UNIX，Macintosh等。另外，其商用版滿足了用戶的需求并獲得了商家的支持。2.使用的算法是經(jīng)過(guò)廣泛的使用檢驗(yàn)并被認(rèn)為是非常安全的算法。值得指出的是，這個(gè)軟件包中包含了用于公鑰加密的RSA，DSS和Diffie-Hellman算法，用于對(duì)稱加密的CAST-128，IDEA和3DES算法以及用SHA-1做Hash編碼。3.應(yīng)用范圍廣泛，即可用于公司選擇和增強(qiáng)加密文件與消息的標(biāo)準(zhǔn)化模式，也可用于個(gè)人通過(guò)Internet或其他網(wǎng)絡(luò)進(jìn)行安全通信。4.不是由政府或者是標(biāo)準(zhǔn)化組織開(kāi)發(fā)或控制。對(duì)那些本能地對(duì)上述“組織”有不信任的人們來(lái)說(shuō)，PGP非常有吸引力。19.1PGP

19.1PGP

19.1PGP操作描述與密鑰管理相對(duì)應(yīng)，PGP的實(shí)際操作由4類(lèi)服務(wù)組成：認(rèn)證、保密、壓縮和電子郵件兼容性[如下表所示]：下面我們一一介紹。19.1PGP認(rèn)證：下圖描述了PGP提供的數(shù)字簽名服務(wù)。該數(shù)字簽名方案在第13章討論過(guò)。認(rèn)證過(guò)程如下：1.發(fā)送方生成消息。2.用SHA-1算法生成消息的160位Hash碼。3.用發(fā)送方的私鑰按RSA算法加密該Hash碼并將結(jié)果預(yù)先加入到消息中。19.1PGP4.接收方用發(fā)送方的公鑰按RSA算法解密消息并回復(fù)Hash碼。5.接收方對(duì)該消息用相同的Hash函數(shù)生成新的Hash碼，并比較該Hash碼與解密得到的Hash碼，如果兩者吻合則該消息為可信的。SHA-1和RSA的結(jié)合提供了一個(gè)高效的數(shù)字簽名方案。鑒于RSA的安全強(qiáng)度，接收者可以確信如果是不同的消息必定無(wú)法生成與該Hash碼匹配Hash值。于是保證了原消息簽名有效。19.1PGPDSS/SHA-1也是生成數(shù)字簽名的可選方案。盡管通常情況下簽名都會(huì)附在消息或者是文件中，但也不盡然：簽名也可以被分離出來(lái)。一個(gè)分離式簽名可能會(huì)被同對(duì)應(yīng)的消息分開(kāi)存儲(chǔ)或傳輸。這在一些情形下是有用的，例如某用戶可能希望能為所有發(fā)送或接收到的消息的各分離式簽名建立并保持一個(gè)日志。一個(gè)可執(zhí)行程序的分離式簽名可用來(lái)甄別該程序是否被病毒感染。另外，分離式簽名還可以用于多個(gè)成員對(duì)一份注入合法契約等文件進(jìn)行簽名，每一個(gè)成員的簽名都是獨(dú)立的并且只用于該文件，否則簽名可能會(huì)被嵌套，例如第二個(gè)成員會(huì)對(duì)文檔和第一個(gè)成員生成的簽名進(jìn)行簽名等。19.1PGP保密：PGP提供的另一個(gè)服務(wù)是保密，這是通過(guò)對(duì)傳輸?shù)南⒒蛘呤潜镜卮鎯?chǔ)的文件進(jìn)行加密來(lái)實(shí)現(xiàn)的。在如上兩種情形下對(duì)稱加密算法(CAST-128)是可用的。同時(shí)，IDEA和3DES也是也用的。使用64位密文反饋模式(DFB)。19.1PGP通常，設(shè)計(jì)加密時(shí)必須討論密鑰分配的問(wèn)題。在PGP中，每一個(gè)對(duì)稱密鑰都只使用一次，這意味著對(duì)每一個(gè)消息都會(huì)隨機(jī)生成一個(gè)128位的自然數(shù)用作新密鑰。因此，盡管這在標(biāo)準(zhǔn)文檔中是指會(huì)話密鑰，其實(shí)是一次性密鑰。因?yàn)樗皇怯靡淮?，所以?huì)話密鑰會(huì)和消息綁定并隨之一起傳輸。用接收者的公開(kāi)密鑰加密以保護(hù)該會(huì)話密鑰[如上圖所示]。用文字描述如下：1.發(fā)送者生成消息和僅用于加密該消息的會(huì)話密鑰，該會(huì)話密鑰為128位隨機(jī)自然數(shù)。2.采用CAST-128(或IDEA或3DES)算法，使用該會(huì)話密鑰加密消息。3.采用RSA算法，用接收者的公開(kāi)密鑰加密該會(huì)話密鑰并預(yù)先發(fā)送給對(duì)方。19.1PGP4.接收者采用RSA算法，用自己的私鑰解密并恢復(fù)會(huì)話密鑰。5.用會(huì)話密鑰解密消息。作為用于對(duì)密鑰進(jìn)行加密的RSA算法的替換，PGP還提供了Diffie-Hellman算法作為選擇。正如第10章中所介紹的那樣，Diffie-Hellman是一個(gè)密鑰交換算法。事實(shí)上，PGP使用了大量的Diffie-Hellman來(lái)提供加/解密。19.1PGP上述過(guò)程中我們會(huì)發(fā)現(xiàn)一些問(wèn)題。首先，為了減少加密時(shí)間，對(duì)稱加密和公鑰加密的結(jié)合在效率上優(yōu)于僅僅使用RSA或者ElGamal直接對(duì)消息進(jìn)行加密：CAST-128和其他對(duì)稱加密算法遠(yuǎn)快于RSA或ElGamal。其次，公鑰算法的使用解決了會(huì)話密鑰分配的問(wèn)題，因?yàn)橹挥薪邮照卟拍苓€原與消息綁定的會(huì)話密鑰。值得注意的是，在這里我們不需要使用像在第14章中討論的會(huì)話密鑰交換協(xié)議，因?yàn)槲覀儾粫?huì)從正在進(jìn)行的會(huì)話中開(kāi)始，而是對(duì)每一個(gè)消息都是用獨(dú)立的一次性密鑰。此外，鑒于電子郵件存儲(chǔ)轉(zhuǎn)發(fā)的特性，使用握手協(xié)議來(lái)確保通信雙方擁有相同的會(huì)話密鑰也是不切實(shí)際的。最后，使用一次性對(duì)稱密鑰也使原本安全強(qiáng)度較高的對(duì)稱加密方法更安全。每一個(gè)密鑰都只加密少量的明文，并且密鑰與密鑰之間沒(méi)有任何關(guān)聯(lián)。因此，在某種意義上說(shuō)只要公鑰算法是安全的，那么整個(gè)方案就是安全的。19.1PGP同時(shí)，PGP為用戶提供了密鑰長(zhǎng)度從768位到3072位范圍之間的選擇(用于數(shù)字簽名的DSS密鑰限制在1024位)。保密性和認(rèn)證性：如上圖所描述，保密性和認(rèn)證性這兩種服務(wù)可能會(huì)對(duì)同一個(gè)消息使用。首先，生成一個(gè)明文的簽名，然后用CAST-128(或IDEA或3DES)對(duì)明文消息和簽名進(jìn)行加密，然后用RSA(或ElGamal)對(duì)會(huì)話密鑰加密。這個(gè)流程比先加密消息然后生成密文的簽名的過(guò)程要好。這樣更便于保存明文消息的簽名。19.1PGP

19.1PGP1.生成簽名在壓縮之前進(jìn)行是由于如下兩個(gè)原因：a.對(duì)未壓縮的消息進(jìn)行簽名更有利于僅存儲(chǔ)未壓縮消息和簽名以便未來(lái)的簽名驗(yàn)證。假如壓縮后對(duì)文檔簽名，那么必須要么存儲(chǔ)消息的一個(gè)壓縮版或者是當(dāng)需要時(shí)對(duì)消息重新壓縮以便驗(yàn)證簽名。b.即使有用戶愿意為驗(yàn)證簽名動(dòng)態(tài)的生成消息的壓縮版，PGP的壓縮算法也表現(xiàn)出不合適。因?yàn)樵撍惴ㄊ遣淮_定的，在運(yùn)行速度和壓縮比之間權(quán)衡時(shí)會(huì)產(chǎn)生該算法各種不同形式的實(shí)現(xiàn)。但是，這些不同的算法實(shí)現(xiàn)是可以同時(shí)使用的，因?yàn)樵撍惴ǖ娜魏伟姹径伎梢哉_的解壓縮任何其他版本的壓縮文件。在Hash函數(shù)和簽名之后使用可以使所有的PGP實(shí)現(xiàn)都統(tǒng)一使用一種版本的壓縮算法。2.在壓縮之后對(duì)消息進(jìn)行加密是為了增強(qiáng)密碼運(yùn)算的安全性。因?yàn)閴嚎s后的消息比原明文的信息冗余少，這讓密碼分析更加困難。19.1PGP所使用的壓縮算法ZIP將在附錄0中有介紹。電子郵件兼容性：當(dāng)使用PGP時(shí)，數(shù)據(jù)塊中至少被傳輸?shù)哪遣糠謺?huì)被加密。假如使用了數(shù)字簽名服務(wù)，那么消息的摘要會(huì)用發(fā)送者的私鑰加密。假如使用了保密服務(wù)，那么消息和簽名(如果有簽名的話)會(huì)用一次性對(duì)稱密鑰加密。因此，數(shù)據(jù)塊的整體或部分會(huì)由任意的8字節(jié)流組成。但是大多數(shù)的電子郵件系統(tǒng)都只允許使用由ACSII文本組成的數(shù)據(jù)塊。為了適應(yīng)限制，PGP提供了將原字節(jié)流轉(zhuǎn)換成可打印的ASCII字符流的服務(wù)。Radix-64就是用于該目的的解決方案。每三個(gè)字節(jié)組成的二進(jìn)制數(shù)據(jù)可以映射成四個(gè)ASCII字符。這種格式也附加了CRC校驗(yàn)碼用來(lái)檢查傳輸錯(cuò)誤。19.1PGP

19.1PGP下圖顯示了到目前為止討論的4種服務(wù)之間的關(guān)系。19.1PGP在傳輸方，假如需要可以生產(chǎn)一個(gè)明文的Hash碼用作簽名。然后壓縮明文(如果有簽名就加上簽名)。接著，如果有保密性要求，這個(gè)數(shù)據(jù)塊(壓縮了的明文或者是壓縮了簽名和明文的集合)就用對(duì)稱密鑰加密，而該對(duì)稱密鑰則是預(yù)先用公鑰加密的。最后，將整個(gè)數(shù)據(jù)塊轉(zhuǎn)換成Radix-64格式。在接收方，首先把接收到的數(shù)據(jù)塊由Radix-64格式轉(zhuǎn)換成二進(jìn)制。然后，假如消息是加密的，那么接收者就用自己的私鑰恢復(fù)出會(huì)話密鑰并用會(huì)話密鑰解密消息。然后把得到的結(jié)果解壓。假如消息是簽名的，那么接收者就恢復(fù)出傳輸過(guò)來(lái)的Hash碼并且與自己計(jì)算的Hash碼進(jìn)行比較。19.1PGPS/MIME(Secure/MultipurposeInternetMailExtension)是對(duì)基于RSA數(shù)據(jù)安全的MIMEInternet電子郵件格式標(biāo)準(zhǔn)的安全性增強(qiáng)。盡管PGP和S/MIME都是IETF工作組推出的標(biāo)準(zhǔn)，但是S/MIME傾向于推廣為商業(yè)或組織用于的工業(yè)標(biāo)準(zhǔn)，而PGP則用來(lái)為個(gè)人電子郵件安全提供服務(wù)選擇。S/MIME在很多的文檔中被定義了，其中最重要的是RFC3370,3850,3851和3852。為了理解S/MIME，我們首先得對(duì)其使用的電子郵件格式(即MIME)有一個(gè)大概的理解。但是為了理解MIME的重要性，又將回到傳統(tǒng)的電子郵件格式標(biāo)準(zhǔn)(RFC822)，而該標(biāo)準(zhǔn)仍然廣泛使用。最新版本的格式規(guī)范是RFC5322(Internet消息格式)。因此，本節(jié)將首先介紹那兩個(gè)較早的標(biāo)準(zhǔn)然后再開(kāi)始討論S/MIME。19.2S/MIME第19章電子郵件RFC5322RFC5322定義了用電子郵件發(fā)送的文本消息的格式。這已經(jīng)是基于Internet的文本郵件消息的標(biāo)準(zhǔn)并且仍然在廣泛使用。在RFC5322中，消息被視為一個(gè)信封和內(nèi)容的組合。信封包含了任何用來(lái)完成傳輸和發(fā)送功能的信息。內(nèi)容則構(gòu)成了發(fā)送給接收者的對(duì)象。RFC5322標(biāo)準(zhǔn)關(guān)注的是內(nèi)容部分。但是，內(nèi)容標(biāo)準(zhǔn)包含了一系列頭域，這些頭域是由郵件系統(tǒng)用來(lái)生成信封的，而該標(biāo)準(zhǔn)也致力于使程序獲取頭域信息更方便。符合RFC5322的消息的大體結(jié)構(gòu)非常簡(jiǎn)單。一個(gè)消息包含了若干行的頭部(thehead)和隨后的無(wú)限制的正文(thebody)。頭部和正文中間用一空行隔開(kāi)。另外，消息是ASCII文本，第一個(gè)空行之上的所有行都是郵件系統(tǒng)中用戶代理部分使用的頭部行。19.2S/MIME頭部行通常包含關(guān)鍵字、冒號(hào)和關(guān)鍵字的參數(shù)，該格式允許將一個(gè)長(zhǎng)行分割成若干短行。使用最頻繁的關(guān)鍵字是From，To，Subject和Date。例如：在RFC5322中常見(jiàn)的另一個(gè)域是消息標(biāo)志(Message-ID)，該域包含一個(gè)與該消息關(guān)聯(lián)的唯一標(biāo)志符。19.2S/MIMEMIMEMIME是RFC5322的擴(kuò)展，目的是解決一些因使用簡(jiǎn)單郵件傳輸協(xié)議(SMTP，在RFC821中定義)或其他一些郵件傳輸協(xié)議而產(chǎn)生的限制。參考文獻(xiàn)列出了SMTP/5322方案的限制。1.SMTP不能傳輸可執(zhí)行文件和其他二進(jìn)制對(duì)象。SMTP郵件系統(tǒng)使用了很多用來(lái)將二進(jìn)制文件轉(zhuǎn)換為文本格式的方案，包括聞名的UNIXUUencode/UUdecode方案。但是，沒(méi)有一個(gè)成為標(biāo)準(zhǔn)或者事實(shí)上的標(biāo)準(zhǔn)。2.SMTP不能傳輸含有國(guó)際語(yǔ)言字符的文本數(shù)據(jù)，因?yàn)檫@些字符是由8位碼表示的，其值可能是十進(jìn)制128或者更大的數(shù)，而SMTP只能用7位的ASCII碼。3.SMTP服務(wù)器會(huì)拒絕超過(guò)一定尺寸的消息。19.2S/MIME4.ASCII碼和EBCDIC碼之間轉(zhuǎn)換的SMTP網(wǎng)關(guān)并未使用一致的映射集，因此常會(huì)出現(xiàn)轉(zhuǎn)換錯(cuò)誤。5.X.400電子郵件網(wǎng)絡(luò)的SMTP網(wǎng)關(guān)不能處理X.400消息中的非文本數(shù)據(jù)。6.一些SMTP的實(shí)現(xiàn)并沒(méi)有嚴(yán)格遵守RFC821文檔中定義的SMTP標(biāo)準(zhǔn)，因此會(huì)導(dǎo)致以下常見(jiàn)的問(wèn)題：回車(chē)和換行的刪除、添加和重排。截?cái)嗷蛘呤窍拗瞥^(guò)76個(gè)字符長(zhǎng)度的行。去除白字符(制表符和空格符)。將消息中的行填充為等長(zhǎng)。將制表符轉(zhuǎn)換成多個(gè)空格符。MIME期望能解決上述這些問(wèn)題并與現(xiàn)存的RFC5322實(shí)現(xiàn)兼容。19.2S/MIME概述：MIME規(guī)范包含以下要素：1.定義了5個(gè)新的頭部域，這些域提供了消息正文的相關(guān)信息。2.定義了一些新的內(nèi)容格式，標(biāo)準(zhǔn)化的表示支持了多媒體的電子郵件。3.定義了編碼轉(zhuǎn)換方式，以使郵件系統(tǒng)能將任何形式的內(nèi)容統(tǒng)一地轉(zhuǎn)換為另一種形式。在本小節(jié)中，我們將介紹這5個(gè)頭部域，在隨后的兩個(gè)小節(jié)將討論內(nèi)容格式和編碼轉(zhuǎn)換方式：MIME-Version(MIME版本)：參數(shù)的值必須為1.0，該域表明消息遵循RFC2045和RFC2046的格式。Content-Type(內(nèi)容類(lèi)型)：詳細(xì)地描述了正文中的數(shù)據(jù)以使接收方的代理能采用合適的代理或機(jī)制來(lái)為用戶展示數(shù)據(jù)或以一個(gè)合適的方法來(lái)處理數(shù)據(jù)。19.2S/MIMEContent-Transer-Encoding(內(nèi)容轉(zhuǎn)換編碼)：指示轉(zhuǎn)換的類(lèi)型以使其能將消息正文的展現(xiàn)形式可為郵件傳輸所用。Content-ID(內(nèi)容標(biāo)志)：在多重上下文中唯一標(biāo)志MIME實(shí)體。Content-Description(內(nèi)容描述)：正文對(duì)象的文本描述，這對(duì)于對(duì)象是不可讀的情形是很有用的(如音頻數(shù)據(jù))。通常在一個(gè)RFC5322頭中會(huì)出現(xiàn)一個(gè)或多個(gè)上述域。一個(gè)合適的實(shí)現(xiàn)必須支持MIME-Version，Content-Type，Content-Transfer-Encoding域，接收方的實(shí)現(xiàn)可以選擇使用或忽略Content-ID和Content-Description域。MIME內(nèi)容類(lèi)型：MIME規(guī)范文檔中有很大的篇幅是關(guān)于各種內(nèi)容類(lèi)型的定義。這也反映了在多媒體環(huán)境下提供處理各種信息展現(xiàn)形式的需求。19.2S/MIME下表列出了RFC2046中規(guī)定的內(nèi)容類(lèi)型。主要有7個(gè)不同的大類(lèi)和總共15個(gè)子類(lèi)。一般而言，用內(nèi)容類(lèi)型表示數(shù)據(jù)的通用類(lèi)型，用子類(lèi)型來(lái)表示該數(shù)據(jù)類(lèi)型的特定格式。19.2S/MIME若正文為文本類(lèi)型(texttype)，則除了要支持制定字符集外不需要特殊的軟件來(lái)獲取文字的全部意義，因此主要的子類(lèi)型為純文本(plaintext)，有簡(jiǎn)單的ASCII碼或ISO8859字符組成的字符串。子類(lèi)型enriched則允許擁有更多的格式信息。類(lèi)型為多部分類(lèi)型(multiparttype)時(shí)，表示正文中包含多個(gè)相互獨(dú)立的部分。域Content-Type中包含一個(gè)稱為分界符的參數(shù)，該分界符定義了正文中各部分的分隔符。此分隔符不能隨意出現(xiàn)，而必須從一個(gè)新行開(kāi)始，并在兩個(gè)連字符后跟分界符值，最后一個(gè)分界符表示最后一部分的結(jié)尾，并有兩個(gè)連字符做后綴。在每個(gè)部分，可以有一個(gè)通常的MIME頭部。19.2S/MIME以下是一個(gè)多部分消息的簡(jiǎn)單例子，包含由簡(jiǎn)單文本組成的兩個(gè)部分：19.2S/MIMEMultipart類(lèi)型有4種子類(lèi)型，其語(yǔ)法相同。子類(lèi)型multipart/mixed用于將相互獨(dú)立的各部分按一定的順序綁定。子類(lèi)型multipart/parallel表示各部分的順序無(wú)關(guān)。如果接受系統(tǒng)合適，則各部分可以并行接收。例如，在圖片或文本顯示時(shí)，可同時(shí)播放音頻。19.2S/MIME子類(lèi)型multipart/alternative表示這若干個(gè)部分是同一個(gè)信息的不同表示。例如：19.2S/MIME在此子類(lèi)型中，各部分按優(yōu)先級(jí)遞增的方式排序。例如，如果接收方可以處理text/enriched格式的信息，則按此格式處理，否則就使用純文本方式。子類(lèi)型multipart/digest用于將正文的每個(gè)部分作為一個(gè)帶頭部的RFC5322消息，從而使得一個(gè)消息中可以包含多個(gè)獨(dú)立的消息。例如，可以用一組緩沖器搜集組中各成員的電子郵件消息并將其封裝到一個(gè)MIME消息中發(fā)送。類(lèi)型message提供了許多MIME的重要特征。子類(lèi)型message/rfc822表明該正文是一個(gè)完整的消息，包含了頭和正文。除了子類(lèi)型的名字外，封裝的消息即可以是RFC5322消息，也可以是任何MIME消息。19.2S/MIME子類(lèi)型message/partial使得可以將一個(gè)大消息分段為若干部分，并可以在目的地重新組裝。對(duì)這個(gè)子類(lèi)型而言，Content-Type：Message/partial域需要說(shuō)明三個(gè)參數(shù)：一個(gè)對(duì)同一個(gè)消息所有分片一致的標(biāo)志id，一個(gè)每段唯一的序列號(hào)sequencenumber和總的段數(shù)total。19.2S/MIME子類(lèi)型message/external-body表明消息所要表達(dá)的數(shù)據(jù)并未包含在該正文中。而是在正文中包含了對(duì)該數(shù)據(jù)的訪問(wèn)。和其他消息類(lèi)型一樣，子類(lèi)型message/external-body也有一個(gè)外頭部和包含其頭部的封裝。外頭部中唯一必須的域?yàn)閮?nèi)容類(lèi)型(Content-Type)域，它指示了子類(lèi)型message/external-body。內(nèi)頭部是封裝消息的頭部。外頭部中的內(nèi)容類(lèi)型(Content-Type)域必須包含一個(gè)訪問(wèn)類(lèi)型(access-type)參數(shù)，它指示了訪問(wèn)方法，例如FTP(文件傳輸協(xié)議)。類(lèi)型application是指其他類(lèi)型的數(shù)據(jù)，如不能解釋的二進(jìn)制數(shù)據(jù)或由郵件應(yīng)用程序處理的信息。19.2S/MIMEMIME轉(zhuǎn)換編碼：MIME規(guī)范中另一個(gè)主要部分是定義消息正文的轉(zhuǎn)換編碼。其目的是在龐大的網(wǎng)絡(luò)環(huán)境中提供可靠的傳輸方式。MIME標(biāo)準(zhǔn)定義了兩種編碼方式，但Content-Transfer-Encoding域可以取6個(gè)值，如下表所示。其中當(dāng)值為7位，8位和binary時(shí)，并不進(jìn)行編碼，而是提供一些與數(shù)據(jù)屬性相關(guān)的信息。對(duì)SMTP傳輸而言，用7位比較安全，而在其他郵件傳輸協(xié)議中可以使用8位和binary格式。19.2S/MIMEContent-Transfer-encoding域也可以取值x-token，用來(lái)表示其他編碼方式，并提供該方式的名字。這種方式可以是生產(chǎn)商規(guī)定的或應(yīng)用程序規(guī)定的方式。目前，有兩種方式：quoted-printable和Base64，它們都是為了提供一種將所有數(shù)據(jù)類(lèi)型的緊湊表示轉(zhuǎn)換為便于人們閱讀的形式而設(shè)計(jì)的。quoted-printable轉(zhuǎn)換編碼使用數(shù)據(jù)由大量可打印的ASCII字符組成。其本質(zhì)上是一種不安全的十六進(jìn)制字符表示方法。并引入軟回車(chē)來(lái)解決每行不得超過(guò)76個(gè)字符的限制。Base64轉(zhuǎn)換編碼是一種Radix-64的編碼方式，是一種對(duì)二進(jìn)制數(shù)據(jù)進(jìn)行編碼的通用方法，在郵件傳輸過(guò)程中無(wú)懈可擊，也用于PGP。19.2S/MIME規(guī)范格式：規(guī)范格式是MIME和S/MIME的一個(gè)重要概念。規(guī)范格式指的是一種與內(nèi)容類(lèi)型相對(duì)應(yīng)的格式，可以在系統(tǒng)中作為標(biāo)準(zhǔn)使用。下表可說(shuō)明此問(wèn)題。19.2S/MIMES/MIME功能就大體功能而言，S/MIME與PGP非常相似。兩者都提供了簽名和加密消息的能力。在本節(jié)中我們將簡(jiǎn)要介紹S/MIME的功能，然后再?gòu)南⒏袷降南?zhǔn)備方面詳細(xì)敘述每個(gè)功能。功能：S/MIME有如下功能：封裝數(shù)據(jù)：由任何類(lèi)型的加密內(nèi)容和加密該內(nèi)容所用的加密密鑰組成，密鑰可以是與一個(gè)或多個(gè)接收方的秘鑰。簽名數(shù)據(jù)：數(shù)字簽名通過(guò)提取待簽名內(nèi)容的數(shù)字摘要，并用簽名的私鑰加密得到。然后用Base64編碼方法重新對(duì)內(nèi)容和簽名編碼。因此，一個(gè)簽名了的數(shù)據(jù)消息只能被具有S/MIME能力的接收方處理。19.2S/MIME透明簽名數(shù)據(jù)：簽名的數(shù)據(jù)形成了內(nèi)容的數(shù)字簽名。但在這種情況下，只有數(shù)字簽名采用了Base64編碼，因此沒(méi)有S/MIME能力的接收方雖然無(wú)法驗(yàn)證簽名但卻可以看到消息內(nèi)容。簽名并封裝數(shù)據(jù)：僅簽名實(shí)體和僅封裝實(shí)體可以嵌套，能對(duì)加密后的數(shù)據(jù)進(jìn)行簽名和對(duì)簽名后的數(shù)據(jù)或透明簽名數(shù)據(jù)進(jìn)行加密。19.2S/MIME密碼算法：下表總結(jié)了在S/MIME中使用的密碼算法。S/MIME中使用了如下術(shù)語(yǔ)：Must：在規(guī)范說(shuō)明書(shū)中表示一定要滿足的要求，其實(shí)現(xiàn)必須與規(guī)范說(shuō)明中的功能一致。Should：如果在特定條件下有合理的理由也可以忽略，但推薦其實(shí)現(xiàn)包含該功能。19.2S/MIMES/MIME整合了三種公鑰算法。第13章的DSS(DigitalSignatureStandard)是其推薦的數(shù)字簽名算法。Diffie-Hellman是其推薦的密鑰交換算法。實(shí)際上，在S/MIME中使用的是其能加密解密的變體ElGamal(詳見(jiàn)第10章)。第9章講述的RSA既可以用來(lái)做簽名，也可以用來(lái)加密會(huì)話密鑰。這些算法與PGP中使用的算法相同，提供了高層安全性。文檔規(guī)范推薦使用160位的SHA-1算法作為數(shù)字簽名的Hash函數(shù)，但是要求接收方能支持128位的MD5算法。第11章對(duì)MD5安全性的討論指出SHA-1的安全性更好一些，但由于MD5已經(jīng)有了廣泛的應(yīng)用，因此必須提供相關(guān)支持。對(duì)消息加密而言，推薦使用3DES。但實(shí)現(xiàn)時(shí)也必須支持40位的RC2，后者是一種弱加密算法，美國(guó)允許出口該算法。19.2S/MIMES/MIME文檔規(guī)范包含如何解決采用何種加密算法。從本質(zhì)上說(shuō)，一個(gè)發(fā)送方代理需要做如下兩個(gè)選擇：一是發(fā)送方代理必須確定接收方代理是否能夠使用該加密算法進(jìn)行解密。二是如果接收方代理只能接收弱加密的內(nèi)容，發(fā)送方代理必須確定弱加密方法是否是可以接受的。為能達(dá)到上述要求，發(fā)送方代理可以在他發(fā)送消息之前宣布他的解密能力，由接收方代理將該消息存儲(chǔ)，留給將來(lái)使用。發(fā)送方代理必須按照如下順序進(jìn)行：1.如果發(fā)送方代理有一個(gè)接收方解密性能表，則他應(yīng)該選擇表中的第一個(gè)(即優(yōu)先級(jí)最高)。2.如果發(fā)送方代理沒(méi)有接收方代理的解密性能表，但曾經(jīng)接收到一個(gè)或多個(gè)來(lái)自該接收方的消息，則應(yīng)該使用與最近接收到的消息一樣的加密算法，加密將要發(fā)送給接收方的消息。19.2S/MIME3.如果發(fā)送方代理沒(méi)有接收方的任何解密性能方面的知識(shí)，并且想冒險(xiǎn)一試(接收方可能無(wú)法解密消息)，則應(yīng)該選擇3DES。4.如果發(fā)送方代理沒(méi)有接收方任何解密性能方面的知識(shí)，并且不想冒險(xiǎn)，則發(fā)送方代理必須使用RC2/40。如果消息需要發(fā)給多個(gè)接收方，并且他們沒(méi)有一個(gè)可以共同接受的加密算法，則發(fā)送方代理需要發(fā)送兩條消息，此時(shí)，應(yīng)該特別注意該消息的安全性將由于弱安全性的一份副本而受到威脅。19.2S/MIMES/MIME消息S/MIME使用了一系列新的MIME內(nèi)容類(lèi)型，如下表所示。所有新的類(lèi)型都使用PKCS(Public-KeyCryptographySpecifications)設(shè)計(jì)，PKCS是紀(jì)念為S/MIME做出貢獻(xiàn)的RSA實(shí)驗(yàn)室及它們發(fā)布的一組公鑰密碼規(guī)范說(shuō)明。下面逐一介紹S/MIME消息處理過(guò)程。19.2S/MIME保護(hù)MIME實(shí)體：S/MIME用簽名和/或加密保護(hù)MIME實(shí)體。一個(gè)MIME實(shí)體可以是一個(gè)整體消息(除RFC5322頭部之外)，或當(dāng)MIME內(nèi)容類(lèi)型為multipart時(shí)，MIME實(shí)體是一個(gè)或多個(gè)消息的子部分。MIME實(shí)體將按照MIME消息準(zhǔn)備規(guī)則進(jìn)行準(zhǔn)備工作。然后將MIME實(shí)體和一些與安全相關(guān)的數(shù)據(jù)(如算法標(biāo)識(shí)符、證書(shū))一起用S/MIME處理，得到所謂的PKCS對(duì)象，最后，將PKCS對(duì)象作為消息內(nèi)容封裝到MIME中(提供合適的MIME頭部)。后面我們將舉例說(shuō)明?？傊?，將要發(fā)送的消息轉(zhuǎn)換成規(guī)范形式。特別地，對(duì)給定的類(lèi)型和子類(lèi)型而言，相應(yīng)的規(guī)范形式將作為消息內(nèi)容。對(duì)一個(gè)多部分的消息而言，合適的規(guī)范形式被用于每個(gè)子部分。19.2S/MIME使用編碼轉(zhuǎn)換時(shí)應(yīng)注意，在大多數(shù)情況下，使用安全算法會(huì)產(chǎn)生部分或全部二進(jìn)制數(shù)據(jù)表示的對(duì)象，將該對(duì)象放入外部MIME消息后，一般用Base64轉(zhuǎn)換編碼對(duì)其進(jìn)行轉(zhuǎn)換。而對(duì)一個(gè)多部分簽名的消息，安全處理過(guò)程并不改變字部分的消息內(nèi)容，除了內(nèi)容用7位表示的以外，其他代碼轉(zhuǎn)換應(yīng)使用Based64或quotedprintable，使得應(yīng)用簽名的內(nèi)容不會(huì)被修改。下面逐個(gè)介紹S/MIME內(nèi)容類(lèi)型。封裝數(shù)據(jù)：子類(lèi)型application/pkcs7-mime擁有一個(gè)smime-type參數(shù)。其結(jié)果(對(duì)象)采用ITU-T推薦的X.209中定義的BER(BasicEncodingRules)表示法。BER格式由8位字符串組成，即為二進(jìn)制數(shù)據(jù)，因此，此對(duì)象可在外部MIME消息中使用Base64轉(zhuǎn)換算法編碼。首先，看看封裝的數(shù)據(jù)。19.2S/MIMEMIME實(shí)體準(zhǔn)備封裝數(shù)據(jù)的步驟如下：1.為特定的對(duì)稱加密算法(RC2/40或3DES)生成偽隨機(jī)的會(huì)話密鑰。2.用每個(gè)接收方的RSA公鑰分別加密會(huì)話密鑰。3.為每個(gè)接收方準(zhǔn)備一個(gè)接收方信息塊(RecipientInfo)，其中包含接收方的公鑰證書(shū)標(biāo)志，加密會(huì)話密鑰的算法標(biāo)志和加密后的會(huì)話密鑰。4.用會(huì)話密鑰加密消息內(nèi)容。接收方信息塊(RecipientInfo)后面緊跟著構(gòu)成封裝數(shù)據(jù)的加密內(nèi)容，然后用Base64編碼，例如(不包含RFC5322)：19.2S/MIME為了恢復(fù)加密的消息，接收方首先去掉Base64編碼，然后用其私鑰恢復(fù)會(huì)話密鑰，最后，用會(huì)話密鑰解密得到消息內(nèi)容。簽名數(shù)據(jù)：signedData的簽名數(shù)據(jù)可以被一個(gè)或多個(gè)簽名者使用。為了簡(jiǎn)便起見(jiàn)，我們將討論范圍限定在單個(gè)數(shù)字簽名內(nèi)。MIME實(shí)體準(zhǔn)備簽名數(shù)據(jù)的步驟如下：1.選擇消息摘要算法(SHA或MD5)。2.計(jì)算帶簽名內(nèi)容的消息摘要或Hash函數(shù)。3.用簽名者的私鑰加密數(shù)字摘要。4.準(zhǔn)備一個(gè)簽名者信息塊(SignerInfo)，其中包含簽名者的公鑰證書(shū)，消息摘要算法的標(biāo)識(shí)符，加密消息摘要的算法標(biāo)識(shí)符和加密的消息摘要。19.2S/MIME簽名數(shù)據(jù)實(shí)體包含一系列塊，包含一個(gè)消息摘要算法標(biāo)識(shí)符，被簽名的消息和簽名者信息塊(signerInfo)，簽名數(shù)據(jù)實(shí)體可以包含一組公鑰證書(shū)，該證書(shū)可以構(gòu)成從上級(jí)認(rèn)證機(jī)構(gòu)或更高級(jí)的認(rèn)證機(jī)構(gòu)到該簽名者的一條鏈路。最后將這些數(shù)據(jù)用Base64轉(zhuǎn)換編碼。例如(不包含RFC5322頭)：為了恢復(fù)簽名消息并驗(yàn)證簽名，接收方首先去掉Base64編碼，然后用簽名者的公鑰解密消息摘要，接收方獨(dú)立計(jì)算消息摘要，并將其與解密得到的消息摘要進(jìn)行比較，從而驗(yàn)證簽名。19.2S/MIME透明簽名：透明簽名(Clearsigning)在對(duì)多部分內(nèi)容類(lèi)型的子類(lèi)型簽名時(shí)使用。簽名過(guò)程并不涉及對(duì)簽名消息的轉(zhuǎn)換，因此該消息發(fā)送時(shí)是明文。因此，具有MIME能力而不具備S/MIME能力的接收者也能閱讀輸入的消息。一個(gè)multipart/signed消息由兩部分組成。第一部分可以是任何MIME類(lèi)型但必須做好準(zhǔn)備，使之在從源端到目的端的傳輸過(guò)程中不被改變，這意味著第一部分不能為7位，需要用Base64或quoted-printable編碼。而后其處理過(guò)程與簽名數(shù)據(jù)相同，但簽名數(shù)據(jù)格式的對(duì)象中消息內(nèi)容域?yàn)榭?，該?duì)象與簽名相分離，再將它用Base64編碼，作為multipart/signed消息的第二部分。第二部分MIME內(nèi)容類(lèi)型為application，子類(lèi)型為pkcs7-signature。19.2S/MIME例如：協(xié)議的參數(shù)表明它是一個(gè)由兩部分組成的透明簽名實(shí)體。參數(shù)micalg表明使用消息摘要類(lèi)型。接收方可以從第一部分獲得消息摘要，并同第二部分中恢復(fù)得到的消息摘要進(jìn)行比較來(lái)進(jìn)行認(rèn)證。19.2S/MIME撤銷(xiāo)請(qǐng)求：典型地，一個(gè)應(yīng)用或用戶向認(rèn)證機(jī)構(gòu)申請(qǐng)公鑰證書(shū)。S/MIME的實(shí)體application/pkcs10用于傳遞證書(shū)請(qǐng)求。證書(shū)請(qǐng)求包括證書(shū)的請(qǐng)求信息塊，公鑰加密算法標(biāo)識(shí)符，用發(fā)送方私鑰對(duì)證書(shū)請(qǐng)求信息塊的簽名。證書(shū)請(qǐng)求信息塊包含證書(shū)主題的名字(擁有待證實(shí)的公鑰實(shí)體)和該用戶公鑰的標(biāo)志位串。僅含證書(shū)消息：僅包含證書(shū)或證書(shū)撤銷(xiāo)表(CRL)的消息在應(yīng)答注冊(cè)請(qǐng)求時(shí)發(fā)送。該消息的類(lèi)型/子類(lèi)型為application/pkcs7-mime，并帶一個(gè)退化的smime-type參數(shù)。其步驟除沒(méi)有消息內(nèi)容及簽名者信息塊為空以外，其他過(guò)程與創(chuàng)建簽名數(shù)據(jù)信息相同。19.2S/MIMES/MIME證書(shū)處理過(guò)程S/MIME使用公鑰證書(shū)的方式與X.509的版本3一致(詳見(jiàn)第14章)。S/MIME使用的密鑰管理模式是嚴(yán)格的X.509證書(shū)層次和PGP的Web信任的一種混合方式。按照PGP模式，S/MIME的管理者和(或)用戶必須配置每個(gè)客戶端的信任密鑰表和證書(shū)撤銷(xiāo)表。也就是說(shuō)，驗(yàn)證接收到的簽名和輸出消息的簽名工作都是通過(guò)本地維護(hù)證書(shū)實(shí)現(xiàn)的。另一方面，證書(shū)由認(rèn)證機(jī)構(gòu)頒發(fā)。19.2S/MIME用戶代理角色：一個(gè)S/MIME用戶需要執(zhí)行若干密鑰管理職能：密鑰生成：與一些行政管理機(jī)構(gòu)相關(guān)的用戶(如與局域網(wǎng)管理相關(guān))必須能生成單獨(dú)的Diffie-Hellman和DSS密鑰對(duì)，并且應(yīng)該能生成RSA密鑰對(duì)。每個(gè)密鑰對(duì)必須是利用非確定的隨機(jī)輸入生成，并用安全的方式保護(hù)。用戶代理應(yīng)該能生成長(zhǎng)度為768位到1024位的RSA密鑰對(duì)，且禁止生成長(zhǎng)度大于512位的RSA密鑰對(duì)。注冊(cè)：為了獲得X.509公鑰證書(shū)，用戶的公鑰必須到認(rèn)證機(jī)構(gòu)注冊(cè)。證書(shū)存儲(chǔ)和檢索：為了驗(yàn)證接收到的簽名和