信息安全三要素?

1. 保密性：信息在傳輸時不被泄露

2. 完整性：信息在傳輸時不被篡改

3. 身份認(rèn)證：用于確定你數(shù)據(jù)的來源是你預(yù)想的

普通的秘鑰加密數(shù)據(jù)是用于解決保密性問題。

數(shù)字簽名是用于解決完整性和身份認(rèn)證問題。

密碼算法分類

1. 受限制的算法：算法的保密性基于保持算法的秘密。

2. 基于秘鑰的算法：算法的保密性基于對秘鑰的保密。（現(xiàn)代密碼理論）

基于秘鑰的算法

1. 對稱密碼算法

又稱傳統(tǒng)密碼算法，單秘鑰算法，加密秘鑰和解密秘鑰相同。

常用算法：AES（Advanced Encryption Standard），DES（Data Encryption Standard)，RC6。

對稱加密算法

2. 非對稱秘鑰算法

加密秘鑰和解密秘鑰不相同，并且是成對出現(xiàn)它，們可以互相加解密。

其中對外公開的秘鑰稱為公鑰，需要保密的秘鑰稱為私鑰。

常用于數(shù)字簽名，身份認(rèn)證。

缺點(diǎn)是加密解密速度慢。

公鑰加密，私鑰解密常用于?數(shù)據(jù)加密。優(yōu)點(diǎn)是公鑰可以對外公開，加密者不需要知道私鑰，不適合大量數(shù)據(jù)。私鑰加密，公鑰解密常用于 數(shù)字簽名。

常用算法：RSA。

非對稱加密算法

3. 對比

非對稱加密與對稱加密相比，其安全性更好：對稱加密的通信雙方使用相同的秘鑰，如果一方的秘鑰遭泄露，那么整個通信就會被破解。而非對稱加密使用一對秘鑰，一個用來加密，一個用來解密，而且公鑰是公開的，秘鑰是自己保存的，不需要像對稱加密那樣在通信之前要先同步秘鑰。

4. 實(shí)際應(yīng)用

在實(shí)際應(yīng)用中，通常采取數(shù)據(jù)本身的加密和解密使用對稱加密算法(AES)。?

RSA算法多用于加密并傳輸對稱算法所需的密鑰，數(shù)字簽名。

數(shù)字簽名

數(shù)字簽名流程

現(xiàn)實(shí)生活中，簽名有什么作用？在一封信中，文末的簽名是為了表示這封信是簽名者寫的。計(jì)算機(jī)中，數(shù)字簽名也是相同的含義：證明消息是某個特定的人，而不是隨隨便便一個人發(fā)送的（身份認(rèn)證）；除此之外，數(shù)字簽名還能證明消息沒有被篡改（完整性）。

用私鑰加密的消息稱為簽名，只有擁有私鑰的用戶可以生成簽名。

用公鑰解密簽名這一步稱為驗(yàn)證簽名，所有用戶都可以驗(yàn)證簽名(因?yàn)楣€是公開的)

一旦簽名驗(yàn)證成功，根據(jù)公私鑰數(shù)學(xué)上的對應(yīng)關(guān)系，就可以知道該消息是唯一擁有私鑰的用戶發(fā)送的，而不是隨便一個用戶發(fā)送的。

由于私鑰是唯一的，因此數(shù)字簽名可以保證發(fā)送者事后不能抵賴對報(bào)文的簽名。由此，消息的接收者可以通過數(shù)字簽名，使第三方確信簽名人的身份及發(fā)出消息的事實(shí)。當(dāng)雙方就消息發(fā)出與否及其內(nèi)容出現(xiàn)爭論時，數(shù)字簽名就可成為一個有力的證據(jù)。（不可抵賴性）

生成簽名

一般來說，不直接對消息進(jìn)行簽名，而是對消息的哈希值進(jìn)行簽名，步驟如下。

對消息進(jìn)行哈希計(jì)算，得到哈希值

利用私鑰對哈希值進(jìn)行加密，生成簽名

將簽名附加在消息后面，一起發(fā)送過去

驗(yàn)證簽名

收到消息后，提取消息中的簽名

用公鑰對簽名進(jìn)行解密，得到哈希值1。

對消息中的正文進(jìn)行哈希計(jì)算，得到哈希值2。

比較哈希值1和哈希值2，如果相同，則驗(yàn)證成功。

數(shù)字證書

數(shù)字簽名中公開的公鑰有可能會被偽造，數(shù)字證書實(shí)際上就是對公鑰進(jìn)行數(shù)字簽名，它是對公鑰合法性提供證明的技術(shù)。

一個數(shù)字證書包括公鑰，對公鑰的數(shù)字簽名（標(biāo)識該證書的確是本CA頒發(fā)出去的），和描述信息（用戶身份信息，版本號、證書序列號、有效期、頒發(fā)者身份等）。

數(shù)字證書還有一個重要的特征就是只在特定的時間段內(nèi)有效。

數(shù)字證書是一種權(quán)威性的電子文檔，可以由權(quán)威公正的第三方機(jī)構(gòu)，即CA（例如中國各地方的CA公司）中心簽發(fā)的證書，也可以由企業(yè)級CA系統(tǒng)進(jìn)行簽發(fā)。

如何生成證書？

服務(wù)器將公鑰A給CA（公鑰是服務(wù)器的）

CA用自己的私鑰B給公鑰A加密，生成數(shù)字簽名A

CA把公鑰A，數(shù)字簽名A，附加一些服務(wù)器信息整合在一起，生成證書，發(fā)回給服務(wù)器。

注：私鑰B是用于加密公鑰A的，私鑰B和公鑰A并不是配對的。

如何驗(yàn)證證書？

客戶端得到證書

客戶端得到證書的公鑰B（通過CA或其它途徑）

客戶端用公鑰B對證書中的數(shù)字簽名解密，得到哈希值

客戶端對公鑰A進(jìn)行哈希值計(jì)算

兩個哈希值對比，如果相同，則證書合法。

注：公鑰B和上述的私鑰B是配對的，分別用于對證書的驗(yàn)證（解密）和生成（加密）。

頒發(fā)過程

數(shù)字證書頒發(fā)過程一般為：用戶首先產(chǎn)生自己的秘鑰對，并將公共密鑰及部分個人身份信息傳送給認(rèn)證中心。認(rèn)證中心在核實(shí)身份后，將執(zhí)行一些必要的步驟，以確信請求確實(shí)由用戶發(fā)送而來，然后，認(rèn)證中心將發(fā)給用戶一個數(shù)字證書，該證書內(nèi)包含用戶的個人信息和他的公鑰信息，同時還附有認(rèn)證中心的簽名信息。用戶就可以使用自己的數(shù)字證書進(jìn)行相關(guān)的各種活動。數(shù)字證書由獨(dú)立的證書發(fā)行機(jī)構(gòu)發(fā)布。數(shù)字證書各不相同，每種證書可提供不同級別的可信度?？梢詮淖C書發(fā)行機(jī)構(gòu)獲得您自己的數(shù)字證書。

CA

電子商務(wù)認(rèn)證授權(quán)機(jī)構(gòu)（CA, Certificate Authority），也稱為電子商務(wù)認(rèn)證中心，是負(fù)責(zé)發(fā)放和管理數(shù)字證書的權(quán)威機(jī)構(gòu)，并作為電子商務(wù)交易中受信任的第三方，承擔(dān)公鑰體系中公鑰的合法性檢驗(yàn)的責(zé)任。

證書的層級結(jié)構(gòu)

用戶需要使用認(rèn)證機(jī)構(gòu)的公鑰，對證書上的數(shù)字簽名進(jìn)行驗(yàn)證。

那么，對于用來驗(yàn)證數(shù)字簽名的認(rèn)證機(jī)構(gòu)的公鑰，怎樣才能判斷它是合法的呢？對于認(rèn)證機(jī)構(gòu)的公鑰，可以由其他認(rèn)證機(jī)構(gòu)施加數(shù)字簽名，從而對認(rèn)證機(jī)構(gòu)的公鑰進(jìn)行驗(yàn)證，即生成一張認(rèn)證機(jī)構(gòu)的公鑰證書。

一個認(rèn)證機(jī)構(gòu)來驗(yàn)證另外一個認(rèn)證機(jī)構(gòu)的公鑰，這樣的關(guān)系可以迭代好幾層。這樣一種認(rèn)證機(jī)構(gòu)之間的層級關(guān)系，我們可以用某公司內(nèi)部PKI來類比。例如某公司的組織結(jié)構(gòu)如下，每一層組織都設(shè)有認(rèn)證機(jī)構(gòu)。

假設(shè)Bob是札幌辦事處的一名員工，札幌辦事處員工的公鑰由札幌辦事處認(rèn)證機(jī)構(gòu)頒發(fā)的（因?yàn)檫@樣更容易認(rèn)證本人身份）。

對于札幌辦事處認(rèn)證機(jī)構(gòu)的公鑰，則由北海道分公司認(rèn)證機(jī)構(gòu)頒發(fā)證書，而對于北海道分公司認(rèn)證機(jī)構(gòu)的公鑰，則由東京總公司認(rèn)證機(jī)構(gòu)頒發(fā)證書，以此類推......。不過這個鏈條不能無限制延伸，總要有一個終點(diǎn)，如果這個終點(diǎn)就是東京總公司認(rèn)證機(jī)構(gòu)（即不存在更高一層的認(rèn)證機(jī)構(gòu)）的話，該認(rèn)證機(jī)構(gòu)一般就稱根CA（Root?CA）。而對于東京總公司認(rèn)證機(jī)構(gòu)，則由東京總公司認(rèn)證機(jī)構(gòu)自己來頒發(fā)證書，這種對自己的公鑰進(jìn)行數(shù)字簽名的行為稱為自簽名。

現(xiàn)在假設(shè)Alice要驗(yàn)證札幌辦事處員工Bob的數(shù)字簽名，那么Alice需要執(zhí)行如下步驟進(jìn)行驗(yàn)證。

首先從最高層認(rèn)證機(jī)構(gòu)（根CA）開始。如果連根CA的公鑰都不合法的話，那么就無法驗(yàn)證證書了，因此我們假設(shè)Alice所持有的東京總公司認(rèn)證機(jī)構(gòu)的公鑰是合法的。

接著，Alice取得北海道分公司認(rèn)證機(jī)構(gòu)的公鑰證書，這個證書上面帶有東京總公司認(rèn)證機(jī)構(gòu)的數(shù)字簽名。Alice用合法的東京總公司認(rèn)證機(jī)構(gòu)的公鑰對數(shù)字簽名進(jìn)行驗(yàn)證。如果驗(yàn)證成功，說明Alice取得了合法的北海道分公司認(rèn)證機(jī)構(gòu)的公鑰。

再接下來，Alice取的札幌辦事處認(rèn)證機(jī)構(gòu)的公鑰證書，這個證書上面帶有北海道分公司認(rèn)證機(jī)構(gòu)的數(shù)字簽名。Alice用合法的北海道認(rèn)證機(jī)構(gòu)的公鑰對數(shù)字簽名進(jìn)行驗(yàn)證。如果驗(yàn)證成功，則說明Alice獲得了合法的札幌辦事處認(rèn)證機(jī)構(gòu)的公鑰。

最后，Alice取得札幌辦事處員工Bob的公鑰證書，這個證書上面帶有札幌辦事處認(rèn)證機(jī)構(gòu)的數(shù)字簽名。Alice用合法的札幌辦事處認(rèn)證機(jī)構(gòu)的公鑰對數(shù)字簽名進(jìn)行驗(yàn)證。如果驗(yàn)證成功，則說明Alice獲得了合法的札幌辦事處員工Bob的公鑰。

上面就是Alice對Bob的數(shù)字簽名進(jìn)行驗(yàn)證的整個過程。當(dāng)然，如此復(fù)雜的驗(yàn)證過程不會是由人來操作的，而是由電子郵件或者瀏覽器等軟件自動完成的。

數(shù)字認(rèn)證過程

數(shù)字認(rèn)證過程

所示的事件序列，如下：

1.Alice 將一個簽名的證書請求發(fā)送到 CA，該證書包含有她的姓名、公共密鑰以及可能的附加信息。

2.CA 根據(jù) Alice 的請求創(chuàng)建一個消息。CA 使用自己的專用密鑰對消息進(jìn)行簽名，以創(chuàng)建一個單獨(dú)的簽名。CA 將消息和簽名返回給 Alice。Alice 的證書中包含了消息和簽名。

3.Alice 將她的證書發(fā)送給 Bob，讓他有權(quán)訪問她的公共密鑰。

4.Bob 使用 CA 的公共密鑰驗(yàn)證證書的簽名。如果證明簽名有效，則他會接受證書中的公共密鑰作為 Alice 的公共密鑰。

哈希

Hash，一般翻譯做“散列”，也有直接音譯為“哈?！钡模褪前讶我忾L度的輸入（又叫做預(yù)映射pre-image）通過散列算法變換成固定長度的輸出，該輸出就是散列值。這種轉(zhuǎn)換是一種壓縮映射，也就是，散列值的空間通常遠(yuǎn)小于輸入的空間，不同的輸入可能會散列成相同的輸出，所以不可能從散列值來確定唯一的輸入值。簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數(shù)。

1.MD5

2.SHA

應(yīng)用1.??????密碼加密

單純使用MD5之所以不好，并不是說MD5這種方法容易遭到破解，而事實(shí)上對于MD5求原象或者第二原象，也就是“逆計(jì)算”這種破解，沒有什么很好的方法。只能通過預(yù)先計(jì)算知道許多MD5的對應(yīng)關(guān)系，存在數(shù)據(jù)庫中，然后使用的時候反查，例如我知道'password'的MD5值是5f4dcc3b5aa765d61d8327deb882cf99，那么我就用一個數(shù)據(jù)庫存起來，只要我看到5f4dcc3b5aa765d61d8327deb882cf99，我就知道這個是口令'password‘使用MD5處理之后的值，原來的口令就是'password'。MD5在身份鑒別系統(tǒng)中用于口令保護(hù)已經(jīng)是很久了事情了，大部分黑客也有針對這種Hash方式準(zhǔn)備相應(yīng)的數(shù)據(jù)庫進(jìn)行反查，這種數(shù)據(jù)庫稱為彩虹表。

應(yīng)用2.??????文件校驗(yàn)

通過hash值對比，判斷文件是否是同一個文件（或者文件是否被修改過）。

加鹽

加鹽加密是一種對系統(tǒng)登錄口令的加密方式，它實(shí)現(xiàn)的方式是將每一個口令同一個叫做”鹽“（salt）的n位隨機(jī)數(shù)相關(guān)聯(lián)?？梢苑烙屎绫砉?。

彩虹表（詞典攻擊）

彩虹表是一個用于加密散列函數(shù)逆運(yùn)算的預(yù)先計(jì)算好的表, 為破解密碼的散列值（或稱哈希值、微縮圖、摘要、指紋、哈希密文）而準(zhǔn)備。一般主流的彩虹表都在100G以上。 這樣的表常常用于恢復(fù)由有限集字符組成的固定長度的純文本密碼。

HTTPS

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。?

HTTPS通信流程

1.https請求

客戶端向服務(wù)端發(fā)送https請求;

2.生成公鑰和私鑰

服務(wù)端收到請求之后，生成公鑰和私鑰。公鑰相當(dāng)于是鎖，私鑰相當(dāng)于是鑰匙，只有私鑰才能夠打開公鑰鎖住的內(nèi)容;

3.返回公鑰

服務(wù)端將公鑰(證書)返回給客戶端，公鑰里面包含有很多信息，比如證書的頒發(fā)機(jī)構(gòu)、過期時間等等;

4.客戶端驗(yàn)證公鑰

客戶端收到公鑰之后，首先會驗(yàn)證其是否有效，如頒發(fā)機(jī)構(gòu)或者過期時間等，如果發(fā)現(xiàn)有問題就會拋出異常，提示證書存在問題。如果沒有問題，那么就生成一個隨機(jī)值，作為客戶端的密鑰，然后用服務(wù)端的公鑰加密;

5.發(fā)送客戶端密鑰

客戶端用服務(wù)端的公鑰加密密鑰，然后發(fā)送給服務(wù)端。

6.服務(wù)端收取密鑰，對稱加密內(nèi)容

服務(wù)端收到經(jīng)過加密的密鑰，然后用私鑰將其解密，得到客戶端的密鑰，然后服務(wù)端把要傳輸?shù)膬?nèi)容和客戶端的密鑰進(jìn)行對稱加密，這樣除非知道密鑰，否則無法知道傳輸?shù)膬?nèi)容。

7.加密傳輸

服務(wù)端將經(jīng)過加密的內(nèi)容傳輸給客戶端。

8.獲取加密內(nèi)容，解密

客戶端獲取加密內(nèi)容后，用之前生成的密鑰對其進(jìn)行解密，獲取到內(nèi)容。

SSL

用以保障在Internet上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密(Encryption)技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡(luò)上之傳輸過程中不會被截取。目前一般通用之規(guī)格為40 bit之安全標(biāo)準(zhǔn)，美國則已推出128 bit之更高安全標(biāo)準(zhǔn)，但限制出境。只要3.0版本以上之I.E.或Netscape瀏覽器即可支持SSL。

SSL協(xié)議位于TCP/IP協(xié)議與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。SSL協(xié)議可分為兩層：?SSL記錄協(xié)議（SSL?Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。?SSL握手協(xié)議（SSL?Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。

證書標(biāo)準(zhǔn)X.509

X.509?是密碼學(xué)里公鑰證書的格式標(biāo)準(zhǔn)。 X.509 證書己應(yīng)用在包括TLS/SSL（WWW萬維網(wǎng)安全瀏覽的基石）在內(nèi)的眾多 Intenet協(xié)議里.同時它也用在很多非在線應(yīng)用場景里，比如電子簽名服務(wù)。

openSSL

OpenSSL 是一個強(qiáng)大的安全套接字層密碼庫，包括了加密算法，常用密鑰和證書管理，SSL協(xié)議等功能。

CSR后綴文件

CSR是Certificate Signing Request的英文縮寫，即證書請求文件。在申請者向CA申請證書時使用，包含申請者的公鑰和申請者的基本信息。

DER格式和PEM格式

DER格式:?Distinguished Encoding Rules，用二進(jìn)制DER編碼，不可讀，不常用。

PEM格式:?Privacy-Enhanced Mail，DER編碼后再用ASCLL(BASE64)編碼，可讀。

CRT，CER后綴文件

證書文件，只有公鑰沒有私鑰。存儲格式可以是PEM和DER。CRT大多數(shù)為PEM編碼，CER大多數(shù)為DER編碼。一般Linux下面叫CRT，Windows下面叫CER。CRT和CER可以互相轉(zhuǎn)換。

PEM后綴文件

可以存放證書或私鑰，或者都有，如果只有私鑰，一般使用KEY文件格式。

DER后綴文件

可以存放證書。（不常用）

PFX

一般CRT和KEY是分開存放在不同文件中的,但Windows的IIS則將它們存在一個PFX文件中,(因此這個文件包含了證書及私鑰)這樣會不會不安全？應(yīng)該不會,PFX通常會有一個"提取密碼",你想把里面的東西讀取出來的話,它就要求你提供提取密碼,PFX使用的時DER編碼。

PFX，DER，PEM可以互相轉(zhuǎn)換。

PKCS1～12

公鑰加密的標(biāo)準(zhǔn)。

P12

PKCS12的簡寫，二進(jìn)制格式，P12文件中包含了CRT和KEY兩部分內(nèi)容，需要提取密碼才能提取相關(guān)的內(nèi)容。

KEY

私鑰文件。

中間人攻擊

https也不是絕對安全的，中間人可以獲取到客戶端與服務(wù)器之間所有的通信內(nèi)容。

中間人截取客戶端發(fā)送給服務(wù)器的請求，然后偽裝成客戶端與服務(wù)器進(jìn)行通信;將服務(wù)器返回給客戶端的內(nèi)容發(fā)送給客戶端，偽裝成服務(wù)器與客戶端進(jìn)行通信。

通過這樣的手段，便可以獲取客戶端和服務(wù)器之間通信的所有內(nèi)容。

使用中間人攻擊手段，必須要讓客戶端信任中間人的證書，如果客戶端不信任，則這種攻擊手段也無法發(fā)揮作用。

中間人攻擊的預(yù)防

1 、針對安全性要求比較高的 app，可采取客戶端預(yù)埋證書的方式鎖死證書，只有當(dāng)客戶端證書和服務(wù)端的證書完全一致的情況下才允許通信，如一些銀行類的app，但這種方式面臨一個問題，證書過期的問題，因證書有一定的有效期，當(dāng)預(yù)埋證書過期了，只有通過強(qiáng)制更新或者要求用戶下載證書來解決。

2 針對安全性要求一般的app，可采用通過校驗(yàn)域名，證書有效性、證書關(guān)鍵信息及證書鏈的方式。

HTTPS單向驗(yàn)證

TCP連接建立好后，對于HTTP而言，服務(wù)器就可以發(fā)數(shù)據(jù)給客戶端。但是對于HTTPS，它還要運(yùn)行SSL/TLS協(xié)議，SSL/TLS協(xié)議分兩層，第一層是記錄協(xié)議，主要用于傳輸數(shù)據(jù)的加密壓縮；第二層是握手協(xié)議，它建立在第一層協(xié)議之上，主要用于數(shù)據(jù)傳輸前的雙方身份認(rèn)證、協(xié)商加密算法、交換密鑰。SSL驗(yàn)證過程就是SSL握手協(xié)議的交互過程。

客戶端會有一個信任庫，里面保存了該客戶端信任的CA（證書簽發(fā)機(jī)構(gòu)）的證書，如果收到的證書簽發(fā)機(jī)構(gòu)不在信任庫中，則客戶端會提示用戶證書不可信。

若客戶端是瀏覽器，各個瀏覽器都會內(nèi)置一些可信任的證書簽發(fā)機(jī)構(gòu)列表，在瀏覽器的設(shè)置中可以看到。

如果不在信任表中，則瀏覽器會出現(xiàn)類似下面的警告頁面，提示你不安全。（當(dāng)然，你可以選擇繼續(xù)訪問）

若客戶端是程序，例如Java中，需要程序配置信任庫文件，以判斷證書是否可信，如果沒設(shè)置，則默認(rèn)使用jdk自帶的證書庫（jre\lib\security\cacerts,默認(rèn)密碼changeit）。如果證書或簽發(fā)機(jī)構(gòu)的證書不在信任庫中，則認(rèn)為不安全，程序會報(bào)錯。（你可以在程序中設(shè)置信任所有證書，不過這樣并不安全）。

HTTPS雙向驗(yàn)證

單向驗(yàn)證過程中，客戶端會驗(yàn)證自己訪問的服務(wù)器，服務(wù)器對來訪的客戶端身份不做任何限制。如果服務(wù)器需要限制客戶端的身份，則可以選擇開啟服務(wù)端驗(yàn)證，這就是雙向驗(yàn)證。從這個過程中我們不難發(fā)現(xiàn)，使用單向驗(yàn)證還是雙向驗(yàn)證，是服務(wù)器決定的。

一般而言，我們的服務(wù)器都是對所有客戶端開放的，所以服務(wù)器默認(rèn)都是使用單向驗(yàn)證。如果你使用的是Tomcat服務(wù)器，在配置文件server.xml中，配置Connector節(jié)點(diǎn)的clientAuth屬性即可。若為true，則使用雙向驗(yàn)證，若為false，則使用單向驗(yàn)證。如果你的服務(wù)，只允許特定的客戶端訪問，那就需要使用雙向驗(yàn)證了。