安全體系 加解密算法、消息摘要、消息認證技術、數字簽名與公鑰證書

轉載地址:http://www.cnblogs.com/songwenlong/p/6517165.html

 

正文

  本文講解對稱加密、非對稱加密、消息摘要、MAC、數字簽名、公鑰證書的用途、不足和解決的問題。

  安全體系(一)—— DES算法詳解

  安全體系(二)—— RSA算法詳解

     安全體系(三)—— SHA1算法詳解

0.概述

  當發送方A向接收方B發送數據時,需要考慮的問題有:

  1.數據的安全性

  2.數據的完整性,即數據不被篡改。

  3.數據的真實性,即數據確實來自於發送方,傳輸過程中沒有被替換。

  4.數據的不可否認性,即驗證發送方確實發送了數據。

  本文只是對整套體系做一個整體的介紹,後續文章詳細講解各個步驟和算法。

  本文的整體結構見下圖。

 

  基本概念: 

  密碼:按特定法則編成,用以對通信雙方的信息進行明密變換的符號。

  密鑰:在現代密碼學中,祕鑰指的是一組特定的祕密數據,在加密時,它控制密碼算法按照指定的方式將明文變換爲相應的密文,並將一組信源標識信息變換不可僞造的簽名;在解密時,它控制密碼算法按照指定的方式將密文變換爲相應的明文,並將簽名信息變換成不可否認的信源證據。

1.數據傳輸的安全

  保證數據傳輸安全的方法就是對數據進行加密了,常用的加密算法有對稱加密和非對稱加密。

1.1 對稱加密

  又稱共享加密,加解密使用相同的密鑰

常見算法

  DES 3DES AES RC5 RC6

  1).爲了安全,A將數據加密發送給B。

  2).密文即使在傳送過程中被截獲,因爲不知道密鑰也無法解密。

  3).B接收到密文之後,需要使用加密相同的密鑰來解密。

  4).需要A將密鑰傳給B,但保證密鑰傳輸過程中的安全又成了問題。

優點

  計算速度快。

缺點

  爲了傳送數據的安全,將數據加密後進行傳輸,但是對稱加密需要發送方將密鑰安全地傳給接收方以便接收方解密,因此密鑰如何安全傳送又成了一個問題

問題

  如何保證密鑰的安全性?

1.2 非對稱加密

  也稱公鑰加密,這套密鑰算法包含配套的密鑰對,分爲加密密鑰和解密密鑰。加密密鑰時公開的,又稱爲公鑰;解密密鑰時私有的,又稱爲私鑰。數據發送者使用公鑰加密數據,數據接收者使用私鑰進行數據解密

常見算法

  RSA

  1).B生成密鑰對,將公鑰傳給A,私鑰自己保留。公鑰即使被其他人獲得也沒有關係。

  2).A用B傳過來的密鑰將要發送的明文數據加密,然後將密文發送給A。其他人即使獲得密文也無法解密,因爲沒有配對的用來解密的私鑰。

  3).B接收到A傳送過來的密文,用自己保留的私鑰對密文解密,得到明文。

優點

  解決了密鑰的安全性問題

缺點

  一是計算速度慢;

  二是無法保證公鑰的合法性,因爲接收到的公鑰不能保證是B發送的,比如,攻擊者截獲B的消息,將公鑰替換。

  這裏先留下一個問題,後面敘述解決辦法:如何保證公鑰是合法的?

2.保證數據完整性

消息摘要

  消息摘要函數時一種用於判斷數據完整性的算法,也稱爲散列函數或哈希函數,函數的返回值就散列值,散列值又稱爲消息摘要或者指紋。

  這種算法是不可逆的,即無法通過消息摘要反向推導出消息,因此又稱爲單向散列函數。

常見算法

  MD5 SHA

  當我們使用某一軟件時,下載完成後需要確認是否是官方提供的完整版,是否被人篡改過。通常軟件提供方會提供軟件的散列值,用戶下載軟件之後,在本地使用相同的散列算法計算散列值,並與官方提供的散列值向對比。如果相同,說明軟件完整,未被修改過。

優點

  可以保證數據的完整性

缺點

  無法保證數據的真實性即不能確定數據和散列值是來自發送方的,因爲攻擊者完全可以將數據和散列值一起替換。

問題

  如何驗證發送的數據確實來自於發送方?

3.保證數據的真實性

  要保證數據來自發送方,即確認消息來自正確的發送者,稱爲消息認證

3.1 消息認證碼

  消息認證碼(Message Authentication Code,簡稱MAC)是一種可以確認消息完整性並進行認證的技術。消息認證碼可以簡單理解爲一種與密鑰相關的單向散列函數。

  1).A把消息發送給B前,先把共享密鑰發送給B。

  2).A把要發送的消息使用共享密鑰計算出MAC值,然後將消息和MAC發送給B。

  3).B接收到消息和MAC值後,使用共享密鑰計算出MAC值,與接收到的MAC值對比。

  4).如果MAC值相同,說明接收到的消息是完整的,而且是A發送的。

  這裏還是存在對稱加密的密鑰配送問題,可以使用公鑰加密方式解決。

優點

  可以保證數據的完整性和真實性。

缺點

  接收方雖然可以確定消息的完整性和真實性,解決篡改和僞造消息的問題,但不能防止A否認發送過消息。

  加入A給B發送了消息,B接收到之後,A否認自己發送過消息給B,並抵賴說,“雖然我和B都能計算處正確的MAC值,但是可能是B的密鑰被攻擊者盜取了,攻擊者給B發的消息。”

問題

  如何讓發送方無法否認發送過數據?

3.2 數字簽名

  數字簽名(Digital Signature)可以解決發送方否認發送過消息的問題

  數字簽名的重點在於發送方和接收方使用不同的密鑰來進行驗證,並且保證發送方密鑰的唯一性,將公鑰算法反過來使用可以達到此目的:A發送消息前,使用私鑰對消息進行簽名,B接收到消息後,使用配對的公鑰對簽名進行驗證;如果驗證通過,說明消息就是A發送的,因爲只有A採用配對的私鑰;第三方機構也是依據此來進行裁決,保證公正性。

  1).A把消息用哈希函數處理生成消息摘要,並報摘要用私鑰進行加密生成簽名,把簽名和消息一起發送給B。

  2). 數據經過網絡傳送給B,當然,爲了安全,可以用上述的加密方法對數據進行加密。

  3). B接收到數據後,提取出消息和簽名進行驗籤。採用相同的哈希函數生成消息摘要,將其與接收的簽名用配對的公鑰解密的結果對比,如果相同,說明簽名驗證成功。消息是A發送的,如果驗證失敗,說明消息不是A發送的。

問題

  依然是,如何確保公鑰的合法性

4.公鑰證書

  我們看到,上面的公鑰加密,數字簽名的問題都在於如何保證公鑰的合法性。

  解決辦法是將公鑰交給一個第三方權威機構——認證機構(Certification Authority)CA來管理。接收方將自己的公鑰註冊到CA,由CA提供數字簽名生成公鑰證書(Public-Key Certificate)PKC,簡稱證書。證書中有CA的簽名,接收方可以通過驗籤來驗證公鑰的合法性

  1).接收方B生成密鑰對,私鑰自己保存,將公鑰註冊到CA。

  2).CA通過一系列嚴格的檢查確認公鑰是B本人的。

  3).CA生成自己的密鑰對,並用私鑰對B的公鑰進行數字簽名,生成數字證書。證書中包含B的公鑰和CA的簽名。這裏進行簽名並不是要保證B的公鑰的安全性,而是要確定公鑰確實屬於B。

  4).發送方A從CA獲取B的證書。

  5).A使用CA的公鑰對從CA獲取的證書進行驗籤,如果成功就可以確保證書中的公鑰確實來自B。

  6).A使用證書中B的公鑰對消息進行加密,然後發送給B。

  7).B接收到密文後,用自己的配對的私鑰進行解密,獲得消息明文。

5.算法詳解索引

     1.DES算法詳解(已完成)

  2.RSA算法詳解(已完成)

  3.SHA算法詳解(已完成)

  4.AES算法詳解

  5.待定


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章