密碼學淺析

前言

早期的tcp/IP定位的直接就是可以更好的實現主機之間的通訊，並無過多的考慮安全問題。隨着互聯網規模的擴大以及鳥大了什麼林子都有的原則，ftp、http、smtp、telnet這些協議都是明文傳輸的，很容易被不法分子利用，安全問題逐漸被人們重視，在互聯網領域當中密碼學是

安全的重要保障，密碼學不是一項技術，而是科學，而且作爲國家軍事戰略高度的科學，對於咱們普通人來說，密碼學就是數據加密的機制。

加密的本質是一種轉換規則。

常見的加密方式有三種：對稱加密，非對稱加密，單向加密

總結：由於應用的某些協議不安全，因此在應用層在傳輸層又加了半層，這半層以被稱爲TLS某種SSL，不管是TLS仍是SSL，主要都是利用密碼學來實現的，而密碼學對咱們這些使用者來說就是一種轉換規則，常見的加密方式又被分爲三種：對稱加密，非對稱加密，單向加密。

補充：

 

SM3中國首個hash算法

所謂的破解並非經過密文推導出明文，而是找到了兩個hash同樣的數據。

所謂的數字簽名就是CA用本身的私鑰加密從數據中提取出來的特徵碼，實現了身份驗證和數據的完整性。

算法並不依賴於算法的自己，而是依賴於密鑰，算法自己不少都是公開的

---

對稱加密和非對稱加密

數據加密：公鑰加密不多用到數據的加密的，由於太慢，密鑰太長，對稱加密比非對稱加密快1000倍左右，公鑰的主要舞臺用於身體驗證。加密數據的話通常要使用對稱加密，加密完成以後的對稱密鑰再用非對稱密鑰加密。

數字簽名：數字簽名的主要目的是讓接收方知道數據的確是發送方發送的，用於用戶身份驗證，發送方生成一段數據，用本身的私鑰加密這段數據而後發給接收方，接收方經過發送方事先公開的公鑰就是確認發送方的身份。

密鑰交換：所謂的密鑰交換我認爲是在SSL的基礎上理解上,好比bob把本身的證書發送給alice,而alice會生成一個對稱密鑰,經過bob給的證書當中的公鑰加密這個對稱密鑰以後發送給bob.,密鑰交換能夠這樣理解,經過非對稱密鑰來完成對對稱密鑰的交換.

小結：

發送方用本身的私鑰加密數據（數字簽名），可以實現數據的身份驗證，可是不能實現數據的機密性。

發送方用對方的公鑰加密數據（密鑰交換），能夠保證的數據所機密性，但不能夠身體驗證。

 

舉例：

A給B發送一段數據，B要確認是這A發的(身份驗證)，數據沒有被修改過（完整性），並不用保證數據的機密性。

A--------------->>------------B

答：A經過單向加密對數據提取一段特徵碼附加在文件的尾部，而後A經過本身的私鑰僅僅加密最後一段特徵碼便可（數字簽名），當B收到以後經過A事先公開的公鑰實現對身份的驗證，解開被加密後的特徵碼以後能夠獲得真正的特徵碼，而後B經過一樣的單向加密算法，對數據進行單向提取特徵碼，經過與發送方發過來的特徵碼作比較來完成數據完整性的較驗。

A--------->-----C-------->--------B

這個過程有沒有可能被人破壞呢？是有可能，仍是使用上述方式：「A對數據提取特徵碼附加在數據的尾部，而後經過本身的私鑰加密發送給B。「  B想要解密A加密的特性碼，確定在加密A發送的數據前獲取A的公鑰，那麼問題來了，B怎樣才能得到A的公鑰呢？通常就是A主動把本身的公鑰發送給B，可是路上仍是有C在攔截，C徹底有可能把A發送給B的公鑰給截獲了，而後本身生成一對密鑰，C把本身的公鑰發送給B並說明本身就是A，而後B就相信了。當A給B發送真正的數據時，又被C給截獲了，C即便不用A的公鑰加密也徹底可以看到A發送給B的內容，固然C的野心不只僅是查看內容這麼簡單，C一般會把A給B發送的數據扔掉，而後本身生成一段數據（固然這段數據多是辱罵B的數據）而後本身用單向加密提取特性碼附加到數據的尾部，C再經過本身的私鑰加密特性碼以後發送給B，這時B還會拿着本身認爲的A的公鑰去解密特性碼，而後對數據作一次單向提取以後與「A」發來的的特性碼對照，通過對照發現這個辱罵本身的數據就是A發送的，因而C與A絕交。

 

三種算法放到一塊，讓A與B通訊一次，而且保證不讓C破壞

A-------------->>-------------B

仍是A給B發送一個數據，而且要保證這個數據只能是B收到，而且不能被人篡改僞造。

  

第一步經過單向加密對數據提取特徵碼附加在數據的尾部，這是在原有的公鑰上面附加了信息，原有的公鑰沒有變化。

第二步經過本身的私鑰對特徵碼進行加密，這是把hash經過私鑰（轉換規則）進行了轉換，並無附加信息。

第三步而後把公鑰+被私鑰加密後的hash這兩部分進行一次對稱加密，這次加密遺留了一個對稱密鑰沒處存放。

第四步而後經過對方的公鑰對對稱密鑰再加加密一次。

 

1. 當B收到以後，首先經過本身的私鑰打開對稱密碼，這裏能夠實現機密性，這個數據只有本身能夠打開。
2. 用對稱密鑰，再打開被加密後的內容（公鑰+被本身私鑰加密後的HASH），這裏什麼也沒實現，若是硬說實現了什麼的話，那就是實現了效率，其實在這裏就能夠看到，是哪一個CA給A發的證書。
3. 若是本身本地沒有此CA的數字證書的話，就顯示不信任的證書頒發機構，若是本地有此CA的數字證書會進一步進行驗證，嘗試是否能打開「被CA私鑰加密後的hash」，若是能打開就實現了身份驗證，說明此公鑰的確是CA給頒發的。
4. 別急，還沒完呢！再把A的公鑰和附加信息hash一遍，而後與A發來的HASH進行對比，這一步能夠實現完整性的校驗。B（一般是客戶端瀏覽器）應該還要檢查此證書是否在證書頒發機構的吊銷列表裏面，還要再查看客戶端訪問的URL是否與公鑰裏面的信息如出一轍，不同也不行。

一次通訊，三次加密算法都用上了。

這種通訊機制當中仍是存在了一個問題，依然存在着傳輸密鑰時被C給截獲的風險，依然是不安全

 

---

 PKI(Public Key Infrastructure)公鑰基礎設施

本小節主要介紹了：

l  公鑰基礎設施的概念和x509證書的格式

l  CA數據簽名的過程以及客戶端驗證CA證書的過程

l  QQ是怎樣實現加密的 

PKI的全稱爲public key infrastructure公鑰基礎設施，這是一個統稱，就像新華電腦學院是多個專業的統稱同樣，其實公鑰基礎設施由四個部分組成，以下圖：

 

   證書存取庫：未來咱們向CA申請證書的時候就是向證書存取庫裏面申請的。如今證書存取庫發放的證書都是X.509的格式，X.509不只僅是一種證書格式仍是證書的規範，有三個版本，咱們如今使用的都是它的第三版證書，它定義了一個規範的證書裏面應該包括：

 

 

CA是怎樣給某個主機進行發證的呢？

第一步：CA想要給別人發證，首先本身得有私鑰和公鑰。私鑰用來給來申請的主機進行數字簽名，公鑰是要發給客戶端的，用來實現對CA的身份驗證，咱們講過的：「使用本身的私鑰加密，讓別人經過公鑰打開，能夠實現身份驗證而不能實現數據的機密性」。

第二步：CA僅有私鑰和公鑰還不成，還要有本身的數字證書。爲何要本身有證書呢？一個CA爲了方便用戶的驗證是要把本身的公鑰公佈於衆的，可是並非直接把本身的公鑰直接公佈出去，而是把本身的數字證書公佈出去（數字證書裏面有本身的公鑰），爲何要這麼作呢？直接公佈公鑰不成嗎？直接公佈公鑰是頗有可能被中間人僞造的，因此要公佈本身的數字證書，這樣方便用戶的驗證。實際上用戶導入CA數字證書的機會不多，由於通常主流的操做系統在發行時都已經把最多見的CA機構的數字證書內置到了操做系統內部了，可是也有沒有導入的CA，好比12306網站使用的CA。CA是給別人發證的，那麼CA本身的證書是誰給它發的呢？答案是本身給本身發的，那麼怎樣才能本身給本身發證呢？是這樣的，過程是很簡單的，CA把本身的公鑰和一些必須要填報的信息：好比主體名稱，國家，城市，等等經過一個文件本身提交給本身，覈實無誤而後再用本身的私鑰對這個請求文件進行數字簽名，簽過名以後就會生成一個數字證書。那麼簽名的過程是怎樣的呢？因爲CA是本身給本身發證，因此提交請求以後並無進行驗證，若是在真實的環境某主機給CA提交請求的話，CA機構會派人到該公司裏內部覈對申請的信息是否真實，有營業執照、公網IP，責任人等等確認無誤以後，CA會經過單向加密，把主機提交的請求文件提取一個特徵碼附加在文件的尾部，而後經過本身的私鑰僅對特徵碼進行加密，注意簽名的過程並無對數據進行加密，加密的只是文件尾部的特徵碼，被加密過的文件特徵碼申請信息就組成一個數字證書，生成數字證書的過程就是數字簽名。從CA給企業頒發證書的這個過程來看，僅僅實現了一個完整性的校驗，對於機密性和身份認證都不能實現 ，由於在這個階段，企業尚未數字證書，最好的方式就是企業拿着U盤去CA把CA的數字證書拿過了，這樣最爲保險，固然也可讓CA把本身的數字證書送過來，其實這一步，通常是用不着用戶作的，系統通常都會把經常使用CA的數字證書給安裝好了。

第三步： CA將作簽名的證書而後送回給申請的公司，申請的公司將把這個數字證書導入到須要使用的此證書的應用程序的主目錄當中，好比，httpd會放到/etc/httpd/當中

NOTE：這個過程在下面的實驗當中有演示。

用戶怎樣驗證對方發來的證書是可信的呢？在描述驗證之前咱們應該明確一點，操做系統在發行時通常都會將市面上最多見，最權威的CA機構的公鑰內置到操做系統的內部以方便用戶的驗證。

第一步：當alice把本身的證書（固然此證書必定要是某CA機構簽署頒佈的）發送給bob時，bob爲了驗證alice就是alice而不第三方假裝的，就要先打開alice給的數字證書，首先查看發行者（CA）的名稱，若是此CA的名稱與系統內置的某一個CA的名稱重合，重合意味着系統內置了此CA的公鑰，反之，就認爲此CA機構不可信任。

第二步：bob經過系統內置的CA公鑰去驗證發行者（CA）的簽名，怎樣驗證呢？咱們在上面講過，CA給alice簽名就是「CA用本身的私鑰對alice申請文件的特徵碼作加密」，因此bob只要用CA的公鑰可以打開CA對alice的私鑰簽名就證實alice是確認是這個CA頒佈的證書，咱們在前面提過：」用本身的私鑰加密能夠實現身體驗證，因此在這裏bob可以用CA的公鑰打開CA的簽名就表示alice的證書就是信任的CA頒發的證書，到了這一步僅僅能說明證書裏面的數據多是正確的，爲何？由於證書裏面的版本號、序列號、主體公鑰等等都沒有加密，僅僅是提取的特徵碼被加密而已，裏面的信息仍是有可能被中間人修改的。

第三步：第三步解開的是證書內部的：」版本號，序列號，主體公鑰，主體名稱等等「這些信息的特徵碼，bob還要經過單身加密計算出這些信息的特徵碼，而後經過本身的計算出的特徵碼與CA公鑰打開的特徵碼作比較，若是同樣，就表示證書內全部的信息都是完整的，可靠的。

第四步：客戶端檢查證書是否位於證書吊銷列表當中，大部分瀏覽器都沒有作最後一步，爲了保險期間咱們最好人工去查看一下。

如今互聯網的證書主要有兩種，一種是我的證書，一種是主機證書。銀行給的U盾，U盾裏面存放的就是用戶本身的數字證書，當咱們須要用電腦在網上轉帳的時候，服務器會把咱們的http請求自動轉換爲https，轉換爲https的過程就是用戶去驗證服務器的數據證書的過程，這是單向的驗證，咱們在淘寶上付款時也是這樣的，可是銀行轉帳客戶端不只要驗證服務器的數字證書，銀行還要驗證用戶的數字證書，而用戶的數字證書就在銀行給的U盾裏面，這個U盾裏保存的數字證書就是我的證書，我的證書與主機證書最大的不一樣是主機證書的主體名字上寫的是主機的名字，好比www.taobao.com而用戶的數字證書上的主體名稱是用戶的姓名，好比馬雲。固然最爲經常使用的仍是主機證書，在這裏須要注意的是證書裏面的主體名必定要與真正主機的主機名要一致，否則的話，業務會失敗.

CA

1.         生成一對密鑰。

2.         利用公鑰和申請信息產生一份申請文件提交給本身（此文件當中包括本身的公鑰）。

3.         本身生成本身的數字簽名證書：CA先利用hash提取出這個文件的特徵碼附加到文件的尾部，而後本身的私鑰對此特徵碼加密，注意，文件並無加密。

4.         將此數字簽名證書公佈於衆，各大操做系統的發行商會將其集成到本身的操做系統當中。

HTTPS

1.         生成一對密鑰

2.         利用公鑰和申請信息產生一份申請文件提交給CA（此文件當中包括本身的公鑰）。

3.         CA對申請信息覈實無誤以後，會生成數字簽名證書：CA先利用hash提取出這個文件的特徵碼附加到文件的尾部，而後本身的私鑰對此特徵碼加密，注意，文件並無加密。

4.         CA將此數字證書給HTTP，HTTP會將其放置到本身的工做目錄的。

Client

Client默認就是有CA本身的數字簽名的，也就是說用戶有CA的公鑰，發行商集成的嘛！

1.         當客戶端訪問網站時，固然先創建虛鏈路、而後附加TLS通道，服務器會把CA簽名過的數字證書發送給客戶端。

2.         客戶端驗證，怎樣驗證呢？用CA的公鑰嘗試打開網站給的數字證書當中被加密後的特徵碼，若是打開了就實現了身體驗證，打開以後利用hash進一步驗證完整性。

3.         客戶端拿到網站的公鑰以後會隨機生成對稱密鑰，經過公鑰加密以後發送給網站，而後後面它們加密的數據都是用對稱密鑰處理以後再發送。

QQ的加密通訊:

當數據從資源子網交給通訊子網以後，數據會被封裝，可是封裝並無改變資源子網的數據，若是有人能夠獲取到這些包的話就能夠看到通訊子網當中的內容。可能有人說不會呀？我用QQ發送的數據即被抓到包也看不到裏面發送的明文，這是怎麼回事呢？其實「資源子網把數據給通訊子網以後數據並無改變」這個原則並無改變，只不過是QQ這個軟件自己實現了數據加密的功能（有的資源子網的協議或者軟件可自行實現數據的加密，而有的協議或者軟件自己是不支持加密的，像早期的QQ就不支持加密），像這樣的案例還有，好比ftp，當咱們使用ftp的時候就能夠抓住ftp要傳輸的內容包括密碼，若是咱們在網上轉帳呢？這豈不是太不安全了，其實這是有解決辦法的。像ftp這種資源子網當中的協議自己不能加密，而通訊子網又不能改變數據的內容，只要在資源子網在通訊子網之間加上半層，讓這半層專門實現加密功能來加密數據。

---

TLS和SSL

SSl（安全的套接字層）和TLS（transport layer security）傳輸層安全

PKI是公共密鑰基礎設施，是爲了數據可以安全可靠的傳輸，實質上這種設施是爲了應用程序準備的，好比http（超文本傳輸協議）這個協議本來只能傳輸明文沒有加密的機制，很是的不安全可靠，可是如今不一樣的了，有了公共密鑰基礎設施，咱們就能夠在http的基礎上使用公共密鑰基礎設施，怎樣使用呢？
OSI參考模型在之因此是七層很大緣由就是某一層的調整並不會影響到其餘層，咱們在應用層和傳輸層中間再放半層，用這半層專門來實現對PKI的應用，憑什麼這半層可以實現加密，就是由於這半層的主要任務就是協商加密方式，對數據進行加密，驗證對方的數字證書，講到這裏，咱們知道了，協商加密方式，對要傳輸的數據加密，驗證對方的證書並非計算機完成的，而是由這半個中間層完成的,那麼這半個層就是TLS或者是SSL.

那麼究竟是TLS仍是SSL呢?它們兩個是什麼關係呢? SSL（安全的套接字層）是網警一個公司爲本身的瀏覽器的研製出的協議，後來微軟戰勝的IE戰勝.後來國際標準化組織也搞了出了一個協議就叫TLS（傳輸層安全協議），TLS如今是初版，至關於SSL的第三版，原理和機制差很少，那麼咱們下面再講的時候是不加以區分的。有的軟件僅支持SSL，有的僅支持TLS，有的兩種協議都支持.

半層？一層？

那麼爲何說這個中間層只有半層而不是一層呢？是這樣的，以下圖：

 

 

當http不使用TLS或者是SSL層的時候傳輸的都是明文，當http使用TLS或者SSL的時候就變成了https，傳輸的不一樣進明文而是密文,因此咱們可使用tls也能夠不使用,這一層並非必需存在的,因此這是說這是半個層而不是一個整層.

SSL只能基於IP地址的訪問，而不能根據主機名來實現，由於SSL它終究不是應用層的的應用或者協議，它是位於應用層與傳輸層之間的庫，SSL握手的時候只能基於IP，而不能基於主機名，是由於在使用基於主機名的訪問的時候主機名是封裝在應用層的，SSL能夠讀取到網絡層的可是讀取不到應用層的信息，因此不管是哪一個虛擬主機,只要是IP同樣,SSL都會當成一個會話來看待,一個IP地址基於一個應用層協議只能創建一個會話.

http VS https

本小節主要介紹了http和https的會話過程:

http的會話過程:

1. 客戶端把請求發送到服務器上,服務器上的內核根據請求包當中的目標端×××給http服務
2. http根據請求到的內容讓內核去硬件當中調用數據,交給http進程
3. http構建響應報文根據套接字回覆到客戶端並記錄日誌

https的會話過程:

1.    客戶端向服務器發起請求

2.    服務器先要跟客戶端協商到底使用SSL還有sls協議的哪一個版本，這是雙向的過程 。

3.    服務器會把本身的證書發給客戶端（客戶端通常沒有證書），客戶端是看簽署的CA是否是本身信任的，信息是否完整，拿到服務器的公鑰。

4.    客戶端會生成一個隨機會話對稱祕鑰，經過服務器端的公鑰加密以後發送給服務器

5.    服務器端就能夠這個對稱祕鑰進行使用了

 

補充：

diffie-hellman算法補充一下，在上文當中沒有介紹，這種算法在IPSEC-*** 和SSH當中會見到，其原理就是經過交換一些材料，進而推斷出密鑰，而不是直接交換密鑰。