安全特性: |
任何一套安全的通信系統在數據傳輸過程當中至少具有如下三個特性:php
1,驗證來源的合法性 2,保證數據的完整性 3,保證數據的私密性
對稱加密: |
對數據的私密性要求,咱們能夠經過對數據進行加解密來完成。以下圖所示:
git
數據加密(encryption):使用一個密鑰(key)並經過一種加密算法將明文(plaintext)
算法
加密成密文(ciphertext)。安全
數據解密(decryption):是數據加密的逆向過程。經過密鑰將密文解密成明文。session
注:圖中加解密的Key能夠是同一個密鑰,也能夠是不一樣的密鑰。併發
根據加解密Key的不一樣將加密體系分爲兩種:ide
1,對稱加密 特色:使用同一個密鑰進行加解密 優勢: 加密速度快 缺點:祕鑰傳遞問題 常見的對稱加密算法有:DES,3DES,AES等 2,非對稱加密 特色:數據傳輸雙方事先都必須產生一對密鑰 一個稱爲公鑰 一個稱爲私鑰 公鑰加密的數據,只有對應的私鑰才能解密 私鑰加密的數據,只有對應的公鑰才能解密 優勢:解決了祕鑰傳遞問題 缺點:加密速度慢 常見的非對稱加密算法有:RSA,DH等
對稱加密圖例:函數
圖注: 發送方利用本身的密鑰(Key)對明文數據進行加密;加密
接收方必須獲得發送方的密鑰(Key);spa
接收方利用發送方的密鑰對密文進行解密;
若是密鑰在傳輸過程當中被第三方獲悉,那這次加密的私密性得不得保障。
對稱加密openssl實現:
加密數據: 格式:openssl enc -ciphername -k password -in file1 -out file2 說明: enc 加密關鍵字 -ciphername 指定加密算法 -k 指定口令關鍵字 password 口令 -in 指定輸入文件(file1) -out 指定輸出文件(file2) 解密數據: 格式:openssl enc -ciphername -k password -d -in file -out file2 說明:-d 解密 其餘參數同上 openssl支持的加密算法:DES,DES3,RC2,RC5,AES256等 實例: 加密: openssl enc -des3 -k 123456 -in test.txt -out test.bin 解密: openssl enc -des3 -k 123456 -d -in test.bin -out test1.txt
非對稱加密: |
非對稱加密圖例:
圖注:首先通信雙方都產生一對密鑰;
數據發送方獲得數據接收方的公鑰;
數據發送方利用數據接收方的公鑰對數據進行加密;
數據接收方利用本身的私鑰對加密數據進行解密;
數據接收方最終獲得明文的數據。
任何一方獲得接收方的公鑰,也解密不了傳輸中的數據。
非對稱加密openssl實現:
產生密鑰對: 格式:openssl genrsa -out file 1024 openssl rsa -in file -pubout 說明: genrsa 使用rsa算法產生密鑰 -out 指定輸出文件 1024 指定算法強度 單位bit rsa 使用rsa算法產生密鑰 -in 指定輸入文件 -pubout 從私鑰中提取公鑰 使用公鑰加密數據: 格式: openssl rsautl -in file -out file -inkey file -pubin -encrypt 說明: rsautl 使用rsautl對文件進行加密 -in 指定輸入文件(須要被加密的文件) -inkey 指定輸入密鑰文件 -pubin 指定-inkey輸入的是一個公鑰文件 -encrpt 表示加密 使用私鑰解密: 格式: openssl rsautl -in file -out file -inkey file -decrypt 說明: -inkey 指定輸入密鑰文件(這裏應該是私鑰文件) -decrypt 表示解密 其餘同上 實例: 產生密鑰對: openssl genrsa -out priv.key 1024 //產生私鑰 openssl rsa -in priv.key -pubout > pub.key //提取公鑰 使用公鑰加密數據: openssl rsautl -in test.txt -out test.bin -inkey pub.key -pubin -encrypt 使用私有解密: openssl rsautl -in test.bin -out test2.txt -inkey priv.key -decrypt
總結:雖然非對稱加密體系實現了密鑰交換的問題,但其自己算法實現複雜致使其加密速度慢。
因而在使用中,人們通常將對稱加密和非對稱加密兩者結合起來使用。
對稱與非對稱結合: |
混合使用之加密圖解:
圖注:首先發送方利用一個隨機數產生了一個對稱密鑰(session key);
發送方利用這個session key對數據進行加密;
發送方拿着接收方的公鑰對這個session key進行加密;
發送方將加密好的數據和加密好的session key發送給接收方;
這種方法既保證了加密速度,又保證了加密密鑰的安全傳送。
混合使用之解密圖解:
圖注:接收方接收到加密的數據和加密的session key;
接收方利用本身的私鑰解密加密的session key;
接收方再利用已解密的session key來解密加密的數據文件;
接收方最終獲得了明文的數據。
總結:雖然混合使用對稱加密和非對稱加密以後,既保證了加密速度,又保證了加密密鑰的安全傳送。
可是始終沒辦法保證來源的合法性。這時候就須要用到數字簽名(Digital Signature)。
數字簽名: |
數字簽名圖解:
圖注:發送方使用本身的私鑰加密數據文件(數字簽名);
接收方接收到這個數字簽名文件;
接收方使用發送方的公鑰來解密這個數字簽名文件;
若是可以解開,則代表這個文件是發送方發送過來的;
不然爲僞造的第三方發送過來的。
對於發送方來說這種簽名有不能否認性。
數字簽名openssl實現:
產生密鑰對: 格式:openssl genrsa -out file 1024 openssl rsa -in file -pubout 使用私鑰完成簽名: 格式:openssl rsautl -in file -out file -inkey file -sign 說明: -inkey 後面跟私鑰 -sign 表示簽名 使用公鑰校驗簽名: 格式:openssl rsautl -in file -out file -inkey file -pubin -verify -inkey 後面跟公鑰 -verify 表示校驗簽名 實例: 簽名: openssl rsautl -in test.txt -out test.sig -inkey priv.key -sign 校驗簽名: openssl rsautl -in test.sig -out test3.txt -inkey pub.key -pubin -verify
總結:非對稱加密中,公鑰加密,私鑰解密。主要用來進行數據加密。
私鑰加密,公鑰解密。主要用來進行數字簽名和認證。
到目前爲止,解決了數據傳輸過程當中數據私密性和來源合法性的問題。可是數據的完整性有靠什麼來保障呢?這就要利用散列函數來實現。
散列函數: |
散列函數的特色:
1,輸入能夠是任意長度 但輸出是定長的。MD5 128bits SHA1 160bits
2,加密過程不可逆,沒法根據特徵碼還原原來的數據
3,雪崩效應 輸入的一點點改變 會致使結果發生很大改變
4,輸入一致,輸出必然相同
注:不一樣的輸入,可能會有一樣的輸出。可是機率很小 並不表明沒有這種可能
常見的散列函數(Hash函數):
1,MD5
2,SHA1
散列函數openssl實現:
產生一個文件的MD5值: 格式: openssl dgst -md5 file md5sum file 產生一個文件的SHA1值: openssl dgst -sha1 file sha1sum file 實例: openssl dgst -md5 openssl-0.9.8h.tar.gz md5sum openssl-0.9.8h.tar.gz openssl dgst -sha1 openssl-0.9.8h.tar.gz sha1sum openssl-0.9.8h.tar.gz
總結:散列函數能夠根據任意長度的輸入,生成定長的摘要信息。這樣能夠用來校驗文件的完整性。
防止數據在傳輸過程當中被第三方篡改。
安全數字簽名: |
安全數字簽名圖解:
圖注:發送方利用散列函數對明文數據進行Hash獲得摘要信息;
發送方使用本身的私鑰對摘要信息進行簽名;
接收方利用發送方的公鑰來驗證來源的合法性;
接收方利用摘要信息來驗證數據的完整性;
注:
當源文件很大,若是對源文件進行簽名,就會比較耗費時間。
若是隻對摘要信息進行簽名,速度比較快,由於它是定長的且位數不長。
中間人***: |
利用散列函數咱們能夠用來保證數據的完整性。使用對稱加密和非對稱加密體系來完成數據的機密性和驗證來源的合法性。但驗證來源的合法性其實存在一個缺陷,就是怎麼保證公鑰的合法性?咱們來看下圖中的例子:
圖注:假設Alice想向Bob發送一個文件。
首先Alice得獲得Bob的公鑰;
可是很不幸,Alice獲得的是Hacker使用本身的公鑰假裝成Bob的公鑰;
因而Alice拿着這個假裝的公鑰對文件進行加密,併發送給Bob;
但不幸的事情又發生了,這個加密文件被Hacker截獲;
因而,Hacker獲得了文件的內容;
Hacker對原文件可能進行篡改/也可能不會篡改;
這樣看Hacker的目的;
因而Hacker利用Bob真正的公鑰對文件進行加密;
而後發送給Bob;
整個過程對Bob和Alice來講全然無知。
經過上圖,咱們看出要想實現對公鑰來源合法性進行驗證。就必須得引入另外一個角色。首先數據通信雙方都得信任這個角色。也就是這個角色具備權威性。其次,這個角色能夠幫助通信雙方安全完成公鑰交換。咱們一般把這樣一個角色或機構稱爲CA。
引入CA: |
利用CA完成整個安全通信過程:
圖注:
1,首先必須保證CA爲數據通信雙方都承認的機構;
2,數據通信雙方向CA提交認證申請。裏面包含各自的公鑰;
3,CA分別對通信雙方的合法性進行驗證;
若是驗證經過,CA則利用本身的私鑰分別對兩份申請文件
進行加密(數字簽名)。最終產生一個由CA完成數字簽名的文件。
咱們把這個文件稱爲數字證書。
4,通信雙方各自下載由CA簽發的數字證書;
5,假設Alice想要發送一個文件給Bob;
6,首先Alice得向Bob請求獲得Bob的數字證書;
7,Alice利用CA的公鑰完成對Bob數字證書合法性認證,
而且從證書中獲得Bob的公鑰。
8,Alice利用散列函數對數據進行Hash產生摘要信息;
並經過程序隨機生成一個session key,
利用這個session key對數據進行加密;
Alice再利用Bob的公鑰對這個session key進行加密;
9,Alice將本身的證書和加密後的文件(包含session key)一併發送給Bob;
10,Bob接收到Alice發來的文件後,先用CA的公鑰來驗證文件來源的合法性。
若是合法,則利用本身的私鑰對session key進行解密,
再利用session key對數據進行解密,獲得明文數據。
而後,利用散列函數對數據進行Hash獲得摘要信息。
將本身獲得的摘要信息和Alice發過來的摘要信息進行比對,
若是一致,則代表數據沒有被篡改。安全通信完成。