從消息認證碼到數字簽名

前面講到，消息認證碼無法防止否認，A,B之間共享密鑰計算出MAC,A,B都能計算出MAC,對于第三方C來說，他無法證明這個MAC是A計算的還是B計算的。

通過數字簽名解決問題。

A,B各自使用不同的密鑰-公鑰密碼，A用私鑰生成一個簽名，B可以用A公開的公鑰進行驗證。

簽名的生成和驗證

數字簽名中的兩種行為：

? ? ? ? 生成消息簽名

? ? ? ? 驗證消息簽名

數字簽名：將公鑰密碼反過來用，

	私鑰	公鑰
公鑰密碼	接收者解密使用	發送者加密使用
數字簽名	簽名者生成簽名使用	驗證者驗證簽名使用
	個人持有	公開

---

數字簽名的方法

直接對消息簽名

1. A用私鑰對消息進行加密
2. A將消息和簽名發給B
3. B用A的公鑰對收到的簽名進行解密
4. B將解密出來的消息和A發的消息進行對比

直接對消息簽名

對消息的散列值簽名

A用單向散列函數計算消息的散列值

A用自己的私鑰對散列值加密

A將消息和簽名發給B

B用A的公鑰對收到的簽名進行解密

B將解密得到的散列值和A發來的消息的散列值進行比較

對消息的散列值簽名

對消息的散列值簽名時序圖?

使用公鑰密碼的私鑰生成簽名，主要是利用了私鑰只有特定的人才持有這一特性。簽名和消息是具有對應關系的，消息不同，簽名內容不同。如果將一份簽名提取出來放在另一個消息后面，驗證簽名的時候會失敗。

應用實例

安全信息公告

軟件下載

公鑰證書

SSL/TLS

對數字簽名的攻擊

中間人攻擊：確認自己得到的公鑰是否真的是通信對象的

單向散列函數攻擊：散列函數抗碰撞性

利用數字簽名攻擊公鑰密碼-不要直接對消息進行簽名，對散列值進行簽名更安全；公鑰密碼和數字簽名分別使用不同的密鑰

數字簽名無法解決的問題

數字簽名可以識別出篡改和偽裝，還可以防止否認。前提條件是用于簽名的公鑰屬于真正的發送者。數字簽名用來識別消息篡改、偽裝及否認，但我們必須從一個沒有被偽裝的發送者得到沒有被篡改的公鑰才行----死循環。

怎樣才能確認自己得到的公鑰是合法 的 ---使用證書。那么證書又由誰來頒發才安全呢？---公鑰基礎設施PKI

?