科學(xué)應(yīng)用層安全協(xié)議高效培訓(xùn)課件

1、科學(xué)應(yīng)用層安全協(xié)議高效培訓(xùn)課件1. 電子郵件安全協(xié)議（PEM、S/MIME、PGP）電子郵件的威脅郵件炸彈郵件欺騙郵件服務(wù)器控制權(quán)電子郵件安全協(xié)議PEM （Privacy Enhanced Email，RFC 1421 through 1424）S/MIMEPGP（Pretty Good Privacy）2電子郵件的安全需求機密性：只有接收者才能閱讀報文的加密：關(guān)鍵是密鑰的分發(fā)收發(fā)雙方如何共享密鑰？認證：發(fā)送者的身份認證基于公鑰技術(shù)，用發(fā)送者的私鑰對報文的摘要進行加密，即數(shù)字簽名基于共享密鑰：事先發(fā)送者與接收者共享一個密鑰，采用消息認證碼（MAC）對報文進行認證完整性：報文未被修改報文的完整性

2、與身份認證的方法類似，通?？稍谝黄疬M行抗否認性：發(fā)信者的不可抵賴性，可供第三方鑒別基于公鑰技術(shù)，采用發(fā)送者的私鑰簽名利用公鑰體制，用接收者的公鑰加密報文。但對于長報文及多個接收者時該怎么辦？發(fā)送者生成一個密鑰，采用對稱密碼算法加密報文，即SM再用接收方的公鑰加密密鑰S，并與加密的報文同時發(fā)送。假設(shè)接收者有A、B、C三人，就分別生成三個加密密鑰KAS，KBS，KCS。3PEM（Privacy Enhanced Mail）PEM協(xié)議是80年代末90年代初發(fā)展起來的，它的功能主要包括加密、源認證和完整性，RFC1421-1424與此同時，出臺了傳輸多種媒體格式的EMAIL標準：MIME（Multip

3、urpose Internet Mail Extensions,RFC2045），而S/MIME（RFC2633）采用了PEM的許多設(shè)計原理在MIME的基礎(chǔ)上進行了擴展4PEM 的構(gòu)成PEM將郵件報文分成幾部分，有的需要加密，有的則需要認證，這些需要特殊處理的報文通過語句標記。例如在需要加密的報文段前插入BEGIN PRIVACY-ENHANCED MESSAGE在需要加密的報文后插入END PRIVACY-ENHANCED MESSAGE報文加密采用DES算法認證采用MD-5密鑰的分發(fā)基于公鑰技術(shù)，用接收者的公鑰加密會話密鑰，并在RFC 1422中定義了證書體系。基于對稱密碼時，采用事先共享

4、的密鑰加密會話密鑰。5 PGP（Pretty Good Privacy）Email安全加密系統(tǒng)PGP提供的安全業(yè)務(wù)：加密：發(fā)信人產(chǎn)生一次性會話密鑰，以IDEA、3-DES或CAST-128算法加密報文，采用RSA或D-H算法用收信人的公鑰加密會話密鑰，并和消息一起送出。認證：用SHA對報文雜湊，并以發(fā)信人的私鑰簽字，簽名算法采用RSA或DSS 。壓縮：ZIP，用于消息的傳送或存儲。在壓縮前簽字，壓縮后加密。兼容性：采用Radix-64可將加密的報文轉(zhuǎn)換成ASCII字符數(shù)據(jù)分段：PGP具有分段和組裝功能6機密性和認證機密性：發(fā)送端產(chǎn)生隨機的128位數(shù)字作為會話密鑰對稱算法加密報文接收端公鑰加密會

5、話密鑰認證采用SHA-1產(chǎn)生160位HASH值用發(fā)送者的私鑰對HASH值簽名報文只需要認證服務(wù)或加密服務(wù)，當(dāng)同時需要認證和加密服務(wù)時采用先簽名，后加密順序（與IPSEC ESP中的先加密，后MAC相反）通常將明文與簽名一起保存比較方便驗證時，不需要涉及會話密鑰7壓縮HASH加密A的公鑰A的私鑰解密對稱密碼加密8壓縮PGP 的壓縮過程在報文的簽名和加密之間，即先對報文簽名，然后壓縮，再是加密簽名后再壓縮是為了保存未壓縮的報文和簽名壓縮后加密是為了提高密碼的安全性，因為壓縮后的報文具有更少的冗余，所以密碼分析會更困難，另外加密的報文也更短壓縮算法采用ZIP9E-mail 的兼容性在多數(shù)的郵件系統(tǒng)中

6、是以ASCII字符形式傳輸，加密后的任意8比特報文可能不符合ASCII字符特點。采用基64轉(zhuǎn)換方式 (see appendix 5B).基64轉(zhuǎn)換方式 的采用將原報文擴展了33%.10分段和重組通常郵件的最大報文的長度限制在50,000 octets.超過標準長度的報文必須分段.PGP 自動對過長的報文分段.接收端再將其重組.11Sumary of PGP Services 1213加密密鑰和密鑰環(huán)PGP使用四種類型的密鑰：一次性會話對稱密鑰，公鑰，私鑰，基于過度階段的傳統(tǒng)密鑰需求需要一種生成不可預(yù)測的會話密鑰需要某種手段來標識具體的密鑰（一個用戶可擁有多個公鑰/私鑰對，以便隨時更換）每個PG

7、P實體需要維護一個保存其公鑰/私鑰對的文件和一個保存通信對方公鑰的文件14密鑰標識符（Key ID）一個用戶有多個公鑰/私鑰對時，接收者如何知道發(fā)送者是用了哪個公鑰來加密會話密鑰將公鑰與消息一起傳送將一個標識符與一個公鑰關(guān)聯(lián)，對一個用戶來說做到一一對應(yīng)定義KeyID 包括64個有效位，(KUa mod 264)15密鑰環(huán)（Key Rings）KeyID在PGP中標識所使用的發(fā)送者和接收者的密鑰號兩個keyID包含在任何PGP消息中提供保密與認證功能需要一種系統(tǒng)化的方法存儲和組織這些key以保證使用PGP在每一個節(jié)點上提供一對數(shù)據(jù)結(jié)構(gòu)存儲該節(jié)點擁有的公鑰/私鑰對私鑰環(huán)存儲本節(jié)點知道的其他用戶的公

8、鑰環(huán)16密鑰對產(chǎn)生時間加了密的私鑰如用戶郵件地址17Format of PGP Message181920公鑰管理PGP雖然采用公鑰密碼體系，但不是證書保護公鑰免受攻擊是PGP的一個問題采用信任關(guān)系保護公鑰21安全協(xié)議的分析與思考認證和加密的次序會話密鑰產(chǎn)生的復(fù)雜度與安全通道的粒度有關(guān)對應(yīng)用層安全來說，由于需求明確，通常采用一次一密，會話密鑰的產(chǎn)生比較簡單對傳輸層安全來說，安全保護的是某個連接。（如SSL協(xié)議，雖然可用于保護所有的應(yīng)用層協(xié)議，但在郵件保護中，由于郵件服務(wù)器到本地的路徑是用POP/MAPI協(xié)議 ，所以需要分段SSL，較為復(fù)雜） 對于網(wǎng)絡(luò)層安全（如IPSEC），安全通道保護的可能是

9、某個數(shù)據(jù)流，也可能是一個端端，也可能是LAN-LAN，因此會話密鑰的生成最為復(fù)雜。對于鏈路層安全來說，安全保護只限于一截鏈路，加密算法和密鑰分發(fā)都不宜復(fù)雜22S/MIMESecure/Multipurpose Internet Mail Extension （安全/多用途Internet郵件擴展，RFC2630、2632、2633）S/MIME 將會成為商業(yè)和機構(gòu)使用的工業(yè)標準.PGP 為個人e-mail 提供安全 23Simple Mail Transfer Protocol (SMTP, RFC 822)SMTP （簡單郵件傳輸協(xié)議）存在的問題:SMTP不能傳輸可執(zhí)行文件和其他二進制碼 (

10、jpeg image)SMTP只能傳輸7-位ASCII字符的文字STMP服務(wù)器拒絕接收超長郵件ASCII 到 EBCDIC 轉(zhuǎn)換問題截取換行超過76字符的行，等等MIME是對RFC 822框架的擴展，致力于解決STMP存在的問題24MIME的頭標MIME的頭標定義了5個新的字段版本（MIME-Version）: 1.0（按照 RFC 2045, RFC 2046定義的規(guī)格）內(nèi)容類型（Content-Type）: 這個字段用于詳細描述主體的數(shù)據(jù)內(nèi)容傳輸編碼（Content-Transfer-Encoding）: 內(nèi)容采用的編碼方案 (如radix-64)內(nèi)容ID（Content-ID）: 該字段

11、主要用于多個上下文時，對MIME實體的標識.內(nèi)容描述（Content Description）: 對內(nèi)容的文本描述 (e.g.,mpeg)25S/MIME 功能在功能上，S/MIME與PGP相似，通過使用簽名、加密或簽名/加密的組合來保證MIME通信的安全，但強化了證書的規(guī)范S/MIME的安全功能：封裝的數(shù)據(jù): 加密的內(nèi)容和加密的會話密鑰簽名的數(shù)據(jù): 報文摘要發(fā)送者的私鑰簽名，然后使用基64變換編碼內(nèi)容和簽名透明簽名: 簽名但不加密.只對簽名進行基64變換，這樣具有MIME支持而沒有S/MIME權(quán)能的接收者也能讀取簽名和封裝的數(shù)據(jù): 各種不同嵌套順序?qū)?shù)據(jù)加密、簽名，如簽名加密的數(shù)據(jù)或加密簽名

12、的數(shù)據(jù)S/MIME使用X.509證書，它的密鑰管理方案介于嚴格的X.509證書層次結(jié)構(gòu)和PGP信任網(wǎng)26Algorithms Used報文摘要: SHA-1 and MD5數(shù)字簽名: DSS對稱密碼算法: Triple-DES, RC2/40 (exportable)公鑰密碼算法: RSA with key sizes of 512 and 1024 bits, and Diffie-Hellman (for session keys).27PGP vsPEM、S/MIMEItemPGPPEM or S/MIMESupports encryption?YesYesSupports authen

13、ticationYesYesSupports non-repudiation?YesYesSupports compression?YesNoSupports mailing lists?NoYesUses base64 coding?YesYesCurrent data encryption algorithmIDEADESKey length for data encryption (bits)12856Current algorithm for key managementRSARSA/D-HKey length for key management (bits)?384/512/102

14、4VariableUser name spaceUser definedX.400X.509 conformant?NoYesCan eavesdropper read messages?NoNoCan eavesdropper read signatures?NoYesInternet Standard?YesYes282. 遠程登錄安全協(xié)議SSH: Secure SHellSSH主要由芬蘭赫爾辛基大學(xué)的Tatu Ylonen開發(fā)的，它提供一條安全的遠程登錄通道，可以代替telnet, rlogin等。由于受版權(quán)和加密算法的限制，很多人都使用它的免費替代產(chǎn)品OpenSSH。SSH協(xié)議有版本1

15、（SSHv1）和版本2（SSHv2），這兩版本互不兼容，目前SSH協(xié)議只有草案（2002，9），由IETF的SECSH工作組規(guī)范，還沒有形成RFC。29SSH的體系SSH傳輸層(Transport Layer)協(xié)議提供服務(wù)器主機認證，提供數(shù)據(jù)加密，提供數(shù)據(jù)完整性支持 SSH認證(Authentication)協(xié)議為服務(wù)器提供用戶的身份認證Secure FTP SSH連接（Connection）協(xié)議將加密的信息隧道復(fù)用成若干個邏輯通道，提供給高層的應(yīng)用協(xié)議使用。SSH Transport Layer ProtocolSFTPConnectionProtocolAuthenticationProtocol30SSH采用的認證、加密算法Supported authentication methodsX509 CertificatesPublic keysPasswordsSupported encryption algorithms3DESBlowfishArcfourCastSupported hash algorithmsSHA1MD5313Web安全協(xié)議（S-HTTP）32S-HTTP采用的認證、加密算法單向哈希函數(shù)MD2，