【文章內(nèi)容簡介】 成為 OpenSSL的指令。OpenSSL的應(yīng)用程序主要包括密鑰生成、證書管理、格式轉(zhuǎn)換、數(shù)據(jù)加密和簽名、 SSL測試以及其它輔助配置功能。2023/2/27星期六 47Ch7網(wǎng)絡(luò)安全協(xié)議? ? Engine機制的出現(xiàn)是在 OpenSSL的 ，開始的時候是將普通版本跟支持 Engine的版本分開的，到了OpenSSL的 ， Engine機制集成到了 OpenSSL的內(nèi)核中，成為了 OpenSSL不可缺少的一部分。 Engine機制目的是為了使 OpenSSL能夠透明地使用第三方提供的軟件加密庫或者硬件加密設(shè)備進行加密。 OpenSSL的 Engine機制成功地達到了這個目的，這使得 OpenSSL已經(jīng)不僅僅使一個加密庫，而是提供了一個通用地加密接口，能夠與絕大部分加密庫或者加密設(shè)備協(xié)調(diào)工作。當然，要使特定加密庫或加密設(shè)備更 OpenSSL協(xié)調(diào)工作，需要寫少量的接口代碼，但是這樣的工作量并不大，雖然還是需要一點密碼學(xué)的知識。 Engine機制的功能跟 Windows提供的 CSP功能目標是基本相同的。目前， OpenSSL的 嵌第三方加密設(shè)備有 8種，包括： CryptoSwift、 nCipher、Atalla、 Nuron、 UBSEC、 Aep、 SureWare以及 IBM4758CCA的硬件加密設(shè)備?，F(xiàn)在還出現(xiàn)了支持 PKCS11接口的Engine接口，支持微軟 CryptoAPI的接口也有人進行開發(fā)。當然，所有上述 Engine接口支持不一定很全面，比如，可能支持其中一兩種公開密鑰算法。2023/2/27星期六 48Ch7網(wǎng)絡(luò)安全協(xié)議? ? BIO機制是 OpenSSL提供的一種高層 IO接口，該接口封裝了幾乎所有類型的 IO接口，如內(nèi)存訪問、文件訪問以及Socket等。這使得代碼的重用性大幅度提高， OpenSSL提供 API的復(fù)雜性也降低了很多。? OpenSSL對于隨機數(shù)的生成和管理也提供了一整套的解決方法和支持 API函數(shù)。隨機數(shù)的好壞是決定一個密鑰是否安全的重要前提。? OpenSSL還提供了其它的一些輔助功能，如從口令生成密鑰的 API， 證書簽發(fā)和管理中的配置文件機制等等。2023/2/27星期六 49Ch7網(wǎng)絡(luò)安全協(xié)議IPSec協(xié)議 由于協(xié)議 IPv4最初設(shè)計時沒有過多地考慮安全性，缺乏對通信雙方真實身份的驗證能力，缺乏對網(wǎng)上傳輸?shù)臄?shù)據(jù)的完整性和機密性保護，并且由于 IP地址可軟件配置等靈活性以及基于源 IP地址的認證機制，使 IP層存在著網(wǎng)絡(luò)業(yè)務(wù)流易被監(jiān)聽和捕獲、 IP地址欺騙、信息泄漏和數(shù)據(jù)項被篡改等多種攻擊，而 IP是很難抵抗這些攻擊的。 為了實現(xiàn)安全 IP， 因特網(wǎng)工程任務(wù)組 IETF于1994年開始了一項 IP安全工程，專門成立了 IP安全協(xié)議工作組 IPSEC， 來制定和推動一套稱為IPSec的 IP安全協(xié)議標準。 2023/2/27星期六 50Ch7網(wǎng)絡(luò)安全協(xié)議IPSec協(xié)議組? 網(wǎng)絡(luò)認證協(xié)議 Authentication Header（ AH）? 封裝安全載荷協(xié)議 Encapsulating Security Payload（ ESP）? 密鑰管理協(xié)議 Inter Key Exchange （ IKE）? 網(wǎng)絡(luò)認證及加密算法 2023/2/27星期六 51Ch7網(wǎng)絡(luò)安全協(xié)議 IPSec安全體系結(jié)構(gòu)圖 IPSec安全體系結(jié)構(gòu) IPSec體系結(jié)構(gòu)ESP協(xié)議 AH協(xié)議加密算法DOI解釋域密鑰管理認證算法2023/2/27星期六 52Ch7網(wǎng)絡(luò)安全協(xié)議? ESP協(xié)議規(guī)定了為通信提供機密性和完整性保護的具體方案，包括 ESP載荷的格式、語義、取值以及對進入分組和外出分組的處理過程等。? DOI〔 Interpretation of Domain， DOI〕 規(guī)定了每個算法的參數(shù)要求和計算規(guī)則，如算法的密鑰長度要求、算法強度要求以及初始向量的計算規(guī)則等。? AH協(xié)議定義了認證的應(yīng)用方法，提供數(shù)據(jù)源認證和完整性保證。? IKE協(xié)議是 IPSec目前唯一的正式確定的密別交換協(xié)議，為 AH和 ESP提供密鑰交換支持，同時也支持其他機制，如密鑰協(xié)商。 2023/2/27星期六 53Ch7網(wǎng)絡(luò)安全協(xié)議安全關(guān)聯(lián)（ Security Association， SA） 為了正確封裝及提取 IPSec數(shù)據(jù)包，有必要采取一套專門的方案，將安全服務(wù) /密鑰與要保護的通信數(shù)據(jù)聯(lián)系到一起；同時要將遠程通信實體與要交換密鑰的 IPSec數(shù)據(jù)傳輸聯(lián)系到一起。換言之，要解決如何保護通信數(shù)據(jù)、保護什么樣的通信數(shù)據(jù)以及由誰來實行保護的問題。這樣的構(gòu)建方案稱為安全關(guān)聯(lián)（ Security Association， SA）。 2023/2/27星期六 54Ch7網(wǎng)絡(luò)安全協(xié)議 SA是單向的，要么對數(shù)據(jù)包進行 “進入 ” 保護，要么進行 “ 外出 ” 保護。也就是說，在一次通信中， IPSec 需要建立兩個 SA， 一個用于入站通信，另一個用于出站通信。 若某臺主機，如文件服務(wù)器或遠程訪問服務(wù)器，需要同時與多臺客戶機通信，則該服務(wù)器需要與每臺客戶機分別建立不同的 SA。 2023/2/27星期六 55Ch7網(wǎng)絡(luò)安全協(xié)議 AH（ Authentication Header） 協(xié)議 AH協(xié)議規(guī)定了 AH頭在 AH實現(xiàn)中應(yīng)插入 IP頭的位置、 AH頭的語法格式、各字段的語義及取值方式，以及實施 AH時進入和外出分組的處理過程。 AH機制涉及到密碼學(xué)中的核心組件 —— 鑒別算法。 ? AH的功能? AH的兩種模式? AH的格式 ? 認證算法2023/2/27星期六 56Ch7網(wǎng)絡(luò)安全協(xié)議AH的功能 AH協(xié)議為 IP通信提供數(shù)據(jù)源認證、數(shù)據(jù)完整性和反重播保證，它能保護通信免受篡改，但不能防止竊聽，適合用于傳輸非機密數(shù)據(jù)。 AH的工作原理是在每一個數(shù)據(jù)包上添加一個身份驗證報頭。此報頭包含一個帶密鑰的 hash散列（可以將其當作數(shù)字簽名，只是它不使用證書），此hash散列在整個數(shù)據(jù)包中計算，因此對數(shù)據(jù)的任何更改將致使散列無效 —— 這樣就提供了完整性保護。 AH不能提供加密服務(wù)，這就意味著分組將以明文的形式傳送。由于 AH的速度比 ESP稍微快一點，因此僅當需要確保分組的源和完整性而不考慮機密性的時候，可以選擇使用 AH。 2023/2/27星期六 57Ch7網(wǎng)絡(luò)安全協(xié)議AH的兩種模式 ? 傳輸模式 ：傳輸模式用于兩臺主機之間，只對上層協(xié)議數(shù)據(jù)（傳輸層數(shù)據(jù)）和 IP頭中的固定字段提供認證，主要保護傳輸層協(xié)議頭，實現(xiàn)端到端的安全；? 隧道模式 ：隧道模式對整個 IP數(shù)據(jù)項提供認證保護，把需要保護的 IP包封裝在新的 IP包中，既可用于主機也可用于安全網(wǎng)關(guān)，并且當 AH在安全網(wǎng)關(guān)上實現(xiàn)時，必須采用隧道模式。 2023/2/27星期六 58Ch7網(wǎng)絡(luò)安全協(xié)議AH的兩種模式 2023/2/27星期六 59Ch7網(wǎng)絡(luò)安全協(xié)議AH的格式 圖 AH報頭格式 下一個報頭長度 安全參數(shù)索引(SPI)序列號 認證數(shù)據(jù)(hash檢查和 )AH報頭2023/2/27星期六 60Ch7網(wǎng)絡(luò)安全協(xié)議? Next Header（ 下一個報頭，占 8字節(jié)）：識別下一個使用 IP協(xié)議號的報頭，例如， Next Header值等于 6時，表示緊接其后的是 TCP報頭。對于 UDP， 它的值將是 17。? Length（ 長度，占 8字節(jié)）： AH報頭長度。? Security Parameters Index (SPI， 安全參數(shù)索引，占 32字節(jié) )： 這是一個為數(shù)據(jù)報識別安全關(guān)聯(lián)的 32 位偽隨機值。其中， SPI 值 0 被保留，用來表明 “ 沒有安全關(guān)聯(lián)存在 ” 。2023/2/27星期六 61Ch7網(wǎng)絡(luò)安全協(xié)議? Sequence Number（ 序列號，占 32字節(jié)）：這是一個無符號單調(diào)遞增的計數(shù)器，從 1開始的 32位單增序列號，不允許重復(fù)，唯一地標識了每一個發(fā)送數(shù)據(jù)包，為安全關(guān)聯(lián)提供反重播保護。接收端校驗序列號為該字段值的數(shù)據(jù)包是否已經(jīng)被接收過，若是，則拒收該數(shù)據(jù)包。對于一個特定的 SA，它實現(xiàn)反重傳服務(wù)。這些信息不被接收對等實體使用，但是發(fā)送方必須包含這些信息。當建立一個 SA時，這個值被初始化為 0。如果使用反重傳服務(wù)重傳，那么這個值決不允許重復(fù)。由于發(fā)送方并不知道接受方是否使用了反重傳功能，該字段中的值不能被重復(fù)的事實就要求終止 SA， 并且在傳送第 23個分組之前建立一個新的 SA。2023/2/27星期六 62Ch7網(wǎng)絡(luò)安全協(xié)議? Authentication Data（ AD， 認證數(shù)據(jù)，可變長）：包含完整性檢查和。接收端接收數(shù)據(jù)包后，首先執(zhí)行 hash計算，再與發(fā)送端所計算的該字段值比較，若兩者相等，表示數(shù)據(jù)完整，若在傳輸過程中數(shù)據(jù)遭修改，兩個計算結(jié)果不一致，則丟棄該數(shù)據(jù)包。通過這個值，通信雙方能實現(xiàn)對數(shù)據(jù)的完整性保護、分組級數(shù)據(jù)源鑒別以及通信的抗重放攻擊。 2023/2/27星期六 63Ch7網(wǎng)絡(luò)安全協(xié)議認證算法 用于計算完整性校驗值 (ICV)的認證算法由 SA指定，對于點到點通信，合適的認證算法包括基于對稱密碼算法 (如 DES)或基于單向 Hash函數(shù) (如MD5或 SHA1)的帶密鑰的消息認證碼 (MAC)。 2023/2/27星期六 64Ch7網(wǎng)絡(luò)安全協(xié)議 ESP（ Encapsulating Security Payload） 協(xié)議 ESP涉及到密碼學(xué)中的核心組件 —— 加密和鑒別算法。 ? ESP的功能 ? ESP的兩種模式 ? ESP的格式 ? 加密算法和認證算法 ? ESP處理 2023/2/27星期六 65Ch7網(wǎng)絡(luò)安全協(xié)議ESP的功能 ESP為 IP數(shù)據(jù)包提供完整性檢查、認證和加密，可以看作是 “ 超級 AH” ， 因為它提供機密性并可防止篡改。 ESP服務(wù)依據(jù)建立的安全關(guān)聯(lián)（ SA） 是可選的。? 一些限制： 完整性檢查和認證一起進行。 僅當與完整性檢查和認證一起時， “ 重播（ Replay） ” 保護才是可選的。 “ 重播 ” 保護只能由接收方選擇。 ESP的加密服務(wù)是可選的，但如果啟用加密，則也就同時選擇了完整性檢查和認證。因為如果僅使用加密，入侵者就可能偽造包以發(fā)動密碼分析攻擊。 ESP可以單獨使用，也可以和 AH結(jié)合使用。 2023/2/27星期六 66Ch7網(wǎng)絡(luò)安全協(xié)議ESP的兩種模式 2023/2/27星期六 67Ch7網(wǎng)絡(luò)安全協(xié)議ESP的格式 ESP協(xié)議包括 ESP報頭、 ESP報尾、 ESP認證報尾三個部分。 圖 ESP報頭、報尾和認證報尾 2023/2/27星期六 68Ch7網(wǎng)絡(luò)安全協(xié)議加密算法和認證算法 ESP所采用的加密算法由 SA指定。為了提高加密效率， ESP設(shè)計使用的是對稱密碼算法。由于 IP包可能會失序到達，因此每個 IP包必須攜帶接收者進行解密所要求的密碼同步數(shù)據(jù) (如初始化向量IV)。 這個數(shù)據(jù)可以在有效負載字段中明確攜帶，也可以從包頭中推導(dǎo)出來。由于機密性是可選擇的，因此加密算法可以是 “ 空 ” 。 ESP中的認證算法同 AH的認證算法一樣。由于認證算法是可選的，因此認證算法也可以是 “ 空” 。雖然加密和認證算法都可為空，但二者不能同時為空。因為這樣做不僅毫無安全保證可言，而且也為系統(tǒng)帶來了無謂的負擔(dān)。 2023/2/27星期六 69Ch7網(wǎng)絡(luò)安全協(xié)議ESP處理 ESP 的處理過程發(fā)生在發(fā)送時的 IP分割之前以及接受時的 IP重新組合之后。? 發(fā)送時的處理① ESP頭定位：在傳輸模式下， ESP頭插在 IP頭和上一層協(xié)議頭之間；在隧道模式下， ESP頭在整個源 IP數(shù)據(jù)項之前。② 查找：只有當與此會話相關(guān)的有效的 SA存在時，才進行 ESP處理。③ 包加密：把數(shù)據(jù)封裝到 ESP的有效負載字段，在傳輸模式下，只封裝上層協(xié)議數(shù)據(jù)；在隧道模式下、封裝整個原 IP數(shù)據(jù)項。應(yīng)使用由 SA指定的密鑰和加密算法對上述結(jié)果加密。2023/2/27星期六 70Ch7網(wǎng)絡(luò)安全協(xié)議? 接受時的處理過程 當接收方收到一個 IP數(shù)據(jù)項時，先根據(jù)包中目的 IP地址、安全協(xié)議 ESP和 SPI查找 SA， 若沒有用于此會話的 SA存在，則接收者必須丟棄此包，并記入日志，否則就按 SA中指定的算法進行解密并重新構(gòu)造原 IP數(shù)據(jù)項格式。 2023/2/27星期六 71Ch7網(wǎng)絡(luò)安全協(xié)議IKE（ InterKeyExchange） 協(xié)議 ? IKE主要完成兩個作用：① 安全關(guān)聯(lián)的集中化管理，減少連接時間；② 密鑰的生成和管理。 ? IKE協(xié)議是 IPSec目前唯一的正式確定的密鑰交換協(xié)議，它為 AH和 ESP提供密鑰交換支持，同時也支持其他機制，加密鑰協(xié)商。 ? IKE是由另外三種協(xié)議（ ISAKMP、 Oakley 和 SKEME） 混合而成的一種協(xié)議。 2023/2/27星期六 72Ch7網(wǎng)絡(luò)安全協(xié)議 PGP——Pretty Good Privacy(相當好的保密)是由 MIT的 ，主要用于安全電子郵件，它可以對通過網(wǎng)絡(luò)進行傳輸?shù)臄?shù)據(jù)創(chuàng)建和檢驗數(shù)字簽名、加密、解密以及壓縮。 PGP2023/2