iT邦幫忙

2021 iThome 鐵人賽

DAY 25
0
自我挑戰組

一個月的演算法挑戰系列 第 25

Day25:安全性和演算法-訊息鑑別碼(Message Authentication Code)

訊息鑑別碼(Message Authentication Code)

訊息鑑別碼(Message Authentication Code,MAC),能夠實現「身份鑑別」、「檢查訊息完整性」兩種功能的機制。即使是密文,也可能在傳輸時遭到竄改,解密成不同的內容產生誤會,訊息鑑別碼就是為了避免這種情況發生。
MAC可以想像成由金鑰和密文排列組合成字串「雜湊碼」。MAC的製作方式有好幾種,包括「HMAC」、「OMAC」、「CMAC」,現在多半使用「HMAC」。

  • HMAC:雜湊訊息鑑別碼(hash-based MAC)
  • OMAC:單金鑰訊息鑑別碼(one-key MAC)
  • CMAC:加密訊息鑑別碼(cipher-based MAC)

MAC缺點是A和B都能對訊息加密,計算MAC,也就是說,無法證明製作原始訊息的是A還是B,因此若其中一方不懷好意,可以在傳出訊息後,主張是對方捏照的信息,由於製作者和驗證者都擁有MAC,因此無法判斷是誰做成MAC,這類詭計可以用「數位簽章」來防範。

HMAC

由於MAC本身存在的安全隱患,HMAC將「key」和訊息再hash,避免反推的情況,會在hash時往裡面加salt,增加複雜度。前幾天提到的加密演算法,不論是哪種,都擺脫不了三種組合:key + message、message + key、key +message + key,因此我們需要更高強度的HMAC。

下列影片清楚講解HMAC架構:

HMAC的優點其中一個最重要的他可以被嵌入在不同的雜湊演算法中,也是因為安全性以及彈性高,HMAC目前廣泛地使用。

在Python中使用HMAC

import hmac
from hashlib import sha1
message = b'Hello, world!'
key = b'secret'
h = hmac.new(key, message, sha1)
print(h.hexdigest())

參考資料:用于消息验证的hash算法HMAC


數位簽章(Digital Signature)

數位簽章是在能夠實現「身份鑑別」和「檢查訊息完整性」兩種功能的訊息鑑別碼裡,加入也確保具有「不可抵賴性」(non-repudiation)的機制。訊息鑑別碼機制使用共同金鑰,造成擁有金鑰的收訊者也可能是訊息的傳送者;另一方面,數位簽章的機制是利用只有傳送者才能製作的稱為「數位簽章」的數據,所以可以確定訊息的製作者。

數位簽章的具體製作方式:參考公開金鑰密碼系統的步驟

數位簽章雖然具備「身份鑑別」、「檢查訊息完整性」、「不可抵賴性」的功能,但仍有一個問題:

  • B以為數位簽章是由A製作,但由可能為不懷好意的X偽裝成A,問題的根本原因是,用公開金鑰密碼系統時,無法得知公開金鑰的擁有者身份,收到的公開金鑰裡,並未包含任何可表示製作者的資訊,有可能是偽裝成A的其他人所製作的公開金鑰,此問題可用「數位憑證」機制來解決。

數位憑證(Digital Certificate)

公開金鑰密碼系統和數位簽章的機制,無法確保公開金鑰確實為通訊對象所擁有,因此,如果不懷好意的第三人調換公開金鑰,收訊者無法察覺,需要利用「數位憑證」解決此問題。

步驟:

  1. A擁有成對的公開金鑰Pa和私密金鑰Sa,打算把公開金鑰Pa傳送給B
  2. 首先,A要向憑證機構(certification authority,CA)申請發行憑證,證明公開金鑰Pa是自己的
  3. 憑證機構本身具備準備好的公開金鑰Pc和私密金鑰Sc
  4. A把公開金鑰Pa和包含電子郵件地址的個人資訊傳送給憑證機構
  5. 憑證機構確認傳來的資訊是否為A本人所有,確認完畢後,用憑證機構的私密金鑰Sc將A的數據製作成數位簽章
  6. 憑證機構將製作完成的數位簽章和數據整合成一個電子檔,並且傳送給A,取代公開金鑰
  7. A將數位憑證傳送給B,B確認收到的憑證中電子郵件地址是A的,接著B取得憑證機構的公開金鑰
  8. B驗證憑證內的簽章是否為憑證機構所發行。憑證的簽章只能用憑證機構的公開金鑰Pc來驗證。換言之,驗證無誤的話,就能確認該憑證確實是由憑證機構發行
  9. 確認完憑證後,從憑證中取出A的公開金鑰Pa,這樣就完成A傳給B的步驟

憑證機構可以由任何人或任何公司發行,B取得的公開金鑰Pc,真的是憑證機構製作的嗎?

事實上憑證機構的公開金鑰Pc,也會議數位憑證的方式提供,因此,這個憑證機構的憑證發行者,就是更上層的憑證機構,上層憑證機構製作下層憑證機構的憑證。
位在最上層的憑證機構稱為「根憑證機構」(root CA),自己的真實性由自己來證明,而root CA用來證明自己的憑證,稱為「根憑證」(root certifficate)。根憑證機構的組織本身若不值得信來,就不會有人使用,所以大多為大企業或政府機關等已經獲得社會信賴的組織。

「伺服器憑證」(server certificate):同樣是由憑證機構發行,個人的憑證與電子郵件地址綁在一起,伺服器憑證則是與網域連在一起。換言之,透過憑證可以確認管理這個網站網域的組織,以及管理存放網站內容的伺服器組織,兩者是同一個。


上一篇
Day24:安全性和演算法-迪菲-赫爾曼金鑰交換(Diffie-Hellman Key Exchange)
下一篇
Day26:河內塔(Tower of Hanoi)
系列文
一個月的演算法挑戰30

尚未有邦友留言

立即登入留言