資訊保安基礎知識 MAC訊息驗證碼及金鑰管理問題

 

版權宣告：本文為博主原創文章，未經博主允許不得轉載。 原文地址https://blog.csdn.net/a359680405/article/details/41518685

       假設Alice和Bob共享一個金鑰，並採用對稱祕鑰加/解密法，Alice想給Bob傳送一條加密訊息，而Bob將會知道它是Alice發的，因為這個約定好的對稱共享祕鑰只有Alice和Bob兩個人知道而已。如果Alice用對稱祕鑰加密函式加密某條訊息資料的話，非常簡單，只需將他們的共享金鑰作為加密金鑰即可，但是如我們所講的，這種方法並不能提供任何資訊未被篡改的真正保證。我們需要一種新的工具，即訊息驗證碼（message authentication codes,MAC）。MAC是一種特殊的摘要演算法，但是它在計算的時候還要採用一個金鑰，因此HMAC函式同時依賴於所使用的金鑰以及要加密的資料資訊。實際上MAC通常是根據摘要演算法構造得出的。<可以理解為 MAC碼值=HMAC函式（共享祕鑰,雜湊函式即摘要演算法MD5或SHA等作用於（訊息資料）） 用的是一個共享祕鑰加密演算法,指的是HMAC函式中的祕鑰引數是同一個，切記HMAC加密演算法是一個單向加密演算法函式，HMAC演算法函式不可逆，即只能用於加密資料，其不可逆指的是沒有對應的解密演算法，可以理解為HAMC是一個特殊型別的HASH值函式，只不過這個HASH函式工作需要一個祕鑰值而已，這個祕鑰值引數一旦指定了，則要想再次使用該函式加密同一個資料要得到相同的HASH雜湊碼結果的話，這個祕鑰引數就不能改變。HMAC=HASH MESSAGE AUTHENTICATION CODE=雜湊 訊息 認證 碼之意

MAC雜湊碼值=HMAC函式（共享祕鑰,訊息資料）

      儘管存在許多基於各種摘要演算法來構造MAC的嘗試，但是因特網安全團體就一種構造方法達成了一致，它被稱做HMAC[Krawzyk1997]，這種方法描述瞭如何基於滿足某種合理假定摘要來建立具有可證明的安全特性的MAC。SSLv3中使用的是一中HMAC的變種，而真正的HMAC在TLS中使用。

      金鑰管理的問題 
      Alice 拿到我們的訊息，使用共享金鑰利用對稱祕鑰加密演算法對正文訊息資訊進行加密

，再在訊息資料包中新增一個也是基於該金鑰+訊息正文利用HMAC(共享祕鑰，訊息正文)構造的一個 MAC摘要值 並將其傳送給 Bob,該MAC碼值作為防篡改驗證碼。她知道只有 Bob 也有該共享金鑰能夠利用該共享金鑰採用對稱祕鑰解密法解密並閱讀這條資訊正文，因為 Bob 有解密函式要使用所需要的金鑰。類似的，Bob 知道傳送這條訊息的只有 Alice，因為只有 Alice 才具有建立相應MAC雜湊值所需要的金鑰。這樣，Bob 就可以知道是 Alice 傳送的資訊，而且還未被篡改，因為只有祕鑰正確Bob利用HAMC(共享祕鑰，前面解密出來的訊息正文值)得出來的MAC值才能和Alice傳送的Alice在本地未傳送前通過HAMC(共享祕鑰，未加密的訊息正文值)所計算出來的並後續傳送給Bob的Mac碼是一致的這是HASH函式的天性，同一個訊息利用同一個HASH函式計算出來的摘要值必然相等，相等說明訊息未被篡改，且此時說明發送方和接受方在HMAC函式中使用了同一個祕鑰，而且這個祕鑰僅僅在此二人之間共享說明二者的身份認證有效都是合法通訊和資料持有參與人。 
      那麼，我們就有了所需要的一切，是嗎？不。與每個人進行通訊，仍然存在與其共享金鑰的問題。周圍有這麼多金鑰需要處理非常不方便。<設想一下如果有兩個人那麼需要交換1個金鑰，如果有三個人則需要交換3個金鑰，如果有n個人，這時就需要n（n-1）/2個金鑰>但更重要的是，這意味著為了進行金鑰交換，你實際上必須要與每一個與之通訊的人會面。這為通過因特網並不安全，除非你個人已經與供應商碰過面。這裡面不便之處就是金鑰管理的問題。

      <因為Alice與Bob要共享金鑰，但是A和B沒有碰過面，那麼就要有一方要傳送金鑰給另一方，但是這個金鑰是需要保密的，不能在網路上直接傳送。所以就涉及到了金鑰的管理問題。有人會說，直接傳送能怎麼樣呢，這就會遭受金鑰被攻擊者截獲（端認證沒有被保證），訊息被截獲並且洩露。MAC=message authentication code  值只能保證訊息不被篡改，金鑰用來保護訊息不被洩露明文，金鑰用來對訊息進行了加密使得明文得以被加密保護。>