加密,數字簽名和數字證書

在蘋果全球開發(fā)者大會上,蘋果規(guī)定2017年1月1日以后,App Store 當中的所有應用必須打開ATS(iOS9中新增App Transport Security(簡稱ATS)特性),在啟用 ATS 之后,它會強制應用通過 HTTPS(而不是 HTTP)連接網絡服務,這能夠通過加密來保障用戶數據安全。所以,所有APP都要使用HTTPS進行網絡請求,否則不能上架。

在iOS9的時候,還可以關閉ATS使用HTTP,現在到年底之前不行了。是時候該改用HTTPS了。
最近研究了一下iOS中使用HTTPS實現請求,以及證書怎么生成,在介紹之前,為了更好的理解證書的特性,在這里我梳理了數字證書和互聯網信息傳遞的安全體系方面的知識,也算是自己的一些總結筆記。

說到數字證書不得不先了解各種加解密算法和摘要算法。目前加密方法可以分兩大類。一類是單鑰加密,也稱作是對稱加密,還有一類就是雙鑰加密,也稱作非對稱加密。數字證書是基于非對稱,摘要算法的,其中的核心就是非對稱加密算法了。

加密算法

對稱加密

對稱加密指加密和解密使用相同密鑰的加密算法。在大多數的對稱算法中,加密密鑰和解密密鑰是相同的,所以也稱這種加密算法為單密鑰算法。

在應用該算法時,它要求發(fā)送方和接收方在安全通信之前,商定一個密鑰。對稱算法的安全性依賴于密鑰,泄漏密鑰就意味著任何人都可以對他們發(fā)送或接收的消息解密,所以密鑰的保密性對通信性至關重要。對稱加密算法的特點是算法公開、計算量小、加密速度快、加密效率高。對稱加密有很多種算法,由于它效率很高,所以被廣泛使用在很多加密協議的核心當中。不足之處是,交易雙方都使用同樣鑰匙,安全性得不到保證。

常見的對稱加密算法有DES,AES,RC4,IDEA等。

非對稱加密

與對稱加密算法不同,非對稱加密算法需要兩個密鑰:公開密鑰和私有密鑰;并且加密密鑰和解密密鑰是成對出現的。在雙鑰體系中,公鑰用來加密信息,私鑰用來數字簽名

非對稱加密的特性

  • 對于一個公鑰,有且只有一個對應的私鑰。
  • 公鑰是公開的,并且不能通過公鑰反推出私鑰。
  • 通過私鑰加密的密文只能通過公鑰能解密,通過公鑰加密的密文也只能通過私鑰能解密。

通過公鑰是極難推算出私鑰的,只能通過窮舉,所以只要密鑰足夠長,要想從公鑰推算出私鑰幾乎不可能的。

非對稱加密不需要共享同一份秘鑰,安全性要比對稱加密高,但由于算法強度比對稱加密復雜,加解密的速度比對稱加解密的速度要慢。因此,在實際使用中,往往與對稱加密和摘要算法結合使用。

常見的非對稱加密算法有RSA,DSA,Diffie-Hellman,ECC等。

對稱加密和非對稱加密的區(qū)別

兩者的主要區(qū)別就是是否使用同一個秘鑰,對稱加密需要用同一個秘鑰。非對稱加密不需要用同一個秘鑰,而是需要兩個秘鑰:公開密鑰和私有密鑰,并且加密密鑰和解密密鑰是成對出現的。

發(fā)布者用公鑰加密數據,然后把加密數據發(fā)布出去,接收者拿到數據后用私鑰解密就可以看到真實內容。即使黑客抓包截獲加密數據,沒有私鑰就無法解出內容。也就是只要私鑰沒有泄露,數據就是安全的。但有種情況是可能黑客拿到了公鑰,他不能解密數據,但可以用拿到的公鑰加密偽造數據,這時候接收者拿到的就是被篡改的數據了。

為了防止數據信息發(fā)布后不被篡改和數據的完整性,就需要用到數字簽名了。

在雙鑰體系中,公鑰用來加密信息,私鑰用來數字簽名。

數字簽名

數字簽名就是對非對稱加密和摘要算法的一種應用。先來介紹下摘要算法:

摘要算法

摘要算法是將任意長度的一塊數據轉換為一個定長的、不可逆轉的數字,其長度通常在128~256位之間。除了加密算法,摘要算法在互聯網安全體系中也扮演了重要的角色。摘要算法具有以下特性:

  • 只要源文本不同,計算得到的結果,必然不同(或者說機會很少)。
  • 無法從結果反推出源數據(那是當然的,不然就能量不守恒了)。

基于以上特性,我們一般使用摘要算法來校驗原始內容是否被篡改。常見的摘要算法有 MD5、SHA 等。

摘要算法用于對比信息源是否一致,因為只要源數據發(fā)生變化,得到的摘要必然不同。因為通常結果比源數據要短很多,所以稱為“摘要”。

簽名

這時候就要利用摘要算法無法還原出原來內容的特性了。

  1. 為了防止發(fā)布內容中途被篡改,發(fā)布者可以通過摘要算法提取發(fā)布內容的摘要,用私鑰加密之得到密文即簽名,這時候將加密內容、簽名以及公鑰一起發(fā)布出去。

  2. 接收者收到數據時,首先驗證公鑰是否是發(fā)布者的公鑰,然后用公鑰對密文進行解密,得到摘要,使用發(fā)布者對文本同樣的摘要算法得到摘要文本,比對摘要是否一致即可確認信息是否被篡改或者是指定發(fā)布者發(fā)布的。

數字簽名.jpg

發(fā)布方


發(fā)布方.png

接受方

接收方.png

再次強調摘要算法的特性,只要源數據改變,經摘要算法后得到的摘要必然不同,而且是不可逆的,不能還原反推出原始數據。

如果黑客抓取到簽名和公鑰,還用公鑰解密簽名得到摘要,不知道摘要算法就還原不了原始數據,最不濟黑客解密了內容,并篡改了,勢必摘要會跟隨改變,黑客拿偽造的內容和截獲的簽名發(fā)出去的時候,此時接收者計算出來的摘要簽名必然跟這個簽名不匹配。這就驗證了是否被篡改了。

源代碼的簽名

規(guī)范.png

這是我們兄弟會源代碼平臺的請求和返回規(guī)范。所有當前的項目的接口請求基本都采用這種規(guī)范,使用到了我們規(guī)定了的一套簽名算法。前面沙龍群技術分享也有提到過,但是后來不少朋友還有很多傳輸過程中的安全疑問。

  1. 每一次發(fā)出的請求(Request)里含有一些參數,包括用這些參數生成的簽名signature。
  2. 其中客戶端跟服務端用同樣的算法生成簽名的。客戶端把算好的簽名跟其他參數一起傳給服務器,服務器把拿到的參數用同樣的算法生成簽名,然后用這個簽名和客戶端傳過來的簽名對比來判斷數據是否被篡改。
  3. 如果抓取到傳輸的數據,勢必要變換業(yè)務參數,一旦參數變動簽名就會變,如果不知道簽名的算法,服務端簽名驗證必然不能通過,而且這個算法也有維護,周期變換規(guī)則,不僅要防止外部破解,也要防止內部離職的人員泄漏。
  4. 具體的加密算法和規(guī)則,前面我們的沙龍技術分享也提供了一個范本給大家,需要的朋友可以在技術群里找客服索取,也可以直接找我。

任何的加密措施,在一定程度都有被破解的可能,我們要做的就是增加破解的難度和成本。

到目前為止還有個風險就是接收者拿到的公鑰被替換了成了黑客的公鑰,接收者這時候被認為是可以接收黑客的數據的。黑客用自己的私鑰做了數字簽名,然后發(fā)布數據給接收者,接收者用黑客的公鑰解密。這樣接收者還是會受到被篡改的數據。

數字證書就是來解決這個問題的。

數字證書

現實生活中的證書是由權限機構頒發(fā)的證明,比如畢業(yè)證等。一般的證書都有機構的公章,通過這個公章來驗證證書的合法性。問題就在這個公章,公章是可以造假的,那么證書就是假的。但是在我們的數字證書中,數字簽名是沒辦法偽造的。

數字證書就是通過數字簽名實現的數字化的證書,在現實生活中公章可以被偽造,但是在計算數字世界中,數字簽名是沒辦法被偽造的。數字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息以及公鑰的文件。數字證書里一般會包含公鑰、公鑰擁有者名稱、CA(簽發(fā)證書機構統(tǒng)稱為CA) 的數字簽名、有效期、授權中心名稱、證書序列號等信息。

接著前面,那怎么判斷數字證書列出的用戶就是公鑰的擁有者呢?(前面這個公鑰可能被黑客替換)

發(fā)布證書的時候,先用私鑰對文件的摘要信息進行簽名,將簽名和證書文件一起發(fā)布,這樣能保證證書無法被偽造。驗證證書是否合法時,首先用公鑰(機構頒發(fā)的證書的公鑰是公開的,誰都可以獲取到)對簽名解密得到摘要信息,另外用同樣的摘要算法得到證書的另一個摘要信息,對比兩個摘要信息是否一致就可以判定該證書是否合法,可以信任的。

數字證書也有很多的簽發(fā)機構,不同的簽發(fā)機構簽發(fā)的證書,用途也是不一樣的,比如iOS開發(fā)中,使用到的ipa文件簽名證書,需要到蘋果申請。而在Web訪問中為了防止Web內容在網絡中安全傳輸,需要用到的SSL證書則需要向幾家公認的機構簽發(fā)。這些簽發(fā)機構統(tǒng)稱為CA(Certificate Authority)。

Web訪問相關的證書可以向國際公認的幾個機構:WebTrust,GlobalSign,GTE,Nortel,Verisign。

我這里貼一張MAC里面的證書管理,受信任的根證書頒發(fā)機構,客戶端會根據這張列表,查看解開數字證書的公鑰是否在列表之內。

證書管理.png

HTTPS證書

HTTPS中密鑰交換用的就是非對稱加密的保密特性來實現的。
目前有2中方法得到HTTPS證書:

  1. 第三方認證的頒發(fā)CA證書(推薦)
  2. 自己制作證書(這種不知道能不能滿足蘋果的審核)

直接購買收費的證書最省事了,也比較安全,推薦這種方法。還可以自己制作證書,但不知道能否通過蘋果的審核,只有等到1月份上架APP的時候測試了。問了身邊幾個朋友,基本上都還沒有支持HTTPS,后面有機會再分享一下怎么自己制作證書,通不通的過也算是一種嘗試了。

總結

數字簽名和數字證書是兩個不同的概念,理解的關鍵點是數字簽名是內容提供方用自己的私鑰對內容摘要(MD5、SHA)非對稱加密,而數字證書的關鍵是 CA 用自己的私鑰對證書內容的摘要非對稱加密從而確保證書內的用戶合法擁有證書里列出的公鑰。

有一篇國外的很好的文章,它用圖片通俗易懂地解釋了,"數字簽名"(digital signature)和"數字證書"(digital certificate)到底是什么。中文的翻譯在這里

在這里簡單的介紹了數字證書和一些加密算法,很多詳細更深入的東西還沒涉及,比如非對稱加密算中用的最廣的RSA算法原理和加密與破解,還有HTTPS秘鑰協商過程等,有興趣的朋友可以更深入的學習下。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,646評論 6 533
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現死者居然都...
    沈念sama閱讀 98,595評論 3 418
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,560評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,035評論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,814評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,224評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,301評論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,444評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發(fā)現了一具尸體,經...
    沈念sama閱讀 48,988評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,804評論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,998評論 1 370
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,544評論 5 360
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 44,237評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,665評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,927評論 1 287
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,706評論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,993評論 2 374

推薦閱讀更多精彩內容