《信息安全引論》課件Chapter7

1、第7章 電子郵件安全 電子郵件是網(wǎng)絡(luò)的殺手級應(yīng)用之一，電子郵件的安全是網(wǎng)絡(luò)安全的重要研究內(nèi)容之一，歸結(jié)起來電子郵件的主要安全需求包括：認(rèn)證性與機(jī)密性。本章主要研究保證電子郵件機(jī)密性和認(rèn)證性的主要技術(shù)手段。具體說本章主要研究PGP(用于私人)和S/MIME(用于工業(yè)和組織)本章內(nèi)容第1節(jié) 電子郵件安全服務(wù)第2節(jié) Pretty Good Privacy 第3節(jié) S/MIME 小結(jié) 本章首先講述了電子郵件的安全需要，接著講述了主要用于保證個人電子郵件安全的技術(shù)PGP。在PGP之后又講述了主要用于保證商業(yè)與組織電子郵件安全的技術(shù)標(biāo)準(zhǔn)S/MIME。集中講述這些技術(shù)的安全保證機(jī)制、有關(guān)的消息格式、消息的內(nèi)

2、容、消息的變換等。內(nèi)容比較瑣碎，但是也比較容易理解。思考題 選擇一個本章沒有研究的電子郵件安全需要，分析什么情況下有這樣的安全需要，并為該安全需要設(shè)計一種安全保證機(jī)制。 分析本章的電子郵件安全方案PGP和S/MIME還有什么缺點(diǎn)與漏洞。第1節(jié) 電子郵件安全服務(wù) 理想的電子郵件安全服務(wù)應(yīng)該包括下列內(nèi)容： (1) 私有性：只有預(yù)期的接收者才能閱讀郵件消息； (2) 認(rèn)證性：向接收者保證發(fā)送者身份的真實(shí)性； (3) 完整性：向接收者保證發(fā)送者發(fā)送的郵件在傳輸過程中沒有被修改過。電子郵件安全服務(wù) (4) 非否認(rèn)：發(fā)送者不能否認(rèn)曾經(jīng)發(fā)送過某個消息。 (5) 郵件提交證據(jù)：郵件系統(tǒng)給發(fā)送者提供的、證明其所

3、發(fā)送的信息已經(jīng)提交給了郵件投遞系統(tǒng)的證據(jù)。 (6) 郵件投遞證據(jù)：證明接收者已經(jīng)收到該郵件消息的證據(jù)。 (7) 消息流的機(jī)密性：確保Carol不僅不知道Alice發(fā)給Bob的郵件內(nèi)容，而且也不知道Alice電子郵件安全服務(wù)是否給Bob發(fā)送過郵件。 (8) 匿名性：郵件的接收者無法知道發(fā)送者的身份。 (9) 防泄漏：保證具有某種安全級別的信息不會泄漏到特定區(qū)域的能力。 (10) 審計：應(yīng)該具有記錄安全相關(guān)事件的能力。 (11) 計費(fèi)：郵件系統(tǒng)應(yīng)該具有記錄使用情況的能力電子郵件安全服務(wù) (12) 自毀服務(wù)：發(fā)送者可以規(guī)定郵件被投遞到接收方之后應(yīng)該自己銷毀。 (13) 消息序列完整性：保證一系列消息

4、按照發(fā)送順序達(dá)到，不會丟失。 目前大多數(shù)郵件系統(tǒng)都不提供這些安全服務(wù)，即使專門設(shè)計的安全郵件系統(tǒng)也只提供其中的若干種。目前安全電子郵件所提供的服務(wù)主要是私有性、認(rèn)證、完整性和消息序列完整性。一些安全服務(wù)的解決思路 (1) 建立密鑰：多數(shù)安全服務(wù)是通過使用密碼機(jī)制實(shí)現(xiàn)的，但是密碼機(jī)制需要密鑰。如果Alice要給Bob發(fā)送消息，那么需要知道哪些密鑰呢？Alice怎樣才能可靠而有效地得到這些密鑰呢？發(fā)送消息的過程還有誰參與？這是電子郵件安全首先要研究的問題。 (2) 私有性：很多人認(rèn)為電子郵件是保密的，其實(shí)那些想知道別人秘密的人有許多方法可以得到別人的郵件消息，比如通過搭線竊聽獲取一些安全服務(wù)的解決

5、思路在網(wǎng)絡(luò)上傳輸?shù)泥]件消息，中繼節(jié)點(diǎn)也可能安裝了保存郵件消息的軟件，并將郵件消息泄露給想知道的人。所以要想保密，不能依賴于網(wǎng)絡(luò)來保證消息的機(jī)密性。通過使用密碼機(jī)制對消息進(jìn)行加密，就可以保證消息的機(jī)密性。很自然的想法是用Bob的公開密鑰或者雙方共享的對稱密鑰加密，但郵件通常不采用這種方式，原因是：如果Alice有一個很長的郵件要發(fā)送給多個接收者，那么就需要針對每個接收者分別加密消息，結(jié)果發(fā)送給每個接收者的消息都不同。而且公鑰加密比對稱加密慢得多。一些安全服務(wù)的解決思路如非必要，最好不要使用長期密鑰，為了延長共享的長期密鑰的生命周期，最好是盡可能少地使用這種代價昂貴的密鑰加密消息。那么郵件系統(tǒng)所使

6、用的方法是：Alice選擇一個隨機(jī)的對稱密鑰S，Alice首先使用S加密郵件消息，然后使用Bob的公鑰加密S，再把加密的消息和加密的密鑰發(fā)給Bob。這種機(jī)制對于要發(fā)送給多個接收者的情況也帶來方便。 (3) 在普通的郵件中，Carol可以將發(fā)送給Bob的郵件的消息中From域填上Alice。如果郵件的一些安全服務(wù)的解決思路來源比較重要的話，這就會成為一個嚴(yán)重的問題。因此安全郵件系統(tǒng)需要Bob確信郵件的消息確實(shí)來源于Alice。一般通過公開密鑰技術(shù)實(shí)現(xiàn)源認(rèn)證。 (4) 消息完整性：當(dāng)Bob接收到Alice發(fā)送來的消息時，他怎么知道Carol是否攔截并篡改了該消息呢？如果不能保證消息的完整性，那么源

7、認(rèn)證也就沒有多大意義。所以，所有的郵件系統(tǒng)要么同時提供消息的完整性和源認(rèn)證，要么一些安全服務(wù)的解決思路都不提供。 (5) 非否認(rèn)：如果Alice給銀行發(fā)送一條消息，要求給Bob的賬戶轉(zhuǎn)100萬美元，而銀行轉(zhuǎn)了賬以后，Alice可以否認(rèn)發(fā)送過這個消息，那銀行還會相信這種方式發(fā)來的信息嗎？銀行不僅需要證實(shí)該消息確實(shí)來自Alice，而且在必要的時候，還應(yīng)當(dāng)能夠向法院證明Alice的確發(fā)送過這個消息。使用公鑰技術(shù)能夠很自然地實(shí)現(xiàn)非否認(rèn)的源認(rèn)證。一些安全服務(wù)的解決思路 (6) 郵件提交證據(jù)：電子郵件能夠提供類似于掛號信服務(wù)的功能。只不過電子郵件系統(tǒng)采用的是對郵件內(nèi)容進(jìn)行密碼學(xué)運(yùn)算的方式。為實(shí)現(xiàn)郵件提交證

8、據(jù)服務(wù)，郵件系統(tǒng)可以將郵件與其他有用的信息串接起來，然后計算消息摘要并對其進(jìn)行簽名。用戶可以使用該收據(jù)來證明該消息已經(jīng)被發(fā)送。 (7) 郵件投遞證據(jù)：電子郵件系統(tǒng)中的實(shí)現(xiàn)方式是要求郵件消息的接收者或者郵件投遞服務(wù)一些安全服務(wù)的解決思路方對郵件消息和其他有用信息的消息摘要進(jìn)行簽名。 (8) 消息流的機(jī)密性：這樣的服務(wù)可以通過中介轉(zhuǎn)發(fā)，甚至通過多個中介轉(zhuǎn)發(fā)。 (9) 匿名性：因?yàn)榇蠖鄶?shù)郵件系統(tǒng)會在郵件消息中自動包含發(fā)送者的名稱。修改發(fā)送者名稱并不能保證匿名性。如果確實(shí)想保證消息的匿名性，可以使用消息流機(jī)密性的類似技術(shù)。一些安全服務(wù)的解決思路 (10) 防泄漏：該特性模仿了強(qiáng)制訪問控制，網(wǎng)絡(luò)可被分為

9、能夠處理特定安全級別的多個部分，每個郵件消息可被標(biāo)記為不同安全級別，消息的路由設(shè)備可以拒絕將某個消息轉(zhuǎn)發(fā)到不能處理該安全級別的網(wǎng)絡(luò)中去。 (11) 校驗(yàn)消息的真正發(fā)送時間：為什么會有人將消息的發(fā)送時間提前呢？不誠實(shí)的采購者為了不對自己所發(fā)出的采購信息負(fù)責(zé)，他可以說該采購信息是在私鑰丟失之后，別人一些安全服務(wù)的解決思路簽署的，但故意將消息時間提前了。這種證明消息是在某個特定的時刻之前生成的，解決方法是采用公證的方法。要證明消息是在某個特定時刻之后生成的，那么可以在消息中嵌入一個在這個時刻以前還不知道的東西，例如某個時間的出版的報紙、刊物等。 BACK第2節(jié) Pretty Good Privacy

10、 電子郵件與WWW被并列稱為網(wǎng)絡(luò)殺手級應(yīng)用(Killer Use) 。這兩方面的應(yīng)用正是互聯(lián)網(wǎng)發(fā)展的雙引擎。電子郵件是唯一的能夠跨越各種體系結(jié)構(gòu)、各種供應(yīng)商平臺的分布式應(yīng)用。用戶期望能夠、并且也確實(shí)能夠向直接或間接與互聯(lián)網(wǎng)相連的其他用戶發(fā)送信息，而不需考慮用戶的操作系統(tǒng)或通信機(jī)制。PGP 由于對電子郵件的依賴越來越嚴(yán)重，電子郵件的安全問題也被提上研究日程。人們希望電子郵件系統(tǒng)也能夠提供安全的電子郵件服務(wù)。電子郵件的安全主要包括機(jī)密性和認(rèn)證性，主要解決方案有PGP和S/MIME，本章主要講述這兩種安全機(jī)制。PGP概述 PGP在計算機(jī)界是一個驚人的現(xiàn)象，因?yàn)镻GP基本上是一個人努力的結(jié)果。PGP并

11、不是一個新的算法或者新的技術(shù)，它是通過將最優(yōu)秀的加密算法、認(rèn)證算法、簽名算法等進(jìn)行恰當(dāng)?shù)慕M合，形成一個基于少量的易于使用的命令的、通用的安全的電子郵件應(yīng)用。該應(yīng)用獨(dú)立于操作系統(tǒng)和處理器。PGP不僅能夠用于保護(hù)電子郵件，也能用于對文件進(jìn)行加密和完整性保護(hù)。PGP概述PGP處理電子郵件的方式與普通電子郵件沒有什么不同。要發(fā)送電子郵件，首先使用PGP來轉(zhuǎn)換要發(fā)送的文件，然后再使用傳統(tǒng)的郵件程序來發(fā)送轉(zhuǎn)換之后的文件。同樣接收用PGP加密的郵件時，也是把接收道的郵件當(dāng)作一個PGP文件進(jìn)行處理。因?yàn)檫@樣有點(diǎn)不太方便，可以把PGP集成到其他郵件系統(tǒng)中，PGP的源代碼中包含幾個經(jīng)過修改的通用的郵件系統(tǒng)。PGP

12、概述 PGP能夠得到廣泛的應(yīng)用，與下面的原因是分不開的： (1) 它的各種版本在全球范圍內(nèi)都可以自由獲取，并且能夠運(yùn)行各種操作平臺(Windows, Unix, Macintosh)。 (2) 它選擇的算法經(jīng)過廣泛的公開分析，被認(rèn)為是極其安全的。而且算法包中包括RSA, DSS, Diffie-Hellman公鑰算法，CAST, IDEA, 3DES對稱加密算法和SHA-1散列算法，給用戶選擇PGP概述的自由。 (3) 具有廣泛的適用性，從希望加密文件與消息的公司到希望在全球范圍內(nèi)進(jìn)行安全通信的個人，都可以使用。 (4) 它不是任何政府或標(biāo)準(zhǔn)組織所開發(fā)的，也不受任何政府或標(biāo)準(zhǔn)組織的控制。這使得

13、PGP很有吸引力。 (5) PGP已經(jīng)成為互聯(lián)網(wǎng)事實(shí)上的標(biāo)準(zhǔn)之一。PGP提供的安全服務(wù) PGP能夠提供三類服務(wù)包括：認(rèn)證性服務(wù)、機(jī)密性服務(wù)、認(rèn)證性與機(jī)密性服務(wù)?，F(xiàn)在我們先看一下PGP如何提供這三種服務(wù)的，然后再來看這三種服務(wù)的細(xì)節(jié)。 PGP的操作有5種：數(shù)字簽名、消息加密、消息壓縮、電子郵件兼容變換、對消息分段。 首先看三類服務(wù)分別是如何實(shí)現(xiàn)的。PGP認(rèn)證過程 (1) Alice產(chǎn)生一個消息。 (2) 用SHA-1生成該消息的160比特的散列值。 (3) Alice 用她的私鑰對散列值簽名，放到原消息的前面。 (4) Bob 收到后用Alice的公鑰解密恢復(fù)散列值。 (5) Bob 用該消息計

14、算其散列值，并與解密的散列值比較，如果匹配，就認(rèn)為消息是可信的。PGP機(jī)密性保證機(jī)制 (1) Alice 產(chǎn)生一個消息與一個128比特的隨機(jī)數(shù)(作為加密該消息的密鑰)。 (2) Alice 用該密鑰和CAST-128 (or IDEA or 3DES) 加密消息。 (3) Alice 用Bob的RSA公開密鑰加密密鑰，并放到消息的前面。 (4) Bob 用自己的私鑰解密，得到會話密鑰。 (5) 用這個會話密鑰解密實(shí)際消息。機(jī)密性與認(rèn)證性 PGP保證機(jī)密性與認(rèn)證性的方法非常簡單、直觀，實(shí)際上就是將機(jī)密性保護(hù)的過程從中間截斷，然后在中間加上保證認(rèn)證的過程。這樣簡單的方法就實(shí)現(xiàn)了認(rèn)證性與機(jī)密性保護(hù)。

15、PGP的壓縮 PGP默認(rèn)在簽名之后，加密之前要進(jìn)行一次壓縮。壓縮能夠節(jié)約電子郵件存儲與傳遞過程中所需要的空間。壓縮算法放在什么位置非常關(guān)鍵。壓縮放在簽名之后的原因有兩個： (1) 簽署未經(jīng)壓縮的消息，使得人們能夠僅僅保存未經(jīng)壓縮的消息以及對消息的簽名，可以在以后隨時進(jìn)行驗(yàn)證。如果簽署的是經(jīng)過壓縮的消息，當(dāng)以后需要驗(yàn)證時，就需要保存一個消息的壓縮文件或者重新進(jìn)行壓縮，這兩種方法都給使用帶來不便。PGP的壓縮 (2) 即使驗(yàn)證時，驗(yàn)證者樂意進(jìn)行壓縮，PGP壓縮也會帶來困難。因?yàn)镻GP算法是不確定的，不同的算法有不同的壓縮率和壓縮速度，并產(chǎn)生不同的壓縮格式。然而，這些不同的壓縮算法具有互操作性。在壓

16、縮之后進(jìn)行散列運(yùn)算與簽名將限制接收方與發(fā)送方必須采用同樣的壓縮算法。消息先壓縮后加密能夠增強(qiáng)安全性，因?yàn)閴嚎s能夠減少原始明文中的信息冗余，這就使得密碼分析更加困難。PGP采用的壓縮算法是ZIP。PGP與E-mail的兼容性 只要采用PGP，至少有部分的數(shù)據(jù)包是經(jīng)過加密后傳輸?shù)?。如果僅使用簽名服務(wù)，那么消息摘要需要加密。如果使用機(jī)密性服務(wù)，消息和簽名都要加密。因而部分或全部的數(shù)據(jù)包是由任意的8個一組的數(shù)據(jù)流組成的。然而許多E-mail系統(tǒng)只允許使用由ASCII文本所組成的數(shù)據(jù)包。為與這種限制相兼容，PGP提供了將原始的8比特二進(jìn)制數(shù)據(jù)流轉(zhuǎn)換成可打印的ASCII文本的服務(wù)。PGP與E-mail的兼

17、容性所用的方案是Radix-64轉(zhuǎn)換。這種方案將3字節(jié)的數(shù)字，轉(zhuǎn)換成4個ASCII碼字符。6個連續(xù)的比特用一個ASCII碼字符來代替。因?yàn)檫@種轉(zhuǎn)換是一種不考慮原始內(nèi)容的盲轉(zhuǎn)換，即使輸入數(shù)據(jù)中偶爾有ASCII碼。所以如果消息經(jīng)過簽名，但不加密，通過這種轉(zhuǎn)換后，消息對于一般的接觸到消息的人來說是不可讀的，這也提供了一定程度的機(jī)密性。下面的圖說明了PGP所提供的四種服務(wù)之間的關(guān)系。發(fā)送方進(jìn)行的處理過程PGP與E-mail的兼容性在傳輸消息時，如果需要簽名，就對未壓縮的明文消息的散列函數(shù)值進(jìn)行簽名。然后對明文和簽名進(jìn)行壓縮。下一步，如果有機(jī)密性要求，就將壓縮后的數(shù)據(jù)進(jìn)行加密，同時將對稱加密密鑰用接收方

18、的公開密鑰加密并置于前面加密的數(shù)據(jù)之前，最后將所有的數(shù)據(jù)用Radix-64轉(zhuǎn)換，轉(zhuǎn)換成Radix-64 格式。在接收方進(jìn)行順序完全相反的操作，具體過程如下圖所示。分拆與重新裝配E-mail設(shè)施通常都限制所傳輸文件的大小，這主要是為了限制利用E-mail發(fā)送可執(zhí)行文件。所以任何大于限制大小的消息都必須拆開成為小于限制大小的消息，分別進(jìn)行傳輸。為適應(yīng)這種情況，PGP自動將太大的消息拆分成能夠通過E-mail進(jìn)行傳輸?shù)南ⅲ@是在前面的所有處理(包括Radix-64轉(zhuǎn)換)都完成后進(jìn)行的。這樣做的好處是會話密鑰與簽名僅在拆分后的一個字組中出現(xiàn)一次。在接收端，PGP首先要剝離E-mail的所有報頭，并重

19、新裝配信息，然后進(jìn)行下面所示的處理。接收方進(jìn)行的處理過程密鑰與密鑰環(huán) PGP中有四種密鑰，分別是一次性的對稱會話密鑰、公開密鑰、私有密鑰和基于通行短語的對稱密鑰。對這些密鑰有三種基本要求： (1) 要能夠產(chǎn)生不可預(yù)測的會話密鑰； (2) 應(yīng)當(dāng)允許用戶使用多個公開密鑰私有密鑰對。原因是用戶可能會時不時地更換其密鑰對。更換密鑰對就帶來一個問題，所有尚在路途中的信息都將用過時的密鑰進(jìn)行處理，而且在更新到達(dá)接收者之前，接收者只能使用舊的密鑰與密鑰環(huán)公開密鑰。此外一個用戶在同一個時間也可能使用多個密鑰對與不同的對象通信，或者僅僅為了限定一個密鑰所加密的信息量，從而增強(qiáng)安全性。所有這些都說明用戶和他們的公

20、鑰之間并不存在一一對應(yīng)的關(guān)系，這就需要一定的機(jī)制來識別具體的密鑰。每一個PGP實(shí)體都必須維護(hù)一個自己的公鑰/私鑰對文件以及需要進(jìn)行通信的其它實(shí)體的公鑰文件。生成會話密鑰 一個會話密鑰與單個消息相關(guān)聯(lián)，而且只用于加密或解密相應(yīng)的消息。在PGP中加密與解密的算法是CAST-128，IDEA或者3DES。假設(shè)使用CAST-128算法，我們來討論會話密鑰的生成方法。首先用CAST-128生成一個128比特的隨機(jī)數(shù)，生成方法是給該算法輸入一個128比特的密鑰和作為明文的兩個64比特的分組。運(yùn)用CFB模式加密，生成兩個64比特的密文分組，將這兩個密文分組連接起來，生成一個128比特生成會話密鑰的會話密鑰。

21、 輸入隨機(jī)數(shù)生成器的明文有兩個64比特的分組，是從128比特的隨機(jī)數(shù)獲得的，而這128個比特的隨機(jī)數(shù)是通過用戶擊鍵所用的時間與實(shí)際敲擊的鍵決定的。因而如果用戶正常敲擊鍵盤上任意的鍵，將會產(chǎn)生合理的隨機(jī)數(shù)。隨機(jī)輸出還與前面的會話密鑰輸入有關(guān)。這樣采用CAST-128，就能產(chǎn)生一個確實(shí)不可預(yù)測的會話密鑰。具體過程如下圖所示。密鑰標(biāo)示 如前所述，加密的消息必須伴隨一個用接收者公鑰加密的會話密鑰。所以只有合法的接受者才能恢復(fù)會話密鑰、進(jìn)一步恢復(fù)出消息。如果每個用戶都只使用一個公鑰私鑰對，那么接收者只要用相應(yīng)的私鑰解密會話密鑰即可?，F(xiàn)在一個用戶可能有許多公鑰私鑰對，那么接收者怎么知道用哪個私有密鑰去解密

22、呢？當(dāng)然樸素的解決方案有兩種，一是用所有的私要試一遍，或者讓發(fā)送者附上所用的公鑰。這兩密鑰標(biāo)示種方法有什么問題呢？在第2種方案中接收者只要驗(yàn)證所附的公鑰確實(shí)是自己的公鑰，就知道對應(yīng)的私鑰，工作就可以進(jìn)行下去。但是附帶公鑰也不是一個小的數(shù)據(jù)，每個信息需要附帶幾百個十進(jìn)制數(shù)。另一種方案是給每個公鑰一個編號。然后只需要告訴接收者所用的公鑰的編號即可。這又產(chǎn)生了一個管理問題：公開密鑰的編號必須在發(fā)送者和接收者之間進(jìn)行交換，并確保始終一致。這是一個不必要的負(fù)擔(dān)。密鑰標(biāo)示 PGP采用的方法是在發(fā)送消息的同時，發(fā)送所采用的公開密鑰的最后面的64比特。這樣雖然不能保證兩個密鑰最后面64比特一定不同，但可以保證

23、兩個不同的密鑰最后64比特相同的概率非常低。 介紹了密鑰表示的概念之后，我們可以更詳細(xì)地看一下PGP所傳送的消息的格式。具體的格式如下面的圖所示。PGP消息 消息：指實(shí)際要傳輸?shù)臄?shù)據(jù)、文件名與表明文件生成時間的時間標(biāo)記。 簽名：包括簽名生成時間、消息摘要(160比特的SHA-1摘要，并用發(fā)送者的私有密鑰簽名)、消息摘要的起始16比特，用于驗(yàn)證對摘要的解密是否正確、發(fā)送者的公鑰ID。 會話密鑰部分：包括用接收者公鑰加密的會話密鑰、接收者公鑰變ID。 所有PGP消息最后轉(zhuǎn)換成Radix64格式消息。密鑰環(huán) 密鑰ID在PGP操作中是非常關(guān)鍵的，為了保證機(jī)密性與真實(shí)性，PGP信息需要兩個密鑰ID，這些

24、密鑰需要系統(tǒng)地存儲與組織以保證所有當(dāng)事人都能夠使用。PGP采用的機(jī)制是在每個節(jié)點(diǎn)有兩個數(shù)據(jù)文件，一個保存該節(jié)點(diǎn)的公鑰私鑰數(shù)據(jù)，另一個保存該節(jié)點(diǎn)知道的其他節(jié)點(diǎn)的公開密鑰數(shù)據(jù)。這些數(shù)據(jù)分別稱為私有密鑰環(huán)和公開密鑰環(huán)。下面的圖表示一般的密鑰環(huán)的結(jié)構(gòu)。私鑰環(huán)時標(biāo)密鑰ID公鑰加密私鑰用戶ID.TiPimod 264PiE(Si)用戶i.公鑰環(huán)時標(biāo)密鑰ID公鑰信任級別用戶ID密鑰合法性簽名簽名信任程度.TiPimod 264PiTrust_flag用戶iTrust_flag.私鑰密鑰環(huán) 為使用方便，用戶ID一般用用戶的E-mail地址來表示。當(dāng)然也可以選用用戶的姓名作為用戶ID。用戶ID或密鑰ID都可以作

25、為索引項(xiàng)。有時可能需要用這兩項(xiàng)合起來作為索引項(xiàng)。為保證機(jī)密性，用戶的私鑰需要加密保存。運(yùn)用基于通行短語(Passphase)的加密過程： (1) 用戶選擇一個通行短語； (2) 利用SHA-1對通行短語進(jìn)行散列運(yùn)算，產(chǎn)生一個散列函數(shù)值，拋棄通行短語；私鑰密鑰環(huán) (3) 系統(tǒng)運(yùn)用CAST-128加密散列值，散列值也被丟棄，用加密過的散列值作為私有密鑰。 相應(yīng)地，用戶如果要想使用私有密鑰，就必須提供通行短語。PGP就可以恢復(fù)出私有密鑰。 這是非常緊湊，非常有效的方案，同任何基于口令的系統(tǒng)一樣，系統(tǒng)的安全性取決于通行短語的安全性。應(yīng)該使用不易猜測，但易于記憶的通行短語。公鑰密鑰環(huán) 需要注意的是在公鑰

26、密鑰環(huán)中，同一個公鑰可能有多個用戶ID。 現(xiàn)在，我們來看一下在消息發(fā)送與接收過程中如何使用密鑰環(huán)。為簡單起見，我們忽略壓縮和轉(zhuǎn)換過程。如下面的圖所示。 發(fā)送方按照以下步驟進(jìn)行： 1 對消息進(jìn)行簽名: (1) PGP應(yīng)用密鑰ID作為索引項(xiàng)從私鑰密鑰環(huán)中找到發(fā)送者的經(jīng)過加密的私鑰。如果沒有提供密鑰ID，就用第一個私發(fā)送者最后發(fā)送的消息形式密鑰環(huán)的使用鑰。(2) PGP提示用戶輸入通行短語，以便對私鑰解密。(3) 利用私鑰構(gòu)造消息的簽名部分。 2 加密消息：PGP產(chǎn)生一個會話密鑰，并用該會話密鑰加密消息。(2) PGP從公鑰密鑰環(huán)中找到接收者的公鑰。(3) 利用公鑰構(gòu)造PGP消息的會話密鑰部分。 而

27、在接收方，接收者進(jìn)行如下操作，如下面的圖所示。 接收者的工作 (1) 解密消息：(a) 從收到的消息的會話密鑰部分找到密鑰ID，據(jù)此找到接收者的私鑰。(b) PGP提示接收者輸入通行短語，用私有密鑰解密得到會話密鑰。(c) 用會話密鑰解密消息。 (2) 認(rèn)證消息: (a) PGP找到發(fā)送者的公鑰。(b) PGP解密消息摘要。(c) PGP計算消息的摘要，然后把計算的消息摘要和解密的消息摘要進(jìn)行比較，如果匹配，則通過認(rèn)證。公鑰管理 PGP用一套聰明的、高效的、互相制約的函數(shù)與格式約定提供有效的機(jī)密性與真實(shí)性服務(wù)。為了使整個系統(tǒng)能夠順利工作，還需要解決一個問題：公開密鑰的管理問題。保護(hù)公開密鑰不被

28、篡改在公開密鑰的應(yīng)用中是一個最困難的問題。它是公開密鑰密碼學(xué)唯一致命的弱點(diǎn)，為解決這個問題需要付出許多計算復(fù)雜性的代價。PGP提供了這個問題的一個結(jié)決框架，因?yàn)镻GP用途廣泛，所以并沒有提出一個剛性的公鑰管理方案。公鑰管理 問題的實(shí)質(zhì)是用戶Alice必須建立包含所有用PGP進(jìn)行通信的對象的公鑰的一個公鑰密鑰環(huán)。假設(shè)Alice的密鑰環(huán)包含Bob的公鑰，但實(shí)際上該公鑰是Carol的。這種情況可能在下面的環(huán)境下發(fā)生：Alice從公鑰數(shù)據(jù)庫中獲得了Bob的公鑰，而事實(shí)上Carol用自己的公鑰替換了Bob的公鑰。這樣的結(jié)果就會產(chǎn)生兩個威脅: (1) Carol能夠給Alice發(fā)送消息，并且能夠假冒Bob

29、的簽名，Alice就會將Carol發(fā)送的消息當(dāng)成是公鑰管理Bob發(fā)送的消息。(2) Carol能夠閱讀Alice給Bob發(fā)送的任何消息。 有一些可行的方案能夠使一個用戶的密鑰環(huán)中包含假的公鑰的風(fēng)險降到最低。下面都是一些可以采取的措施： (1) 用物理措施獲得Bob的密鑰。Bob可以當(dāng)面告訴Alice，或者當(dāng)面寫給Alice，或者把密鑰存到一個磁盤中交給Alice，Alice拿回去直接裝到自己的密鑰環(huán)中。公鑰管理 (2) 通過電話驗(yàn)證密鑰：Bob可以通過E-mail告訴Alice他的公鑰，然后通過電話告訴Alice公鑰的散列函數(shù)值，如果Alice能夠辨別Bob的聲音，該方法就是可行的。 (3)

30、Alice 通過一個互相信任的個體獲得Bob的公鑰。 (4) Alice從CA處得到Bob的公開密鑰。 在后兩種情況下，Alice都需要決定可信者的可信水平。公鑰管理 盡管PGP并沒有規(guī)定建立認(rèn)證的任何機(jī)制，但卻提供了一個方便的利用信任鏈的方法，將信任與公鑰關(guān)聯(lián)起來，并開發(fā)信任信息?；镜慕Y(jié)構(gòu)如下：公鑰環(huán)的每一個記錄包含一個公鑰證書和一個信任水平，表明PGP對該公鑰的信任程度。信任度越高，用戶ID與該密鑰的綁定關(guān)系越緊密。與密鑰環(huán)的條目有關(guān)連的還有密鑰環(huán)擁有者所收集到的關(guān)于證書的零個或者多個簽名。每個簽名以此與一個信任域相關(guān)聯(lián)，表明PGP用戶信任簽名者對證書的簽名的公鑰管理信任程度。密鑰信任域

31、的內(nèi)容是從收集的關(guān)于該條目的所有簽名計算出來的。最后密鑰環(huán)中的每一個條目都定義了與某個擁有者相關(guān)聯(lián)的一個公鑰、一個擁有者的信任域用于表明公鑰環(huán)的擁有者對于該公鑰擁有者所簽發(fā)的證書的信任程度。這個信任水平是有由密鑰環(huán)的擁有者自己確定的。 包含在框架中密鑰信任域、簽名信任域和擁有者信任域被稱為Trust flag byte. 假設(shè)我們在討論用戶Alice的密鑰環(huán)，信任處理操作如下：Trust flag byte 內(nèi)容信任操作處理 (1) 當(dāng)Alice鑰在自己的密鑰環(huán)中添加一個公開密鑰時，必須為該公開密鑰的擁有者分配一個Trust flag。如果該公鑰的擁有者就是Alice本人，該公鑰將會在Alic

32、e私鑰密鑰環(huán)中出現(xiàn)，那么就分配一個最高程度的信任度。否則PGP將請求Alice對該密鑰進(jìn)行評價，Alice必須給出一個希望的信任程度，Alice的選擇包括Unknown, untrust, marginally trust or completely trust. (2) 添加一個公鑰時，必須附帶一個或多個簽名。以后還可以添加更多的簽名。當(dāng)添加一個信任操作處理簽名時，PGP就會搜索公鑰環(huán)，查看該簽名的簽名人是否是一個已知的公鑰的擁有者。如果是，就為該簽名的簽名信任域分配一個OWNERTRST值，否則就分配一個未知用戶值。 (3) 以本條目的簽名信任域?yàn)榛A(chǔ)計算密鑰信任值。如果至少有一個簽名是由

33、最高信任程度的擁有者簽署的，那么密鑰信任值就設(shè)置為完全信任。否則PGP要計算信任值的加權(quán)和。對信任操作處理對于總是信任的簽名分配1/X的權(quán)重，對于通常信任的簽名分配1/Y的權(quán)重，其中X和Y是用戶設(shè)置的參數(shù)。如果所有簽名者關(guān)于密鑰/用戶ID的權(quán)重和達(dá)到1，就認(rèn)為綁定是可信的，密鑰的可信值就設(shè)置為完全可信。因而如果缺少最高可信者簽名，至少需要X個總是信任簽名或者Y個通常信任的簽名，或者他們的組合。 PGP會周期性地更新密鑰環(huán)，以保證一致性。本質(zhì)上這是一個自頂向下的過程。信任操作處理對于每一個OWNERTRUST域，PGP掃描密鑰環(huán)，找到擁有者的所有簽名，并將SIGTRUAT域修改為與OWNERTR

34、UST域值相等。從具有最高信任程度的密鑰開始處理。所有KEYLEGIT域值以附帶的簽名為基礎(chǔ)進(jìn)行計算。下面的圖表明了簽名信任域值和密鑰信任域值關(guān)聯(lián)的方法。該圖表示的是一個密鑰環(huán)的結(jié)構(gòu)，用戶Alice已經(jīng)得到了一些公開密鑰，有些直接來自于密鑰的擁有者，有些來自于第三者。標(biāo)“You”的節(jié)點(diǎn)代表Alice，該密鑰具有信任操作處理最高的信任程度。在Alice為他們分配其他值以前，該密鑰環(huán)中的其它節(jié)點(diǎn)的OWNERTRUST值一律為undefined. 在這個密鑰環(huán)的結(jié)構(gòu)途中要注意的幾種情況： (1) Alice與節(jié)點(diǎn)E、F之間的信任關(guān)系； (2) H和A、B節(jié)點(diǎn)之間的信任關(guān)系； (3) N和R節(jié)點(diǎn)之間的

35、信任關(guān)系； (4) 孤兒節(jié)點(diǎn)S的情況。公鑰的撤銷 一個用戶可能希望撤銷其使用的密鑰，原因可能是密鑰遭到破壞，或者僅僅不想使用更長的時間。密鑰遭到破壞可能是攻擊者得到了你的未加密的私鑰的副本，或者攻擊者從你的私鑰密鑰環(huán)得到了你的私鑰以及通行短語。 撤銷公鑰的機(jī)制約定由公鑰的擁有者簽發(fā)一個自己簽名的撤銷證書。內(nèi)容與正常的簽名證書形式想同，但包括撤銷該公鑰的證書的目的。證書的擁有者應(yīng)當(dāng)盡可能快、盡可能廣泛地告訴潛在的通信者，及時更新它們的密鑰環(huán)。 BACK第3節(jié) S/MIME S/MIME是基于RSA數(shù)據(jù)安全公司技術(shù)的電子郵件安全強(qiáng)化機(jī)制。PGP與S/MIME兩者各有優(yōu)勢，不過從目前的趨勢看來，似乎

36、S/MIME將會成為商業(yè)與其他社會機(jī)構(gòu)所使用的工業(yè)標(biāo)準(zhǔn)，而PGP將會成為個人用戶安全的首選。要想理解S/MIME，必須首先熟悉MIME，并與傳統(tǒng)的RFC822規(guī)定的電子郵件格式進(jìn)行比較。 RFC822格式：RFC822定義了電子郵件發(fā)送的文本消息的格式?，F(xiàn)在已經(jīng)作為文本電子郵件RFC822郵件格式的格式標(biāo)準(zhǔn)。RFC822定義E-mail信息包括信封和內(nèi)容。信封包括完成內(nèi)容傳輸與提交所需要的需要的額外信息。內(nèi)容則組成了向接收者所提交的主題。內(nèi)容包含郵件系統(tǒng)創(chuàng)造信封所需要的一套報頭域。符合RFC822的消息結(jié)構(gòu)非常簡單。一條消息包括報頭和不受限制的主體(body) 。報頭和body之間用一個空白行

37、隔開。在第一個空白行之前的所有行都被認(rèn)為是郵件系統(tǒng)所使用的報頭行。一個報頭行通常由一個RFC822郵件格式關(guān)鍵詞，緊跟一個冒號，然后是關(guān)鍵詞的參數(shù)。并允許將一個較長的報頭行分成若干行。經(jīng)常使用的關(guān)鍵詞有From, To, Subject, and Date. 下面就是一個簡單的例子。Date: Tue, 16 Oct 2006 10:38:18From: “Tom” To: smithCc: Jones.Hello. Please meet me at SNNU on Oct.28.RFC822郵件格式 RFC822格式有以下局限性： (1) 使用的郵件協(xié)議僅限于SMTP，而SMTP協(xié)議不能傳

38、輸可執(zhí)行文件與其他二進(jìn)制對象； (2) SMTP不能傳輸包含National language characters. 因?yàn)檫@些character是用8比特編碼表示的，而SMTP僅限于7比特的ASCII碼； (3) SMTP將拒絕超過規(guī)定大小的郵件消息； (4) 在ASCII和EBCDIC編碼之間進(jìn)行轉(zhuǎn)換的SMTP網(wǎng)管并不使用一套一致的映射，導(dǎo)致RFC822郵件格式翻譯問題。 (5) 某些SMTP的布署并不完全符合SMTP標(biāo)準(zhǔn)。主要問題包括：刪除、添加或者重新記錄回車、換行；截斷或者限制超過76字符的行；將消息中的一行填充到相同的長度；將Tab字符轉(zhuǎn)換成多個空格字符。 MIME就是為解決這些問

39、題，并要與RFC822格式兼容而提出的新的郵件格式。MIME郵件格式 MIME是RFC822格式的擴(kuò)展，主要是為了使E-mail能夠收發(fā)各種格式的文件。主要包含下面的幾個元素：定義了5個消息報頭說明消息主體的有關(guān)信息定義了7種內(nèi)容類型實(shí)現(xiàn)多媒體電子郵件表示的標(biāo)準(zhǔn)化定義了6種內(nèi)容轉(zhuǎn)換編碼將內(nèi)容轉(zhuǎn)換成受郵件系統(tǒng)保護(hù)的免于修改的格式。MIME的5種報頭 (1) MIME版本號：只有一個參數(shù)1.0。 (2) Content-Type: 描述信息主體的數(shù)據(jù)，為使接收者選擇適當(dāng)?shù)拇砘驒C(jī)制表示或處理有關(guān)的數(shù)據(jù)提供足夠詳細(xì)的信息。 (3) 內(nèi)容轉(zhuǎn)換編碼：說明信息主體所用的變換方法。 (4) Content-

40、ID: 用于在多個消息中唯一地標(biāo)示一個MIME實(shí)體。 (5) 內(nèi)容描述：一個對于主題和信體的文字描述，如果主題不可讀，這部分信息就很有用。MIME 內(nèi)容類型 MIME定義了7中內(nèi)容類型：Type SubtypeTypeSubtypeTextPlain, EnrichedVideompegMultipartMixed, Digest Parallel, AlternativeAudioBasicMessageRFC822, Partial, External-bodyApplicationPS, Octet流ImageJpeg, gifMIME 內(nèi)容類型 MIME的內(nèi)容類型聲明了數(shù)據(jù)的大類和子類

41、，并規(guī)定了那種內(nèi)容類型的具體格式。 (1) Text type 的首選子類是Plain text, 是指ASCII碼串或者ISO8859碼串，enriched 子類提供了更高的格式靈活性。 (2) 多部類型：說明信體包含多個相互獨(dú)立的部分，內(nèi)容類型報頭包括一個邊界參數(shù)，定義信體之間的邊界，邊界不應(yīng)出現(xiàn)信息的任何部分，最后邊界表明最后一個部分的結(jié)束。下面是一個multi-part消息的例子。From: Alice To: BobSubject: sample messageMIME-Version: 1.0Content-type: multi-part/mixed; boundary=“sim

42、ple message”This is the preamble - -simple boundaryThis is implicitly. - -simple boundary Content-type: Text/plain; charset=us-asciiThis is explicitly. - -simple boundary-MIME 內(nèi)容類型多部類型有4個子類：mixed表示不同的部分相互獨(dú)立，但一起發(fā)送，應(yīng)當(dāng)按郵件消息的順序提交給接收者；Parallel子類沒有限定不同部分的順序；Alternative子類是同一個信息的不同版本，接收者的郵件系統(tǒng)應(yīng)該顯示對于接收者來說是最好的

43、版本。 (3) Message type 為MIME提供了一些重要的性能。Rfc822子類表明信體是一個完整的包含信頭和信體的消息。Partial 子類使得消息能夠MIME 內(nèi)容類型拆開成許多部分，到目的地后必須重新組裝。這個子類需要三個參數(shù)：消息的各個片段需要分配同樣的ID號，每個片斷需要有一個序列號，全部片段數(shù)。External-body子類表明信的真正數(shù)據(jù)并不在信體中，信體只是關(guān)于如何訪問有關(guān)數(shù)據(jù)的說明。 (4) 應(yīng)用類型:只其他類型的數(shù)據(jù)，可能是無解釋的二進(jìn)制數(shù)據(jù)或者需要基于郵件的應(yīng)用處理的信息。MIME 轉(zhuǎn)換編碼 除了內(nèi)容類型的定義外，MIME另一個重要的定義是消息體(body)的編

44、碼方法。這主要是為了能夠通過大范圍網(wǎng)絡(luò)將郵件提交給用戶。MIME定義了2種編碼方法。內(nèi)容編碼域?qū)嶋H上可以有6個選項(xiàng)(7bit, 8bit, binary, quoted-printable, base64, x-token)，但7bit, 8bit, binary 實(shí)際上表明沒有用任何編碼方法。X-token 表明采用了MIME規(guī)定的范圍以外的編碼方法，這就需要提供具體的編碼方法。MIME 轉(zhuǎn)換編碼MIME規(guī)定的兩種有效編碼方法是quoted- printable 與base64。 當(dāng)數(shù)據(jù)主要是與可打印的ASCII碼相應(yīng)的8個一組的數(shù)據(jù)時，使用quoted-printable編碼。本質(zhì)上是直接

45、引用八進(jìn)制碼直接表示字符的編碼。Base64編碼方法就是前面所講的Radix64編碼。 S/MIME的作用 從作用來看，S/MIME與PGP非常相似，都提供簽名與加密的能力。S/MIME提供下面的四種功能： (1) Enveloped data: 包括加密任何類型的數(shù)據(jù)、為多個接收者加密會話密鑰。 (2) Signed data: 加密內(nèi)容的摘要形成數(shù)字簽名，并用接收者的公鑰加密簽名。簽名與內(nèi)容一起用Base64編碼。S/MIME的作用 (3) Clear-signed data: 是對內(nèi)容的數(shù)字簽名。只有數(shù)字簽名部分才用Base64編碼。這樣即使不支持S/MIME的接收者也可以閱讀內(nèi)容，但不

46、能驗(yàn)證簽名。 (4) Signed and enveloped data: 僅僅經(jīng)過簽名的實(shí)體與僅僅經(jīng)過加密的實(shí)體才能夠嵌套，這樣加密的數(shù)據(jù)可以再簽名，簽名的數(shù)據(jù)也可以再加密。 密碼學(xué)算法：下面的標(biāo)概括了S/MIME所使用的算法與術(shù)語。加密算法功能要求產(chǎn)生消息摘要用于數(shù)字簽名必須支持SHA-1，接收者應(yīng)當(dāng)支持MD5。加密消息摘要形成數(shù)字簽名雙方必須支持DSS，發(fā)送代理應(yīng)支持RSA，接收代理應(yīng)支持RSA簽名驗(yàn)證傳輸消息用的加密會話密鑰雙方代理必須支持Diffie-Hellman。發(fā)送代理應(yīng)支持RSA加密，接收代理應(yīng)支持RSA解密用一次性會話密鑰加密消息發(fā)送代理應(yīng)支持3DES與RC2/40，接收大

47、力必須支持3DES解密，應(yīng)當(dāng)支持RC2/40解密加密算法 S/MIME集成了三種公鑰算法：DSS、RSA和Diffie-Hellman。對于散列算法，S/MIME規(guī)定了兩種算法：SHA-1和MD5算法。對于加密算法，S/MIME規(guī)定了兩種算法：3DES和比特密鑰RC2 40算法。 在決定選用什么加密算法進(jìn)行加密時，發(fā)送代理必須考慮接收方的解密能力?；具x擇原則如下： (1) 如果發(fā)送代理有一個按接收方的喜好排序加密算法的解密列表，應(yīng)當(dāng)選擇列表中的第一個算法。 (2) 如果發(fā)送代理沒有這樣的列表，那么最近一次接收方發(fā)來的信息用什么算法加密，就選擇什么算法加密。 (3) 如果上述的消息都沒有，并樂

48、意冒接收方無法解密的風(fēng)險，那么就選用3DES算法。 (4) 如果上述的消息都沒有，而且不愿意冒接收方無法解密的風(fēng)險，那么就選用RC2算法。S/MIME 消息 S/MIME的消息類有兩個大類，6個子類。所有的新的應(yīng)用類型用設(shè)計的PKCS( public key cryptography specification). 保證一個MIME實(shí)體的安全措施：簽名、加密或者二者并用。一個MIME實(shí)體可以是全部的MIME消息，如果消息是由多個部分組成的，那么每個部分都可以是一個MIME實(shí)體。一個MIME實(shí)體與有關(guān)的數(shù)據(jù)、比如算法ID與證書等，通過S/MIME的處理生成一個PKCS對保證MIME實(shí)體的安全象。

49、一個PKCS對象作為消息內(nèi)容被處理并包裝成MIME。需要特別注意轉(zhuǎn)換編碼的應(yīng)用。多數(shù)情況下應(yīng)用安全算法生成一個可部分或全部用任意二進(jìn)制數(shù)表示的數(shù)據(jù)。這個數(shù)據(jù)再轉(zhuǎn)換成Base64編碼發(fā)送出去。一個應(yīng)用/pkcs7-mime子類用于四類S/MIME的處理過程，每個過程有一個唯一的smime類型參數(shù)。處理的結(jié)果稱為一個對象，并以Basic Encoding Rules 的方式表示，BER是國際電信聯(lián)盟在X.209中規(guī)定的編碼規(guī)則。BER格式是由8個一組的任意串組成的，這樣的對象應(yīng)當(dāng)在發(fā)送出去之前轉(zhuǎn)換成base64編碼格式的消息。Enveloped Data 準(zhǔn)備一個envelopedData MIM

50、E實(shí)體的過程如下：Enveloped Data其中RecipientInfo的信息包包括接收者的公鑰證書號、用于加密會話密鑰的算法ID以及加密的會話密鑰。RecipientInfo與緊跟著的加密的消息構(gòu)成了EnvelopedData。然后，這個信息也用base64編碼。要恢復(fù)加密的消息，接收者首先剝掉base64編碼，然后用自己的私鑰解密會話密鑰，最后用會話密鑰解密消息內(nèi)容。Signed Data 準(zhǔn)備一個Signed Data MIME實(shí)體的過程如下： (1) 選擇消息摘要算法； (2) 計算消息摘要； (3) 用簽名者的私人密鑰加密消息摘要； (4) 生成一個稱為SignerInfo的信息

51、包，包括簽名者的公鑰證書號、消息摘要算法ID、加密算法ID與經(jīng)過加密的消息摘要。Signed Data 消息摘要算法ID、被簽署的消息與SignerInfo 等構(gòu)成了一個signedData 實(shí)體。也可能還包含足以構(gòu)造從根CA或最高級別的CA到簽名者的證書鏈的一套證書。這條信息被編碼成base64碼。 要恢復(fù)簽名的消息并驗(yàn)證簽名，接收者首先剝掉base64編碼，然后用簽名者的公鑰解密消息摘要。接收者獨(dú)立計算消息摘要，并與解密的消息摘要進(jìn)行比較來驗(yàn)證簽名。Clear Signing Clear signing (透明簽名)是通過具有簽名子類的多部分內(nèi)容類型獲得的。因?yàn)樵摵灻⒉粚σ獋鬏數(shù)男畔⑦M(jìn)行

52、簽名，發(fā)送的消息是透明的，故稱為透明簽名。 一個multipart/signed 簽署消息有兩部分組成。第1部分可以是任何MIME類型，但必須進(jìn)行適當(dāng)?shù)奶幚硪员ＷC在源端發(fā)往目的端的過程中不被篡改。這就意味著如果第1部分不是7比特形式，就需要用base64或者quoted-printableClear Signing進(jìn)行編碼。然后用SignedData方式相同的方法處理這一部分。但是這種情況下創(chuàng)建的具有SignedData格式的對象的消息內(nèi)容域是空的。這個對象可以與簽名相分離。然后用base64編碼這個對象，變成multipart/signed的第2部分。這第2部分具有MIME應(yīng)用內(nèi)容類型以及pkcs7-Signature子類。接收者可以提取第1部分的消息摘要，與從第2部分的簽名中恢復(fù)的消息摘要進(jìn)行比較來驗(yàn)證簽名。Registration Request 通常，一個用戶或者一個應(yīng)用會向一個CA申請一份公鑰證書。要傳遞一個證書請求需要用application/pkcs10 S/MIME實(shí)體。證書請求包含證書請求信息包RequestInfo，緊跟一個公鑰加密算法ID與用發(fā)送者私鑰簽名的RequestInfo.RequestInf