信息安全工程第14章常見的安全系統(tǒng)_第1頁
信息安全工程第14章常見的安全系統(tǒng)_第2頁
信息安全工程第14章常見的安全系統(tǒng)_第3頁
信息安全工程第14章常見的安全系統(tǒng)_第4頁
信息安全工程第14章常見的安全系統(tǒng)_第5頁
已閱讀5頁,還剩230頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

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

文檔簡介

第14章常見的平安系統(tǒng)14.1IPSec協(xié)議14.2SSL協(xié)議14.3Kerberos認(rèn)證系統(tǒng)14.4PGP協(xié)議14.5PEM協(xié)議14.6S/MIME協(xié)議14.7S-HTTP協(xié)議14.8WMAN(IEEE802.16)平安技術(shù)14.9WSN平安機(jī)制 14.1IPSec協(xié)議

IPSec協(xié)議平安體系結(jié)構(gòu)

1.平安協(xié)議

IPSec提供了兩種平安協(xié)議:認(rèn)證頭(AH,AuthenticationHeader)和封裝平安有效載荷(ESP,EncapsulatingSecurityPayload),用于對IP數(shù)據(jù)報(bào)或上層協(xié)議數(shù)據(jù)報(bào)進(jìn)行平安保護(hù)。其中,AH只提供了數(shù)據(jù)完整性認(rèn)證機(jī)制,可以證明數(shù)據(jù)源端點(diǎn),保證數(shù)據(jù)完整性,防止數(shù)據(jù)被篡改和重播;ESP同時(shí)提供了數(shù)據(jù)完整性認(rèn)證和數(shù)據(jù)加密傳輸機(jī)制,它除了具有AH所有的平安能力之外,還可以提供數(shù)據(jù)傳輸機(jī)密性。AH和ESP可以單獨(dú)使用,也可以聯(lián)合使用。每個協(xié)議都支持以下兩種應(yīng)用模式。

(1)傳輸模式:為上層協(xié)議數(shù)據(jù)提供平安保護(hù)。

(2)隧道模式:以隧道方式傳輸IP數(shù)據(jù)報(bào)文。AH或ESP提供的平安性完全依賴于它們所采用的密碼算法。為保證一致性和不同實(shí)現(xiàn)方案之間的互通性,必須定義一些需要強(qiáng)制實(shí)現(xiàn)的密碼算法。因此,在使用認(rèn)證和加密機(jī)制進(jìn)行平安通信時(shí),必須解決以下三個問題:

(1)通信雙方必須協(xié)商所要使用的平安協(xié)議、密碼算法和密鑰。

(2)必須方便和平安地交換密鑰(包括定期改變密鑰)。

(3)能夠?qū)λ袇f(xié)商的細(xì)節(jié)和過程進(jìn)行記錄和管理。2.平安關(guān)聯(lián)

IPSec使用一種稱為平安關(guān)聯(lián)(SA,SecurityAssociations)的概念性實(shí)體集中存放所有需要記錄的協(xié)商細(xì)節(jié)。因此,在SA中包含了平安通信所需的所有信息,可以將SA看做是一個由通信雙方共同簽署的有關(guān)平安通信的“合同〞。

SA使用一個平安參數(shù)索引(SPI,SecurityParameterIndex)來唯一地標(biāo)識。SPI是一個32位隨機(jī)數(shù),通信雙方要使用SPI來指定一個協(xié)商好的SA。

使用SA的好處是可以建立不同等級的平安通道。例如,一個用戶可以分別與A網(wǎng)和B網(wǎng)建立平安通道,分別設(shè)置兩個SA:SA(a)和SA(b)。在SA(a)中,可以協(xié)商使用更加健壯的密碼算法和更長的密鑰。3.密鑰管理

IPSec支持兩種密鑰管理協(xié)議:手工密鑰管理和自動密鑰管理(IKE,InternetKeyExchange)。其中,IKE是基于Internet的密鑰交換協(xié)議,它具有如下功能:

(1)協(xié)商效勞:通信雙方協(xié)商所使用的協(xié)議、密碼算法和密鑰。

(2)身份認(rèn)證效勞:對參與協(xié)商的雙方身份進(jìn)行認(rèn)證,確保雙方身份的合法性。

(3)密鑰管理:對協(xié)商的結(jié)果進(jìn)行管理。

(4)平安交換:產(chǎn)生和交換所有密鑰的密碼源物質(zhì)。

IKE是一個混合型協(xié)議,集成了ISAKMP(InternetSecurityAssociationsandKeyManagementProtocol)協(xié)議和局部Oakley密鑰交換方案。具體協(xié)議

1.封裝平安有效載荷(ESP)協(xié)議

ESP是插入在IP數(shù)據(jù)報(bào)內(nèi)的一個協(xié)議頭,為IP數(shù)據(jù)報(bào)提供數(shù)據(jù)機(jī)密性、數(shù)據(jù)完整性、抗重播以及數(shù)據(jù)源驗(yàn)證等平安效勞。ESP使用一個加密器提供數(shù)據(jù)機(jī)密性,使用一個驗(yàn)證器提供數(shù)據(jù)完整性認(rèn)證。加密器和驗(yàn)證器所采用的專用算法是由ESP平安聯(lián)盟的相應(yīng)組件決定的。

因此,ESP是一種通用的、易于擴(kuò)展的平安機(jī)制,它將根本的ESP功能定義和實(shí)際提供平安效勞的專用密碼算法別離開,有利于密碼算法的更換和更新。圖ESP頭格式在任何模式下,ESP頭總是跟隨在一個IP頭之后,ESP頭格式如下圖。在IPv4中,IP頭的協(xié)議字段值為50,表示在IP頭之后是一個ESP頭。跟隨在ESP頭后的內(nèi)容取決于ESP的應(yīng)用模式。如果是傳輸模式,那么是一個上層協(xié)議頭(TCP/UDP);如果是隧道模式,那么是另一個IP頭。

(1)平安參數(shù)索引(SPI):它是一個32位的隨機(jī)數(shù)。SPI、目的IP地址和協(xié)議值組成一個三元組,用來唯一地確定一個特定的SA,以便對該數(shù)據(jù)報(bào)進(jìn)行平安處理。通常,在密鑰交換(IKE)過程中由目標(biāo)主機(jī)來選定SPI。SPI是經(jīng)過驗(yàn)證的,但并沒有被加密,因?yàn)镾PI是一種狀態(tài)標(biāo)識,由它來指定所采用的加密算法及密鑰,以及對數(shù)據(jù)報(bào)進(jìn)行解密。如果SPI本身被加密,那么會產(chǎn)生嚴(yán)重的“先有雞,還是先有蛋〞的問題,這一點(diǎn)很重要。(2)序列號:它是一個單向遞增的32位無符號整數(shù)。通過序列號,可使ESP具有抗重播攻擊的能力。盡管抗重播效勞是可選的,但是發(fā)送端必須產(chǎn)生和發(fā)送序列號字段,只是接收端不一定要處理。建立SA時(shí),發(fā)送端和接收端的計(jì)數(shù)器必須初始化為0(發(fā)送端通過特定SA發(fā)送的第一個數(shù)據(jù)報(bào)的序列號為1)。如果選擇了抗重播效勞(默認(rèn)情況下),那么序列號是不能出現(xiàn)重復(fù)(循環(huán))的。因此,發(fā)送端和接收端的計(jì)數(shù)器在傳送第232個數(shù)據(jù)報(bào)時(shí)必須重新設(shè)置,這可以通過建立一個新的SA和新的密鑰來實(shí)現(xiàn)。序列號是經(jīng)過驗(yàn)證的,但沒有被加密,因?yàn)榻邮斩耸歉鶕?jù)序列號來判斷一個數(shù)據(jù)報(bào)是否重復(fù)的,如果先解密序列號,然后作出是否丟棄該數(shù)據(jù)報(bào)的決定,那么會造成處理資源的浪費(fèi)。(3)初始化向量IV:提供密碼算法所在應(yīng)用模式下的初始向量值。

(4)載荷數(shù)據(jù):被ESP保護(hù)的數(shù)據(jù)報(bào)包含在載荷數(shù)據(jù)字段中,其字段長度由數(shù)據(jù)長度來決定。如果密碼算法需要密碼同步數(shù)據(jù)(如初始化向量IV),那么該數(shù)據(jù)應(yīng)顯式地包含在載荷數(shù)據(jù)中。任何需要這種顯式密碼同步數(shù)據(jù)的密碼算法都必須指定該數(shù)據(jù)的長度、結(jié)構(gòu)及其在載荷中的位置。對于強(qiáng)制實(shí)施的密碼算法(DES-CBC)來說,IV是該字段中的第一個8位組。如果需要隱式的密碼同步數(shù)據(jù),那么生成該數(shù)據(jù)的算法由RFC指定。(5)填充項(xiàng):0~255個字節(jié),填充內(nèi)容可以由密碼算法來指定。如果密碼算法沒有指定,那么由ESP指定,填充項(xiàng)的第1個字節(jié)值是1,后面的所有字節(jié)值都是單向遞增的。填充的作用如下:

①某些密碼算法要求明文的長度是密碼分組長度的整數(shù)倍,因此需要通過填充項(xiàng)使明文(包括載荷數(shù)據(jù)、填充項(xiàng)、填充項(xiàng)長度和下一個頭)長度到達(dá)密碼算法的要求。

②通過填充項(xiàng)把ESP頭的“填充項(xiàng)長度〞和“下一個頭〞兩個字段靠后排列。

③用來隱藏載荷的實(shí)際長度,從而支持局部數(shù)據(jù)流的機(jī)密性。(6)填充項(xiàng)長度:該字段為8位,指明填充項(xiàng)的長度,接收端利用它恢復(fù)載荷數(shù)據(jù)的實(shí)際長度。該字段必須存在,當(dāng)沒有填充項(xiàng)時(shí),其值為0。

(7)下一個頭:該字段為8位,指明載荷數(shù)據(jù)的類型。如果在隧道模式下使用ESP,那么其值為4,表示為IP-in-IP;如果在傳輸模式下使用,那么其值為上層協(xié)議的類型,如TCP對應(yīng)的值為6。

(8)認(rèn)證數(shù)據(jù):該字段是可變長的,它是由認(rèn)證算法對ESP數(shù)據(jù)報(bào)進(jìn)行散列計(jì)算所得到的完整性校驗(yàn)值(ICV)。該字段是可選的,只有對ESP數(shù)據(jù)報(bào)進(jìn)行處理的SA提供了完整性認(rèn)證效勞,才會有該字段。SA使用的認(rèn)證算法必須指明ICV的長度、比較規(guī)那么以及認(rèn)證的步驟。2.認(rèn)證頭(AH)協(xié)議

AH協(xié)議為IP數(shù)據(jù)報(bào)提供了數(shù)據(jù)完整性、數(shù)據(jù)源驗(yàn)證以及抗重播等平安效勞,但不提供數(shù)據(jù)機(jī)密性效勞。也就是說,除了數(shù)據(jù)機(jī)密性之外,AH提供了ESP所能提供的一切效勞。

AH可以采用隧道模式來保護(hù)整個IP數(shù)據(jù)報(bào),也可以采用傳輸模式只保護(hù)一個上層協(xié)議報(bào)文。在任何一種模式下,AH頭都會緊跟在一個IP頭之后。AH不僅可以為上層協(xié)議提供認(rèn)證,還可以為IP頭的某些字段提供認(rèn)證。由于IP頭中的某些字段在傳輸中可能會被改變(如效勞類型、標(biāo)志、分段偏移、生存期以及頭校驗(yàn)和等字段),發(fā)送方無法預(yù)測最終到達(dá)接收方時(shí)這些字段的值,因此,這些字段不能受到AH的保護(hù)。圖顯示了IP頭的可變字段(陰影局部)和固定字段。圖IP頭的可變字段(陰影局部)和固定字段3.AH頭格式

在任何模式下,AH頭總是跟隨在一個IP頭之后,AH頭格式如下圖。在IPv4中,IP頭的協(xié)議字段值為51,表示在IP頭之后是一個AH頭。跟隨在AH頭后的內(nèi)容取決于AH的應(yīng)用模式,如果是傳輸模式,那么是一個上層協(xié)議頭(TCP/UDP);如果是隧道模式,那么是另一個IP頭。

(1)下一個頭:8位,與ESP頭中對應(yīng)字段的含義相同。圖AH頭格式(2)載荷長度:8位,以32位為長度單位指定了AH的長度,其值是AH頭的實(shí)際長度減2。這是因?yàn)锳H是一個IPv6擴(kuò)展頭,IPv6擴(kuò)展頭長度的計(jì)算方法是實(shí)際長度減1,IPv6是以64位為長度單位計(jì)算的,AH是以32位為長度單位進(jìn)行計(jì)算的,所以將減1變換為減2(1個64位長度單位=2個32位長度單位)。如果采用標(biāo)準(zhǔn)的認(rèn)證算法,認(rèn)證數(shù)據(jù)字段長度為96位,加上3個32位固定長度的局部,那么載荷長度字段值為4(96/32+3-2=4)。如果使用“空〞認(rèn)證算法,將不會出現(xiàn)認(rèn)證數(shù)據(jù)字段,那么載荷長度字段值為1。

(3)保存:16位,保存給將來使用,其值必須為0。該字段值包含在認(rèn)證數(shù)據(jù)的計(jì)算中,但被接收者忽略。(4)平安參數(shù)索引(SPI):32位,與ESP頭中對應(yīng)字段的含義相同。

(5)序列號:32位,與ESP頭中對應(yīng)字段的含義相同。

(6)認(rèn)證數(shù)據(jù):可變長字段,它是認(rèn)證算法對AH數(shù)據(jù)報(bào)進(jìn)行完整性計(jì)算所得到的完整性校驗(yàn)值(ICV)。該字段的長度必須是32位的整數(shù)倍,因此可能會包含填充項(xiàng)。SA使用的認(rèn)證算法必須指明ICV的長度、比較規(guī)那么以及認(rèn)證的步驟。IPSec實(shí)現(xiàn)模式

1.傳輸模式

傳輸模式又稱主機(jī)實(shí)現(xiàn)模式,通常當(dāng)ESP在一臺主機(jī)(客戶機(jī)或效勞器)上實(shí)現(xiàn)時(shí)使用。傳輸模式使用原始明文IP頭,并且只加密數(shù)據(jù),包括它的TCP和UDP頭。

由于主機(jī)是一種端節(jié)點(diǎn),因此傳輸模式主要用于保護(hù)一個內(nèi)部網(wǎng)中兩個主機(jī)之間的數(shù)據(jù)通信。主機(jī)實(shí)現(xiàn)方案可分為以下兩種類型。(1)在操作系統(tǒng)上集成實(shí)現(xiàn):由于IPSec是一個網(wǎng)絡(luò)層協(xié)議,因此可以將IPSec協(xié)議集成到主機(jī)操作系統(tǒng)上的TCP/IP中,作為網(wǎng)絡(luò)層的一局部來實(shí)現(xiàn)。

(2)嵌入?yún)f(xié)議棧實(shí)現(xiàn):將IPSec嵌入?yún)f(xié)議棧中,插入在網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層之間來實(shí)現(xiàn)。

傳輸模式的優(yōu)點(diǎn)是:能夠?qū)崿F(xiàn)端到端的平安性,能夠?qū)崿F(xiàn)所有的IPSec平安模式,能夠提供基于數(shù)據(jù)流的平安保護(hù)。2.隧道模式

隧道模式又稱為基于網(wǎng)關(guān)的實(shí)現(xiàn)模式,通常應(yīng)用于ESP關(guān)聯(lián)到多臺主機(jī)的網(wǎng)絡(luò)訪問介入裝置實(shí)現(xiàn)的場合。隧道模式處理整個IP數(shù)據(jù)包,包括全部TCP/IP或UDP/IP頭和數(shù)據(jù),它用自己的地址作為源地址參加到新的IP頭中。當(dāng)隧道模式用在用戶終端設(shè)置時(shí),它可以提供更多的便利來隱藏內(nèi)部效勞器主機(jī)和客戶機(jī)的地址。

ESP支持傳輸模式。這種模式可保護(hù)高層協(xié)議,也可保護(hù)IP包的內(nèi)容,特別是用于兩個主機(jī)之間的端對端通信(例如,客戶與效勞器或是兩臺工作站)。傳輸模式中的ESP加密有時(shí)候會認(rèn)證IP包的內(nèi)容,但不認(rèn)證IP包頭。這種配置對于裝有IPSec的小型網(wǎng)絡(luò)特別有用。但是,要全面實(shí)施VPN,使用隧道模式會更有效。ESP也支持隧道模式,這種模式可保護(hù)整個IP包。為此,IP包在添加了ESP字段后,整個包以及包的平安字段被認(rèn)為是新的IP包的外層內(nèi)容,附有新的IP外層包頭。原來的(及內(nèi)層)包通過“隧道〞從一個IP網(wǎng)絡(luò)起點(diǎn)傳輸?shù)搅硪粋€IP網(wǎng)點(diǎn),中途的路由器可以檢查IP的內(nèi)層包頭。因?yàn)樵瓉淼陌驯淮虬?新的包可能有不同的源地址及目的地址,所以可以到達(dá)平安傳輸?shù)哪康摹MǔK淼滥J接迷趦啥嘶蛞欢耸瞧桨簿W(wǎng)關(guān)的架構(gòu)中,例如裝有IPSec的路由器或防火墻。使用了隧道模式,防火墻內(nèi)很多主機(jī)不需要安裝IPSec也能平安地通信。這些主機(jī)所生成的未加保護(hù)的網(wǎng)包,經(jīng)過外網(wǎng)時(shí),使用隧道模式的平安組織規(guī)定(即SA,發(fā)送者與接收者之間的平安關(guān)聯(lián)關(guān)系,主要用于定義裝在本地網(wǎng)絡(luò)邊緣的平安路由器或防火墻中的IPSec軟件進(jìn)行IP交換所規(guī)定的參數(shù))的方式傳輸。以下是隧道模式的IPSec運(yùn)作的例子。某網(wǎng)絡(luò)的主機(jī)甲生成一個IP包,目的地址是另一個網(wǎng)中的主機(jī)乙。這個包從起始主機(jī)被發(fā)送到主機(jī)甲的網(wǎng)絡(luò)邊緣的平安路由器或防火墻。防火墻對所有出去的包進(jìn)行過濾,看有哪些包需要進(jìn)行IPSec的處理。如果這個從甲到乙的包需要使用IPSec,那么防火墻就進(jìn)行IPSec的處理,并把網(wǎng)包打包,添加外層IP包頭。這個外層包頭的源地址是防火墻,而目的地址可能是主機(jī)乙的網(wǎng)絡(luò)邊緣的防火墻?,F(xiàn)在這個包被傳送到主機(jī)乙的防火墻,中途的路由器只檢查外層IP包頭。之后,主機(jī)乙的防火墻會把外層IP包頭除掉,把IP內(nèi)層發(fā)送至主機(jī)。隧道模式主要用于保護(hù)兩個內(nèi)部網(wǎng)通過公用網(wǎng)絡(luò)進(jìn)行的數(shù)據(jù)通信,通過IPSec網(wǎng)關(guān)構(gòu)建VPN,從而實(shí)現(xiàn)兩個內(nèi)部網(wǎng)之間的平安數(shù)據(jù)交換。隧道模式有以下兩種類型:

(1)在操作系統(tǒng)上集成實(shí)現(xiàn):將IPSec協(xié)議集成到網(wǎng)關(guān)操作系統(tǒng)上的TCP/IP中,作為網(wǎng)絡(luò)層的一局部來實(shí)現(xiàn)。

(2)嵌入網(wǎng)關(guān)物理接口上實(shí)現(xiàn):將實(shí)現(xiàn)IPSec的硬件設(shè)備直接接入網(wǎng)關(guān)的物理接口上來實(shí)現(xiàn)。

隧道模式的優(yōu)點(diǎn)是:能夠在公用網(wǎng)(如Internet)上構(gòu)建VPN來保護(hù)內(nèi)部網(wǎng)之間進(jìn)行的數(shù)據(jù)交換,能夠?qū)M(jìn)入內(nèi)部網(wǎng)的用戶身份進(jìn)行驗(yàn)證。 14.2SSL協(xié)議

協(xié)議組成

SSL協(xié)議的根本目標(biāo)是在兩個通信實(shí)體之間建立平安的通信連接,為基于客戶機(jī)/效勞器模式的網(wǎng)絡(luò)應(yīng)用提供平安保護(hù)。SSL協(xié)議提供了以下3種平安特性。

(1)數(shù)據(jù)機(jī)密性:采用對稱加密算法(如DES、RC4等)來加密數(shù)據(jù),密鑰是在雙方握手時(shí)指定的。

(2)數(shù)據(jù)完整性:采用消息鑒別碼(MAC)來驗(yàn)證數(shù)據(jù)的完整性,MAC是采用Hash函數(shù)實(shí)現(xiàn)的。

(3)身份合法性:采用非對稱密碼算法和數(shù)字證書來驗(yàn)證同層實(shí)體之間的身份合法性。圖SSL協(xié)議的根本結(jié)構(gòu)握手協(xié)議

在SSL協(xié)議中,客戶和效勞器之間的通信分成兩個階段:第一階段是握手協(xié)商階段,雙方利用握手協(xié)議協(xié)商和交換有關(guān)協(xié)議版本、壓縮方法、加密算法和密鑰等信息,同時(shí)還可以相互驗(yàn)證對方的身份;第二階段是數(shù)據(jù)交換階段,雙方利用記錄協(xié)議對數(shù)據(jù)實(shí)施加密和認(rèn)證,確保數(shù)據(jù)交換的平安。因此,在數(shù)據(jù)交換之前,客戶和效勞器之間首先要使用握手協(xié)議進(jìn)行有關(guān)參數(shù)的協(xié)商和確認(rèn)。SSL握手協(xié)議也包含兩個階段:第一階段用于交換密鑰等信息,第二階段用于用戶身份認(rèn)證。在第一階段,通信雙方通過相互發(fā)送HELLO消息進(jìn)行初始化。通過HELLO消息,雙方就能夠確定是否需要為本次會話產(chǎn)生一個新密鑰。如果本次會話是一個新會話,那么需要產(chǎn)生新的密鑰,雙方需要進(jìn)入密鑰交換過程;如果本次會話建立在一個已有的連接上,那么不需要產(chǎn)生新的密鑰,雙方立即進(jìn)入握手協(xié)議的第二階段。第二階段的主要任務(wù)是對用戶身份進(jìn)行認(rèn)證,通常效勞器方要求客戶方提供經(jīng)過簽名的客戶證書進(jìn)行認(rèn)證,并將認(rèn)證結(jié)果返回給客戶。至此,握手協(xié)議結(jié)束。在握手協(xié)議中,定義了一組控制消息,客戶和效勞器之間使用這些消息進(jìn)行握手協(xié)商。當(dāng)客戶和效勞器首次建立會話時(shí),必須經(jīng)歷一個完整的握手協(xié)商過程(參見圖14.2.2)。圖中,*表示可選的消息,不是一定要發(fā)送的。圖新建一個會話時(shí)的握手協(xié)商過程(1)客戶方向效勞器方發(fā)送一個ClientHello消息,請求握手協(xié)商。

(2)效勞器方向客戶方回送ServerHello消息,進(jìn)行響應(yīng)和確認(rèn)。

這樣客戶和效勞器之間通過Hello消息建立了一個會話的有關(guān)屬性參數(shù)(協(xié)議版本、會話ID、密碼組及壓縮方法),并相互交換了兩個隨機(jī)數(shù)(ClientHello.random和ServerHello.random)。(3)效勞器方可以根據(jù)需要選擇性地向客戶方發(fā)送有關(guān)消息:①Certificate消息,發(fā)放效勞器證書;②CertificateRequest消息,請求客戶方證書等;③ServerKeyExchange消息,與客戶方交換密鑰。在完成處理后,效勞器方向客戶方發(fā)送ServerHelloDone消息,表示效勞器完成協(xié)商,等待客戶方的回應(yīng)。(4)客戶方根據(jù)接收到的效勞器方消息進(jìn)行響應(yīng):①如果客戶證書是一個數(shù)字簽名的證書,那么必須發(fā)送CertificateVerify消息,提供用于檢驗(yàn)數(shù)字簽名證書的有關(guān)信息;②如果接收到CertificateRequest消息,那么客戶方必須發(fā)送Certificate消息,發(fā)送客戶證書;③如果接收到ServerKeyExchange消息,那么客戶方必須發(fā)送ClientKeyExchange消息,與效勞器方交換密鑰。密鑰是由ClientHello消息和ServerHello消息協(xié)商的公鑰密碼算法決定的。

(5)如果客戶方要改變密碼標(biāo)準(zhǔn),那么發(fā)送ChangeCipherSpec消息給效勞器方,說明新的密碼算法和密鑰,然后使用新的密碼標(biāo)準(zhǔn)發(fā)送Finished消息;如果客戶方不改變密碼標(biāo)準(zhǔn),那么直接發(fā)送Finished消息。(6)如果效勞器方接收到客戶方的ChangeCipherSpec消息,那么也要發(fā)送ChangeCipherSpec消息進(jìn)行響應(yīng),然后使用新的密碼標(biāo)準(zhǔn)發(fā)送Finished消息;如果效勞器方接收到客戶方的Finished消息,那么直接發(fā)送Finished消息進(jìn)行響應(yīng)。

(7)至此,握手協(xié)商階段結(jié)束,客戶方和效勞器方進(jìn)入數(shù)據(jù)交換階段。

上述過程中,ChangeCipherSpec消息是一個獨(dú)立的SSL協(xié)議類型,并不是SSL握手協(xié)議信息。

如果雙方是在已有連接上重建一個會話,那么不需要協(xié)商密鑰以及有關(guān)會話參數(shù),從而可以簡化握手協(xié)商過程(參見圖14.2.3)。圖重建一個會話時(shí)的握手協(xié)商過程(1)客戶方使用一個已有的會話ID發(fā)出ClientHello消息。

(2)效勞器方在會話隊(duì)列中查找與之相匹配的會話ID,如果有相匹配的會話,那么效勞器方在該會話狀態(tài)下重新建立連接,并使用相同的會話ID向客戶方發(fā)送一個ServerHello消息;如果沒有相匹配的會話,那么效勞器方產(chǎn)生一個新的會話ID,并且客戶方和效勞器方必須進(jìn)行一次完整的握手協(xié)商過程。

(3)在會話ID匹配的情況下,客戶方和效勞器方必須分別發(fā)送ChangeCipherSpec消息,然后發(fā)送Finished消息。

(4)至此,重建一個會話階段結(jié)束,客戶方和效勞器方進(jìn)入數(shù)據(jù)交換階段。記錄協(xié)議

1.記錄格式

在SSL協(xié)議中,所有的傳輸數(shù)據(jù)都被封裝在記錄中,記錄由記錄頭和長度不為0的記錄數(shù)據(jù)組成。所有的SSL通信,包括握手消息、平安記錄和應(yīng)用數(shù)據(jù),都要通過SSL記錄層傳送。在SSL記錄層,上層數(shù)據(jù)被分段封裝在一個SSL明文記錄中,數(shù)據(jù)段最大長度為214字節(jié)。SSL記錄層不區(qū)分客戶信息的界限。例如,多個同種類型的客戶信息可能被連接成一個單一的SSL明文記錄。SSL記錄格式如下圖。圖SSL記錄格式圖中:

(1)信息類型:指示封裝在數(shù)據(jù)段中的信息類型,由上層協(xié)議解釋和處理。

(2)版本號:使用的SSL協(xié)議版本號。

(3)長度:以字節(jié)表示的數(shù)據(jù)段長度,最大為214字節(jié)。

(4)數(shù)據(jù)段:上層協(xié)議獨(dú)立處理的數(shù)據(jù)單位。2.記錄壓縮

每個SSL記錄都要按協(xié)商好的壓縮算法進(jìn)行壓縮處理,其壓縮算法是在當(dāng)前會話狀態(tài)中定義的。壓縮必須是無損壓縮。經(jīng)過壓縮處理后,在SSL記錄中會增加一些壓縮狀態(tài)信息,但增加局部的長度不能超過1024字節(jié)。

在解壓處理時(shí),如果解壓縮(去掉有關(guān)壓縮狀態(tài)信息)后的數(shù)據(jù)長度超過了214個字節(jié),那么會產(chǎn)生一個解壓縮失敗的警告。此外,解壓函數(shù)肯定不會發(fā)生內(nèi)部緩沖區(qū)溢出。3.記錄加密

經(jīng)過壓縮的SSL記錄還要按協(xié)商好的加密算法和MAC算法進(jìn)行加密和完整性認(rèn)證保護(hù),其加密算法和MAC算法是在當(dāng)前CipherSpec中定義的。SSL支持流加密算法(如RC4算法)和分組加密算法(如RC2、IDEA和DES算法等),認(rèn)證算法支持MD5和SHA算法。

CipherSpec初始時(shí)為空,不提供任何平安性。一旦完成了握手過程,通信雙方就建立了密碼算法和密鑰,并記錄在當(dāng)前的CipherSpec中。在發(fā)送數(shù)據(jù)時(shí),發(fā)送方從CipherSpec中獲取密碼算法對數(shù)據(jù)加密,并計(jì)算MAC,將SSL明文記錄轉(zhuǎn)換成密文記錄。在接收數(shù)據(jù)后,接收方從CipherSpec中獲取密碼算法對數(shù)據(jù)解密,并驗(yàn)證MAC,將SSL密文記錄轉(zhuǎn)換成明文記錄。4.ChangeCipherSpec協(xié)議

ChangeCipherSpec協(xié)議由單一的ChangeCipherSpec消息構(gòu)成,用于改變當(dāng)前的密碼標(biāo)準(zhǔn)(CipherSpec)??蛻舴交蛐谄鞣皆诎l(fā)送Finished消息之前使用ChangeCipherSpec消息通知對方,將采用新的密碼標(biāo)準(zhǔn)和密鑰來加密和解密數(shù)據(jù)記錄。5.警告協(xié)議

SSL記錄層通過警告協(xié)議傳送警告消息。警告消息中包含警告級別和警告描述。警告消息類型如表所示。表警告消息類型警告消息大致可以分成終止警告和錯誤警告兩種,只有close_notify是終止警告,其余均為錯誤警告。在錯誤警告中,又可分成一般錯誤警告和致命錯誤警告,致命錯誤警告將會導(dǎo)致會話失效。同樣,警告消息也要在SSL記錄中進(jìn)行壓縮和加密處理。

SSL握手協(xié)議的錯誤處理比較簡單。任何一方檢測出錯誤后,便向?qū)Ψ桨l(fā)送一個相應(yīng)的警告消息。如果是致命錯誤警告,那么雙方立刻終止連接,雙方均要放棄所有與失敗連接有關(guān)的任何會話標(biāo)識符、密碼和密鑰等。通信雙方都可以使用close_notify警告消息來終止會話。在發(fā)出close_notify警告消息后,不再接收新的消息或數(shù)據(jù)。為了防止切斷攻擊,雙方都應(yīng)知道連接的結(jié)束。如果一個連接沒有收到close_notify警告消息就終止了,那么會話是不可恢復(fù)的。因此,任何一方在關(guān)閉連接前都應(yīng)發(fā)送一個close_notify警告消息,而另一方也要發(fā)送close_notify警告消息進(jìn)行響應(yīng),并立即關(guān)閉連接。 14.3Kerberos認(rèn)證系統(tǒng)

Kerberosv4

圖Kerberos認(rèn)證框圖1.Kerberos協(xié)議

Kerberos協(xié)議分三個階段共六步實(shí)現(xiàn)。

階段Ⅰ:認(rèn)證業(yè)務(wù)交換,C從AS獲取票證授權(quán)證。

(1)用戶在工作站上提出申請票證授權(quán)證:(2)AS回送票證授權(quán)證。AS驗(yàn)證C的訪問權(quán)限后,準(zhǔn)備好票證Tickettgs和C與TGS共享密鑰kc,tgs,并以用戶通行字導(dǎo)出的密鑰kc加密送出:(3)用戶請求效勞授權(quán)證。工作站要求用戶送入通行字,并用它導(dǎo)出密鑰kc,以kc對所接收消息進(jìn)行解密得:用戶C以kc,v解密得TS5+1,實(shí)現(xiàn)對V的驗(yàn)證,并開始享受聯(lián)機(jī)效勞。C與V用kc,v進(jìn)行聯(lián)機(jī)通信業(yè)務(wù)。

用戶開始時(shí)要進(jìn)行Ⅰ~Ⅲ階段協(xié)議,得到的kc,tgs和Tickettgs在有效期Lifetime2內(nèi)可屢次使用,以申請向不同效勞器聯(lián)機(jī)的證書Ticketv和會話密鑰kc,v。后者只執(zhí)行第Ⅱ、Ⅲ階段協(xié)議,所得Ticketv和會話密鑰在有效期Lifetime4內(nèi)使用,與特定效勞器V進(jìn)行聯(lián)機(jī)效勞。一般地,Lifetime2為8小時(shí),Lifetime4要短得多。上述階段中,僅第Ⅰ階段要求用戶出示通行字。2.Kerberos的平安性

(1)用戶與AS共享密鑰kc,由用戶鍵入的通行字導(dǎo)出,這是Kerberos最薄弱的環(huán)節(jié),易被竊聽和猜測攻擊,但Kerberos的票證方式大大降低了通行字的使用頻度。

(2)系統(tǒng)平安基于對AS和TGS的絕對信任,且實(shí)現(xiàn)軟件不能被篡改。

(3)時(shí)限Lifetime1、Lifetime2和時(shí)戳TS1~TS5及TS5+1大大降低了重放攻擊的可能性,但要求網(wǎng)內(nèi)時(shí)鐘同步,且限定時(shí)戳驗(yàn)證時(shí)差|Δt|≤5分鐘為合法,不視為重發(fā)。這要求效勞器要存儲以前的認(rèn)證碼,一般難以做到。(4)Kerberos協(xié)議中的第(2)~(6)步傳輸都采用了加密,從而提高了抗攻擊能力。

(5)AS要存儲所有屬于它的用戶及TGS、V的ID、kc(通行字的Hash值)、ktgs,TGS要存儲ktgs,V要存儲kv。3.Kerberosv4在多個認(rèn)證效勞器AS環(huán)境下的認(rèn)證

(1)Kerberos效勞器應(yīng)在數(shù)據(jù)庫中擁有所有所屬用戶的ID和通行字的Hash值,所有用戶要向Kerberos效勞器注冊。

(2)Kerberos效勞器要與每個效勞器分別共享一個密鑰,所有效勞器需向Kerberos效勞器注冊。

由(1)、(2)兩條決定的范圍稱做Kerberos的一個獨(dú)立區(qū)(Realm)。為保證一個獨(dú)立區(qū)的用戶可向另一個獨(dú)立區(qū)的效勞器申請聯(lián)機(jī)效勞,需要有一個機(jī)構(gòu)能支持獨(dú)立區(qū)之間的認(rèn)證。

(3)各區(qū)的Kerberos效勞器之間有共享密鑰,兩兩Kerberos效勞器相互注冊。圖多個認(rèn)證效勞器環(huán)境下的認(rèn)證效勞C→Vrem:Ticketvrem‖AuthentiCAtorc

Kerberosv5

1.v4和v5的比照

v4和v5的比照方下:

(1)對加密體制的依賴性。v4的加密算法為DES,出口受限,且強(qiáng)度受疑心;v5增加了一個標(biāo)識符,指示所用加密技術(shù)類型和密鑰的長度,因而可采用任何算法和任意長密鑰。

(2)對Internet協(xié)議的依賴性。v4規(guī)定用InternetProtocol(IP)尋址,而不用其他(如ISO網(wǎng))尋址;v5標(biāo)記了地址類型和長度,可用于任意網(wǎng)。(3)消息字節(jié)次序。v4利用選定的字節(jié)次序,標(biāo)記指示最低位為最低地址,或最高位為最低地址,雖可行但不方便;v5規(guī)定所有消息格式均用ASN.1(AbstractSyntaxNotationOne)和BER(BasicEncodingRules),字節(jié)次序無模糊之處。

(4)票證有效期。v4中的有效期以5分鐘為單元,用8bit表示量級,最大為1280分鐘或不到21小時(shí),可能不夠用(如大型問題模擬);v5可以規(guī)定任意確定的起止時(shí)間。

(5)認(rèn)證傳遞。v4中不允許將發(fā)給一用戶的證書,遞送至另一個主機(jī)或讓其他用戶使用;v5那么允許。

(6)獨(dú)立區(qū)間認(rèn)證。在N個區(qū)之間,v4要求有N2個Kerberos-to-Kerberos關(guān)系。v5允許較少的關(guān)系。(7)加密方式。v4采用非標(biāo)準(zhǔn)明文和密文分組連接的工作模式(即PCBC)加密,已經(jīng)證明,PCBC抗密文組變化能力差;v5改用了CBC模式。

(8)會話密鑰對。v4中每個票證均有一個會話密鑰,用戶可以用它對送給效勞器的認(rèn)證碼進(jìn)行加密,并對和此票證一起送至一相應(yīng)效勞器的消息進(jìn)行加密,由于同一票證可以在特定效勞器中屢次重復(fù)使用,因此可能使攻擊者重發(fā)過去截獲的到用戶或到效勞器的消息;v5中提供的用戶和效勞器之間的協(xié)商僅用于一次性連接的子會話密鑰技術(shù)。

(9)通行字攻擊。v4和v5都面臨這個問題,從AS到用戶的消息是用基于用戶通行字導(dǎo)出的密鑰加密的。2.通行字-密鑰變換

Kerberos中通行字以7bitASCII字符(校驗(yàn)位不計(jì)在內(nèi))表示,長度任意。處理過程中:①將字符串變換為比特流B,先去掉校驗(yàn)位;②將B按56bit分組,第一組與第二組自斷點(diǎn)處折回,逆序逐位模2加,參看圖14.3.3;③將56bit數(shù)據(jù)附加上校驗(yàn)位變?yōu)?4bit密鑰(附加校驗(yàn)),以kPW表示;④以原Password字符串按8bit分組作為DES密鑰,對kPW用CBC模式加密,輸出最后密文(Hash值)作為密鑰kc。圖逆序逐位模2加法攻擊者假設(shè)截獲AS→C的消息,那么會試圖以各種通行字來解密。假設(shè)找到通用字,那么可從Kerberos效勞器得到認(rèn)證證書。v5提供了一種預(yù)認(rèn)證(Preauthentication)機(jī)制,使這類攻擊更為困難,但還不能阻止這類攻擊。3.v5協(xié)議

v5針對v4的缺點(diǎn)進(jìn)行了改進(jìn)。v5中的新成員如下:

(1)Realm:指示用戶的獨(dú)立區(qū)。

(2)Options:提供用戶要求在回送票證中附加的某種標(biāo)志。

(3)Times:要求Ticket的起、止及延長的終止時(shí)間。

(4)Nonce:隨機(jī)值,防止重發(fā)。

(5)子密鑰:用戶選項(xiàng),要求進(jìn)行特定會話時(shí)保護(hù)消息的加密密鑰。假設(shè)未選,那么從Ticket取kc,v作為會話密鑰。

(6)序列號:用戶選項(xiàng),在本次會話中,限定效勞器發(fā)送給用戶的消息開始的序號,用于檢測重發(fā)。 14.4PGP協(xié)議

PGP(PrettyGoodPrivacy)是一種對電子郵件進(jìn)行加密和簽名保護(hù)的平安協(xié)議和軟件工具。它將基于公鑰密碼體制的RSA算法和基于單密鑰體制的IDEA算法巧妙地結(jié)合起來,同時(shí)兼顧了公鑰密碼體系的便利性和傳統(tǒng)密碼體系的高速度,從而形成了一種高效的混合密碼系統(tǒng)。PGP中,發(fā)送方使用隨機(jī)生成的會話密鑰和IDEA算法加密郵件文件,使用RSA算法和接收方的公鑰加密會話密鑰,然后將加密的郵件文件和會話密鑰發(fā)送給接收方;接收方使用自己的私鑰和RSA算法解密會話密鑰,然后用會話密鑰和IDEA算法解密郵件文件。PGP還支持對郵件的數(shù)字簽名和簽名驗(yàn)證。另外,PGP還可以用來加密文件。PGP的密碼算法

隨著Internet的開展,電子郵件已成為溝通、聯(lián)系、交流思想的重要手段,對人們的工作和生活產(chǎn)生了深刻的影響。電子郵件和普通信件一樣,屬于個人隱私,而私密權(quán)是一種根本人權(quán),必須得到保護(hù)。在電子郵件的傳輸過程中,可能存在著被第三者非法閱讀和篡改的平安風(fēng)險(xiǎn)。通過密碼技術(shù)可以防止電子郵件被非法閱讀;通過數(shù)字簽名技術(shù),可以防止電子郵件被非法篡改。

PGP是一種供群眾免費(fèi)使用的郵件加密軟件,它是一種基于RSA和IDEA算法的混合密碼系統(tǒng)?;赗SA的公鑰密碼體系非常適合于處理電子郵件的數(shù)字簽名、身份認(rèn)證和密鑰傳遞問題,而IDEA算法加密速度快,非常適合于郵件內(nèi)容的加密。PGP采用了基于數(shù)字簽名的身份認(rèn)證技術(shù)。對于每個郵件,PGP使用MD-5算法產(chǎn)生一個128位的散列值作為該郵件的唯一標(biāo)識,并以此作為郵件簽名和簽名驗(yàn)證的根底。例如,為了證實(shí)郵件是A發(fā)給B的,A首先使用MD-5算法產(chǎn)生一個128位的散列值,再用A的私鑰加密該值,作為該郵件的數(shù)字簽名,然后把它附加在郵件后面,再用B的公鑰加密整個郵件。在這里,應(yīng)領(lǐng)先簽名再加密,而不應(yīng)先加密再簽名,以防止簽名被篡改(攻擊者將原始簽名去掉,換上其他人的簽名)。B收到加密的郵件后,首先使用自己的私鑰解密郵件,得到A的郵件原文和簽名,然后使用MD-5算法產(chǎn)生一個128位的散列值,并和解密后的簽名相比較。如果兩者相符合,那么說明該郵件確實(shí)是A寄來的。PGP還允許對郵件只簽名而不加密,這種情況適用于發(fā)信人公開發(fā)表聲明的場合。發(fā)信人為了證實(shí)自己的身份,可以用自己的私鑰簽名。收件人用發(fā)信人的公鑰來驗(yàn)證簽名,這不僅可以確認(rèn)發(fā)信人的身份,還可以防止發(fā)信人抵賴自己的聲明。

PGP采用了IDEA算法對郵件內(nèi)容進(jìn)行加密。由于IDEA算法是單密鑰密碼算法,加密和解密共享一個隨機(jī)密鑰,因此,PGP通過RSA算法來解決隨機(jī)密鑰平安傳遞問題。發(fā)信人首先隨機(jī)生成一個密鑰(每次加密都不同),使用IDEA算法加密郵件內(nèi)容,然后再用RSA算法加密該隨機(jī)密鑰,并隨郵件一起發(fā)送給收件人。收信人先用RSA算法解密出該隨機(jī)密鑰,再用IDEA算法解密出郵件內(nèi)容。IDEA算法是一個專利算法,用于非商業(yè)用途時(shí)可以不交納專利使用費(fèi)(PGP軟件是免費(fèi)的)。PGP的密鑰管理

在PGP中,采用公鑰密碼體制來解決密鑰分發(fā)和管理問題。公鑰可以公開,不存在監(jiān)聽問題,但公鑰的發(fā)布仍有一定的平安風(fēng)險(xiǎn),主要是公鑰可能被篡改。下面舉一個例子來說明這種情況。

假設(shè)A要給B發(fā)郵件,必須首先獲得B的公鑰,A從BBS上下載了B的公鑰,然后用它加密郵件,并用Email系統(tǒng)發(fā)給了B。然而,在A和B都不知道的情況下,另一個人C假冒B的名字生成一個密鑰對,并在BBS中用自己生成的公鑰替換了B的公鑰。結(jié)果A從BBS上得到的公鑰便是C的,而不是B的。但是,一切看來都很正常,因?yàn)锳拿到的公鑰的用戶名仍然是“B〞。于是,便出現(xiàn)了以下平安風(fēng)險(xiǎn):(1)C可以用他的私鑰來解密A給B的郵件。

(2)C可以用B的公鑰來轉(zhuǎn)發(fā)A給B的郵件,并且誰都不會起疑心。

(3)C可以改動郵件的內(nèi)容。

(4)C可以偽造B的簽名給A或其他人發(fā)郵件,因?yàn)檫@些人擁有的公鑰是C偽造的,他們會以為是B的來信。為了防止這些情況的發(fā)生,最好的方法是讓任何人都沒有時(shí)機(jī)篡改公鑰,比方直接從B的手中得到他的公鑰。然而,當(dāng)B遠(yuǎn)在千里之外或無法見到時(shí),獲得公鑰是很困難的。PGP采用一種公鑰介紹機(jī)制來解決這個問題。例如,A和B有一個共同的朋友D,而D手中B的公鑰是正確的(這里假設(shè)D已經(jīng)認(rèn)證過B的公鑰)。這樣D可以用他的私鑰在B的公鑰上簽名(使用上面所講的簽名方法),表示D可以擔(dān)保這個公鑰是屬于B的。當(dāng)然,A需要用D的公鑰來驗(yàn)證D給出的B的公鑰,同樣D也可以向B證實(shí)A的公鑰,D就成為了A和B之間的中介人。這樣,B或D就可以放心地把經(jīng)過D簽名的B的公鑰上載到BBS中,任何人(即使是BBS的管理員)篡改B的公鑰都不可能不被A發(fā)現(xiàn),從而解決了利用公共信道傳遞公鑰的平安問題。這里還可能存在一個問題:怎樣保證D的公鑰是平安的。理論上,D的公鑰確有被偽造的可能,但很難實(shí)現(xiàn)。因?yàn)檫@需要造假者參與整個認(rèn)證過程,對A、B和D三個人都很熟悉,并且還要籌劃很久。為了防止這個問題的發(fā)生,PGP建議由一個大家都普遍信任的機(jī)構(gòu)或人來擔(dān)當(dāng)這個中介人角色,這就需要建立一個權(quán)威的認(rèn)證機(jī)構(gòu)或認(rèn)證中心。由這個認(rèn)證中心簽名的公鑰都被認(rèn)為是真實(shí)的,大家只需要有這樣的公鑰就可以了。通過認(rèn)證中心提供的認(rèn)證效勞可以方便地驗(yàn)證一個由該中心簽名的公鑰是否是真實(shí)的,假冒的公鑰很容易被發(fā)現(xiàn)。這樣的權(quán)威認(rèn)證中心通常由非個人控制的組織或政府機(jī)構(gòu)來充當(dāng)。在非常分散的人群中,PGP建議使用非官方途徑的密鑰中介方式,因?yàn)檫@種非官方途徑更能反映出人們自然的社會交往,而且人們可以自由地選擇所信任的人作為中介人。這里必須遵循的一條規(guī)那么是:在使用任何一個公鑰之前,必須首先作公鑰認(rèn)證,無論公鑰是從權(quán)威的認(rèn)證中心得到的,還是從可信任的中介人那里得到的。密鑰可以通過來認(rèn)證。每個密鑰都有一個唯一標(biāo)識符(KeyID)。KeyID是一個8位十六進(jìn)制數(shù),兩個密鑰具有相同KeyID的可能性是幾十億分之一。PGP還提供了一種更可靠的密鑰標(biāo)識方法——密鑰指紋(KeyFingerprint)。每個密鑰都對應(yīng)一個指紋,即數(shù)字串(16位十六進(jìn)制數(shù)),這個指紋重復(fù)的可能性是微乎其微的。由于密鑰是隨機(jī)生成的,因此任何人都無法指定生成一個具有某個指紋的密鑰,那么從指紋就無法反推出密鑰。這樣,在A拿到B的公鑰后,便可以用與B核對這個指紋,以認(rèn)證B的公鑰。如果A無法和B通,那么A可以和D通來認(rèn)證D的公鑰,通過D來認(rèn)證B的公鑰。這就是直接認(rèn)證和間接介紹的結(jié)合。RSA私鑰的平安同樣也是至關(guān)重要的。相對于公鑰而言,私鑰不存在被篡改的問題,但存在被泄露的問題。RSA私鑰是一個很長的數(shù)字,用戶不可能記住它。 PGP允許用戶為隨機(jī)生成的RSA私鑰指定一個口令。只有給出正確的口令,才能將私鑰釋放出來使用。因此,首先要確保用戶口令的平安,應(yīng)當(dāng)妥善地保管好口令。當(dāng)然,私鑰文件本身失密也是很危險(xiǎn)的,因?yàn)槠谱g者可以使用窮舉法試探出口令。PGP2.6.3(i)命令和參數(shù)說明

1.加密和解密命令

使用接收者的公鑰加密一個純文本文件:

pgp-e文件名接收者公鑰

使用發(fā)送者的私鑰簽名一個純文本文件:

pgp-s文件名[-u發(fā)送者私鑰]

使用發(fā)送者的私鑰簽名一個純文本文件,并且傳送給沒有使用PGP的接收者:

pgp-sta文件名[-u發(fā)送者私鑰]

使用發(fā)送者的私鑰簽名一個純文本文件,然后使用接收者的公鑰加密:

pgp-es文件名接收者公鑰[-u發(fā)送者私鑰]使用傳統(tǒng)的密碼加密一個純文本文件:

pgp-c文件名

解密一個被加密的文件,或者檢查一個文件簽名的完整性:

pgp被加密的文件名[-o純文本文件名]

使用多個接收者的公鑰加密一個純文本文件:

pgp-e文件名接收者公鑰①接收者公鑰②接收者公鑰③

解密一個被加密的文件,并且保存簽名:

pgp-d被加密的文件名

從一個文件中提取出指定用戶的簽名驗(yàn)證:

pgp-sb文件名[-u簽名的用戶名]

從一個被簽名的文件中提取出指定用戶的簽名驗(yàn)證:

pgp-b簽名的文件名2.鑰匙管理命令

產(chǎn)生一個公鑰/私鑰對:

pgp-kg

將一個公鑰或私鑰參加公鑰環(huán)或私鑰環(huán)中:

pgp-ka密鑰文件名[密鑰環(huán)文件名]

從指定用戶的公鑰環(huán)/私鑰環(huán)中取出想要的公鑰/私鑰:

pgp-kx用戶名密鑰文件名[密鑰環(huán)文件名]或pgp-kxa用戶名密鑰文件名[密鑰環(huán)文件名]查看指定用戶的公鑰環(huán)內(nèi)容:

pgp-kv[v][用戶名][密鑰環(huán)文件名]

查看指定用戶的公鑰環(huán)“指紋〞(Fingerprint),以便用與該密鑰所有者核對密鑰:

pgp-kvc[用戶名][密鑰環(huán)文件名]

查看指定用戶的公鑰環(huán)內(nèi)容,并檢查簽名情況:

pgp-kc[用戶名][密鑰環(huán)文件名]

編輯私鑰環(huán)中密鑰的用戶名或口令,還可以修改公鑰環(huán)的信任參數(shù):

pgp-ke用戶名[密鑰環(huán)文件名]

從指定用戶的公鑰環(huán)中刪除一個密鑰或一個用戶名:

pgp-kr用戶名[密鑰環(huán)文件名]在指定用戶的公鑰環(huán)中簽名認(rèn)證一個公鑰,如果沒有-u參數(shù),那么使用缺省的私鑰簽名:

pgp-ks被簽名的用戶名[-u簽名的用戶名][密鑰環(huán)文件名]

在密鑰環(huán)中刪除一個指定用戶的特定簽名:

pgp-krs用戶名[密鑰環(huán)文件名]

永久性地廢除指定用戶的密鑰,并且生成一個“密鑰廢除證書〞:

pgp-kd用戶名

在指定用戶的公鑰環(huán)中暫?;蚣せ钜粋€公鑰的使用:

pgp-kd用戶名3.其他命令參數(shù)

如果使用ASCIIradix-64格式來產(chǎn)生加密文件,那么要在加密、簽名或取出密鑰時(shí)參加-a參數(shù):

pgp-sea文件名用戶名或pgp-kxa用戶名密鑰文件[密鑰環(huán)名]

如果產(chǎn)生加密文件后將原明文文件刪除,那么要在加密或簽名時(shí)參加-a參數(shù):

pgp-sew原明文文件名接收者名

如果將一個ASCII文件轉(zhuǎn)換成接收者的本地文本格式,那么要參加-t參數(shù):

pgp-seat文件名接收者名

如果在屏幕上分頁顯示解密后的文本信息,那么要使用-m(more)參數(shù):

pgp-m解密后的文件名pgp-steam要加密的文件名接收者名

如果在解密后仍使用原文件名,那么要參加-p參數(shù):

pgp-p加密的文件名

如果要使用類似于Unix形式的過濾導(dǎo)入模式,那么要參加-f參數(shù):

pgp-feast接收者名<輸入文件名>輸出文件名

如果在加密時(shí)要從文本文件中參加多個用戶名,那么要使用-@參數(shù):

pgp-e文本文件名指定的用戶名-@用戶列表文件名(多個接收者)PGP的應(yīng)用

1.生成密鑰對

首先,用戶需要生成一個密鑰對(公鑰/私鑰),命令格式為pgp-kg,其生成過程共分為以下3個步驟。

(1)PGP首先會提示用戶選擇密鑰長度,有以下3種選擇:

①512位:低檔商業(yè)級。

②768位:高檔商業(yè)級。

③1024位:軍事級別。有些版本的PGP可以提供2048位的超強(qiáng)加密。(2)PGP提示輸入用戶標(biāo)識,PGP采用用戶名加Email地址的形式來標(biāo)識一個用戶。PGP需要設(shè)置一個口令來保護(hù)生成的私鑰,還需要用戶無規(guī)那么地輸入一個字符串,PGP用它來生成一個隨機(jī)數(shù)。

(3)PGP生成3個文件:pubring.pgp、secring.pgp和randseed.bin。其中,pubring.pgp與secring.pgp分別為公鑰環(huán)文件與私鑰環(huán)文件,randseed.bin為隨機(jī)種子文件。2.發(fā)布公鑰

密鑰對生成后,用戶就可以發(fā)布自己的公鑰了。公鑰的發(fā)放可以用電子郵件或匿名FTP來實(shí)現(xiàn),也可以把公鑰上載到Internet的公鑰效勞器發(fā)布,供大家獲取。下面是PGP公鑰效勞器的統(tǒng)一地址:

電子郵件:pgp-public-。

Web地址-key.html。

匿名。

例如,用戶可使用瀏覽器翻開-key.html,選擇任一公鑰效勞器,根據(jù)菜單說明檢索,獲取他人公鑰或提交自己的公鑰。3.密鑰管理

密鑰由密鑰類型、編號、長度、創(chuàng)立時(shí)間和用戶標(biāo)識信息等組成。私鑰與公鑰分別存放在私鑰環(huán)與公鑰環(huán)文件中。私鑰環(huán)文件是不可讀文件,但用戶可以使用一些命令(如增加、刪除和修改私鑰環(huán)文件內(nèi)容等)間接地對私鑰進(jìn)行管理。

用戶在使用PGP密鑰管理命令時(shí),需要注意命令參數(shù)的使用。例如,用-kv參數(shù)可以查看密鑰的內(nèi)容,如類型、長度、編號、創(chuàng)立日期及用戶標(biāo)識等;用-kc參數(shù)可以查看密鑰的信息以及密鑰簽名人的可信度;用-ke參數(shù)可以修改私鑰信息、口令或改變他人公鑰的可信度;用-ka參數(shù)可以將密鑰參加到密鑰環(huán)中;用-kr參數(shù)可以從密鑰環(huán)中刪除密鑰;用-kx參數(shù)可以從密鑰環(huán)中提取密鑰等。4.郵件加密和簽名

使用收信人公鑰對郵件加密,其命令格式為pgp-eatwmfileuserID。其中,userID是收件人標(biāo)識信息,用來確定所使用的公鑰;file是要加密的郵件文件名;-e參數(shù)用來加密指令;-a參數(shù)用來生成后綴為.asc的ASCII文件;-t參數(shù)用來將電子郵件轉(zhuǎn)換為可接受的文本格式;-w參數(shù)用來銷毀原文件;-m參數(shù)用來提醒接收方在閱讀解密郵件后銷毀郵件。這5個命令參數(shù)可以單獨(dú)使用,也可以合并使用。為了證明發(fā)信人的身份并確保郵件在傳輸過程中的完整性,發(fā)信人可以使用自己的私鑰對郵件進(jìn)行數(shù)字簽名。對郵件進(jìn)行數(shù)字簽名的命令格式為pgp-sabfile。其中,-s參數(shù)用來簽名命令;-b參數(shù)用來單獨(dú)生成簽名文件,可與加密指令合用。簽名人用自己的私鑰生成一個數(shù)字簽名,這個數(shù)字簽名既可附加在文件中,也可以單獨(dú)作為一個簽名文件。收信人使用發(fā)信人公鑰來驗(yàn)證簽名,以證實(shí)發(fā)信人的身份。此外,收信人還可以利用這個簽名來驗(yàn)證郵件的完整性,判斷郵件是否被篡改。

把郵件加密和數(shù)字簽名結(jié)合起來,可以最大限度地保障電子郵件的平安傳輸。下面是一個使用PZ的私鑰和Li的公鑰加密和簽名郵件的例子。

pgpseatLi|mailLi@

PrettyGoodPrivacy(tm)2.6.3Ipublickeyencryptionforthemasses.

(c)199096Philipzimmermann,Phil′sPrettyGoodSoftware.19960118

InternationalversionnotforuseintheUSA.DoesnotuseRSAREF

Currenttime:2001/10/24GMT

Li:

Hi.Howdoyoudo?

PZ

^D

…youneedapassphrasetounlockyouRSAsecretkey.

KeyforuserID:PZ<PZ@>

1024bitkey,keyID69059347,created2001/08/16

Enterpassphrase:Passisgood.Justamoment

Recipients′publickey(s)willbeusedtoencrypt.

KeyforuserID:Li<Li@>

1024bitkey,keyID23ED1378creted2001/08/10

Transportarmorfile:letter.asc5.郵件解密

收信人收到郵件后,先將郵件保存在一個文件(如letter.asc)中,然后使用PGP系統(tǒng)進(jìn)行解密處理。解密郵件的命令格式為pgpletter.asc。根據(jù)PGP系統(tǒng)的提示輸入口令,取出自己的私鑰來解密郵件,然后用發(fā)信人的公鑰來驗(yàn)證發(fā)信人的身份和郵件的完整性,最后PGP會提示生成一個明文文件,收信人翻開這個文件就可以瀏覽郵件內(nèi)容了。至此,就完成了從發(fā)送到接收的PGP操作過程,電子郵件平安地從發(fā)送方傳輸?shù)搅私邮辗?。PGP現(xiàn)在已經(jīng)可以和Outlook結(jié)合在一起了。下面通過實(shí)例說明如何在Outlook中使用PGP加密。首先,翻開OutlookExpress,撰寫一份給合作伙伴的郵件,內(nèi)容為“helloworld!〞。第二步,在發(fā)送之前,選中郵件所有內(nèi)容,右鍵單擊任務(wù)欄中的“PGPencryption〞圖標(biāo)。第三步,選取“CurrentWindow->Encrypt〞,對郵件進(jìn)行加密。如果這種方法出錯,那么可以先把要加密的信息進(jìn)行復(fù)制或剪切,然后右鍵點(diǎn)擊“PGPencryption〞圖標(biāo),從彈出的菜單中選中“encryptfromclipboard〞,這樣信息會在內(nèi)存中加密。之后回到輸寫正文的窗口中,點(diǎn)擊鼠標(biāo)右鍵,選“粘貼〞。最后,在提示輸入密碼時(shí),輸入自己的私鑰的passphrase。收到郵件并雙擊“翻開〞后,單擊“DecryptPGPMessage〞圖標(biāo),解密郵件。 14.5PEM協(xié)議

協(xié)議簡介

PEM由下述四個RFC文件規(guī)定,并于1993年發(fā)布了最后文本。

(1)RFC1421:Internet中的PEM第Ⅰ局部消息加密和認(rèn)證方法。

(2)RFC1422:Internet中的PEM第Ⅱ局部基于證書的密鑰管理。

(3)RFC1423:Internet中的PEM第Ⅲ局部算法、模型和識別符。

(4)RFC1424:Internet中的PEM第Ⅳ局部密鑰證實(shí)和有關(guān)業(yè)務(wù)。這些RFC文件由屬于IETF(InternetEngineeringTaskForce)的PEM工作組負(fù)責(zé),而PEM工作組又屬于IAB(InternetArchitectureBoard)。自1985年開始,IAB的PrivacyandSecurityResearchGroup負(fù)責(zé)起草工作。

PEM具有廣泛的適用性和兼容性,除了在Internet中采用外,還在Compuserve、AmericaOnline、GEnie、Delphi和許多公告網(wǎng)上采用。PEM在應(yīng)用層上實(shí)現(xiàn)端-端業(yè)務(wù),適于在各種硬件或軟件平臺上實(shí)現(xiàn)。PEM與具體郵遞軟件、操作系統(tǒng)、硬件或網(wǎng)絡(luò)的特征無關(guān),兼容無平安的郵遞系統(tǒng);與郵遞系統(tǒng)、協(xié)議、用戶接口具有兼容性;支持郵遞表業(yè)務(wù);和各種密鑰管理方式(包括人工預(yù)分配、中心化分配、基于單鑰或雙鑰的分配方式)兼容;支持PC用戶。PEM的平安業(yè)務(wù)具有機(jī)密性、數(shù)據(jù)源認(rèn)證、消息完整性和不可抵賴性。

PEM不支持一些與平安有關(guān)的業(yè)務(wù),如接入控制、業(yè)務(wù)流量保密、路由控制、有關(guān)多個用戶使用同一PC機(jī)的平安問題、消息收條和對收條的不可抵賴、與所查消息自動關(guān)聯(lián)、消息復(fù)本檢測、防止重放或其他面向數(shù)據(jù)流的業(yè)務(wù)。PGP與PEM的比較

1.可信賴模型

PEM依賴層次結(jié)構(gòu)分配密鑰,通過少數(shù)根級效勞器(IRPA)實(shí)現(xiàn)中心化控制,為指令型,即“我知道你是誰,因?yàn)槟愕腃A已為你簽了字,有關(guān)的PCA已為你的CA簽了字,而IRPA也已為PCA簽了字〞。

PGP中沒有設(shè)置可信賴中心,而是采用可信賴人的概念,即依據(jù)“我知道你是誰,因?yàn)槲艺J(rèn)識(且信賴)的人相信你所說的你的身份〞的原那么,由用戶自己去決定其信賴的人。每一個他所信賴者就相當(dāng)于CA,但沒有PCA、IRPA等機(jī)構(gòu)。2.應(yīng)用對象

PEM被特別設(shè)計(jì)用于Email,其認(rèn)證比保密更重要一些。任何一個消息至少有認(rèn)證業(yè)務(wù)。PEM重視身份(認(rèn)證符),而不關(guān)心可信賴程度。

PGP認(rèn)為保密至少和認(rèn)證一樣重要,或更重要一些。PGP最初設(shè)計(jì)用來確保E-mail業(yè)務(wù)平安。PGP還有壓縮功能,有靈活的可信賴模型,有時(shí)將可信賴與可認(rèn)證等同起來。3.加密

PGP和PEM的消息類型如表所示。PGP和PEM都可加密和簽署消息,都可對未加密的消息簽字。只有PGP可以加密未簽字的消息。PEM送出的消息必須是簽署過的。PEM不可能隱蔽匿名重發(fā)函件者(Remailer),而PGP消息可以是未簽字的和匿名的。表PEM和PGP的消息類型4.簽字信息的隱蔽

假設(shè)消息是加密的,那么PGP就不可能證實(shí),但對PEM的任何消息,即使是加密的也能證實(shí)。這就是說,任何人都可證實(shí)誰發(fā)了PEM,在PEM上不可能發(fā)送匿名消息,也不可能向網(wǎng)上發(fā)送一個匿名的、能為合法收信人認(rèn)證的消息。5.密鑰生成

PGP用戶利用所提供的軟件生成自己的公鑰/密鑰對,密鑰證書基于:①任意ASCII字符串(典型的為“name?emailaddress?〞);②在輸入一些隨機(jī)報(bào)文時(shí),從鍵入字分析導(dǎo)出的隨機(jī)數(shù)。用戶以通行短語保護(hù)其密鑰,當(dāng)PGP軟件需用密鑰時(shí),要求用戶送入通行短語。PGP支持的當(dāng)前命名法為InternetEmail命名法(X.400標(biāo)準(zhǔn)),該法工作性能良好,準(zhǔn)備擴(kuò)充適用于任意模型或標(biāo)準(zhǔn)。PGP的名字有唯一性,但不如PEM強(qiáng)化。

PEM中X.509證書可由用戶、提名人或硬件生成,由用戶的CA簽署證書,并錄入目錄效勞器。用戶公鑰參考X.500來區(qū)分名字,可以保證唯一,且可以擴(kuò)充。6.密鑰分配

PGP通過E-mail、布告牌、密鑰效勞器等進(jìn)行公鑰分配。為了防止竄擾,密鑰由第三方簽字,每個用戶可以決定由誰來充當(dāng)可信的第三者(中間人),這是PGP傳播公鑰的手段。可信賴傳遞性的條件是:A相信B,B相信C,假設(shè)要A相信C,那么要求B對C很信賴,并愿代其簽署他所簽過的公鑰給A,這是PGP“證書機(jī)構(gòu)〞的根底。PGP無真正的嚴(yán)格的層次結(jié)構(gòu)。

PEM是按X.500標(biāo)準(zhǔn)建立的層次結(jié)構(gòu)。7.密鑰撤消

PGP中公鑰不依靠有組織的機(jī)構(gòu)分配,而是通過相互“轉(zhuǎn)抄〞來傳播的。一旦秘密泄露,不可能有保證地撤消其公鑰。雖然可以發(fā)布“密鑰撤消證書〞,但不能保證讓每個在公鑰環(huán)形存儲器中存有被撤消證書用戶的公鑰的用戶都知道。

PEM情況下,X.500目錄或每個PCA郵箱中有密鑰的證書撤消表(CRL),因而可以迅速實(shí)現(xiàn)某一公鑰的撤消。CRL必須能被每個用戶訪問。PGP和PEM的平安問題

(1)密碼分析攻擊。假設(shè)能破解RSA的秘密鑰,那么可能解讀加密Email,并能偽造簽字。但對所有密碼分析技術(shù),RSA被認(rèn)為是平安的。PGP中選n=512bit已足夠。

假設(shè)能攻破DES,那么可解讀PEM中的消息。政府部門(如NSA)可能破譯DES。DES雖只有56bit密鑰,但對于一般單位,尚無力以硬件來破譯。RIPEM1.1可以用三重DES加密,抗攻擊能力加大。

PGP中的IDEA密鑰為128bit,已足夠強(qiáng),但它是一種新算法,還未像DES那樣經(jīng)過近20年的攻擊。(2)對密鑰管理的攻擊。秘密鑰喪失或泄露是致命的,因此需要倍加保護(hù)。以單鑰算法加密時(shí),密鑰一般從通信字短語導(dǎo)出。攻擊者可以設(shè)法截獲通行短語或竊取秘密鑰數(shù)據(jù)庫,這對PGP和PEM都是一種威脅。不要通過不平安線路傳遞通行短語或秘密文件。最平安的是不要讓別人在物理入口訪問你的系統(tǒng)。

接受偽裝公鑰騙取你的秘密信息是另一種威脅,因此必須從可信賴的人或CA索取某人的公鑰,并通過可靠方式(如驗(yàn)證簽字、指紋等),才接受某人的公鑰。(3)重發(fā)攻擊。在PEM中,假設(shè)A傳送一個帶MIC-ONLY的消息(只有認(rèn)證而無保密),消息為“好,我們干〞,那么竊聽者截獲此消息后,將其轉(zhuǎn)送給另外的人C。如果C已有一個已認(rèn)證的消息,并等著你告訴他是否要做那件事,那么這一攻擊起作用。另外,攻擊者還可以將截獲的消息延遲后再發(fā)給B,或改變源的發(fā)信人名,將你的公鑰作為他注冊的公鑰來傳一個消息給B,希望由B送一個消息(未知)給他,這類攻擊在PEM和PGP中均可能出現(xiàn)。

防止重發(fā)要加上發(fā)信人和收信人名以及消息唯一性識別符(如時(shí)戳等),以使收信人能夠鑒別消息是否是重發(fā)的。(4)本地攻擊。E-mail的平安性不可能大于實(shí)施加密的機(jī)器的平安性。一個Unix的超級用戶可能有方法得到你的加密函件,當(dāng)然這些方法要費(fèi)點(diǎn)精力,如在PGP和PEM執(zhí)行程序中設(shè)置特洛伊木馬之類的陷門。攻擊者可在用戶終端和運(yùn)行E-mail平安程序的遠(yuǎn)端機(jī)器之間竊聽明文。因此,E-mail平安程序應(yīng)安裝在自己的機(jī)器上,且在自己完全控制下,其他人不能訪問,另外這些軟件還要經(jīng)過仔細(xì)檢查,確定沒有病毒、陷門等。當(dāng)然,這需要在平安、費(fèi)用和方便使用之間進(jìn)行折衷。

共用工作站時(shí),E-mail平安程序裝在工作站上,其他人可以自己選用秘密鑰,并在軟盤上執(zhí)行平安程序。(5)不可信賴的伙伴。如果你將一個秘密消息傳給另一個人,而他卻不在意地將此消息隨便擴(kuò)散,那么原來的平安措施全都白費(fèi)。因此,應(yīng)當(dāng)按原來消息的保密性來考慮可以遞送的接收者,密碼的平安性首先依賴于應(yīng)用它的人的可信賴性。

(6)業(yè)務(wù)量分析。無論P(yáng)EM或PGP類型的Email,都不可能防止業(yè)務(wù)量分析。這類分析可能對某些用戶造成威脅。防止此類攻擊的方法是增加一些無意義的業(yè)務(wù)來掩蔽其真正的業(yè)務(wù)量,但這要付出相當(dāng)大的代價(jià),從而大大增加了網(wǎng)絡(luò)和收信人的負(fù)擔(dān)。 14.6S/MIME協(xié)議

MIME協(xié)議描述

在Internet中,主要使用兩種電子郵件協(xié)議來傳送電子郵件:SMTP(SimpleMailTransferProtocol)和MIME(MultipurposeInternetMailExtensions)。SMTP協(xié)議描述了電子郵件的信息格式及其傳遞方法,使電子郵件能夠正確地尋址和可靠地傳輸。SMTP協(xié)議只支持文本形式電子郵件的傳送。MIME協(xié)議不僅支持文本形式電子郵件的傳送,而且支持二進(jìn)制文件的傳送,即發(fā)信人可以將二進(jìn)制文件作為電子郵件的附件隨電子郵件一起發(fā)送,而接收端的MIME協(xié)議會自動將附件別離出來,存儲在一個文件中,供收信人讀取。由于MIME協(xié)議大大擴(kuò)展了電子郵件的應(yīng)用范圍,因此一般的電子郵件系統(tǒng)都支持MIME協(xié)議。MIME協(xié)議定義了電子郵件的信息格式,它由郵件頭和郵件體組成。其中,郵件頭定義了郵件的發(fā)送方和接收方的有關(guān)信息;郵件體是郵件數(shù)據(jù),可以是各種數(shù)據(jù)類型。在MIME協(xié)議中,數(shù)據(jù)類型一般是復(fù)合型的,也稱為復(fù)合數(shù)據(jù)。該協(xié)議允許將不同類型的數(shù)據(jù)(如圖像、音頻和格式化文本等)嵌入到同一個郵件體中進(jìn)行傳送。在包含復(fù)合數(shù)據(jù)的郵件體中,設(shè)有邊界標(biāo)志,以標(biāo)明每種類型數(shù)據(jù)的開始和結(jié)束。

SMTP和MIME協(xié)議都是為開放的Internet而設(shè)計(jì)的,并沒有考慮電子郵件的平安問題。隨著辦公自動化和網(wǎng)絡(luò)化的開展,電子郵件已成為溝通、聯(lián)系和交流信息的重要手段,并得到了廣泛的應(yīng)用。為了保證基于電子郵件的信息交換的平安,必須采用信息平安技術(shù)來增強(qiáng)電子郵件通信的平安性。比較成熟的電子郵件平安增強(qiáng)技術(shù)主要有S/MIME協(xié)議和PGP協(xié)議等。S/MIME協(xié)議描述

S/MIME協(xié)議是MIME協(xié)議的平安性擴(kuò)展,它在MIME協(xié)議的根底上增加了分級平安方法,為電子郵件提供了消息完整性、源端不可否認(rèn)性、數(shù)據(jù)機(jī)密性等平安效勞。S/MIME協(xié)議是在早期信息平安技術(shù)(包括早期的PGP)的根底上開展起來的。RFC2632和RFC2633文檔公布了S/MIME的詳細(xì)標(biāo)準(zhǔn)。

由于S/MIME協(xié)議是針對企業(yè)級用戶設(shè)計(jì)的,主要面向Internet和企業(yè)網(wǎng)環(huán)境,因而得到了許多廠商的支持,被認(rèn)為是商業(yè)環(huán)境下首選的平安電子郵件協(xié)議。目前市場上已有多種支持S/MIME協(xié)議的產(chǎn)品,如微軟的OutlookExpress、LotusDomino/Notes、NovellGroupWise及NetscapeCommunicator等。傳統(tǒng)的郵件用戶代理(MUA)可以使用S/MIME為所發(fā)送的郵件增加平安效勞,并在接收時(shí)能夠解釋郵件中的平安效勞。S/MIME提供的平安效勞并不限于郵件,還可用于任何能夠傳送MIME數(shù)據(jù)的傳送機(jī)制,如HTTP等。S/MIME利用了MIME面向?qū)ο蟮奶匦?允許在混合傳送系統(tǒng)中平安地交換信息。

S/MIME協(xié)議通過簽名和加密來增強(qiáng)MIME數(shù)據(jù)的平安性,它使用CMS(CryptographicMessageSyntax,見RFC2630)來創(chuàng)立一個用密碼增強(qiáng)的MIME體,并且定義一種application/pkcs7-mime的MIME類型來傳送MIME體。S/MIME還定義了兩種用于傳送S/MIME簽名消息的MIME類型:multipart/signed和application/pkcs7-signature。內(nèi)容類型

1.SignedData內(nèi)容類型

發(fā)送代理使用SignedData內(nèi)容類型來傳輸一個消息的數(shù)字簽名,或者在無數(shù)字簽名信息的情況下用來傳輸證書。

2.EnvelopedData內(nèi)容類型

發(fā)送代理使用EnvelopedData內(nèi)容類型來傳輸一個被加密的消息。由于在加密消息內(nèi)容時(shí)采用了對稱密碼算法,因此加密和解密消息使用相同的密鑰。該密鑰采用非對稱密碼算法來加密傳輸,即發(fā)送者使用接收者公鑰來加密該密鑰,因此發(fā)送者必須獲得接收者的公鑰后才能使用這個效勞。該內(nèi)容類型不提供認(rèn)證效勞。3.簽名消息屬性

一個S/MIME消息中的簽名信息是用簽名屬性來描述的,這些屬性分別是簽名時(shí)間(SigningTime)、S/MIME能力(S/MIMECapabilities)和S/MIME加密密鑰選擇(S/MIMEEncryptionKeyPreference)。

(1)簽名時(shí)間屬性:用于表示一個消息的簽名時(shí)間。簽名時(shí)間通常由該消息的創(chuàng)立者來生成。在2049年之前,簽名時(shí)間采用UTCTime來編碼;2050年及以后,簽名時(shí)間采用GeneralizedTime來編碼。(2)S/MIME能力屬性:用于表示S/MIME所能提供的平安能力,如簽名算法、對稱密碼算法和密鑰交換算法等。該屬性是可伸縮和可擴(kuò)展的,將來可以通過適當(dāng)?shù)姆椒ㄔ黾有碌钠桨材芰?。該屬性通過一個能力列表向客戶展示它所支持的平安能力,供客戶選擇。

(3)S/MIME加密密鑰選擇屬性:用于標(biāo)記簽名者首選的加密密鑰。該屬性的目的是為那些分開使用加密和簽名密鑰的客戶提供一種互操作能力,主要用于加密一個會話密鑰,以便加密和解密消息。如果只是簽名消息,或者首選的加密證書與用于簽名消息的證書不同,那么發(fā)送代理將使用這個屬性。當(dāng)給一個特定的接收者發(fā)送一個CMSEnvelopedData消息時(shí),應(yīng)當(dāng)按以下步驟來確定所使用的密鑰管理證書:

(1)如果在一個來自特定接收者的SignedData對象上發(fā)現(xiàn)了一個S/MIME加密密鑰選擇屬性,那么它所標(biāo)識的X.509證書將作為該接收者的X.509密鑰管理證書來使用。

(2)如果在一個來自特定接收者的SignedData對象上未發(fā)現(xiàn)一個S/MIME加密密鑰選擇屬性,那么應(yīng)當(dāng)使用相同的主體名作為簽名的X.509證書,即從X.509證書集合中搜索一個X.509證書,使之能夠作為密鑰管理證書來使用。

(3)如果未發(fā)現(xiàn)一個X.509密鑰管理證書,那么不能與消息簽名一起加密。如果找到了多個X.509密鑰管理證書,那么由S/MIME代理做出屬性選擇。內(nèi)容加密

S/MIME采用對稱密碼算法來加密與解密消息內(nèi)容。發(fā)送和接收代理都要支持基于DES和3DES的密碼算法,接收代理還應(yīng)支持基于40位密鑰長度的RC2(簡稱RC2/40)以及與其兼容的密碼算法。

當(dāng)一個發(fā)送代理創(chuàng)立一個加密的消息時(shí),首先要確定它所使用的密碼算法類型,并將結(jié)果存放在一個能力列表中。該能力列表包含了從接收者接收的消息以及out-of-band信息,如私人合同、用戶參數(shù)選擇和法定的限制等。一個發(fā)送代理可以按其優(yōu)先順序來通告它的解密能力。對于進(jìn)入簽名消息中的加密能力屬性,可按下面的方法進(jìn)行處理:

(1)如果接收代理還未建立起發(fā)送者公鑰能力列表,那么在驗(yàn)證進(jìn)入消息中的簽名和簽名時(shí)間后,接收代理將創(chuàng)立一個包含簽名時(shí)間的能力列表。

(2)如果已經(jīng)建立了發(fā)送者公鑰能力列表,那么接收代理將驗(yàn)證進(jìn)入消息中的簽名和簽名時(shí)間。如果簽名時(shí)間大于存儲在列表中的簽名時(shí)間,那么接收代理將更新能力列表中的簽名時(shí)間和能力。

在發(fā)送一個消息之前,發(fā)送代理要確定是否同意使用弱密碼算法來加密該消息中的特定數(shù)據(jù)。如果不同意,那么不能使用弱密碼算法(如RC2/40等)。規(guī)那么1:能力(KnownCapabilities)

如果發(fā)送代理已經(jīng)接收了有關(guān)接收者的加密能力列表,那么選擇該列表中排在第一的能力信息和密碼算法來加密消息內(nèi)容(這種加密能力的排列順序通常是由接收者有意安排的)。也就是說,發(fā)送代理將根據(jù)接收者提供的加密能力信息來選擇加密消息內(nèi)容的密碼算法,以保證接收者能夠解密被加密的消息。規(guī)那么2:未知能力,加密應(yīng)用(UnknownCapabilities,KnownUseofEncryption)如果發(fā)送代理并不知道某一接收者的加密能力,但曾經(jīng)接收過來自該接收者的加密消息,并且在所接收的加密消息中具有可信任的簽名,那么發(fā)送代理將選擇該接收者在簽名和加密消息中曾使用過的相同密碼算法來加密消息。規(guī)那么3:未知能力,未知S/MIME版本(UnknownCapabilities,UnknownVersionofS/MIME)如果發(fā)送代理不知道接收者的加密能力,也不知道接收者的S/MIME版本,那么選擇3DES算法來加密消息,因?yàn)?DES算法是一種S/MIMEv3必須支持的強(qiáng)密碼算法。發(fā)送代理也可以不選擇3DES算法,而用RC2/40算法來加密消息。RC2/40算法是一種弱密碼算法,具有一定的平安風(fēng)險(xiǎn)。

如果一個發(fā)送代理需要將一個加密消息傳送給多個接收者,并且這些接收者的加密能力可能是不相同的,那么發(fā)送代理不得不屢次發(fā)送該消息。如果每次發(fā)送該消息時(shí)選擇不同強(qiáng)度的密碼算法來加密消息,那么存在一定的平安風(fēng)險(xiǎn),即竊聽者有可能通過解密弱加密的消息來獲得強(qiáng)加密消息的內(nèi)容。S/MIME消息格式

S/MIME消息是MIME實(shí)體和CMS對象的組合,使用了多種MIME類型和CMS對象。被保護(hù)的數(shù)據(jù)總是一個標(biāo)準(zhǔn)化的MIME實(shí)體和其他便于對CMS對象進(jìn)行處理的數(shù)據(jù),如證書和算法標(biāo)識符等。CMS對象被嵌套封裝在MIME實(shí)體中。為了適應(yīng)多種特定的簽名消息環(huán)境,S/MIME提供了多種消息格式:只封裝數(shù)據(jù)格式,只簽名數(shù)據(jù)格式,簽名且封裝數(shù)據(jù)格式。多種消息格式主要為了適應(yīng)多種特定的簽名消息環(huán)境。S/MIME用來保護(hù)MIME實(shí)體。一個MIME實(shí)體由MIME頭和MIME體兩局部組成,被保護(hù)的MIME實(shí)體可以是“內(nèi)部〞MIME實(shí)體,即一個大的MIME消息中“最里面〞的對象,還可以是“外部〞MIME實(shí)體,即把整個MIME實(shí)體處理成CMS對象。

在發(fā)送端,發(fā)送代理首先按照本地保護(hù)協(xié)議來創(chuàng)立一個MIME實(shí)體,保護(hù)方式可以是簽名、封裝或簽名且封裝等;然后對MIME實(shí)體進(jìn)行標(biāo)準(zhǔn)化處理和轉(zhuǎn)移編碼,構(gòu)成一個標(biāo)準(zhǔn)化的S/MIME消息;最后發(fā)送該S/MIME消息。

在接收端,接收代理接收到一個S/MIME消息后,首先將該消息中的平安效勞處理成一個MIME實(shí)體,然后解碼并展現(xiàn)給用戶或應(yīng)用。1.標(biāo)準(zhǔn)化

為了在創(chuàng)立簽名和驗(yàn)證簽名的過程中能夠唯一明確地表示一個MIME實(shí)體,每個MIME實(shí)體必須轉(zhuǎn)換成一種標(biāo)準(zhǔn)格式。標(biāo)準(zhǔn)化的細(xì)節(jié)依賴于一個實(shí)體的實(shí)際MIME類型和子類型,通常由發(fā)送代理的非平安局部來完成,而不是由S/MIME來完成。

文本是主要的MIME實(shí)體,必須具有標(biāo)準(zhǔn)化的行結(jié)尾和字符集。行結(jié)尾必須是<CR><LF>字符對,字符集應(yīng)當(dāng)是一種已注冊的字符集。在字符集參數(shù)中命名所選的字符集,使接收代理能夠正確地確定所使用的字符集。2.轉(zhuǎn)移編碼

由于標(biāo)準(zhǔn)的InternetSMTP根底結(jié)構(gòu)是一種基于7位文本的傳輸設(shè)施,不能保證8位文本或二進(jìn)制數(shù)據(jù)的傳輸,盡管SMTP傳輸網(wǎng)絡(luò)中的某些網(wǎng)段現(xiàn)在已經(jīng)能夠處理8位文本和二進(jìn)制數(shù)據(jù),因此,為了使簽名消息或其他二進(jìn)制數(shù)據(jù)能夠在7位文本傳輸設(shè)施上透明地傳輸,必須對這種MIME實(shí)體進(jìn)行轉(zhuǎn)移編碼,使之轉(zhuǎn)換成一種7位文本的實(shí)體。通過轉(zhuǎn)移編碼還可以使M

溫馨提示

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

最新文檔

評論

0/150

提交評論