通信協(xié)議分析-7-安全協(xié)議之配置與實現(xiàn)缺陷

第七章協(xié)議配置與實現(xiàn)層安全2017年春季學(xué)期主要內(nèi)容7.1協(xié)議架構(gòu)7.2配置層安全7.3實現(xiàn)層安全7.4協(xié)議安全性分析方法7.5SSL/TLS的前世今生7.6問題與未來之路7.7課程總結(jié)chaofeng@7.1協(xié)議架構(gòu)一個協(xié)議的完整應(yīng)用包含三個層次：1、協(xié)議規(guī)范2、協(xié)議配置3、協(xié)議實現(xiàn)7.1協(xié)議架構(gòu)1、協(xié)議規(guī)范定義協(xié)議的邏輯描述：協(xié)議方、時序關(guān)系、消息格式、密碼算法的使用方法等雙方、三方認(rèn)證協(xié)議、密鑰交換協(xié)議對稱加密算法、非對稱加密算法、散列算法等7.1協(xié)議架構(gòu)1、協(xié)議規(guī)范密碼算法包含多種類別：對稱加密算法、公鑰加密算法、散列算法、數(shù)字簽名算法—密碼學(xué)原語每種類別還包含多個算法：對稱加密算法（DES、3DES、AES…）、非對稱加密算法（RSA、橢圓曲線…）、散列算法（MD5、SHA-1…）、數(shù)字簽名算法（DSA…）7.1協(xié)議架構(gòu)1、協(xié)議規(guī)范只關(guān)心到密碼原語級別，不關(guān)心密碼算法具體的使用問題將密碼算法當(dāng)黑盒對待—是不可破解的使研究人員盡可能將精力集中在協(xié)議的邏輯安全性上7.1協(xié)議架構(gòu)2、協(xié)議配置關(guān)注關(guān)心密碼算法是如何使用的算法選擇--使用3DES還是AES還是IDEA？密鑰多長—密鑰越長越好，但多長為好？密碼算法的使用模式—ECB?CBC?OFB?密碼算法如何與別的算法結(jié)合使用—與異或算法如何結(jié)合使用、與CRC32算法如何結(jié)合使用？7.1協(xié)議架構(gòu)3、協(xié)議實現(xiàn)關(guān)注協(xié)議的軟件/硬件實現(xiàn)形式采用什么編程語言—C/C++/.NET/Java/Python?如何定義各種數(shù)據(jù)結(jié)構(gòu)？…7.1協(xié)議架構(gòu)4、案例SSL/TLS協(xié)議規(guī)范&配置層RFC2246(TLS1.0)、RFC5246(TLS1.3)機(jī)密性：DES、3DES、IDEA、RC2、RC4完整性：MD5、SHA-17.1協(xié)議架構(gòu)4、案例SSL/TLS協(xié)議規(guī)范&配置層ApplicationlayerprotocolSSLhandshakeprotocolSSLChangecipherspecprotocolSSLAlertprotocolSSLrecordprotocolTCPIP7.1協(xié)議架構(gòu)4、案例SSL/TLS協(xié)議實現(xiàn)層OpenSSL--非常流行的開源SSL/TLS實現(xiàn)JSSE--Java實現(xiàn)的，支持SSL3.0，TLS1.0/1.1/1.2BouncyCastle—密碼學(xué)庫，Android主要使用GnuTLS—C語言實現(xiàn)，Unix中廣泛使用NSS—最初由網(wǎng)景公司開發(fā)，F(xiàn)ireFox和Chrome使用7.1協(xié)議架構(gòu)4、案例SSL/TLS協(xié)議實現(xiàn)層7.2配置層安全配置層主要關(guān)心選擇何種密碼算法、密碼算法的使用模式以及密碼算法與其他算法結(jié)合使用的問題。設(shè)計人員需要深入分析同種密碼原語中不同密碼算法的特點，根據(jù)需求選擇合適的密碼算法，設(shè)計合適的用法分析人員需針對使用的密碼算法，采用不同的分析方法，分析協(xié)議的安全性。7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法非對稱加密算法消息完整性算法數(shù)字簽名算法7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法—安全性包含兩個部分ENC(m,k)、DEC(c,k)DEC(ENC(m,k),k)==m7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法—安全性什么樣的對稱加密算法才叫安全？有明確定義嗎？7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法—安全性ENCDECk攻擊者queryqueryoutput7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法—安全性幾種攻擊模型：選擇明文攻擊（CPA）：攻擊者能夠自由的選擇明文，獲取這些明文對應(yīng)的密文選擇密文攻擊（CCA）：攻擊者能夠自由的選擇密文，獲取這些密文對應(yīng)的明文7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法—安全性對稱密碼算法的幾種安全屬性不可區(qū)分性(IND)密文不會向任何計算能力為多項式有界的敵手泄漏有關(guān)相應(yīng)明文的任何有用信息7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法—安全性對稱密碼算法的幾種安全屬性明文完整性（INT-PTXT）攻擊者不能產(chǎn)生一個有效的密文，其解密產(chǎn)生的明文從未被加密過。7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法—安全性對稱密碼算法的幾種安全屬性密文完整性（INT-CTXT）攻擊者不能產(chǎn)生一個發(fā)送者未發(fā)送過的有效密文—不論這密文對應(yīng)的明文是否是新的7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別對稱加密算法使用模式問題7.2配置層安全7.2.1密碼原語的安全級別消息認(rèn)證碼包含兩部分：MAC(m,k)、VER(m,mac,k)VER(m,MAC(m,k),k)==TRUE7.2配置層安全7.2.1密碼原語的安全級別消息認(rèn)證碼安全定義：Let’splayagame7.2配置層安全7.2.1密碼原語的安全級別消息認(rèn)證碼安全定義：Let’splayagameMACVERk攻擊者queryqueryoutput7.2配置層安全7.2.1密碼原語的安全級別消息認(rèn)證碼不可偽造性（UF-CMA）強(qiáng)不可偽造性（SUF-CMA）7.3實現(xiàn)層安全Q:協(xié)議沒有邏輯問題了，密碼算法使用了安全了，還會有缺陷嗎？A:NO!協(xié)議的實現(xiàn)形式—軟件或硬件也會帶來問題，疊加產(chǎn)生新的問題7.4協(xié)議安全性分析方法7.4.1安全驗證方法假設(shè)密碼算法完善安全性只有擁有密鑰，才能進(jìn)行對于的密碼操作考慮攻擊者對通信網(wǎng)絡(luò)的控制能力截獲、修改、重發(fā)、發(fā)送消息使用已有密鑰對消息加解密

對協(xié)議協(xié)議的控制能力作為內(nèi)部人，攻擊其他實體符號方法7.4協(xié)議安全性分析方法7.4.1安全驗證方法7.4協(xié)議安全性分析方法7.4.1安全驗證方法自動驗證工具Proverif、Athena、AVISPA優(yōu)點：自動化強(qiáng)缺點：假設(shè)條件強(qiáng)，結(jié)論不一定可靠符號方法RSA加密：C=MemodnC1=M1emodnC2=M2emodnC1*C2=(M1*M2)emodn7.4協(xié)議安全性分析方法7.4.1安全驗證方法密碼算法并不完善可以存在不同的安全級別任意多項式時間計算能力對消息進(jìn)行任意變形、猜解密鑰等計算方法7.4協(xié)議安全性分析方法7.4.1安全驗證方法7.4協(xié)議安全性分析方法7.4.2存在的問題要想對大型協(xié)議自動驗證，用符號方法要想得到可靠的結(jié)論，用計算方法

理想很豐滿，現(xiàn)實很骨感！7.4協(xié)議安全性分析方法7.4.2存在的問題7.5SSL/TLS的前世今生REF：

[1] H.Krawczyk,K.G.Paterson,andH.Wee,“OnthesecurityoftheTLSprotocol:Asystematicanalysis,”inAdvancesinCryptology–CRYPTO2013,Springer,2013,pp.429–448.

[2].Gossip

on

SSL

Security7.5SSL/TLS的前世今生7.5.1SSL/TLS簡介SSL全稱是SecureSocketsLayer，安全套接字層，它是由網(wǎng)景公司（Netscape）設(shè)計的主要用于Web的安全傳輸協(xié)議，目的是為網(wǎng)絡(luò)通信提供機(jī)密性、認(rèn)證性及數(shù)據(jù)完整性保障。如今，SSL已經(jīng)成為互聯(lián)網(wǎng)保密通信的工業(yè)標(biāo)準(zhǔn)。SSL最初的幾個版本（SSL1.0、SSL2.0、SSL3.0）由網(wǎng)景公司設(shè)計和維護(hù)，從3.1版本開始，SSL協(xié)議由因特網(wǎng)工程任務(wù)小組（IETF）正式接管，并更名為TLS（TransportLayerSecurity），發(fā)展至今已有TLS1.0、TLS1.1、TLS1.2這幾個版本。7.5SSL/TLS的前世今生7.5.1SSL/TLS簡介

7.5SSL/TLS的前世今生7.5.1SSL/TLS簡介如TLS名字所說，SSL/TLS協(xié)議僅保障傳輸層安全。同時，由于協(xié)議自身特性（數(shù)字證書機(jī)制），SSL/TLS不能被用于保護(hù)多跳（multi-hop）端到端通信，而只能保護(hù)點到點通信。SSL/TLS協(xié)議能夠提供的安全目標(biāo)主要包括如下幾個：認(rèn)證性——借助數(shù)字證書認(rèn)證服務(wù)器端和客戶端身份，防止身份偽造機(jī)密性——借助加密防止第三方竊聽完整性——借助消息認(rèn)證碼（MAC）保障數(shù)據(jù)完整性，防止消息篡改重放保護(hù)——通過使用隱式序列號防止重放攻擊7.5SSL/TLS的前世今生7.5.1SSL/TLS簡介SSL/TLS協(xié)議有一個高度模塊化的架構(gòu)，分為很多子協(xié)議:Handshake協(xié)議：包括協(xié)商安全參數(shù)和密碼套件、服務(wù)器身份認(rèn)證（客戶端身份認(rèn)證可選）、密鑰交換；ChangeCipherSpec協(xié)議：一條消息表明握手協(xié)議已經(jīng)完成；Alert協(xié)議：對握手協(xié)議中一些異常的錯誤提醒，分為fatal和warning兩個級別，fatal類型的錯誤會直接中斷SSL鏈接，而warning級別的錯誤SSL鏈接仍可繼續(xù)，只是會給出錯誤警告；Record協(xié)議：包括對消息的分段、壓縮、消息認(rèn)證和完整性保護(hù)、加密等。7.5SSL/TLS的前世今生7.5.2協(xié)議流程一個典型的TLS1.0協(xié)議交互流程如下圖所示：每一個SSL/TLS鏈接都是從握手開始的，握手過程包含一個消息序列，用以協(xié)商安全參數(shù)、密碼套件，進(jìn)行身份認(rèn)證以及密鑰交換。握手過程中的消息必須嚴(yán)格按照預(yù)先定義的順序發(fā)生，否則就會帶來潛在的安全威脅。7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列ClientHello：ClientHello通常是握手過程中的第一條消息，用于告知服務(wù)器客戶端所支持的密碼套件種類、最高SSL/TLS協(xié)議版本以及壓縮算法。ClientHello中還包含一個隨機(jī)數(shù)，這個隨機(jī)數(shù)由4個字節(jié)的當(dāng)前GMTUNIX時間以及28個隨機(jī)選擇的字節(jié)組成，共32字節(jié)。該隨機(jī)數(shù)會在密鑰生成過程中被使用。另外，ClientHello中還可能包含客戶端支持的TLS擴(kuò)展。（TLS擴(kuò)展可以被用來豐富TLS協(xié)議的功能或者增強(qiáng)協(xié)議的安全性）7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列ServerHello：服務(wù)器接受到ClientHello后，會返回ServerHello。服務(wù)器從客戶端在ClientHello中提供的密碼套件、SSL/TLS版本、壓縮算法列表里選擇它所支持的項，并把它的選擇包含在ServerHello中告知客戶端。接下來SSL協(xié)議的建立就基于服務(wù)器選擇的密碼套件類型、SSL/TLS協(xié)議版本以及壓縮算法。ServerHello中同樣會包含一個隨機(jī)數(shù)，同樣4+28字節(jié)類型，由服務(wù)器生成7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列Certificate：客戶端和服務(wù)器都可以發(fā)送證書消息來證明自己的身份，但是通?？蛻舳俗C書不被使用。服務(wù)器一般在ServerHello后會接一條Certificate消息，Certificate消息中會包含一條證書鏈，從服務(wù)器證書開始，到Certificateauthority（CA）或者最新的自簽名證書結(jié)束。7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列下圖描述了一個典型的證書鏈：7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列SSL中使用的證書通常是X.509類型證書，X.509證書的內(nèi)容如下：在用的X.509證書包含Version1和Version3兩種版本，其中v1版本的證書存在安全隱患，同時不支持TLS擴(kuò)展，被逐漸棄用?，F(xiàn)在大多數(shù)在用的SSL證書都是V3版本。7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列同時證書會附帶與協(xié)商好的密鑰交換算法對應(yīng)的密鑰。密鑰交換算法以及它們所要求的密鑰類型如下表所示。7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列ServerKeyExchange：該消息僅當(dāng)以下密鑰交換算法被使用時由服務(wù)器發(fā)出：RSA_EXPORT（僅當(dāng)服務(wù)器的公鑰大于512bit時）、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon使用其它密鑰交換算法時，服務(wù)器不能發(fā)送此消息。ServerkeyExchange消息會攜帶這些密鑰交換算法所需要的額外參數(shù)，以在后續(xù)步驟中協(xié)商PreMasterSecret。這些參數(shù)需要被簽過名。7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列CertificateRequest：這個消息通常在要求認(rèn)證客戶端身份時才會有。消息中包含了證書類型以及可接受的CA列表。ServerHelloDone：服務(wù)器發(fā)送這條消息表明服務(wù)器部分的密鑰交換信息已經(jīng)發(fā)送完了，等待客戶端的消息以繼續(xù)接下來的步驟。這條消息只用作提醒，不包含數(shù)據(jù)域。7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列ClientKeyExchange：這條消息包含的數(shù)據(jù)與所選用的密鑰交換算法有關(guān)。如果選擇的密鑰交換算法是RSA，那么消息包含的參數(shù)為用服務(wù)器RSA公鑰（包含在之前證書中的或者是ServerKeyExchange中的）加密過的PreMasterSecret，它有48個字節(jié)，前2個字節(jié)表示客戶端支持的最高協(xié)議版本，后46個字節(jié)是隨機(jī)選擇的。如果選擇的密鑰交換算法是DH或者DHE，則可能有兩種情況：隱式DH公開值：包含在Certificate消息里；顯示DH公開值：公開值是本消息的一部分。7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列CertificateVerify：這條消息用來證明客戶端擁有之前提交的客戶端證書的私鑰。7.5SSL/TLS的前世今生7.5.2協(xié)議流程1）握手過程中的消息序列Finished：表明握手階段結(jié)束。這是第一條用協(xié)商的算法和密鑰保護(hù)的消息。因為是用協(xié)商好的密鑰加密的消息，它可以用來確認(rèn)已經(jīng)協(xié)商好的密鑰。同時Finished消息包含一個verify_data域，可以用來校驗之前發(fā)送和接收的信息。Verify_data域是一個PRF函數(shù)的輸出（pseudo-randomfunction）。這個偽隨機(jī)函數(shù)的輸入為：（1）兩個hash值：一個SHA-1，一個MD5，對之前握手過程中交換的所有消息做哈希；（2）theMasterSecret，由預(yù)備主密鑰生成；（3）finished_label，如果客戶端發(fā)送的則是”clientfinished”，服務(wù)器發(fā)送的則是”serverfinished”。此外，F(xiàn)inished消息不能夠在ChangeCipherSpec前發(fā)送。7.5SSL/TLS的前世今生7.5.2協(xié)議流程2）密鑰產(chǎn)生為了保證信息的完整性和機(jī)密性，SSL需要有六個加密秘密：四個密鑰和兩個IV。為了信息的可信性，客戶端需要一個散列密鑰（HMAC），加密要有一個密鑰，分組加密要一個IV，服務(wù)端也是如此。

SSL需要的密鑰是單向的，不同于那些在其他方向的密鑰。如果在一個方向上有攻擊，這種攻擊在其他方向是沒影響的。7.5SSL/TLS的前世今生7.5.2協(xié)議流程2）密鑰產(chǎn)生7.5SSL/TLS的前世今生7.5.2協(xié)議流程2）密鑰產(chǎn)生7.5SSL/TLS的前世今生7.5.2協(xié)議流程2）密鑰產(chǎn)生7.5SSL/TLS的前世今生7.5.2協(xié)議流程3）Record協(xié)議7.5SSL/TLS的前世今生7.5.2協(xié)議流程3）Record協(xié)議7.5SSL/TLS的前世今生7.5.3SSL/TLS協(xié)議演變與安全分析史7.5SSL/TLS的前世今生7.5.3SSL/TLS協(xié)議演變與安全分析史安全派漏洞派我的安全性經(jīng)過了手工證明你有漏洞！我的證明過程有可靠性保證你有漏洞！我的安全性還經(jīng)過計算自動證明你有漏洞！能不說有漏洞么？你的證明假設(shè)有問題！……到底誰的錯?7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Beast攻擊-2011基于瀏覽器的SSL/TLS攻擊（BrowserExploitAgainstSSL/TLS）7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Beast攻擊-2011基于瀏覽器的SSL/TLS攻擊（BrowserExploitAgainstSSL/TLS）

7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Beast攻擊-2011基于瀏覽器的SSL/TLS攻擊（BrowserExploitAgainstSSL/TLS）7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Beast攻擊-2011基于瀏覽器的SSL/TLS攻擊（BrowserExploitAgainstSSL/TLS）7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Beast攻擊-2011基于瀏覽器的SSL/TLS攻擊（BrowserExploitAgainstSSL/TLS）、1.惡意插件強(qiáng)迫Alice的瀏覽器訪問/AAAA7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Beast攻擊-2011基于瀏覽器的SSL/TLS攻擊（BrowserExploitAgainstSSL/TLS）、2.Mallory捕獲到C1,C2,C3,…Cn，并且知道P3=P/1.1<CR><LF><X>7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Beast攻擊-2011基于瀏覽器的SSL/TLS攻擊（BrowserExploitAgainstSSL/TLS）、3.假設(shè)IV是Mallory捕獲的最后一個密文（第二步之后IV=Cn），計算Pi=IV⊕C2⊕Pguess，其中Pguess=P/1.1<CR><LF><W[i]>，并將Pi添加至REQUESTBODY的后面，Alice的瀏覽器將計算Ci=Ek(IV⊕Pi)，并將Ci發(fā)送至服務(wù)器7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Beast攻擊-2011基于瀏覽器的SSL/TLS攻擊（BrowserExploitAgainstSSL/TLS）、4.Mallory捕獲到Ci，如果Ci=C3，X=W[i]，否則將i遞增，返回步驟3Ci=Ek(IV⊕Pi)=Ek(IV⊕IV⊕C2⊕Pguess)

=Ek(C2⊕P/1.1<CR><LF><W[i]>)C3=Ek(C2⊕P/1.1<CR><LF><X>)7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Beast攻擊-2011基于瀏覽器的SSL/TLS攻擊（BrowserExploitAgainstSSL/TLS）、攻擊者自適應(yīng)選擇CBC模式下IV的值，對明文值進(jìn)行猜解7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Crime攻擊-2012HTTPS壓縮信息泄露（CompressionRatioInfo-leakMadeEasy）7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Crime攻擊-2012HTTPS壓縮信息泄露（CompressionRatioInfo-leakMadeEasy）7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Crime攻擊-2012HTTPS壓縮信息泄露（CompressionRatioInfo-leakMadeEasy）7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Crime攻擊-2012HTTPS壓縮信息泄露（CompressionRatioInfo-leakMadeEasy）加密算法本該保密的東西，被壓縮算法泄露7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Crime攻擊-2012HTTPS壓縮信息泄露（CompressionRatioInfo-leakMadeEasy）不怕神一般的對手，就怕豬一樣的隊友7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Lucky13攻擊-2013TLS協(xié)議驗證加密填充算法邊信道信息泄露漏洞7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Lucky13攻擊-2013TLS協(xié)議驗證加密填充算法邊信道信息泄露漏洞7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Lucky13攻擊-2013TLS協(xié)議驗證加密填充算法邊信道信息泄露漏洞7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Lucky13攻擊-2013TLS協(xié)議驗證加密填充算法邊信道信息泄露漏洞7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Lucky13攻擊-2013TLS協(xié)議驗證加密填充算法邊信道信息泄露漏洞7.5SSL/TLS的前世今生7.5.3SSL/TLS缺陷分析-Lucky13攻擊-2013TLS協(xié)議驗證加密填充算法邊信