什麼是 HMAC-MD5？

01-23

HMAC-MD5比MD5多一個key，具體有什麼應用場景，誰可以解釋的通俗明白一點

你想知道什麼是HMAC-MD5?

下面把我之前總結的一些內容寫在這裡，先介紹下什麼是MD5。

MD5---- Hash加密演算法（本質上說不是加密演算法，因為無法解密，準確來說是一種簽名演算法）

其實在Java庫當中，java.security.MessageDigest 已經實現了Md5演算法(ps：該類實現了Md5和SHA演算法，我們可以根據需要調用相應實例)我們可以直接調用，信息摘要是安全的單向哈希函數，它接收任意大小的數據，並輸出固定長度的哈希值。

import java.io.UnsupportedEncodingException; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException;


public static String getDigest(String msg) throws NoSuchAlgorithmException, UnsupportedEncodingException

{

		final MessageDigest md5 = MessageDigest.getInstance("MD5");

		final byte[] byteArray = msg.getBytes("UTF-8");

		final byte[] md5Bytes = md5.digest(byteArray);

//將生成的md5Bytes轉成16進位形式 final StringBuffer hexValue = new StringBuffer(); for (int i = 0; i &< md5Bytes.length; i++) { int val = ((int) md5Bytes[i]) 0xff; if (val &< 16) hexValue.append("0"); hexValue.append(Integer.toHexString(val)); } return hexValue.toString(); }

MD5Hash演算法的特點：

1：輸入任意長度的信息，經過摘要處理，輸出為128位的信息.。（數字指紋）

2：不同輸入產生不同的結果，（唯一性）

3：根據128位的輸出結果不可能反推出輸入的信息(不可逆)

既然不可能反推出輸入的信息，可以說Md5隻能用於信息驗證，而不能用來加密解密進行消息傳遞。這是與RC4的根本區別。

MD5Hash演算法作用：

1：防止數據被篡改

2：防止直接看到明文 ps:在密碼存儲中，即使採用md5存儲密碼也是有可能出現安全漏洞的，比如撞庫的暴力破解

3：數字簽名

先介紹到這裡，等下補上H-MAC的

HMAC演算法的實現過程需要一個加密用的散列函數（表示為H）和一個密鑰。

一般我們採用的散列函數為Md5或者SHA-1，這兩個散列函數的分割數據塊長度都是64位元組，即512位，HMAC-MD5演算法就是採用密鑰加密+Md5信息摘要的方式形成新的密文。

由於數據塊長度為64，為了保證密鑰+data進行digest的時候的數據完整性(為什麼需要保證？)最終加進數據的密鑰保證為64個位元組長。

密鑰的長度可以是小於等於數據塊長度的任何正整數值。應用程序中使用的密鑰長度若是比B大，則首先使用散列函數H作用於它，然後用H輸出的L長度字元串作為MAC中實際使用的密鑰。一般情況下，推薦的最小密鑰K長度是L長(與H的輸出數據長度相等，比如MD5的L就是16位元組，SHA-1是20位元組)

過程如下：

(1) 在密鑰key後面添加0來創建一個長為B(64位元組)的字元串（str）；

(2) 將上一步生成的字元串(str) 與ipad（0x36）做異或運算，形成結果字元串（istr）

(3) 將數據流data附加到第二步的結果字元串(istr)的末尾

(4) 做md5運算於第三步生成的數據流(istr)

(5) 將第一步生成的字元串(str) 與opad（0x5c）做異或運算，形成結果字元串（ostr）

(6) 再將第四步的結果(istr) 附加到第五步的結果字元串（ostr）的末尾

(7) 做md5運算於第6步生成的數據流（ostr），最終輸出結果(out)

注意：如果第一步中，key的長度klen大於64位元組，則先進行md5運算，使其長度klen = 16位元組

有人說HMAC-MD5的產生是因為碰撞率比MD5更低？

HMAC-MD5的應用？先看下面這篇文章

通過實例演示如何建立基於SSL的安全通道連接

在當前世界中，網路已成為不可或缺的元素。它將原來遙不可及的事物，方便快捷的聯繫到一起。為了充分利用網路所帶來的便捷，越來越多的企業選擇將信息發布在網路上。電子商務、物聯網、雲計算與服務，也都在計劃與實施中。與此同時，網路的普及，也給信息安全帶來了挑戰。如何保證信息在不可靠網路中的安全傳輸，成為企業 IT 實施優先考慮的問題。

SSL 是指安全套接字（Secure Socket Layer），是應用最為廣泛的安全協議。它在 TCP/IP 協議之上提供了一條安全通道，可以保證在不安全網路環境下的數據安全。它支持各種加密演算法、數字簽名、數字證書，可以防禦常見的網路攻擊。WebSphere MQ 對 SSL 具有很好的支持，從而保證消息在網路中安全的傳送。本文在介紹 SSL 的基礎上，以實例方式詳細描述了如何在 MQ 中實現基於 SSL 的安全傳輸。文章中的實例，主要基於 MQ 7.0.1.9，同時也會介紹新版本 MQ 7.1 及 MQ 7.5 的變化。

網路攻擊類型及應對策略

網路將數以千萬計的機器連接在一起，環境複雜多變，所以網路攻擊也是花樣百出。這裡，根據攻擊對消息產生的影響，主要可以劃分為三類：竊聽、篡改、仿冒。這三種攻擊方式，分別會破壞消息的私密性、完整性和通信雙方的互信。針對這些攻擊的特點，SSL 提供了可靠的防禦策略。

1)竊聽與加密

竊聽，即偷聽別人的談話，在網路中意味著攔截消息並偷看其中的內容。那麼，為了避免消息被別人竊聽，就需要對消息進行加密。這樣，即使消息被攻擊者截獲，他們也無法輕鬆獲知其中的內容。

加密即按照一定的規則（加密演算法）將原消息（明文）轉化為對竊聽者不可讀的密文。通信雙方共享加密的規則，所以消息接收者可以將密文再轉回可讀的明文。密鑰是一個隨機字元串，是加密及解密不可或缺的元素。發送者使用密鑰對明文加密，接收者使用密鑰對密文解密。

通信雙方可以共享一個相同的密鑰，用於加密和解密。這稱為對稱加密或者秘密密鑰加密。這種方法的優勢是速度快，劣勢是難以安全的傳遞密鑰，特別是有很多通信對象時。要安全的將密鑰交到通信方，你需要和每一個人見面。為了解決這個問題，就出現了不對稱加密或者公共密鑰加密。使用這種方法，每一個通信對象都有一個密鑰對：公鑰和私鑰。發送者使用對方的公鑰加密，接收者使用自己的私鑰解密。因為公鑰是公開的，這就解決了密鑰傳遞的問題。但是，也造成了一些性能的損失。在實際的應用中，為了避免密鑰傳遞問題同時保證性能，通常使用不對稱加密來交換密鑰，然後使用對稱加密傳輸數據。

加密是一個非常重要，也非常活躍的研究領域，有非常多的加密演算法。例如，數據加密標準（DES），三重 DES，RC2 和 RC4 等。

2)篡改與消息摘要

篡改是指攻擊者攔截並修改消息的內容。加密不能避免消息被修改，接收者也無法判斷消息是否被修改過。這裡，就需要用到消息摘要（Message Digest）技術。消息摘要是一個表示消息特徵的定長字元串。它有兩個重要的特徵：不可逆性和抗衝突性。不可逆性是指從消息可以計算出消息概要，但是從消息摘要基本不可能得到消息；抗衝突性是指要想產生具有相同摘要值的兩條消息是相當困難的。這兩個特性，使消息摘要可以用來驗證消息的完整性。發送者使用摘要演算法計算出消息摘要，並隨同消息發送給對方；接收者收到消息以後，同樣會根據消息計算出消息摘要 , 並和收到的摘要對比。如果兩者相同，則表示消息沒有被篡改。

在實際應用中，消息摘要很少被單獨使用，通常用於數字簽名和消息認證碼（MAC）。消息認證碼是基於消息和密鑰生成的消息摘要。它在驗證完整性同時，可以在一定程度上完成用戶驗證功能。數字簽名是經過加密的消息摘要。

(PS:似乎就是消息被篡改了我必須知道，從而發現並處理這個篡改事件)

3)仿冒與數字證書

仿冒即假冒別人進行通信。消息認證碼可以用來驗證消息的發送者。數字簽名則更進一步，具有不可抵賴性。因為數字簽名是使用發送者私鑰加密的消息摘要，只有發送者才能產生。這一切似乎都很完美，使用加密防止竊聽，使用摘要防止篡改，使用數字簽名防止仿冒，似乎不要什麼數字證書。

事實當然不是這樣，下面的攻擊方式將瓦解以上所有的防線。這就是中間人攻擊（man-in-the-middle attack）。在通信雙方交換公鑰的過程中，攻擊者攔截雙方的公鑰，並將自己的密鑰發送給通信雙方。這樣，通信雙方就會使用攻擊者的密鑰加密。在這樣情況下，所有的加密、簽名都失效了。中間人攻擊細節如下圖所示：

圖 1.中間人攻擊

從上圖可以看出，第 1, 2, 3, 4 步是公鑰交換過程。在此過程中，攻擊者獲得了發送方和接收方的公鑰，而將自己的公鑰發送給通信雙方。第 5, 6, 7, 8 步是發送消息的過程。在此過程中，發送方和接收方都是用攻擊者公鑰加密，而攻擊者截獲數據後重新使用通信雙方公鑰加密，這就使雙方難以察覺攻擊者的存在。

要防範中間人攻擊，就需要使用數字證書，這裡，數字證書主要指由專門的證書頒發機構（CA）授權的證書，稱為 CA 證書。CA 證書將證書屬主信息和公鑰綁定到一起。證書頒發機構負責驗證證書申請者的身份信息。通過可信的第三方（CA），通信方可以向任何人證明其擁有的公鑰，其他人也可以通過 CA 驗證其證書真偽，這就阻止了中間人攻擊。CA 證書一般包含所有者的公鑰 , 所有者的專有名稱 , 簽發證書的 CA 的專有名稱 , 證書開始生效的日期 , 證書過期日期等信息。

與 CA 證書相對應的，還有自簽署證書。

自簽署證書一般用在測試環境中。在後面的章節中，會使用自簽署證書實現基於 SSL 的安全連接。

SSL 握手

SSL 連接實現主要分為兩部分：SSL 握手和數據傳輸。前者使用 SSL 握手協議建立連接，後者使用記錄協議傳輸數據。這裡，主要介紹 SSL 握手流程。握手是 SSL 客戶端和 SSL 伺服器端完成認證，並確定用於數據傳輸的加密密鑰的過程。這裡，SSL 客戶端是指主動發起連接的一端，不要和 MQ 客戶端混淆。SSL 握手具體流程如下：

SSL 客戶端發送「Hello」消息給 SSL 伺服器端，並列出客戶端所支持的 SSL 版本、加密演算法和摘要演算法。在實際應用中，一般將加密演算法和摘要演算法結合到一起，組成一個加密套件。同時，客戶端還會發送一個隨機數，用於以後產生加密密鑰。
SSL 伺服器端對客戶端的連接請求作出回應。從客戶端提供的加密套件列表中，選擇要使用的加密套件，併產生另外一個隨機數。同時，伺服器端會發送自己的數字證書給客戶端，裡面包含伺服器端的認證信息及公共密鑰。如果伺服器端需要驗證客戶端，它還會在消息中包含要求客戶端提供數字證書的請求。
客戶端收到伺服器端的回應。它首先使用 CA 證書驗證伺服器端證書的有效性。在此過程中，客戶端會檢查證書的簽名、證書認證路徑、有效日期、證書狀態等。驗證通過後，抽取出其中的公鑰。客戶端產生另外一個隨機數，並使用伺服器端的公鑰加密後發送給伺服器端。
如果伺服器端要求客戶端提供證書，客戶端會將隨機數用私鑰加密，連同證書發送給伺服器端。伺服器端對客戶端的證書進行驗證，並使用客戶端的公鑰解密收到的隨機數。
伺服器端和客戶端基於前面提供的隨機數，計算出用於數據加密的共享密鑰。
客戶端將所有握手消息的 MAC 值發送給伺服器端，伺服器端也將所有握手消息的 MAC 值發送給客戶端。這麼做是為了防止攻擊者在握手過程中篡改了消息內容。
客戶端和伺服器端使用握手過程中產生的加密密鑰交換握手結束消息。握手結束，SSL 連接建立。

在 SSL 連接建立後，將開始遵循記錄協議對數據進行傳輸。

WebSphere MQ SSL 配置與管理

WebSphere MQ 支持安全套接字協議（SSL）和傳輸層安全協議（TLS，是 SSL 的後續版本）。在本章中，主要介紹 GSKit，以及與 SSL/TLS 相關的隊列管理器屬性及通道屬性。用戶可以使用 MQ 資源管理器設置這些屬性，也可以使用 MQSC 命令設置。

MQ 與 GSKit

MQ 對 SSL 的支持，是通過 GSKit（Global Security Kit）實現的。GSkit 提供實現 SSL 所必須的函數庫及工具，被應用於很多 IBM 產品。

在 MQ 7.0 及以前的版本中，GSKit 是單獨安裝的，版本是 GSKit V7.0。從 MQ 7.0.1 開始，引入 GSKit V8.0 作為可選版本。在 MQ 後續版本 MQ 7.1 和 MQ 7.5 中 GSKit V8.0 完全取代 GSKit 7.0，成為默認版本並集成到 MQ 安裝包中。

與 GSKit V7.0 相比，GSKit V8.0 支持新的更安全的散列演算法 SHA-2，支持所有 Java 環境中的密鑰重置，支持更嚴格的 FIPS 認證以及多語言的錯誤輸出。具體的細節，請參考 MQ 信息中心文檔。

GSKit V7.0 和 GSKit V8.0 可以共存於同一系統中，不同的隊列管理器可以選擇使用不用的 GSKit 版本。

此外，GSKit V8.0 還集成了 GSKCapiCmd 命令，用於管理密鑰、證書請求及證書。同時，用戶也可 iKeyman （IBM Key Management）工具實現同樣的功能。一般來說，iKeyman 可以隨 MQ 一起安裝，並且具有 GUI 界面，使用比較方便。

其中SSL握手就是使用的HMAC-MD5，俗稱challenge協議，回來再詳細介紹

比如你和對方共享了一個密鑰K，現在你要發消息給對方，既要保證消息沒有被篡改，又要能證明信息確實是你本人發的，那麼就把原信息和使用K計算的HMAC的值一起發過去。對方接到之後，使用自己手中的K把消息計算一下HMAC，如果和你發送的HMAC一致，那麼可以認為這個消息既沒有被篡改也沒有冒充。

MD5就是通過散列對要輸出的數據進行摘要，接收到數據時，再同樣進行MD5散列，與給定的MD5散列值比較，一致不一致就很清楚了。

通常來說，傳輸的數據和MD5是不同的渠道給出的，比如網頁上顯示MD5，下載鏈接是某個鏡像網站的。

如果要通過同一個渠道發送數據和散列值的話（比如消息認證碼），就要考慮數據和MD5同時被篡改的問題，如果第三方修改了數據，然後進行MD5散列，並一塊發給接收方，接收方並不能察覺到數據被篡改。

HMAC-MD5就可以用一把發送方和接收方都有的key進行計算，而沒有這把key的第三方是無法計算出正確的散列值的，這樣就可以防止數據被篡改。

維基百科在這邊： https://en.wikipedia.org/wiki/HMAC-MD5