SSLTLS協(xié)議-信息安全概論課件與復(fù)習提綱

1SSL/TLS協(xié)議1994年Netscape開發(fā)了SSL(SecureSocketLayer)協(xié)議，專門用于保護Web通訊版本和歷史1.0，不成熟2.0，基本上解決了Web通訊的安全問題Microsoft公司發(fā)布了PCT(PrivateCommunicationTechnology)，并在IE中支持3.0，1996年發(fā)布，增加了一些算法，修改了一些缺陷TLS1.0(TransportLayerSecurity,也被稱為SSL3.1)，1997年IETF發(fā)布了Draft，同時，Microsoft宣布放棄PCT，與Netscape一起支持TLS1.01999年，發(fā)布RFC2246(TheTLSProtocolv1.0)1SSL/TLS協(xié)議1994年Netscape開發(fā)了SSL(12SSL/TLS協(xié)議協(xié)議的設(shè)計目標為兩個通訊個體之間提供保密性和完整性(身份認證)互操作性、可擴展性、相對效率協(xié)議的使用2SSL/TLS協(xié)議協(xié)議的設(shè)計目標23采用的基本技術(shù)主要是為應(yīng)用層數(shù)據(jù)提供傳輸中的安全。它所采用的基本技術(shù)為：

（1）身份認證采用公開密鑰體制；

（2）數(shù)據(jù)保密采用對稱密鑰體制；（3）消息的完整性保護采用帶密鑰的消息認證碼（MAC）。SSL/TLS概況3采用的基本技術(shù)SSL/TLS概況3SSLTLS協(xié)議-信息安全概論ppt課件與復(fù)習提綱4SSLTLS協(xié)議-信息安全概論ppt課件與復(fù)習提綱56SSL/TLS協(xié)議棧TLS更改密碼說明協(xié)議（ChangeCipherSpec）保證可擴展性。TLS警告協(xié)議（AlertProtocol）產(chǎn)生必要的警告信息。6SSL/TLS協(xié)議棧TLS更改密碼說明協(xié)議（Change67TLS體系結(jié)構(gòu)如圖所示，它位于傳輸層之上、應(yīng)用層之下。它獨立與應(yīng)用層，使應(yīng)用層可以直接建立在TLS上。

TLS體系結(jié)構(gòu)IP協(xié)議TCP協(xié)議紀錄協(xié)議握手協(xié)議更改密碼說明協(xié)議警告協(xié)議HTTP協(xié)議Telnet協(xié)議…7TLS體系結(jié)構(gòu)如圖所示，它位于傳輸層之上、應(yīng)用層之下。它獨78TLS會話TLSSession定義：指客戶和服務(wù)器之間的一個關(guān)聯(lián)關(guān)系。通過TLS握手協(xié)議創(chuàng)建session，它確定了一組密碼算法的參數(shù)。Session可以被多個連接共享，從而可以避免為每個連接協(xié)商新的安全參數(shù)而帶來昂貴的開銷。TLSSession都有一個當前狀態(tài)TLSconnection與底層協(xié)議的點對點連接相關(guān)聯(lián)每個connection都與一個session相關(guān)聯(lián)連接是短暫的8TLS會話TLSSession定義：89TLS會話狀態(tài)會話實際上是一組參數(shù)，包括Sessionidentifier，字節(jié)序列，由服務(wù)器產(chǎn)生，用來標識一個會話狀態(tài)Peercertificate(可以為NULL)，對方的X.509v3證書Compressionmethod，壓縮數(shù)據(jù)的算法Cipherspec，指定數(shù)據(jù)加密算法和用于HMAC的散列算法，以及算法的有關(guān)參數(shù)Mastersecret,客戶和服務(wù)器之間共享的48字節(jié)的數(shù)據(jù)Isresumable，標記是否這個會話可以被用來初始化一個新的連接9TLS會話狀態(tài)會話實際上是一組參數(shù)，包括910TLS連接的狀態(tài)連接狀態(tài)也包含一組參數(shù)Serverandclientrandom，客戶和服務(wù)器為每個連接選擇的字節(jié)序列ServerwriteMACsecret，服務(wù)器在發(fā)送數(shù)據(jù)的時候，用于MAC運算的keyClientwriteMACsecret，客戶在發(fā)送數(shù)據(jù)的時候，用于MAC運算的keyServerwritekey，服務(wù)器加密數(shù)據(jù)的密鑰，以及客戶解密數(shù)據(jù)的密鑰Clientwritekey，客戶加密數(shù)據(jù)的密鑰，以及服務(wù)器解密數(shù)據(jù)的密鑰Initializationvectors，在密碼塊鏈接(CBC)模式中用到的IV，最初由握手協(xié)議初始化，以后，每一個記錄的最后一個密文塊被用作下一個記錄的IVSequencenumbers，每一個連接都需要維護一個序列號，當密碼參數(shù)變化時，重置為010TLS連接的狀態(tài)連接狀態(tài)也包含一組參數(shù)1011TLS記錄協(xié)議操作過程示意圖11TLS記錄協(xié)議操作過程示意圖1112TLS記錄協(xié)議中的操作第一步，fragmentation上層消息的數(shù)據(jù)被分片成214字節(jié)大小的塊，或者更小第二步，compression(可選)必須是無損壓縮，如果數(shù)據(jù)增加的話，則增加部分的長度不超過1024字節(jié)第三步，計算消息認證碼(MAC)計算公式：

HMAC_hash(MAC_write_secret,

seq_num

||TLSCompressed.type

||TLSCompressed.version

||TLSCompressed.length

||TLSCompressed.fragment)12TLS記錄協(xié)議中的操作第一步，fragmentation1213TLS記錄協(xié)議中的操作(續(xù))第四步，encryption采用密碼塊鏈接(CBC)加密，算法由cipherspec參數(shù)指定數(shù)據(jù)長度不超過214+2048字節(jié)，包括加密之后的數(shù)據(jù)內(nèi)容HMACpadding,共padding_lengthIV，初始協(xié)商指定，以后，前后記錄連接起來說明：如果是流密碼算法，則不需要padding13TLS記錄協(xié)議中的操作(續(xù))第四步，encryption1314TLS記錄協(xié)議的處理結(jié)果結(jié)果如下：

struct{ContentTypetype;——8位，上層協(xié)議類型

ProtocolVersionversion;——16位，主次版本

uint16length;——加密后數(shù)據(jù)的長度，

不超過214+2048字節(jié)

EncryptedDatafragment;——密文數(shù)據(jù)

}TLSCiphertext;14TLS記錄協(xié)議的處理結(jié)果結(jié)果如下：1415TLS密碼變化協(xié)議它位于TLS記錄協(xié)議之上所以，它用到了TLS記錄協(xié)議的處理過程ContentType=20協(xié)議只包含一條消息，一個字節(jié)1用途：切換狀態(tài)

把密碼參數(shù)設(shè)置為當前狀態(tài)

在握手協(xié)議中，當安全參數(shù)

協(xié)商一致后，發(fā)送此消息這條消息使得接收方改變當

前狀態(tài)讀參數(shù)，使得發(fā)送方

改變當前狀態(tài)寫參數(shù)15TLS密碼變化協(xié)議它位于TLS記錄協(xié)議之上1516TLS警告協(xié)議位于TLS記錄協(xié)議之上所以，也用到了TLS記錄協(xié)議的處理過程ContentType=21協(xié)議數(shù)據(jù)包含兩個字節(jié)

第一個字節(jié)為level：

分別為warning(1)和

fatal(2)兩種情況

第二個字節(jié)為情況說明Fatal類型的alert消息導致

連接立即終止，此時，對應(yīng)

該會話的其他連接可以繼續(xù)，

但是會話標識符無效，以免

利用此失敗的連接來建立新

的連接16TLS警告協(xié)議位于TLS記錄協(xié)議之上1617AlertProtocol第二字節(jié)說明close_notify(0),unexpected_message(10),bad_record_mac(20),*decryption_failed(21),*record_overflow(22),*decompression_failure(30),*handshake_failure(40),*bad_certificate(42),unsupported_certificate(43),certificate_revoked(44),certificate_expired(45),certificate_unknown(46),illegal_parameter(47),*unknown_ca(48),*access_denied(49),decode_error(50),*decrypt_error(51),export_restriction(60),*protocol_version(70),*insufficient_security(71),*internal_error(80),*user_canceled(90),#no_renegotiation(100),#說明：

1*表示該消息往往是fatal級別

2#表示該消息往往是warning級別

3對于其他的錯誤情況，發(fā)送方可以根據(jù)情況決定是warning還是fatal,對于warning消息，接收方可以自行決定如何處理，如果是fatal消息，則一定要當作fatal消息來對待17AlertProtocol第二字節(jié)說明close_no1718TLS握手協(xié)議位于TLS記錄協(xié)議之上也用到了TLS記錄協(xié)議的處理過程ContentType=22協(xié)議格式用途：當TLS客戶和服務(wù)器開始通訊的時候，它們要通過協(xié)商，在以下信息方面獲得一致:

協(xié)議版本、密碼算法、是否認證對方、

用什么技術(shù)來產(chǎn)生共享秘密數(shù)據(jù)，等等18TLS握手協(xié)議位于TLS記錄協(xié)議之上1819TLS握手協(xié)議的流程交換Hello消息，對于算法、交換隨機值等協(xié)商一致交換必要的密碼參數(shù)，以便雙方得到統(tǒng)一的premastersecret（一個用在對稱加密密鑰生成中的46字節(jié)的隨機數(shù)字）交換證書和相應(yīng)的密碼信息，以便進行身份認證產(chǎn)生mastersecret把安全參數(shù)提供給TLS記錄層檢驗雙方是否已經(jīng)獲得同樣的安全參數(shù)19TLS握手協(xié)議的流程交換Hello消息，對于算法、交換隨1920TLS握手協(xié)議使用的消息消息參數(shù)hello_requestNullclient_hello版本，隨機數(shù)，會話id，密碼參數(shù)，壓縮方法server_hellocertificateX.509v3證書鏈server_key_exchange參數(shù)，簽名certificate_request類型，CAsserver_doneNullcertificate_verify簽名client_key_exchange參數(shù)，簽名finishedHash值20TLS握手協(xié)議使用的消息消息參數(shù)hello_reques2021第一階段：建立起安全能力屬性客戶發(fā)送一個client_hello消息，包括以下參數(shù)：

版本、隨機數(shù)(32位時間戳+28字節(jié)隨機序列)、會話ID、客戶支持的密碼算法列表(CipherSuite)、客戶支持的壓縮方法列表然后，客戶等待服務(wù)器的server_hello消息服務(wù)器發(fā)送server_hello消息，參數(shù)：

客戶建議的低版本以及服務(wù)器支持的最高版本、服務(wù)器產(chǎn)生的隨機數(shù)、會話ID、服務(wù)器從客戶建議的密碼算法中挑出一套、服務(wù)器從客戶建議的壓縮方法中挑出一個21第一階段：建立起安全能力屬性客戶發(fā)送一個client_h2122關(guān)于會話ID(SessionID)客戶方客戶指定的會話ID如果不等于0，則表示它希望基于這個會話來更新已有連接的安全參數(shù)，或者創(chuàng)建一個新的連接如果會話ID等于0，則表示客戶希望在一個新的會話上建立一個新的連接服務(wù)器或者同意客戶指定的會話ID，需要檢查cache中的會話狀態(tài)或者返回一個新的會話ID22關(guān)于會話ID(SessionID)客戶方2223CipherSuite第一個元素指定了密鑰交換的方法，TLS支持以下一些方法：RSA，要求服務(wù)器提供一個RSA證書DH(Diffie-Hellman)，要求服務(wù)器的證書中包含了由CA簽名的DH公開參數(shù)?？蛻艋蛘咴谧C書中提供DH公開參數(shù)，或者在密鑰交換消息中提供此參數(shù)EDH(EphemeralDiffie-Hellman)，產(chǎn)生臨時的密鑰，DH公開參數(shù)由發(fā)送者的私鑰進行簽名，接收者用對應(yīng)的公鑰進行驗證匿名的DH，不加認證。會受到中間人攻擊然后，指定以下信息加密算法，和類型(流還是分組密碼算法)HMAC算法，MD5還是SHA-1HashSizeKeyMaterialIVSize23CipherSuite第一個元素指定了密鑰交換的方法，T2324第二階段：服務(wù)器認證和密鑰交換服務(wù)器發(fā)送自己的證書，消息包含一個X.509證書，或者一條證書鏈除了匿名DH之外的密鑰交換方法都需要服務(wù)器發(fā)送server_key_exchange消息可選的，有些情況下可以不需要。只有當服務(wù)器的證書沒有包含必需的數(shù)據(jù)的時候才發(fā)送此消息消息包含簽名，被簽名的內(nèi)容包括兩個隨機數(shù)以及服務(wù)器參數(shù)服務(wù)器發(fā)送certificate_request消息非匿名server可以向客戶請求一個證書包含證書類型和CAs服務(wù)器發(fā)送server_hello_done,然后等待應(yīng)答24第二階段：服務(wù)器認證和密鑰交換服務(wù)器發(fā)送自己的證書，消息2425第三階段：客戶認證和密鑰交換客戶收到server_done消息后，它根據(jù)需要檢查服務(wù)器提供的證書，并判斷server_hello的參數(shù)是否可以接受，如果都沒有問題的話，發(fā)送一個或多個消息給服務(wù)器如果服務(wù)器請求證書的話，則客戶首先發(fā)送一個certificate消息，若客戶沒有證書，則發(fā)送一個no_certificate警告然后客戶發(fā)送client_key_exchange消息，消息的內(nèi)容取決于密鑰交換的類型最后，客戶發(fā)送一個certificate_verify消息，其中包含一個簽名，對從第一條消息以來的所有握手消息的HMAC值(用master_secret)進行簽名25第三階段：客戶認證和密鑰交換客戶收到server_don2526第四階段：結(jié)束第四階段建立起一個安全的連接客戶發(fā)送一個change_cipher_spec消息，并且把協(xié)商得到的CipherSuite拷貝到當前連接的狀態(tài)之中然后，客戶用新的算法、密鑰參數(shù)發(fā)送一個finished消息，這條消息可以檢查密鑰交換和認證過程是否已經(jīng)成功。其中包括一個校驗值，對所有以來的消息進行校驗。服務(wù)器同樣發(fā)送change_cipher_spec消息和finished消息。握手過程完成，客戶和服務(wù)器可以交換應(yīng)用層數(shù)據(jù)。26第四階段：結(jié)束第四階段建立起一個安全的連接2627密鑰交換算法TLS記錄協(xié)議需要：CipherSuite,mastersecret,andtheclientandserverrandomvalues在hello消息中，交換隨機數(shù)以及各種算法對于各種密鑰交換算法，從pre_master_secret計算得到master_secret，然后從內(nèi)存中刪除，公式：

master_secret=PRF(pre_master_secret,

“mastersecret”,ClientHello.random

+ServerHello.random)[0..47]

*PRF(secret,label,seed)為偽隨機函數(shù)Master_secret總是48字節(jié)長，而pre_master_secret長度不定，取決于密鑰交換算法兩類密鑰交換算法：RSA，客戶產(chǎn)生一個48字節(jié)的pre_master_secret，然后通過服務(wù)器的公鑰加密再傳遞給服務(wù)器Diffie-Hellman，雙方協(xié)商得到的密鑰被用作pre_master_secret27密鑰交換算法TLS記錄協(xié)議需要：CipherSuite,2728重用一個TLS會話客戶和服務(wù)器在交換hello消息中，客戶要求重用已有的TLS會話，服務(wù)器同意使用cache中的會話

*sessionid跳過第二第三階段，直接把TLS會話中的參數(shù)傳遞給TLS記錄層28重用一個TLS會話客戶和服務(wù)器在交換hello消息中，客2829TLS/SSL安全性分析針對一些常見的攻擊手法針對密鑰算法的破解取決于算法的強度，協(xié)商過程利用明文模式的攻擊上層協(xié)議中常常有一些固定的模式可以參考，比如http協(xié)議中g(shù)et字節(jié)串構(gòu)造字典(密文-密鑰對)，查字典TLS辦法：用長密鑰，使得不可能構(gòu)造這樣的字典重放攻擊TLS中的nonce有32字節(jié)(包含時間戳)，可用于避免重放攻擊會話ID標識了一個完整的會話，要重放部分會話需要知道私鑰中間人攻擊通過證書來認證對方對于雙方都是匿名的模式，中間人攻擊也是成立的29TLS/SSL安全性分析針對一些常見的攻擊手法2930SSL:PRNG攻擊Netscapev1.1版本中存在，利用隨機數(shù)發(fā)生器的弱點先看隨機數(shù)發(fā)生器globalvariableseed;RNG_CreateContext()

(seconds,microseconds)=timeofday;/*Timeelapsedsince1970*/

pid=processID;ppid=parentprocessID;

a=mklcpr(microseconds);b=mklcpr(pid+seconds+(ppid<<12));seed=MD5(a,b);

mklcpr(x)/*notcryptographicallysignificant;shownforcompleteness*/return((0xDEECE66D*x+0x2BBB62DC)>>1);（待續(xù)）30SSL:PRNG攻擊Netscapev1.1版本中存3031SSL:PRNG攻擊(續(xù))種子關(guān)聯(lián)：pid,ppid,seconds,microsecondsSeconds往往可以獲得，microseconds未知如果在目標機器上有賬號，則pid和ppid可以獲得否則，可以尋找pid和ppid的。

對于大多數(shù)UNIX平臺，pid+(ppid<<12)只有27位globalvariablechallenge,secret_key;RNG_GenerateRandomBytes()

x=MD5(seed);seed=seed+1;returnx;create_key()

RNG_CreateContext();tmp=RNG_GenerateRandomBytes();tmp=RNG_GenerateRandomBytes();

challenge=RNG_GenerateRandomBytes();secret_key=RNG_GenerateRandomBytes();31SSL:PRNG攻擊(續(xù))種子關(guān)聯(lián)：pid,ppid3132PRNG的啟示PRNG并不是SSL協(xié)議本身的缺陷，而是實現(xiàn)上導致的缺陷隨機數(shù)對于安全協(xié)議或者安全系統(tǒng)的重要性Reference:

IanGoldbergandDavidWagner,“RandomnessandtheNetscapeBrowser”,January1996Dr.Dobb'sJournal32PRNG的啟示PRNG并不是SSL協(xié)議本身的缺陷，而是實3233針對SSL的其他攻擊Million-messageattack BleichenbacherD.,"ChosenCiphertextAttacksagainstProtocolsBasedonRSAEncryptionStandardPKCS#1"inAdvancesinCryptology--CRYPTO'98,LNCSvol.1462,pages:1--12,1998.Exportciphersanddistributedcracking舉例：40位RC4，/date/1995/07/msg00052.htmldowngradeattacks往SSL的低版本退化密碼算法的退化33針對SSL的其他攻擊Million-messageat3334MicrosoftIE中SSL/TLS的一個漏洞IE處理內(nèi)嵌在HTTP頁面中的HTTPS對象存在一個漏洞它只檢查HTTPS服務(wù)器的證書是否由可信的CA簽名的，而完全忽略該證書是否有適當?shù)拿郑约笆欠褚呀?jīng)過期。對于當前這個頁面而言，其實并不危險問題在于IE會把這個證書緩存起來，并標記為可信任的，一直到瀏覽器的會話結(jié)束這意味著，假如說，IE客戶在訪問一個HTTP頁面時，如果該頁面被插入一個包含指向有問題的SSLserver的HTTPS對象(比如說一個image)的話，IE不會警告遇到一個非法的證書，只要這個證書確實是被可信CA簽名的34MicrosoftIE中SSL/TLS的一個漏洞IE處3435IE中SSL/TLS的漏洞的情形假如說中間人在服務(wù)器返回的頁面上加上一句話

<imgsrc="/nonexistent.gif"width=1height=1>HTTPS部分顯示的是一個被偷來的或者過期的的證書，這個證書是有效簽名的，但是IE并不檢查證書中的名字和過期情況如果客戶通過HTTPS連接到y(tǒng)oursite網(wǎng)站上，IE將認為這是可信的站點，而不再進一步檢查……參考：ttp:///archives/vulnwatch/2001-q4/0077.html

/archives/vulnwatch/2001-q4/0080.html35IE中SSL/TLS的漏洞的情形假如說中間人在服務(wù)器返回3536電子郵件服務(wù)的協(xié)議電子郵件的服務(wù)靠電子郵件協(xié)議保證。SMTP（simplemailtransferprotocol）：是普遍使用的郵件傳輸協(xié)議。缺點：郵件以明文形式傳輸，不支持圖象等信息；信息容易被捕獲，甚至篡改偽造。后來使用的擴展的ESMTP解決了上面的問題。POP3（postofficeprotocol3）：允許用戶在郵件服務(wù)器上收發(fā)郵件的協(xié)議。在線方式：連接并保持讀取郵件服務(wù)器，郵件保存在服務(wù)器上。離線方式：僅登錄服務(wù)器下載郵件到客戶程序連接，郵件暫時保存在服務(wù)器上。36電子郵件服務(wù)的協(xié)議電子郵件的服務(wù)靠電子郵件協(xié)議保證。3637Outlook中的設(shè)置37Outlook中的設(shè)置3738電子郵件服務(wù)的協(xié)議IMAP4：消息訪問協(xié)議，用戶有選擇接收郵件。允許用戶查詢郵件，先讀取郵箱中的郵件信息頭，然后再決定是否下載。MIME：多用途Internet郵件擴展協(xié)議，傳輸非文本信息的標準。將各種多媒體信息轉(zhuǎn)換城ASCII文本隨郵件一同發(fā)送。38電子郵件服務(wù)的協(xié)議IMAP4：消息訪問協(xié)議，用戶有選擇接3839電子郵件攻擊安全防范竊取電子郵件郵件傳輸采用SMTP協(xié)議，數(shù)據(jù)沒有任何加密。黑客可以在數(shù)據(jù)包經(jīng)由路由器捕獲到信息。防范：首選郵件加密傳輸。電子郵件炸彈指發(fā)件人以不名來歷的電子郵件地址，不斷重復(fù)將電子郵件發(fā)給同一發(fā)件人，由于每個人的信箱容量有限，當龐大的垃圾郵件到達信箱的時候，會擠滿信箱，不能接收正常的郵件。防范：設(shè)置過濾器39電子郵件攻擊安全防范竊取電子郵件3940電子郵件攻擊安全防范電子郵件病毒客戶端軟件自身缺陷。如outlook郵件中的病毒。病毒通過郵件傳輸速度快、范圍廣和破壞力大的特點。防范：郵件掃描。40電子郵件攻擊安全防范電子郵件病毒4041安全電子郵件——S/MIME是對MIME電子郵件格式的安全擴展基于密碼學的諸多成果與PKI的結(jié)合，使用X.509證書，以及PKCS標準算法協(xié)商不可能在線進行，只能用一組規(guī)則保證盡可能地達到安全性不嚴格的信任模型，由客戶實現(xiàn)和用戶來決定S/MIME更象商用或組織使用的工業(yè)標準，PGP更面向個體用戶選用。41安全電子郵件——S/MIME是對MIME電子郵件格式的4142

S/MIME功能提供了簽名和加密消息的功能Envelopeddata：包含郵件加密之后的內(nèi)容，以及針對一個或多個接收者的加密密鑰Signeddata：對簽名內(nèi)容作消息摘要，然后用簽名者的私鑰對摘要加密，以此形成一個數(shù)字簽名；內(nèi)容與簽名被轉(zhuǎn)換成base64編碼，一個簽名的數(shù)據(jù)消息只能被具有S/MIME能力的接收者查看Clear-signeddata：只有簽名部分用base64編碼，結(jié)果是，即使接收者沒有S/MIME能力，他也能查看消息內(nèi)容，只是他不能驗證該簽名Signedandenvelopeddata：簽名和加密的結(jié)合，加密數(shù)據(jù)被簽名或者簽名數(shù)據(jù)被加密42S/MIME功能提供了簽名和加密消息的功能4243PGP(PrettyGoodPrivacy)安全電子郵件系統(tǒng)由個人發(fā)展起來——PhilZimmermann(齊默爾曼)PGP為電子郵件和文件存儲應(yīng)用提供了認證和保密性服務(wù)選擇理想的密碼算法把算法很好地集成到通用應(yīng)用中，獨立于操作系統(tǒng)和微處理器自由發(fā)放，包括文檔、源代碼等與商業(yè)公司(NetworkAssociates)合作，提供一個全面兼容的、低價位的商業(yè)版本PGP歷史1991年推出1.0版，1994年推出2.6版目前最新7.1版算法的專利之爭。困擾了3年多與美國出口管理限制之爭，長達5年的調(diào)查43PGP(PrettyGoodPrivacy)安全電4344PGP版本眾多，包括各種系統(tǒng)平臺，商業(yè)版本使用戶得到很好的支持算法的安全性已經(jīng)得到了充分的論證，如公鑰加密包括RSA、DSS、Diffie-Hellman，單鑰加密包括CAST-128、IDEA、3DES、AES，以及SHA-1散列算法適用性強，公司可以選擇用來增強加密文件和消息，個人可以選擇用來保護自己與外界的通信不是由政府或者標準化組織所控制，可信性44PGP版本眾多，包括各種系統(tǒng)平臺，商業(yè)版本使用戶得到很好4445PGP功能列表為了適應(yīng)郵件的大小限制，PGP支持分段和重組數(shù)據(jù)分段郵件應(yīng)用完全透明，加密后的消息用Radix64轉(zhuǎn)換Radix64郵件兼容性消息用ZIP算法壓縮ZIP壓縮消息用一次性會話密鑰加密，會話密鑰用接收方的公鑰加密CAST或IDEA或3DES、AES及RSA或D-F消息加密用SHA-1創(chuàng)建散列碼，用發(fā)送者的私鑰和DSS或RSA加密消息摘要DSS/SHA或RSA/SHA數(shù)字簽名說明采用算法服務(wù)45PGP功能列表為了適應(yīng)郵件的大小限制，PGP支持分段和重4546PGP——功能：身份認證發(fā)送方產(chǎn)生消息M用SHA-1對M生成一個160位的散列碼H用發(fā)送者的私鑰對H加密，并與M連接接收方用發(fā)送者的公鑰解密并恢復(fù)散列碼H對消息M生成一個新的散列碼，與H比較。如果一致，則消息M被認證。46PGP——功能：身份認證發(fā)送方4647PGP——身份認證說明說明：1.RSA的強度保證了發(fā)送方的身份2.SHA-1的強度保證了簽名的有效性3.DSS/SHA-1可選替代方案。簽名與消息可以分離對消息進行單獨的日志記錄可執(zhí)行程序的簽名記錄，檢查病毒文檔多方簽名，可以避免嵌套簽名47PGP——身份認證說明說明：4748PGP——

保密性發(fā)送方生成消息M并為該消息生成一個隨機數(shù)作為會話密鑰。用會話密鑰加密M用接收者的公鑰加密會話密鑰并與消息M結(jié)合接收方用自己的私鑰解密恢復(fù)會話密鑰用會話密鑰解密恢復(fù)消息M48PGP——保密性發(fā)送方4849PGP——

保密性說明對稱加密算法和公鑰加密算法的結(jié)合可以縮短加密時間用公鑰算法解決了會話密鑰的單向分發(fā)問題不需要專門的會話密鑰交換協(xié)議由于郵件系統(tǒng)的存儲-轉(zhuǎn)發(fā)的特性，用握手方式交換密鑰不太可能每個消息都有自己的一次性密鑰，進一步增強了保密強度。所以，每個密鑰只加密很小部分的明文內(nèi)容49PGP——保密性說明對稱加密算法和公鑰加密算法的結(jié)合4950PGP——保密與認證的結(jié)合兩種服務(wù)都需要時，發(fā)送者先用自己的私鑰簽名，然后用會話密鑰加密消息，再用接收者的公鑰加密會話密鑰。50PGP——保密與認證的結(jié)合兩種服務(wù)都需要時，發(fā)送者先用5051PGP——

郵件數(shù)據(jù)處理順序：簽名——

壓縮——

加密壓縮對郵件傳輸或存儲都有節(jié)省空間的好處。簽名后壓縮的原因：不需要為檢驗簽名而保留壓縮版本的消息為了檢驗而再做壓縮不能保證一致性，壓縮算法的不同實現(xiàn)版本可能會產(chǎn)生不同的結(jié)果壓縮之后再做加密的原因：壓縮后的消息其冗余小，增加密碼分析的難度若先加密，則壓縮難以見效E-mail兼容性PGP處理后的消息，部分或者全部是加密后的消息流，為任意的8位字節(jié)。某些郵件系統(tǒng)只允許ASC字符，所以PGP提供了轉(zhuǎn)換到ASC格式的功能。采用了Radix-64轉(zhuǎn)換方案51PGP——郵件數(shù)據(jù)處理順序：簽名——壓縮——5152PGP——

PGP密鑰PGP使用四種類型的密鑰：一次性會話傳統(tǒng)密鑰公鑰私鑰基于口令短語的傳統(tǒng)密鑰PGP對密鑰的需求會話密鑰：需要一種生成不可預(yù)知的會話密鑰的方法，PGP使用了一種復(fù)雜的隨機密鑰生成算法(一定的真隨機性)公鑰和私鑰需要某種手段來標識具體的密鑰一個用戶擁有多個公鑰/私鑰對密鑰更新管理私鑰如何保存52PGP——PGP密鑰PGP使用四種類型的密鑰：5253PGP——

密鑰標識符和鑰匙環(huán)一個用戶有多個公鑰/私鑰對時，接收者如何知道發(fā)送者是用哪個公鑰來加密會話密鑰的？將公鑰與消息一起傳送。將一個標識符與一個公鑰關(guān)聯(lián)，對一個用戶來說唯一。即用戶ID和密鑰ID標識一個密鑰定義KeyID包括64個有效位(PGP采用公鑰的低64位作為KeyID)鑰匙環(huán)KeyID對于PGP非常關(guān)鍵。PGP消息中包括兩個keyID，分別提供保密與認證功能。需要一種系統(tǒng)化的方法存儲和組織這些密鑰以保證有效使用這些密鑰PGP密鑰管理方案：用戶機器(節(jié)點)上有一對數(shù)據(jù)結(jié)構(gòu)：

私鑰環(huán)：存儲本節(jié)點擁有的公鑰/私鑰對

公鑰環(huán)：存儲本節(jié)點所知道的其他用戶的公鑰53PGP——密鑰標識符和鑰匙環(huán)一個用戶有多個公鑰/私鑰5354PGP——PGP消息的格式(A->B)54PGP——PGP消息的格式(A->B)5455PGP——

私鑰環(huán)信息：時間戳、KeyID、公鑰、私鑰、UserIDUserID：通常是用戶的郵件地址。也可以是一個名字，可以重名私鑰如何保存：用戶選擇一個口令短語用于加密私鑰當系統(tǒng)用RSA生成一個新的公鑰/私鑰對時，要求用戶輸入口令短語。對該短語使用SHA-1生成一個160位的散列碼后，銷毀該短語系統(tǒng)用其中128位作為密鑰用CAST-128加密私鑰，然后銷毀這個散列碼，并將加密后的私鑰存儲到私鑰環(huán)中當用戶要訪問私鑰環(huán)中的私鑰時，必須提供口令短語。PGP將取出加密后的私鑰，生成散列碼，解密私鑰55PGP——私鑰環(huán)信息：5556PGP——公鑰環(huán)信息：時間戳、KeyID、公鑰、對所有者信任度、用戶ID、密鑰合法度、簽名、對簽名者信任度UserID：公鑰的擁有者。多個UserID可以對應(yīng)一個公鑰。公鑰環(huán)可以用UserID或KeyID索引。56PGP——公鑰環(huán)信息：5657PGP——發(fā)送方處理消息的過程簽名：從私鑰環(huán)中得到私鑰，利用userid作為索引PGP提示輸入口令短語，恢復(fù)私鑰構(gòu)造簽名部分加密：PGP產(chǎn)生一個會話密鑰，并加密消息PGP用接收者userid從公鑰環(huán)中獲取其公鑰構(gòu)造消息的會話密鑰部分57PGP——發(fā)送方處理消息的過程簽名：5758PGP——接收方處理消息的過程解密消息PGP用消息的會話密鑰部分中的KeyID作為索引，從私鑰環(huán)中獲取私鑰PGP提示輸入口令短語，恢復(fù)私鑰PGP恢復(fù)會話密鑰，并解密消息驗證消息PGP用消息的簽名部分中的KeyID作為索引，從公鑰環(huán)中獲取發(fā)送者的公鑰PGP恢復(fù)被傳輸過來的消息摘要PGP對于接收到的消息作摘要，并與上一步的結(jié)果作比較58PGP——接收方處理消息的過程解密消息5859PGP——公鑰管理由于PGP重在廣泛地在正式或非正式環(huán)境下的應(yīng)用，所以它沒有建立嚴格的公鑰管理模式。有關(guān)的問題：一旦你的私鑰泄漏，存在兩種危險：別人可以偽造你的簽名其他人發(fā)送給你的保密信件可被別人讀取防止公鑰環(huán)上包含錯誤的公鑰保證公鑰環(huán)上公鑰的正確性物理上得到B的公鑰。可靠，但有一定局限性通過電話驗證公鑰從雙方都信任的個體D處獲得B的公鑰從一個信任的CA中心得到B的公鑰59PGP——公鑰管理由于PGP重在廣泛地在正式或非正式環(huán)5960PGP——公鑰信任模型盡管PGP沒有包含任何建立認證權(quán)威機構(gòu)或建立信任體系的規(guī)范，但它提供了一個利用信任關(guān)系的方法，將信任關(guān)系與公鑰聯(lián)系起來。每個公鑰有三個相關(guān)的屬性：Keylegitimacyfield：合法性或者有效性，表明PGP對“此用戶公鑰是合法的”的信任程度；信任級別越高，這個userID與該公鑰的綁定越強。這個字段是由PGP計算的。每一個公鑰項都有一個或者多個