網絡安全

兩類密碼體制

對稱密匙密碼體制

　　加密密匙和解密密匙使用的是相同的密碼體制。

公式密碼體制

　　RSA密碼體制是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密算法是公開的。 由公鑰加密的內容能夠而且只能由私鑰進行解密，而且由私鑰加密的內容能夠而且只能由公鑰進行解密。也就是說，RSA的這一對公鑰、私鑰均可以用來加密和解密，而且一方加密的內容能夠由而且只能由對方進行解密。 

　　使用不一樣的加密密匙與解密密匙。這種密碼體制的產生是由於對稱密匙密碼體制的分配和數字簽名的需求。

　　在公鑰密碼體制中，加密密鑰PK(public key，即公鑰）是公開的，而解密密鑰SK(secret key,即私鑰)是須要保密的。假設A向B使用公鑰密碼體制發送消息，主要過程以下：

1. 密鑰對產生器產生接受者B的一對密鑰，加密密鑰PKb和解密密鑰SKb。B將PKb公開，發送者所用的加密密匙PBk就是接收着B的公匙，他向公衆公開，而B所用的解密密匙SKb就是接受者B的私鑰，對其餘人都保密
2. 發送者A用B的公鑰 PBk經過E運算對明文X加密，得出密文Y發送給B：Y=Epkb(X);
3. 用本身的私鑰SKb經過D運算進行解密，恢復出明文：Dskb(Y)=Dskb(Epkb(X))=X;
4. 雖然計算機上很容易產生PKb和SKb，但從已知的PKb實際上不能導出SKb，即從PKb到SKb是「計算上不可能的」
5. 雖然公鑰能夠用來加密，但不能用來解密：Dpkb(Epkb(X))!=X
6. 先對X進行D運算和E運算或進行E運算和D運算結果是同樣的：Epkb(Dskb(X))=Dskb(Epkb(X))=X

數字簽名

　　做用：爲了向「客戶」證實本身是「服務器」， 「服務器」把一個字符串（也就是信息摘要）用本身的私鑰加密——即數字簽名，把明文和加密後的密文一塊兒發給「客戶」。

　　「客戶」收到信息後，她用本身持有的公鑰解密密文，和明文進行對比，若是一致，說明信息的確是由服務器發過來的。由於由「服務器」用私鑰加密後的內容，由而且只能由公鑰進行解密，私鑰只有「服務器」持有，因此若是解密出來的內容是可以對得上的，那說明信息必定是從「服務器」發過來的。

看別人的一個小例子：

1. 「客戶」->「服務器」：你好
2. 「服務器」->「客戶」：你好，我是服務器
3. 「客戶」->「服務器」：向我證實你就是服務器
4. 「服務器」->「客戶」：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]——這裏用數字簽名證實是服務器
5. 「客戶」->「服務器」：{個人賬號是aaa，密碼是123，把個人餘額的信息發給我看看}[公鑰|RSA]
6. 「服務器」->「客戶」：{你的餘額是100元}[私鑰|RSA]

　　注意上面的的信息 {你的餘額是100元}[私鑰]，這個是「服務器」用私鑰加密後的內容，可是咱們以前說了，公鑰是發佈出去的，所以全部的人都知道公鑰，因此除了「客戶」，其它的人也能夠用公鑰對{你的餘額是100元}[私鑰]進行解密。因此若是「服務器」用私鑰加密發給「客戶」，這個信息是沒法保密的，由於只要有公鑰就能夠解密這內容。然而「服務器」也不能用公鑰對發送的內容進行加密，由於「客戶」沒有私鑰，發送個「客戶」也解密不了。

　　在實際的應用過程，通常是經過引入對稱加密來解決這個問題

1. 「客戶」->「服務器」：你好
2. 「服務器」->「客戶」：你好，我是服務器
3. 「客戶」->「服務器」：向我證實你就是服務器
4. 「服務器」->「客戶」：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
5. 「客戶」->「服務器」：{咱們後面的通訊過程，用對稱加密來進行，這裏是對稱加密算法和密鑰}[公鑰|RSA]    //標註部分是對稱加密的算法和密鑰的具體內容，客戶把它們發送給服務器。
6. 「服務器」->「客戶」：{OK，收到！}[密鑰|對稱加密算法]
7. 「客戶」->「服務器」：{個人賬號是aaa，密碼是123，把個人餘額的信息發給我看看}[密鑰|對稱加密算法]
8. 「服務器」->「客戶」：{你的餘額是100元}[密鑰|對稱加密算法]

　　在上面的通訊過程當中，「客戶」在確認了「服務器」的身份後，「客戶」本身選擇一個對稱加密算法和一個密鑰，把這個對稱加密算法和密鑰一塊兒用公鑰加密後發送給「服務器」。注意，因爲對稱加密算法和密鑰是用公鑰加密的，就算這個加密後的內容被「黑客」截獲了，因爲沒有私鑰，「黑客」也無從知道對稱加密算法和密鑰的內容。

　　因爲是用公鑰加密的，只有私鑰可以解密，這樣就能夠保證只有服務器能夠知道對稱加密算法和密鑰，而其它人不可能知道(這個對稱加密算法和密鑰是「客戶」本身選擇的，因此「客戶」本身固然知道如何解密加密)。這樣「服務器」和「客戶」就能夠用對稱加密算法和密鑰來加密通訊的內容了。

　　RSA加密算法在這個通訊過程當中所起到的做用主要有兩個：

1. 由於私鑰只有「服務器」擁有，所以「客戶」能夠經過判斷對方是否有私鑰來判斷對方是不是「服務器」。——數字簽名的應用
2. 客戶端經過RSA的掩護，安全的和服務器商量好一個對稱加密算法和密鑰來保證後面通訊過程內容的安全。

信息摘要

　　將消息哈希轉換成一個固定長度的值惟一的字符串。值惟一的意思是不一樣的消息轉換的摘要是不一樣的，而且可以確保惟一。該過程不可逆，即不能經過摘要反推明文（彷佛SHA1已經能夠被破解了，SHA2尚未。通常認爲不可破解，或者破解須要耗費太多時間，性價比低）。利用這一特性，能夠驗證消息的完整性。

數字簽名的三個功能

1. 接收者覈實發送者對報文的簽名，由於除了A外沒有被人持有A的私鑰，因此除了A外沒有別人產生密文Dska(X)的能力，因此B相信報文X是A簽名發送的——報文鑑別
2. 接收者確信所收到的數據和發送者發送的徹底一致而沒有被篡改過，由於若是其餘人篡改了報文，沒法用A的私鑰SKa對X進行加密，那麼B對篡改的報文進行解密將會獲得不可讀的明文，就知道報文被篡改過，這可保證——報文的完整性
3. 發送者過後不能對報文簽名的抵賴，若A要想抵賴曾發送報文給B，B可把X及Dsk(X)出示進行給公證的第三者——不能否認

 

數字證書

　　「服務器」要對外發布公鑰，那「服務器」如何把公鑰發送給「客戶」呢？咱們第一反應可能會想到如下的兩個方法：

1. 把公鑰放到互聯網的某個地方的一個下載地址，事先給「客戶」去下載。
2. 每次和「客戶」開始通訊時，「服務器」把公鑰發給「客戶」。

　　可是這個兩個方法都有必定的問題，

1. 「客戶」沒法肯定這個下載地址是否是「服務器」發佈的，你憑什麼就相信這個地址下載的東西就是「服務器」發佈的而不是別人僞造的呢，萬一下載到一個假的怎麼辦？另外要全部的「客戶」都在通訊前事先去下載公鑰也很不現實。
2. 由於任何人均可以本身生成一對公鑰和私鑰，他只要向「客戶」發送他本身的私鑰就能夠冒充「服務器」了。

示意以下：

1. 「客戶」->「黑客」：你好           //黑客截獲「客戶」發給「服務器」的消息
2. 「黑客」->「客戶」：你好，我是服務器，這個是個人公鑰    //黑客本身生成一對公鑰和私鑰，把公鑰發給「客戶」，本身保留私鑰
3. 「客戶」->「黑客」：向我證實你就是服務器
4. 「黑客」->「客戶」：你好，我是服務器 {你好，我是服務器}[黑客本身的私鑰|RSA]      //客戶收到「黑客」用私鑰加密的信息後，是能夠用「黑客」發給本身的公鑰解密的，從而會誤認爲「黑客」是「服務器」

　　所以「黑客」只須要本身生成一對公鑰和私鑰，而後把公鑰發送給「客戶」，本身保留私鑰，這樣因爲「客戶」能夠用黑客的公鑰解密黑客的私鑰加密的內容，「客戶」就會相信「黑客」是「服務器」，從而致使了安全問題。這裏問題的根源就在於，你們均可以生成公鑰、私鑰對，沒法確認公鑰對究竟是誰的。 若是可以肯定公鑰究竟是誰的，就不會有這個問題了。例如，若是收到「黑客」冒充「服務器」發過來的公鑰，通過某種檢查，若是可以發現這個公鑰不是「服務器」的就行了。

　　爲了解決此問題，出現的數字證書。

　　數字證書能夠保證數字證書裏的公鑰確實是這個證書的全部者(Subject)的，或者證書能夠用來確認對方的身份。也就是說，咱們拿到一個數字證書，咱們能夠判斷出這個數字證書究竟是誰的

數字證書構成

1. Issuer (證書的發佈機構)：指出是什麼機構發佈的這個證書，也就是指明這個證書是哪一個公司建立的(只是建立證書，不是指證書的使用者)。對於上面的這個證書來講，就是指"SecureTrust CA"這個機構。
2. Valid from , Valid to (證書的有效期)：也就是證書的有效時間，或者說證書的使用期限。 過了有效期限，證書就會做廢，不能使用了。
3.  Public key (公鑰)：這個咱們在前面介紹公鑰密碼體制時介紹過，公鑰是用來對消息進行加密的，第2章的例子中常常用到的。這個數字證書的公鑰是2048位的，它的值能夠在圖的中間的那個對話框中看獲得，是很長的一串數字。
4. Subject (主題)：這個證書是發佈給誰的，或者說證書的全部者，通常是某我的或者某個公司名稱、機構的名稱、公司網站的網址等。 對於這裏的證書來講，證書的全部者是Trustwave這個公司。
5. Signature algorithm (簽名所使用的算法)：就是指的這個數字證書的數字簽名所使用的加密算法，這樣就可使用證書發佈機構的證書裏面的公鑰，根據這個算法對指紋進行解密。指紋的加密結果就是數字簽名(第1.5節中解釋過數字簽名)。
6. Thumbprint, Thumbprint algorithm (指紋(hash值)以及指紋算法(hash算法))：這個是用來保證證書的完整性的，也就是說確保證書沒有被修改過，這東西的做用和2.7中說到的第3個問題相似。 其原理就是在發佈證書時，發佈者根據指紋算法(一個hash算法)計算整個證書的hash值(指紋)並和證書放在一塊兒，使用者在打開證書時，本身也根據指紋算法計算一下證書的hash值(指紋)，若是和剛開始的值對得上，就說明證書沒有被修改過，由於證書的內容被修改後，根據證書的內容計算的出的hash值(指紋)是會變化的。 注意，這個指紋會使用"SecureTrust CA"這個證書機構的私鑰用簽名算法(Signature algorithm)加密後和證書放在一塊兒。

通訊過程：

 「客戶」向服務端發送一個通訊請求：

　　「客戶」->「服務器」：你好

 「服務器」向客戶發送本身的數字證書。證書中有一個公鑰用來加密信息，私鑰由「服務器」持有：

　　「服務器」->「客戶」：你好，我是服務器，這裏是個人數字證書 

「客戶」收到「服務器」的證書後，它會去驗證這個數字證書究竟是不是「服務器」的，數字證書有沒有什麼問題，數字證書若是檢查沒有問題，就說明數字證書中的公鑰確實是「服務器」的。檢查數字證書後，「客戶」會發送一個隨機的字符串給「服務器」用私鑰去加密，服務器把加密的結果返回給「客戶」，「客戶」用公鑰解密這個返回結果，若是解密結果與以前生成的隨機字符串一致，那說明對方確實是私鑰的持有者，或者說對方確實是「服務器」。

　　「客戶」->「服務器」：向我證實你就是服務器，這是一個隨機字符串     //前面的例子中爲了方便解釋，用的是「你好」等內容，實際狀況下通常是隨機生成的一個字符串。

　　「服務器」->「客戶」：{一個隨機字符串}[私鑰|RSA]

驗證「服務器」的身份後，「客戶」生成一個對稱加密算法和密鑰，用於後面的通訊的加密和解密。這個對稱加密算法和密鑰，「客戶」會用公鑰加密後發送給「服務器」，別人截獲了也沒用，由於只有「服務器」手中有能夠解密的私鑰。這樣，後面「服務器」和「客戶」就均可以用對稱加密算法來加密和解密通訊內容了。

　　「服務器」->「客戶」：{OK，已經收到你發來的對稱加密算法和密鑰！有什麼能夠幫到你的？}[密鑰|對稱加密算法]

　　「客戶」->「服務器」：{個人賬號是aaa，密碼是123，把個人餘額的信息發給我看看}[密鑰|對稱加密算法]

　　「服務器」->「客戶」：{你好，你的餘額是100元}[密鑰|對稱加密算法]

 數字證書的應用

假設咱們公司"ABC Company"花了1000塊錢，向一個證書發佈機構"SecureTrust CA"爲咱們本身的公司"ABC Company"申請了一張證書，注意，這個證書發佈機構"SecureTrust CA"是一個你們公認並被一些權威機構接受的證書發佈機構，咱們的操做系統裏面已經安裝了"SecureTrust CA"的證書。"SecureTrust CA"在給咱們發佈證書時，把Issuer,Public key,Subject,Valid from,Valid to等信息以明文的形式寫到證書裏面，而後用一個指紋算法計算出這些數字證書內容的一個指紋，並把指紋和指紋算法用本身的私鑰進行加密，而後和證書的內容一塊兒發佈，同時"SecureTrust CA"還會給一個咱們公司"ABC Company"的私鑰給到咱們。咱們花了1000塊錢買的這個證書的內容以下：

Issuer : SecureTrust CA
Subject : ABC Company
Valid from ： 某個日期
Valid to： 某個日期
Public Key : 一串很長的數字
…… 其它的一些證書內容……
{證書的指紋和計算指紋所使用的指紋算法}[SecureTrust CA的私鑰|RSA]//這個就是"SecureTrust CA"對這個證書的一個數字簽名，表示這個證書確實是他發佈的，有什麼問題他會負責(收了咱們1000塊，
出了問題確定要負責任的)

　　咱們"ABC Company"申請到這個證書後，咱們把證書投入使用，咱們在通訊過程開始時會把證書發給對方，對方如何檢查這個證書的確是合法的而且是咱們"ABC Company"公司的證書呢？首先應用程序(對方通訊用的程序，例如IE、OUTLook等)讀取證書中的Issuer(發佈機構)爲"SecureTrust CA" ，而後會在操做系統中受信任的發佈機構的證書中去找"SecureTrust CA"的證書，若是找不到，那說明證書的發佈機構是個水貨發佈機構，證書可能有問題，程序會給出一個錯誤信息。 若是在系統中找到了"SecureTrust CA"的證書，那麼應用程序就會從證書中取出"SecureTrust CA"的公鑰，而後對咱們"ABC Company"公司的證書裏面的指紋和指紋算法用這個公鑰進行解密，而後使用這個指紋算法計算"ABC Company"證書的指紋，將這個計算的指紋與放在證書中的指紋對比，若是一致，說明"ABC Company"的證書確定沒有被修改過而且證書是"SecureTrust CA" 發佈的，證書中的公鑰確定是"ABC Company"的。對方而後就能夠放心的使用這個公鑰和咱們"ABC Company"進行通訊了。

祕鑰分配

對稱加密密鑰分配

　　密鑰分配中心（KDC），這是一個你們都信任的機構，其任務就是給須要進行祕密通訊的用戶臨時分配一個會話密鑰（僅使用一次），假設A和B都是KDC的登記用戶，A和B在KDC登記時就已經在KDC上安裝了各自和KDC進行通訊的主密鑰Ka和Kb，

1. 用戶A向密鑰分配中心KDC發送時用明文，說明想和用戶B通訊，在明文中給出B在KDC登記的身份
2. KDC用隨機數產生「一次一密」的會話密鑰Kab供A和B此次會話使用，而後向A發送回答報文，這個回答報文用A的密鑰Ka加密，這個報文包含此次使用的Kab和請A傳送給B的一個票據，該票據包括A和B在KDC登記的身份，以及此次會話將要使用的密鑰Kab，票據用B的密鑰Kb加密，A沒法知道票據的內容，由於A沒有B的密鑰Kb
3. 當B收到A傳來的票據並用本身的密鑰Kb解密後，知道A要和他通訊，同時也知道KDC爲此次和A通訊所分配的會話密鑰Kab，此後A和B就能夠通訊了。

公鑰的分配

　　若是每一個用戶都有其餘用戶的公鑰，就能夠實現通訊。

　　若是A想要欺騙B，A向B發送一份僞造是C發送的報文，A用本身的數字簽名和私鑰，並附上本身的公鑰，謊稱是C的，B如何知道這不是C的公鑰呢？

　　認證中心（CA）來發的證書包含公鑰的擁有者和標識信息，此證書被CA進行了數字簽名，任何用戶均可以從可信的地方得到CA的公鑰，來驗證某個公鑰是否爲某個實體全部

參考：http://www.javashuo.com/article/p-cqbqotlb-g.html