Linux下數據傳輸安全與加密

概述：兩個計算機在互聯網上通訊時，它們之間發送的信息若是不通過特殊的處理，即加密機制，很容易被其餘人給獲取到，若是是普通的信息，那卻是無所謂，可是若是涉及到我的的私密信息，那這樣豈不是很糟糕，本篇來講一下這個安全和加密機制。

---

加密算法和協議：

    對稱加密：數據加密（保密性）（3DES,AES)

    公鑰加密：身份認證、密鑰交換、數據加密（不經常使用，比對稱加密要慢3個數量級）（RSA,DSA）

    單項加密：數據完整性（MD5,SHA）

    密鑰交換：RSA、DH（迪菲-赫爾曼）、ECDH（橢圓曲線DH）、ECDHE（臨時橢圓曲線DH）

****************************************************************************************************

對稱加密：加密和解密使用同一個密鑰
    DES：Data Encryption Standard，56bits
    3DES：
    AES：Advanced (128, 192, 256bits)
    Blowfish，Twofish
    IDEA，RC6，CAST5
特性：
    一、加密、解密使用同一個密鑰，效率高
    二、將原始數據分割成固定大小的塊，逐個進行加密
缺陷：
    一、密鑰過多
    二、密鑰分發
    三、數據來源沒法確認

非對稱加密算法：即公鑰加密

公鑰加密：密鑰是成對出現
    公鑰：公開給全部人；public key
    私鑰：本身留存，必須保證其私密性；secret key
特色：用公鑰加密數據，只能使用與之配對的私鑰解密；反之亦然
功能：
    數字簽名：主要在於讓接收方確認發送方身份
    對稱密鑰交換：發送方用對方的公鑰加密一個對稱密鑰後發送給對方
    數據加密：適合加密較小數據
缺點：密鑰長，加密解密效率低下
算法：
    RSA（加密，數字簽名）,DSA（數字簽名）,ELGamal

具體實現：

▲基於一對公鑰/密鑰對
    用密鑰對中的一個加密，另外一個解密

▲實現加密

    接收者
    生成公鑰/密鑰對：P和S
    公開公鑰P，保密密鑰S
    發送者
    使用接收者的公鑰來加密消息M
    將P(M)發送給接收者
    接收者
    使用密鑰S來解密：M=S(P(M))

單項加密

將任意數據縮小成固定大小的「指紋」
    任意長度輸入
    固定長度輸出
    若修改數據，指紋也會改變（「不會產生衝突」）
    沒法從指紋中從新生成數據（「單向」）
功能：數據完整性
常見算式
    md5: 128bits、sha1: 160bits、sha224
    sha25六、sha38四、sha512
經常使用工具
    md5sum | sha1sum [ --check ] file
    openssl、gpg
    rpm -V

密鑰交換

密鑰交換：IKE（Internet Key Exchange ）
    公鑰加密：
    DH (Deffie-Hellman)：
DH：
一、A: a,p協商生成公開的整數a,大素數p
     B: a,p
二、A:生成隱私數據:x (x<p )，計算得出a^x%p，發送給B
    B:生成隱私數據:y,計算得出a^y%p，發送給A
三、A:計算得出（a^y%p）^x = a^xy%p，生成爲密鑰
    B:計算得出（a^x%p）^y = a^xy%p, 生成爲密鑰

此時，A和B便生成了一個相同的密鑰，注意這個密鑰交換協議算法只能用於密鑰的交換，而不能用於消息的加密處理，當雙方肯定要用的密鑰後，要使用其餘的對稱加密操做實際加密和解密數據

****************************************************************************************************

注意，以上所說的加密算法和協議雖然可以實現兩個兩個計算機之間的加密通訊，但是保證不了其餘計算機的干預消息。

例如：A和B是互聯網上的兩臺主機，A擁有本身的私鑰，B擁有本身的私鑰，此時如若A要給B發送消息，可是第一次它並不知道誰是B，若是此時有另外一臺機器C告訴A說我就是B，而後把本身的公鑰發送給A，A此時還覺得和它通訊的真的是B，然而倒是A和C在通訊。

    那麼問題來了，如何肯定B的身份呢？若是此時有一個雙方都信任的第三方機構，由它來確認B的身份，那麼問題就能夠解決了，隨之而來的是誰來肯定這個第三方機構的身份呢，若是是一個假的機構呢？因此還須要這個機構的上級來肯定它，知道到了頂層。固然這個頂層是咱們全部人在心底都默認知道和了解的。

    說了這麼多，這個所謂的第三方機構就叫作CA，當CA每確認一臺機器的時候，就會給它頒發一個證書，具體以下:

CA和證書

PKI: Public Key Infrastructure
    簽證機構：CA（Certificate Authority）
    註冊機構：RA
    證書吊銷列表：CRL
    證書存取庫：

X.509：定義了證書的結構以及認證協議標準
    版本號
    序列號
    簽名算法
    頒發者
    有效期限
    主體名稱
    主體公鑰
    CRL分發點
    擴展信息
    發行者簽名

證書類型：
    證書受權機構的證書
    服務器
    用戶證書

獲取證書兩種方法：
    使用證書受權機構
        生成簽名請求（csr）
        將csr發送給CA
        從CA處接收簽名
    自簽名的證書
        自已簽發本身的公鑰

證書籤發過程：以下圖所示

一、A將本身的公鑰發送給CA

二、CA在肯定A的身份後，會將證書頒發給A，其中過程以下

    1）CA會將應有內容整合到證書上，證書的內容結構如上。

    2）而後將此內容使用單向加密算法生成特徵碼（用於驗證證書完整性）

    3）最後，CA會使用本身的私鑰來對此特徵嗎進行加密，生成數字簽名（用來驗證是否爲CA簽署的證書），而後發給A

3）B的過程與A相同

當B驗證A的身份時，就是經過證書來驗證的，步驟以下

    1）使用CA的公鑰來解密數字簽名，若是成功，則驗證了CA身份

    2）利用相同的單項加密算法來計算證書內容結構的特徵碼，與原來的特徵碼相比較，若是相同，則保證了證書的完整性

    3）從證書內容中取出A的公鑰

---

加密通訊過程詳解：

1）

第一階段：ClientHello：客戶端向服務器端發起加密通訊的請求

    向服務器發送本身支持的協議版本，好比tls1.2

    客戶端生成一個隨機數，稍後用戶生成」會話密鑰「

    本身支持的各類加密算法，好比AES，RSA；、

    支持的壓縮算法；

第二階段：ServerHello（迴應）

    確認使用的加密通訊協議版本，好比tls1.2；（若是版本不同，則拒絕通訊）

    服務器端生成一個隨機數，主要在稍後用戶生成」會話密鑰「

    確認使用的加密方法

    發送服務器證書

    索要客戶端證書（不過通常服務器端都不會驗證客戶端）

第三階段：

    驗證服務器證書，確認無誤後，取出其公鑰；（驗證發證機構、證書籤名、證書完整性、證書持有者、證書有效期、吊銷列表）

    發送一下信息給服務器端

    一個隨機數：用於服務器公鑰加密

    編碼變動通知：表示隨後的信息都將用雙方商定的加密方法和密鑰發送

    客戶端握手結束通知

第四階段：

    收到客戶端發來的第三個隨機數-pre-master-kty後，計算生成本次會話用到的會話密鑰

    向客戶端發送以下消息：

    編碼變動通知：與上相同

    服務器端握手結束通知

此時雙方已經彼此確認了對方的身份，而且創建一條安全的通道，接下來就能夠傳輸信息了。此過程以下圖所示

（1）A-->B

    1）使用單向加密算法計算要傳輸的數據的特徵碼（並無對原數據內容加密）

    2）使用本身的私鑰來加密這段特徵碼生成數字簽名

    3）使用對稱加密算法加密上面的全部數據（包括原數據，特徵碼，數字簽名），將生成的對稱加密的密碼附加在加密過的數據後面

    4）使用B的公鑰來加密這段對稱加密的密碼，並將以上全部數據發送給B

（2）B收到A發送的數據後

    1）使用B的要來解密對稱加密的密碼（若是能夠解密，則保證接收放是B）

    2）利用解密過的對稱加密密碼來解密這段數據

    3）解密後經過利用A的公鑰來解密數字簽名（若是能夠，則保證了數據是從A發的）

    4）此時，呈如今B的有兩樣東西，一個是原數據，還有一個是特徵碼。且原數據是沒有加密的。此時B須要使用相同的單項加密算法對此時的原數據計算特徵碼，與A發送過來的特徵碼相比較，若是相等，則保證了原數據的完整性。

    至此。信息的加密與解密過程完成。

    

---

總結：

    在以上所述的過程當中，我的認爲有幾點須要強調：

1）單項加密並不加密原數據，只是爲了計算原數據的特徵碼。用於數據的完整性校驗

2）對稱加密算法加密和解密都是用同一個密鑰。用於加密數據

3）公鑰加密加密的是特徵碼。用於生成數字簽名

4）證書的頒發和驗證過程和數據的傳輸過程是兩個過程