導航:首頁 > 源碼編譯 > 怎麼根據ca證書確認加密演算法

怎麼根據ca證書確認加密演算法

發布時間:2024-07-09 21:01:11

❶ 數字證書的簽名哈希演算法跟指紋演算法都是指對摘要(指紋的)的編碼嗎

證書簽名使用的演算法是發布者自己規定的 使用自己的私鑰對證書編碼的哈希值進行加密 一般演算法為md5withrsa或者sha256withrsa。哈希演算法是唯一的 就是把證書編碼轉換為固定長度的2進制 這個過程不可逆 就是說無法通過哈希值還原證書編碼。指紋演算法就是哈希演算法 一般都是sh1。證書認證的流程是證書所有者把證書和指紋(證書的哈希值並用私鑰加密)發給用戶 用戶根據證書計算出一個哈希值 用公鑰解密指紋得到一個哈希值 看一下兩者是否相同 相同及證明證書未被篡改。演算法是由所有者的私鑰加密的。ca的作用是ca是可以認證一個證書鏈,源頭就是ca 一旦你信任了這個ca 就是信任了ca發布的證書,這樣你與ca發布的證書的所有者通信時可以根據證書鏈找到ca ca可信任了則這個發布者就是可信任的

❷ HTTPS加密原理

HTTP、HTTPS在我們日常開發中是經常會接觸到的。

我們也都知道,一般 android 應用開發,在請求 API 網路介面的時候,很多使用的都是 HTTP 協議;使用瀏覽器打開網頁,也是利用 HTTP 協議。看來 HTTP 真是使用廣泛啊,但是,HTTP 是不安全的。利用網路抓包工具就可以知道傳輸中的內容,一覽無余。比如我經常會使用 Fiddler 來抓包,搜集一些有趣的 API 介面。

那麼問題來了,如何保證 HTTP 的安全性呢?基本上所有的人都會脫口而出:使用 HTTPS 協議。99.9% 的人都知道 HTTPS 會將傳輸的內容進行加密,但是接著問具體加密的過程和步驟,很多人就啞口無言了。

為了防止出現這種尷尬的局面,所以今天你就要好好看看這篇的內容了。以後就可以裝個逼,哈哈!

先科普一下,加密演算法的類型基本上分為了兩種:

對稱加密的意思就是說雙方都有一個共同的密鑰,然後通過這個密鑰完成加密和解密,這種加密方式速度快,但是安全性不如非對稱加密好。

舉個例子,現在學霸小明這里有一道數學題的答案:123 。他想把答案傳給自己一直暗戀的小紅。所以他們雙方在考試開考前,約定了一把密鑰:456 。那麼小明就把答案內容經過密鑰加密,即 123 + 456 = 579 ,將 579 寫在小紙條上扔給小紅。如果此時別人撿到了小紙條,不知道他們是加密傳輸的,看到上面的 579 ,會誤以為答案就是 579 ;如果是小紅撿到了,她拿出密鑰解密,579 - 456 = 123 ,得到了正確的答案。

這就是所謂的對稱加密,加解密效率高,速度快,但是雙方任何一方不小心泄露了密鑰,那麼任何人都可以知道傳輸內容了。

講完了對稱加密,我們看看啥是非對稱加密。

非對稱加密就是有兩把密鑰,公鑰和私鑰。私鑰自己藏著,不告訴任何人;而公鑰可以公開給別人。

經過了上次作弊後,小紅發現了對稱加密如果密鑰泄露是一件可怕的事情。所以她和小明決定使用非對稱加密。小紅生成了一對公鑰和私鑰,然後把公鑰公開,小明就得到了公鑰。小明拿到公鑰後,把答案經過公鑰加密,然後傳輸給小紅,小紅再利用自己的私鑰進行解密,得到答案結果。如果在這個過程中,其他人得到傳輸的內容,而他們只有小紅公鑰,是沒有辦法進行解密的,所以也就得不到答案,只有小紅一個人可以解密。

因此,相比較對稱加密而言,非對稱加密安全性更高,但是加解密耗費的時間更長,速度慢。

對稱加密和非對稱加密的具體應用我還是深有體會的,因為所在的公司是做金融支付方面的,所以加解密基本上算是天天見了。

說完加密類型後,我們再來看看 HTTPS 。

我們先來看一個公式:

HTTPS = HTTP + SSL

從這個公式中可以看出,HTTPS 和 HTTP 就差在了 SSL 上。所以我們可以猜到,HTTPS 的加密就是在 SSL 中完成的。

所以我們的目的就是要搞懂在 SSL 中究竟幹了什麼見不得人的事了?

這就要從 CA 證書講起了。CA 證書其實就是數字證書,是由 CA 機構頒發的。至於 CA 機構的權威性,那麼是毋庸置疑的,所有人都是信任它的。CA 證書內一般會包含以下內容:

正好我們把客戶端如何校驗 CA 證書的步驟說下吧。

CA 證書中的 Hash 值,其實是用證書的私鑰進行加密後的值(證書的私鑰不在 CA 證書中)。然後客戶端得到證書後,利用證書中的公鑰去解密該 Hash 值,得到 Hash-a ;然後再利用證書內的簽名 Hash 演算法去生成一個 Hash-b 。最後比較 Hash-a 和 Hash-b 這兩個的值。如果相等,那麼證明了該證書是對的,服務端是可以被信任的;如果不相等,那麼就說明該證書是錯誤的,可能被篡改了,瀏覽器會給出相關提示,無法建立起 HTTPS 連接。除此之外,還會校驗 CA 證書的有效時間和域名匹配等。

接下來我們就來詳細講一下 HTTPS 中的 SSL 握手建立過程,假設現在有客戶端 A 和伺服器 B :

到此,SSL 握手過程就講完了。可能上面的流程太過於復雜,我們簡單地來講:

我們可以發現,在 HTTPS 加密原理的過程中把對稱加密和非對稱加密都利用了起來。即利用了非對稱加密安全性高的特點,又利用了對稱加密速度快,效率高的好處。真的是設計得非常精妙,令人贊不絕口。

好了,HTTPS 加密原理到這就講的差不多了,不知道電腦前的你有沒有看懂呢?

如果有哪裡不明白的地方,可以在底下留言交流。

bye ~~

❸ 一文弄懂關於證書,簽名,ssl,android包簽名機制。

所有的概念都基於一個非常重要的基礎:

rsa 非對稱加密演算法

先感受下幾個概念

PKI。

PKI是公鑰基礎設施(Public Key Infrastructure) 包括PKI策略、軟硬體系統、證書機構CA、注冊機構RA、證書發布系統和PKI應用等。

我們關注就倆東西: PKCS 證書機構CA 。前者是定義加密演算法,簽名,證書相關的各種事情採用的協議。後者可以為我們頒發權威的證書。

PKCS
PKCS(The Public-Key Cryptography Standards )是由美國RSA數據安全公司及其合作夥伴制定的一組公鑰密碼學標准,其中包括證書申請、證書更新、證書作廢表發布、擴展證書內容以及數字簽名、數字信封的格式等方面的一系列相關協議。RSA演算法可以做加密、解密、簽名、驗證,還有RSA的密鑰對存儲。這些都需要標准來規范,如何輸入,如何輸出,如何存儲等。

PKCS。全稱是公鑰密碼學標准, 目前共發布過 15 個標准,這些標准都是協議。總結一下 就是對加密演算法,簽名,證書協議的描述。下面列舉一些常用的協議,這些協議在本文都會對應上。

這些協議具體的實現就體現在openssl等工具中, 以及jdk工具keytool jdk java第三方庫bouncycastle。

比如用openssl 如何生成公/私鑰(PKCS#1)、簽名(PKCS#1 )、簽名請求文件(KCS#10)、 帶口令的私鑰(PKCS#8)。 含私鑰的證書(PKCS#12)、證書庫(PKCS#12)

其中涉及到演算法的基礎協議PKCS#1等,由於涉及到密碼學原理所以我們並不需要深究它,只要知道怎麼做就可以了。

現實中我們要解決這樣一種情況:

客戶端和伺服器之間的數據要進行加密。需要兩個達成同一個對稱秘鑰加密才行,那麼這個秘鑰如何生成,並在兩邊都能拿到,並保證傳輸過程中不被泄露。 這就用到非對稱加密了。 後續的傳輸,就能用這個 對稱秘鑰來加密和解密了。

還有這樣一個問題:

就是客戶端如何判斷服務端是否是合法的服務端。這就需要服務端有個id來證明它,而這個id 就是證書,而且必須是權威機構頒發的才能算是合法的。
因為客戶端即瀏覽器,認定證書合法的規則必須通過第三方來確認 即ca頒發的證書。否則就我可能進了一個假網站。

而這兩個問題 都是ssl協議要解決的內容。

所以ssl協議做了兩件事情,一是驗證身份,二是協商對稱秘鑰,並安全的傳輸。 而實現這個過程的關鍵數據模型就是證書, 通過證書中的ca對證書的簽名,實現了身份驗證,通過證書中的公鑰,實現對對稱秘鑰加密,從而實現數據保密。 其實還順手做了一件事情就是通過解密簽名比對hash,保證了數據完整性。

明白ssl協議 首先明白幾個重要的概念:

證書: 顧名思義就是提供了一種在Internet上驗證通信實體身份的方式,數字證書不是數字身份證,由權威公正的第三方機構,即CA(例如中國各地方的CA公司)中心簽發的證書, 就是可以認定是合法身份的。客戶端不需要證書。 證書是用來驗證服務端的。

一般的證書都是x509格式證書,這是一種標準的證書,可以和其他證書類型互相轉換。完整來說證書包含,證書的內容,包括 版本號, 證書序列號, hash演算法, 發行者名稱,有效期, 公鑰演算法,公鑰,簽名(證書原文以及原文hash一起簽名)而這個內容以及格式 都是標准化的,即x509格式 是一種標準的格式。

簽名: 就用私鑰對一段數據進行加密,得到的密文。 這一段數據在證書的應用上就是 對證書原文+原文hash進行簽名。
誰簽的名,就是用誰的私鑰進行加密。就像身份證一樣, 合法的身份證我們都依據是政府簽的,才不是假證, 那就是瀏覽器會有政府的公鑰,通過校驗(解密)簽名,如果能夠解密,就可以確定這個就是政府的簽名。就對了。

hash演算法 :對原始數據進行某種形式的信息提取,被提取出的信息就被稱作原始數據的消息摘要。比如,MD5和SHA-1及其大量的變體。 hash演算法具有不可逆性,無法從摘要中恢復出任何的原始消息。長度總是固定的。MD5演算法摘要的消息有128個比特位,SHA-1演算法摘要的消息最終有160比特位的輸出。

ca機構: 權威證書頒發機構,瀏覽器存有ca的公鑰,瀏覽器以此公鑰來驗證服務端證書的合法性。

證書的獲取: 生成證書申請文件.csr(涉及到PKCS#10定義的規范)後向ca機構申請。 或者自己直接通過生成私鑰就可以一步到位生成自簽名證書。 自簽名證書就是用自己的私鑰來簽名證書。

那麼為了體現到 證書身份認證、數據完整、保密性三大特性 ,證書的簡化模型可以認為包含以下兩個要素:伺服器公鑰,ca的簽名(被ca私鑰加密過的證書原文+原文hash),

身份認證:
瀏覽器存有ca公鑰,用ca公鑰解密網站發給你的證書中的簽名。如果能解密,說明該證書由ca頒發,證書合法。 否則瀏覽器就會報警告,問你是否信任這個證書,也就是這個網站。這時候的證書可以是任何人簽發的,可以自己簽發的。 但是中間人攻擊。 完全偽造新的證書, 這就沒有辦法了。 所以還是信任證書的時候要謹慎。

數據完整:
如果你信任該證書的話,這時候就會用證書中的公鑰去解密簽名,如果是ca簽發的證書,那麼之前就已經通過ca的公鑰去解密簽名了。 然後得到證書hash,然後在瀏覽器重新對證書做hash,兩者比對一致的話,說明證書數據沒有被篡改。

保密性:
使用證書的公鑰對對稱秘鑰加密保證傳輸安全,對稱秘鑰生成後,後續的傳輸會通過對稱秘鑰來在服務端和客戶端的加解密。

那麼ssl協議的具體過程就是:

4.網站接收瀏覽器發來的數據之後 使用自己的私鑰校驗簽名,並對原文進行hash 與解密出的hash 做比對檢查完整性。然後發送編碼改變通知,伺服器握手結束通知(所有內容做hash )。 發送給客戶端校驗。

5 客戶端校驗,校驗成功後,之後就用 對稱秘鑰進行通信了。

總共的過程是 c-s-c- s-c 四次握手。

四次握手簡單來說分別是:
1.請求獲取證書
2.服務端返回證書,客戶端驗證了證書的合法性和完整性,同時生成了對稱秘鑰。
3.客戶端把加密的 對稱秘鑰發給伺服器。伺服器檢查真實性和完整性。
4.服務端返回握手結束通知,客戶端再檢查一次真實性和完整性。

前兩次握手是明文, 後兩次握手是密文。 所以都要檢查身份真實性和數據完整性。

ca的作用:
ca起到一個權威中間人的角色,如果脫離了ca, 那麼證書還是證書,還能加密,保證數據完整性。 但是無法應用在客戶端去認定伺服器身份合法這個場景下。

  

下面就詳細說下 脫離了ca簽發的證書的應用:
  

自簽名證書:

證書如果沒有權威機構的簽名,就是沒有權威機構給你簽發身份證。 那麼這時候身份認證的場景變了。
這時候的認證場景就變成了,不再是某個官方權威說了算,而是假設第一次碰到這個證書,會認為,這個證書與之捆綁的實體之間是合法的並做記錄。如果當這個實體下次捆綁了另一個證書,那麼就是非法的。

這種情況常用於android中安裝和校驗app的時候,會先假設第一次安裝的是合法的應用,認定這個app證書中的公鑰是合法的公鑰。然後通過自簽名的證書,校驗簽名,就能實現後續安裝是否合法以及完整性。

android中的如何對app進行身份認定和不被篡改:

android系統在安裝app時候會進行校驗applicationId,applicationId 不同會認定為不同應用。相同應用,第二次安裝會校驗證書是否和之前app的證書相同,如果相同則兩個包很可能來自同一個身份。 如果證書不同,也就是該包被另一個身份用自己的私鑰重新簽名過,就會拒絕安裝。 然後通過公鑰來解密簽名,如果能解密,說明身份是ok的。否則拒絕安裝。比對解密簽名後的hash 與apk包內的cert.sf文件(該文件是apk內所有文件生成的hash文件)是否一致,如果相同則認定為沒有被篡改。

android在提交應用商店的問題:

應用商店也會校驗 後續的上傳和第一次上傳時的證書,以及類似上述的後續的一系列校驗。防止合法的開發者平台被盜後,上傳非法應用。

android在接入第三方sdk的問題:

接入第三方sdk 會提交applicationId 和 sha1 值。 這個sha1值就是對 證書原文的簽名後的sha1,也就是證書指紋。這個證書是證書庫里最初的那個證書(x509格式),而不是對apk簽名後生成的證書(PKCS#7)。一般的證書簽名的主體是證書原文本身,而對apk簽名還額外會對apk所有文件生成的hash值文件(cert.sf)進行一次簽名。

第三方平台會記錄 applicationId 與sha1 的對應關系。 當有假冒app試圖接入時候,由於會對app內的PKCS#7證書轉換為原始的x509格式證書,重新生成sha1值,與用戶提交sha1 比對, 如果相同則說明證書很可能是ok的。 因為sha1就是證書的指紋。 之後就會通過證書中的公鑰來校驗簽名,從而最終確認身份合法性以及信息完整性。

第三方平台之所以需要用戶去提交證書指紋sha1值,多了這一步,就意味著你的證書是可以更換的,一旦更換了證書,就必須提交新的指紋給我,然後我來做匹配。而應用商店沒有這個功能, 一旦你的證書的私鑰丟了, 那就必須重新建一個新的app。

總結來看證書的身份認定機制:

在ssl協議下,這種場景是 瀏覽器用於認定合法的伺服器身份。 在自簽名證書下,需要用戶選擇是否信任該證書。

在android app採用自簽名證書的場景下, 證書起到了 假設第一次的證書合法,公鑰合法,後續如果證書不一致或不能夠完成簽名校驗,就是非法。

證書庫:

證書庫應該滿足PKCS#12協議。 但是jdk提供了製作證書的工具keytool 可以生成keystore類型的證書庫,後綴為jks。 keystore pk12可以通過keytool命令互相轉換。

證書庫是個證書的容器, 可以用來創建數字證書。 在keystore證書庫中,所有的數字證書是以一條一條(採用別名alias區別)的形式存入證書庫的。證書庫中的證書格式為pk12,即包含私鑰。 如果導出證書的話, 可以導出為x509不包含私鑰的格式 或者pk12包含私鑰的證書。 也可以也可以用-import參數加一個證書或證書鏈到信任證書。

android中一般都採用讀取證書庫的方式,通過證書庫來創建一個證書,通過alias來區分。 所以在簽名的時候,一個alias是一個證書,不同的alias是不同的證書,不要搞錯了。

幾個關系:

證書和非對稱加密演算法的關系:
證書代表一個身份的主體,包含了非對稱秘鑰體系中的公鑰,以及用私鑰對證書簽名。這種組織結構,把非對稱加密演算法從加密的功能,拓寬到了用於身份認證,信息完整性上。這體現在了證書的作用。 本質還是利用了非對稱加密演算法的特性。

ssl協議和證書的關系。
因為證書解決了客戶端對伺服器的身份認證(自簽名證書除外),同時也解決了加密,和信息完整性,所以ssl協議基於證書來實現。

閱讀全文

與怎麼根據ca證書確認加密演算法相關的資料

熱點內容
騰訊雲域名解析到阿里雲伺服器需要備案嗎 瀏覽:542
應用加密機和可信平台 瀏覽:993
linuxusb禁用 瀏覽:724
宿州市電信dns伺服器地址是多少 瀏覽:85
數字簽名中報文加密方式 瀏覽:483
解壓包變成記事本格式了 瀏覽:287
安卓編程怎麼復制文本 瀏覽:820
雲開通伺服器 瀏覽:389
python編程集合降序 瀏覽:283
山西抖音小程序源碼 瀏覽:700
方舟編譯器到底什麼原理 瀏覽:643
演算法概率與人工干預 瀏覽:673
軟通動力android 瀏覽:20
linuxwireshark命令 瀏覽:197
php播放器插件 瀏覽:952
如何把python寫的程序導入手機 瀏覽:27
mysql中查詢系統變數的命令是什麼 瀏覽:144
尚恩解壓圖片 瀏覽:556
新手程序員學那個語言接私活 瀏覽:21
疏解壓力同義詞 瀏覽:81