一牙寞、加密和解密相關知識簡介
1袜啃、信息安全標準
NIST（National Institute of Standards and Technology）美國國家標準與技術研究院，制定了網(wǎng)絡信息安全與保密的三個要素：（這三大要素被簡稱為：CIA）
- 保密性(confidentiality)：信息不泄露給非授權用戶崔拥、實體或過程极舔，或供其利用的特性。（一般包括數(shù)據(jù)保密性链瓦、隱私性拆魏。）
- 完整性(Integrity)：數(shù)據(jù)未經(jīng)授權不能進行改變的特性。即信息在存儲或傳輸過程中保持不被修改慈俯、不被破壞和丟失的特性渤刃。（一般包括數(shù)據(jù)完整性、系統(tǒng)完整性贴膘。）
- 可用性(Availability)：可被授權實體訪問并按需求使用的特性卖子。即當需要時能否存取所需的信息。例如網(wǎng)絡環(huán)境下拒絕服務刑峡、破壞網(wǎng)絡和有關系統(tǒng)的正常運行等都屬于對可用性的攻擊洋闽；
盡管三要素能保證網(wǎng)絡信息安全和保密，但從很多從事網(wǎng)絡安全的研究人員的反饋發(fā)現(xiàn)突梦，除了CIA外诫舅，還有另外兩個標準也被經(jīng)常提醒：
- 真實性：一個實體是真實的，是可被驗證的宫患。要確保數(shù)據(jù)發(fā)送方的確是它所聲稱的那個人刊懈。
- 可追溯性：一旦受到攻擊，能追溯攻擊發(fā)生的原處在什么地方撮奏。
2俏讹、OSI組織定義的安全框架x.800
安全攻擊：
- 被動攻擊：竊聽、（常見報文捕獲畜吊、監(jiān)聽流量）
- 主動攻擊：偽裝泽疆、重播、消息修改玲献、拒絕服務
安全機制：
- 加密殉疼、數(shù)字簽名梯浪、訪問控制、數(shù)據(jù)完整性瓢娜、認證交換挂洛、流量填充、路由控制眠砾、公證
安全服務：
- 認證 ：同等實體認證
- 訪問控制
- 數(shù)據(jù)保密性：連接保密性虏劲、無連接保密性、選擇域保密性褒颈、流量保密性
- 數(shù)據(jù)完整性 ：不允許插入柒巫、刪除、修改谷丸、重播
- 不可否認性
3堡掏、加密方式和算法
(1)、對稱加密
對稱加密：采用單鑰密碼系統(tǒng)的加密方法刨疼，同一個密鑰可以同時用作信息的加密和解密泉唁。
對稱加密的算法：
DES : 數(shù)據(jù)加密標準（56位密鑰）
3DES
AES ：高級加密標準（128，192揩慕，256亭畜，384，512）
Blowfish
Twofish
IDEA
RC6
CAST5
對稱加密的特性：
- 加密漩绵、解密使用同一口令贱案；
- 將明文分隔成固定大小的塊，逐個進行加密
對稱加密的缺陷：
- 密鑰過多止吐；
- 密鑰傳輸；
密鑰交換侨糟、身份驗正碍扔、數(shù)據(jù)完整性
(2)、公鑰加密
公鑰加密：由對應的一對唯一性密鑰（即公開密鑰和私有密鑰）組成的加密方法秕重。
密鑰：public key, secret key （p/s）
公鑰是從私鑰中提取出來的不同。
公鑰加密，只能私鑰解密溶耘。私鑰加密二拐，也只能公鑰解密。
常用加密算法：
RSA
DSA:只能用于身份驗證
EIGamal
(3)凳兵、單向加密
單向加密：不可逆的加密
單向加密特性：
- 定長輸出: 無論原始數(shù)據(jù)是多大百新，結果大小都相同的
- 雪崩效應: 輸入的微小改變，將會引起結果的巨大改變
單向加密算法：
MD5（128位）庐扫、SHA1饭望、SHA256仗哨、SHA384、SHA512
二铅辞、加密和解密的過程和原理
首先問一個問題：
假設B與A通信厌漂，B向A發(fā)送報文，怎么才能保證B的報文安全斟珊、可靠地被A接收到苇倡，并且保證報文數(shù)據(jù)的完整性？
接下來圍繞著這個問題來說明一下囤踩。
加密和解密的過程和原理圖
加密解密過程和原理詳細說明：
1旨椒、發(fā)送端B
-
為保證安全，要對報文加密高职。加密方法有三類：對稱加密钩乍、公鑰加密和單向加密。對稱加密不安全怔锌，單向加密是不可逆的寥粹，因而使用公鑰加密。
問題：公鑰加密安全（一般為2048位）埃元，但是加密過程太慢了涝涤，不適用當前網(wǎng)絡需求，該怎么辦岛杀？
-
為了解決上述問題阔拳，B可以用單向加密提取出報文的特征碼（特征碼能保證報文的數(shù)據(jù)完整性），再使用自身的私鑰對特征碼進行公鑰加密（特征碼數(shù)據(jù)小类嗤，對其進行公鑰加密速度快）糊肠，并把加密后的特征碼附加到報文后。（使用私鑰加密是為了驗證身份）
問題：這種方式能實現(xiàn)數(shù)據(jù)完整性和身份驗證的檢驗遗锣，但是卻缺失了報文的數(shù)據(jù)保密性货裹，又該怎么辦？
為了解決上述問題精偿，B在把加密的特征碼附加到報文后弧圆，把特征碼和報文當做一個數(shù)據(jù)（假設為data），使用對稱加密算法對該數(shù)據(jù)(data)加密得出一個密碼笔咽，再把密碼附加到該數(shù)據(jù)(data)后搔预。為了使得在傳輸過程中密碼不被其他人獲取或篡改，使用A的公鑰對密碼進行加密（只有A的私鑰能對其解密）叶组，把加密的密碼附加到數(shù)據(jù)data后拯田，再這些數(shù)據(jù)一并發(fā)送給A。
2扶叉、接收端A
- A接收到B傳來的報文勿锅，利用自身的私鑰對其解密帕膜，獲得密碼。因為只有A的私鑰能對B傳來的報文（使用A的公鑰加密密碼）解密溢十，所以能防止其他人對該傳輸?shù)膱笪倪M行解密而獲得其中的信息垮刹，保證了數(shù)據(jù)的保密性。
- A利用獲得的密碼解密其中對稱加密的數(shù)據(jù)张弛，獲得經(jīng)過加密的特征碼和原報文荒典。
- A使用B的公鑰對該特征碼解密，能解密則說明該報文是B發(fā)送過來的吞鸭，實現(xiàn)了身份驗證寺董。（假設解密后的特征碼是fcode）
- A使用同等單向加密算法對接收到的原報文提取其特征碼。使用該特征碼和解密后獲得的特征碼(fcode)做比較刻剥，如果一樣遮咖，則說明原報文的數(shù)據(jù)完整。
問題：以上這種方式能保證數(shù)據(jù)完整性造虏、身份驗證和數(shù)據(jù)的保密性御吞，在加密和解密的過程中都要用到對方的公鑰，如何在傳輸過程中安全可靠地獲得對方的公鑰就成了關鍵的一環(huán)漓藕，那該如何做呢陶珠？
答：安全可靠地獲取對方的公鑰靠CA(Certificate Authority )證書授權中心來實現(xiàn)。
因而接下來享钞，我們來說說CA揍诽。
三、CA（證書授權中心）
1栗竖、CA證書標準：x.509
x.509: 定義了證書結構和認證協(xié)議標準暑脆；（基于公鑰和數(shù)字簽名）
用于：IP安全、TLS/SSL（傳輸層安全）和S/MIME（安全電子郵件通信）
x.509證書標準詳細說明：
（1）版本號（默認為1狐肢，如果有多個擴展饵筑，可能為3）
（2）證書序列號（是一個整數(shù)，在CA中唯一標識处坪，表明發(fā)行了多少個證書）
（3）算法參數(shù) （標志用了那種算法）
（4）發(fā)行者的名稱（CA自己的名字）
（5）有效期限
（6）主體名稱（證書擁有者名稱）(很關鍵！＜茏ā同窘！)（個人用戶使用的是個人用戶名，主機使用的必須是主機名而不是ip地址）
（7）公鑰（最重要）（公鑰由證書擁有者提供）
（8）發(fā)行者的ID（CA的唯一編號）
（9）主體的ID（CA生成的證書擁有者唯一編號）
（10）擴展
（11）CA的簽名（用于驗證CA的來源合法性）
CA是相對于發(fā)送方B和接收方A的第三方部脚，是具有公信力的機構想邦。
2、驗證數(shù)字證書的過程
B在發(fā)送之前獲得A的數(shù)字證書或A在接收之前獲得B的數(shù)字證書委刘，都會去驗證該數(shù)字證書的真?zhèn)巍?br> 以B在發(fā)送之前獲得A的數(shù)字證書為例丧没，說明驗證數(shù)字證書的過程：
- 要用對應給A發(fā)數(shù)字證書的那個CA的公鑰去解密CA的簽名鹰椒，如果能解密，則說明A的數(shù)字證書確實是那個信任的CA所頒發(fā)的證書呕童。
- 解密出一段特征碼漆际，B再使用同樣的單向加密算法提取A的數(shù)字證書的特征碼，比較這兩個特征碼是否一樣夺饲，如果一樣奸汇，則表示獲得的A的數(shù)字證書是完整的。
- 此后往声，還要去驗證該數(shù)字證書中的持有者是不是A擂找，如果驗證通過，才可以確定該數(shù)字證書確實是A的數(shù)字證書浩销。
- 確認該數(shù)字證書的擁有者是A后贯涎，還要去查看該數(shù)字證書是否在有效期限內和是否在CA的數(shù)字證書吊銷列表中。
四慢洋、SSL層
1塘雳、SSL層
SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網(wǎng)絡通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議且警。
版本：sslv1, sslv2, sslv3
ssl是介于應用層和傳輸層之間的半層粉捻，一般被制作成公共共享庫，要想使用ssl就要調用ssl共享庫斑芜。
2肩刃、https通信過程
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道杏头，簡單講是HTTP的安全版盈包。即HTTP下加入SSL層，HTTPS的安全基礎是SSL醇王。
以https為例呢燥，進一步說明如何依靠CA來可靠的獲得通信對方的公鑰
https的主要實現(xiàn)過程說明：
（1）在通信之前，服務器端通過加密算法生成一對密鑰寓娩，并把其公鑰發(fā)給CA申請數(shù)字證書
（2）CA審核后叛氨，結合服務端發(fā)來的相關信息生成數(shù)字證書，并把該數(shù)字證書發(fā)回給服務器端棘伴。
（3）客戶端和服務器端經(jīng)tcp三次握手寞埠，建立初步連接。
（4）客戶端發(fā)送http報文請求并協(xié)商使用哪種加密算法焊夸。
（5）服務端響應報文并把自身的數(shù)字簽名發(fā)給服務端仁连。
（6）客服端下載CA的公鑰，驗證其數(shù)字證書的擁有者是否是服務器端（這個過程可以得到服務器端的公鑰）阱穗。（一般是客戶端驗證服務端的身份饭冬，服務端不用驗證客戶端的身份使鹅。）
（7）如果驗證通過，客戶端生成一個隨機對稱密鑰昌抠，用該密鑰加密要發(fā)送的URL鏈接申請患朱，再用服務器端的公鑰加密該密鑰
（8）客戶端把加密的密鑰和加密的URL鏈接一起發(fā)送到服務器。
（9）服務器端使用自身的私鑰解密扰魂，獲得一個對稱密鑰麦乞，再用該對稱密鑰解密經(jīng)加密的URL鏈接，獲得URL鏈接申請劝评。
（10）服務器端根據(jù)獲得的URL鏈接取得該鏈接的網(wǎng)頁內容姐直，并用客戶端發(fā)來的對稱密鑰把該網(wǎng)頁內容加密后發(fā)給客戶端。
（11）客戶端收到加密的網(wǎng)頁內容蒋畜，用自身的對稱密鑰解密声畏，就能獲得網(wǎng)頁的內容了。
（12）TCP四次揮手姻成，通信結束插龄。
五、openssl自建CA過程詳解
OpenSSL是套開放源代碼的軟件庫包科展，實現(xiàn)了SSL與TLS協(xié)議均牢。其主要庫是以C語言所寫成，實現(xiàn)了基本的加密功能才睹。
OpenSSL可以運行在絕大多數(shù)類Unix操作系統(tǒng)上（包括Solaris徘跪，Linux，Mac OS X與各種版本的開放源代碼BSD操作系統(tǒng)）琅攘，OpenVMS與Microsoft Windows垮庐。它也提供了一個移植版本，可以在IBM i（OS/400）上運作坞琴。
此軟件是以Eric Young以及Tim Hudson兩人所寫的SSLeay為基礎所發(fā)展的哨查，SSLeay隨著兩人前往RSA公司任職而停止開發(fā)。
雖然此軟件是開放源代碼的剧辐，但其授權書條款與GPL有沖突之處寒亥，故GPL軟件使用OpenSSL時（如Wget）必須對OpenSSL給予例外。
openssl建立私有CA
openssl創(chuàng)建私有CA的過程：
前提：安裝openssl
# yum install openssl
1荧关、建立CA服務器
（1）生成密鑰
# (umask 077; openssl genrsa -out /etc/pki/CA/private/cakey.pem 2048)
命令解釋：
- ( ) 表示將會在當前shell中新建一個子shell护盈，將（）中的命令放到該子shell中執(zhí)行，執(zhí)行完畢后關閉子shell并回到當前shell羞酗。
由于要對生成的cakey.pem文件設置合適權限，可使用umask修改文件的默認權限設置紊服。為了不影響當前shell的默認權限設置檀轨，使用（）將這些命令放到子shell中執(zhí)行就行了胸竞！ - genrsa : 指定使用rsa算法生成私鑰
- -out ：指定生成的私鑰的存放位置（注意：該存放位置是在配置文件中默認定義了的，路徑和文件名不能隨意修改２翁选Ｎ乐Α！）
- 2048 ：指定生成一個2048位的私鑰
（2）自簽證書
# openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem -days 3655
命令解釋：
- req: 生成證書簽署請求
- -news: 新請求
- -x509: 專門用于生成自簽署證書
- -key /path/to/keyfile: 指定私鑰文件（req命令能根據(jù)私鑰自動抽取出公鑰）
- -out /path/to/somefile: （注意：路徑和文件名不用隨意修改６锟妗）
- -days n: 有效天數(shù)（一般和-x509一起使用才有意義校赤。）
（3）初始化工作環(huán)境
只有第一次創(chuàng)建CA時，才需要初始化工作環(huán)境
# touch /etc/pki/CA/{index.txt,serial}
# echo 01 > /etc/pki/CA/serial （指定序列號從那個數(shù)字開始）
2筒溃、節(jié)點申請證書
(1) 節(jié)點生成請求
- 生成密鑰對兒
# (umask 077; openssl genrsa -out /etc/httpd/ssl/httpd.key 2048)
- 生成證書簽署請求
# openssl req -new -key /etc/httpd/ssl/httpd.key -out /etc/httpd/ssl/httpd.csr
.csr ：證書簽署請求马篮，一般都是這樣的后綴
紅框中的信息，需要和CA自簽證書中填寫的保持一致怜奖，否則會出錯浑测。
- 把簽署請求文件發(fā)送給CA服務器
(2) CA簽署證書
- 驗正證書中的信息
- 簽署證書
格式：openssl ca -in /path/to/somefile.csr -out /path/to/somefile.crt -days N
說明：-in 指定證書簽署請求文件 ； -out CA根據(jù)請求文件生成的證書歪玲，一般為 .crt 后綴迁央；N 指定證書生效時長，天為單位
[root@localhost CA]# openssl ca -in /etc/httpd/ssl/httpd.csr -out /etc/httpd/ssl/httpd.crt -days 1000
Using configuration from /etc/pki/tls/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Jul 3 14:07:23 2014 GMT
Not After : Mar 29 14:07:23 2017 GMT
Subject:
countryName = CN #國家名
stateOrProvinceName = GuangDong #省份名
organizationName = 51CTOblog #公司名
organizationalUnitName = Ops #部門名
commonName = www.hjqjk.com #主機名
emailAddress = hjqjk@163.com #郵箱
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
F9:DB:00:04:8A:D7:17:C8:21:B7:2D:15:F2:E9:89:66:BB:6D:D5:F9
X509v3 Authority Key Identifier:
keyid:98:56:B3:30:B0:9D:75:A1:69:AD:BF:2F:E4:0D:FE:3F:17:87:B0:A8
Certificate is to be certified until Mar 29 14:07:23 2017 GMT (1000 days)
Sign the certificate? [y/n]:y #詢問是否簽署證書
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
[root@localhost CA]# ls /etc/httpd/ssl #證書已簽署滥崩，自建CA到這里就成功了
httpd.crt httpd.csr httpd.key
- 發(fā)送給請求者
之后岖圈，只要把簽署的證書發(fā)回給申請者就行了！
