網(wǎng)絡(luò)與信息安全安全基礎(chǔ)四-文庫(kù)吧資料
2024-10-19 10:51本頁(yè)面
【正文】 ? 在 RSA算法作加密運(yùn)算的時(shí)候，首先對(duì)明文消息進(jìn)行編碼，其格式為 0 2 random bytes 0 message ? 假設(shè)密文 C， 攻擊者可以產(chǎn)生一系列整數(shù) S并計(jì)算 C’ = C*(Se) mod n， 在解密的時(shí)候，每一個(gè) C’對(duì)應(yīng)于一個(gè) M’。 secret_key = RNG_GenerateRandomBytes()。 tmp = RNG_GenerateRandomBytes()。 create_key() RNG_CreateContext()。 seed = seed + 1。 對(duì)于大多數(shù) UNIX平臺(tái)， pid+(ppid 12)只有 27位 global variable challenge, secret_key。 shown for pleteness */ return ((0xDEECE66D * x + 0x2BBB62DC) 1)。 seed = MD5(a, b)。 a = mklcpr(microseconds)。 /* Time elapsed since 1970 */ pid = process ID。 這里， S1和 S2為 secret的各一半，如果 secret為奇數(shù)個(gè)字節(jié)，則 S1和 S2共享一個(gè)字節(jié) TLS/SSL安全性分析 ? 針對(duì)一些常見(jiàn)的攻擊手法 ? 針對(duì)密鑰算法的破解 ? 取決于算法的強(qiáng)度，協(xié)商過(guò)程 ? 利用明文模式的攻擊 ? 上層協(xié)議中常常有一些固定的模式可以參考，比如 協(xié)議中g(shù)et字節(jié)串 ? 構(gòu)造字典 (密文 密鑰對(duì) )，查字典 ? TLS辦法：用長(zhǎng)密鑰，使得不可能構(gòu)造這樣的字典 ? 重放攻擊 ? TLS中的 nonce有 32字節(jié) (包含時(shí)間戳 )，可用于避免重放攻擊 ? 會(huì)話 ID標(biāo)識(shí)了一個(gè)完整的會(huì)話，要重放部分會(huì)話需要知道私鑰 ? 中間人攻擊 ? 通過(guò)證書(shū)來(lái)認(rèn)證對(duì)方 ? 對(duì)于雙方都是匿名的模式，中間人攻擊也是成立的 歷史上針對(duì) SSL/TLS的攻擊 ? PRNG ? Millionmessage attack ? 其它 SSL: PRNG攻擊 ? Netscape ，利用隨機(jī)數(shù)發(fā)生器的弱點(diǎn) ? 先看隨機(jī)數(shù)發(fā)生器 global variable seed。 ? 握手過(guò)程完成，客戶和服務(wù)器可以交換應(yīng)用層數(shù)據(jù)。其中包括一個(gè)校驗(yàn)值，對(duì)所有以來(lái)的消息進(jìn)行校驗(yàn)。會(huì)受到中間人攻擊 ? 然后，指定以下信息 ? 加密算法，和類型 (流還是分組密碼算法 ) ? HMAC算法， MD5還是 SHA1 ? 是否可出口 ? HashSize ? Key Material ? IV Size 第二階段：服務(wù)器認(rèn)證和密鑰交換 ? 服務(wù)器發(fā)送自己的證書(shū)，消息包含一個(gè) ，或者一條證書(shū)鏈 ? 除了匿名 DH之外的密鑰交換方法都需要 ? 服務(wù)器發(fā)送 server_key_exchange消息 ? 可選的，有些情況下可以不需要。 length TLS密碼變化協(xié)議 Change Cipher Spec Protocol ? 它位于 TLS記錄協(xié)議之上 ? 所以，它用到了 TLS記錄協(xié)議的處理過(guò)程 ? ContentType = 20 ? 協(xié)議只包含一條消息，一個(gè)字節(jié) 1 ? 用途：切換狀態(tài) 把密碼參數(shù)設(shè)置為當(dāng)前狀態(tài) 在握手協(xié)議中，當(dāng)安全參數(shù) 協(xié)商一致后，發(fā)送此消息 ? 這條消息使得接收方改變當(dāng) 前狀態(tài)讀參數(shù)，使得發(fā)送方 改變當(dāng)前狀態(tài)寫(xiě)參數(shù) TLS警告協(xié)議 Alert Protocol ? 位于 TLS記錄協(xié)議之上 ? 所以，也用到了 TLS記錄協(xié)議的處理過(guò)程 ? ContentType = 21 ? 協(xié)議數(shù)據(jù)包含兩個(gè)字節(jié) 第一個(gè)字節(jié)為 level： 分別為 warning(1)和 fatal(2)兩種情況 第二個(gè)字節(jié)為情況說(shuō)明 ? Fatal類型的 alert消息導(dǎo)致 連接立即終止，此時(shí)，對(duì)應(yīng) 該會(huì)話的其他連接可以繼續(xù)， 但是會(huì)話標(biāo)識(shí)符無(wú)效，以免 利用此失敗的連接來(lái)建立新 的連接 Alert Protocol第二字節(jié)說(shuō)明 close_notify(0), unexpected_message(10), bad_record_mac(20),* decryption_failed(21),* record_overflow(22), * depression_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), 說(shuō)明： 1 * 表示該消息往往是 fatal級(jí)別 2 表示該消息往往是 warning級(jí)別 3 對(duì)于其他的錯(cuò)誤情況，發(fā)送方可以根據(jù)情況決定是 warning還是 fatal,對(duì)于 warning消息，接收方可以自行決定如何處理，如果是 fatal消息，則一定要當(dāng)作 fatal消息來(lái)對(duì)待 TLS握手協(xié)議 TLS Handshake Protocol ? 位于 TLS記錄協(xié)議之上 ? 也用到了 TLS記錄協(xié)議的處理過(guò)程 ? ContentType = 22 ? 協(xié)議格式 ? 用途： ? 當(dāng) TLS客戶和服務(wù)器開(kāi)始通訊的時(shí)候，它們要通過(guò)協(xié)商，在以下信息方面獲得一致 : 協(xié)議版本、密碼算法、是否認(rèn)證對(duì)方、 用什么技術(shù)來(lái)產(chǎn)生共享秘密數(shù)據(jù)，等等 TLS握手協(xié)議的流程 ? 交換 Hello消息，對(duì)于算法、交換隨機(jī)值等協(xié)商一致 ? 交換必要的密碼參數(shù)，以便雙方得到統(tǒng)一的 premaster secret ? 交換證書(shū)和相應(yīng)的密 碼信息，以便進(jìn)行身份認(rèn)證 ? 產(chǎn)生 master secret ? 把安全參數(shù)提供給 TLS記錄層 ? 檢驗(yàn)雙方是否已經(jīng)獲得同樣的安全參數(shù) TLS握手協(xié)議使用的消息 消息 參數(shù) hello_request Null client_hello 版本，隨機(jī)數(shù)，會(huì)話 id
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號(hào)-1