加密方案發展

2021-09-12 02:17:25 字數 2940 閱讀 4596

一開始使用非對稱加密可以達到安全,但是效率太低,

使用對稱秘鑰效率高,但如果寫入客戶端,被破解後就可以解密雙方資料,因為服務端也是相同的秘鑰

服務端生成會話金鑰,進行非對稱加密下發,咋一看這個會話金鑰是加密後在網路上傳輸的,但實際上裡面存在乙個問題:由於公鑰是公開的,因此任何人都能用公鑰解開並獲取你的會話金鑰。因此,這個方案也不夠完善。

我們再回顧一下這個方案,發現存在乙個本質的問題:這個會話金鑰是服務端單獨生成的,那一定會導致一種結果:只要客戶端能最終解密出來,那黑客也一定能解密出來。因為對於服務端而言,客戶端和黑客都是金鑰的接收方,兩者是平等的,無法區別的。

客戶端主動生成金鑰

具體方式如下:

服務端明文下發公鑰給客戶端;

客戶端生成乙個隨機數作為會話金鑰,利用公鑰加密後傳送給服務端;

服務端收到後,通過私鑰對密文進行解密並獲取隨機數。

可以看出這個過程裡,黑客就算攔截了我們的加密資料,也會因為沒有私鑰而無法獲取會話金鑰。

看起來,方案很完美了,但實際上裡面仍然存在乙個漏洞:如果最開始下發的明文公鑰就是假的呢?這會導致的結果是:使用者全程和乙個中間黑客通訊:信任黑客的公鑰,然後自以為安全的進行資料通訊,結果把所有個人資訊都暴露給黑客了,最重要的是,服務端對此一無所知!

公鑰的合法性校驗

為了公鑰的合法性校驗,人們建立了專門頒發證書的機構:「證書中心」(certificate authority,簡稱ca),它會利用自己的私鑰,將我們的公鑰和相關資訊進行加密,生成乙個數字證書。在客戶端內部,會存在乙個受信任的根證書頒發機構,所以客戶端在每次拿到乙個公鑰後,就去查詢這個公鑰是否在這裡受信任證書列表中,如果不在,則認為公鑰無效,不再進行後續操作。如果存在,再繼續進行下一步認證。

而這也和https的實現機制相近。

前提 非常重要的事情—加密方案中的加密演算法都是公開的,而金鑰是保密的,沒有金鑰就不能解密,有了金鑰就能解密 *

三個角色 客戶端 **伺服器 真實伺服器

所謂攔截破解攔截,就是**伺服器可以看到客戶端發給伺服器的資料和服務端返回給客戶端的資料,並可以篡改

指定信任證書 https 驗證流程,(還有不指定的,就是會預設用根證書驗證,但不能保證唯一性)

用我們的證書去申請 ca證書,一對ca公鑰 和 ca私鑰

ca公鑰留在客戶端 ca私鑰留在服務端

建立鏈結握手過程中 -》 通過**伺服器 -》到達服務端

**伺服器將ca證書給客戶端,客戶端通過使用本地ca證書公鑰解密,驗證通過,取出公鑰,生成對稱秘鑰,然後加密返回**伺服器,**伺服器拿到之後沒有私鑰,不能解密取出對稱秘鑰,只能返回給伺服器

對於瀏覽器

客戶不留你們的證書,只有幾個最大的ca跟證書

通過ca根證書驗證你們的ca證書,再通過ca證書驗證**證書

通過根證書驗證 報certificateexception 驗證失敗,就會彈出是否要信任此證書,同意可繼續瀏覽

對於手機

內建也有幾個最大的ca跟證書

在客戶端中覆蓋google預設的證書檢查機制(x509trustmanager),並且在**中無任何校驗ssl證書有效性相關**

public class mysslsocketfactory extends sslsocketfactory 

//客戶端並未對ssl證書的有效性進行校驗,並且使用了自定義方法的方式覆蓋android自帶的校驗方法

public void checkservertrusted(x509certificate chain,

string authtype) throws certificateexception

public x509certificate getacceptedissuers()

};sslcontext.init(null, new trustmanager , null);

}}

但問題出來了:

如果使用者手機中安裝了乙個惡意證書,那麼就可以通過中間人攻擊的方式進行竊聽使用者通訊以及修改request或者response中的資料。

手機銀行中間人攻擊過程:

客戶端在啟動時,傳輸資料之前需要客戶端與服務端之間進行一次握手,在握手過程中將確立雙方加密傳輸資料的密碼資訊。

中間人在此過程中將客戶端請求伺服器的握手資訊攔截後,模擬客戶端請求給伺服器(將自己支援的一套加密規則傳送給伺服器),伺服器會從中選出一組加密演算法與hash演算法,並將自己的身份資訊以證書的形式發回給客戶端。證書裡面包含了**位址,加密公鑰,以及證書的頒發機構等資訊。

而此時中間人會攔截下服務端返回給客戶端的證書資訊,並替換成自己的證書資訊。

客戶端得到中間人的response後,會選擇以中間人的證書進行加密資料傳輸。

中間人在得到客戶端的請求資料後,以自己的證書進行解密。

在經過竊聽或者是修改請求資料後,再模擬客戶端加密請求資料傳給服務端。就此完成整個中間人攻擊的過程。

防護辦法:

服務端使用ca機構頒發的證書,客戶端預設用根證書驗證就可以,(但只能驗證是否是合法的ca證書,只要是ca證書都能通過驗證,需要做訪問網域名稱限制,(還是說預設ca頒發的就不敢做壞事,做壞事可以查))

新增指定新增指定信任證書(這個證書可以是ca申請的(使用ca機構頒發證書的方式可行,但是如果與實際情況相結合來看的話,時間和成本太高,所以目前很少有用此辦法來做。),也可以是自己自簽名生成的)

在客戶端內部,會存在乙個受信任的根證書頒發機構,所以客戶端在每次拿到乙個公鑰後,就去查詢這個公鑰是否在這裡受信任證書列表中,如果不在,則認為公鑰無效,不再進行後續操作。如果存在,再繼續進行下一步認證。

public void initssl() throws certificateexception, ioexception, keystoreexception,

nosuchalgorithmexception, keymanagementexception

log.e("tttt", result.tostring());

}

無線充方案發展方向

傳統無線充方案的分離式由於器件多,pcb布局複雜,已無法滿足當前的市場應用,隨著對成本要求越來越高,高整合無線充晶元作為最具潛力的方案架構被業內人士廣泛看好,它具有器件少,成本低等優勢 目前市面上存在方案有 1.無線充soc晶元方案 mos管。soc是主控,驅動及解碼集合在一起,mos管外掛程式等組...

檔案加密方案

使用者輸入密碼,軟體驗證密碼是否正確。傳統的對稱加密演算法,給出密文,隨意給出乙個金鑰,使之來解密。演算法都是可以繼續的,即使解密出來的資訊是亂的。如何驗證使用者的密碼是否正確?最差的解決方案 把使用者的檔案先加密,然後將使用者的密碼儲存到檔案末尾。解密時,驗證使用者輸入的金鑰是否和檔案末尾相同,如...

資料加密方案

資料加密又稱密碼學,它是一門歷史悠久的技術,指通過加密演算法和加密金鑰將明文轉變為密文,而解密則是通過解密演算法和解密金鑰將密文恢復為明文。資料加密目前仍是計算機系統對資訊進行保護的一種最可靠的辦法。它利用密碼技術對資訊進行加密,實現資訊隱蔽,從而起到保護資訊的安全的作用。資料加密技術要求只有在指定...