數字證書
- 系列博文
- 前言
- 一、數字證書
- 二、CA(Certification Authority)認證
- 2.1 CA認證資訊
- 2.2 CA結構
- 2.3 一般的證書產生流程
- 2.4 完整流程
- 三、PKI,Public Key infrastructure ,公鑰基礎設施
- 3.1 PKI/CA發展歷程
- 3.2 PKI權威機構
- 四、PKI應用和訪問控制
- 4.1 網銀安全流程
- 4.2 HTTPS(HTTP over SSL)
- 4.2.1 SSL概述
- 4.2.2 **身份認證、密碼安全傳輸和存盤:**
- 4.3 身份認證方式舉例
- 4.3.1 動態口令牌
- 4.3.2 指紋識別認證
- 4.3.3 虹膜識別認證
- 4.3.4 視網膜識別認證
- 4.3.5 臉型驗證
- 4.3.6 掌形識別技術
系列博文
- 信安小白,說明白滲透測驗及資訊安全
- 信安小白,一篇博文講明白暴力破解和SQL注入
- 信安小白,一篇博文講明白上傳漏洞——獲得shop靶機的Webshell
- 信安小白,一篇博文講明白存盤型、反射型XSS漏洞
- 信安小白,一篇博文講明白CSRF攻擊和防御
- 信安小白,科普一篇博文講對稱密碼演算法、非對稱密碼演算法
- 信安小白,一篇博文講明白數字簽名
- 信安小白,一篇博文講明白數字證書和PKI(公鑰基礎設施)
前言

必要參考:信安小白,一篇博文講明白數字簽名
??從圖中可知,傳遞合同的整個程序中最重要的部分,因此需要會話密鑰進行AES加密資訊,而會話密鑰是用Bob的公鑰進行RSA加密,因此用RSA演算法加密AES演算法密鑰是安全的關鍵所在,也就是說:整個程序的資訊安全機制在于如何將Bob的公鑰,安全傳輸給Alice,用于加密AES演算法密鑰,同時Bob也需要Alice的公鑰來驗證簽名,

??公鑰本身是公開的,Alice和Bob需要交換密鑰進行操作,程序中會出現公鑰在傳輸時被第三人替換,被中間人攻擊的情況,
中間攻擊: Tom截獲兩個人的公鑰,同時發送自己的公鑰給雙方,Alice無法驗證收到的公鑰是否是Bob的,Alice將原本是Bob的公鑰(其實是Tom的公鑰)用于資料加密發送給Bob,Tom在中途截獲了Alice發送的資料包,用自己的私鑰進行解密,獲得合同,如果合同被Tom修改后再次用Bob的公鑰加密,這樣Bob收到的合同與Alice最初發送的合同就不一樣了,會存在很大隱患,

出現的問題:
??Alice和Bob都以為是直接和對方進行秘密通信,實際上所有的資訊都被Tom翻譯過了,如何確認身份?或者說能否確認身份?(不能用發送私鑰的方式確認身份,因為還需要使用公鑰來解密進而確認身份,出現相同的問題!)

參照生活中我們會使用到的身份證——只能使用數字證書的方式解決以上問題
一、數字證書
??參照身份證,證明每個人是唯一的,身份證號能證明我們每一個個體的身份,而數字證書上的證明就是公鑰,身份證還需要公安局權威認證,因此數字證書也需要第三方權威頒發,這里的第三方就是CA認證,身份證還需要公安局蓋章,證明是公安局簽發用于防偽,而數字證書上需要第三方權威機構的數字簽名用于防偽認證,

二、CA(Certification Authority)認證
CA----認證中心
- CA為電子商務、電子政務等網路環境中各個物體頒發數字證書,以證明身份的真實性,并負責在交易中檢驗和管理證書,
- CA對數字證書的簽名使得第三者不能被偽造和篡改證書,
- CA認證是具有權威性、可信賴性、公證性的第三方機構,
數字證書模版:

2.1 CA認證資訊
- 數字證書資訊經過hash演算法得到摘要1
- CA用自己的私鑰對摘要進行簽名
- 簽名附在數字證書資訊后面
- 接收方用CA公鑰解密得到摘要1
- 接收方將數字證書資訊進行hash得到摘要2
- 比對摘要1和摘要2驗證
- CA是權威的機構因此公鑰不是很容易會被篡改,就好比110號碼是公安局的電話,沒有人敢用110號碼進行詐騙,

2.2 CA結構

2.3 一般的證書產生流程
??個人先向注冊機構進行證書申請,隨后注冊機構向證書認證機構提出申請,認證機構負責生產證書,從證書資料庫發布證書(認證機構的數字簽名)與個人系結(個人公鑰)交給注冊機構,注冊機構再交給個人,個人拿上證書進行資料傳輸,通過證書資料庫進行證書狀態查詢,用自己的私鑰進行證書確認,

2.4 完整流程
數字證書:發送方自己的數字證書(公鑰)
圖中沒畫Bob把自己的數字證書發送給Alice的程序,也少了雙方數字證書的驗證!

??上圖中整個程序的核心的部分是數字簽名、數字證書、會話密鑰的加密都需要用到的公鑰演算法(非對稱加密演算法),對稱加密演算法只用于加密資料,非對稱加密演算法用的很多,基于公鑰演算法而展現的模式叫做PKI,
三、PKI,Public Key infrastructure ,公鑰基礎設施
- PKI是一組組件和規程
- PKI是一個用公鑰概念和技術來實施和提供安全服務的具有普適性的安全基礎設施,
- PKI提供的服務:
-1. 認證服務
-2. 完整性
-3. 保密性
3.1 PKI/CA發展歷程
- 20世紀80年代,美國學者提出了PKI的概念
- 為了推進PKI在聯邦政府范圍內的應用,1996年就成立了聯邦PKI指導委員會
- 1996年,以Visa、MastCard、IBM、Netscape、MS、數家銀行推出SET協議,推出CA和證書概念
- 1999年,PKI論壇成立
- 2000年4月,美國國防部宣布要采用PKI安全倡議方案,
- 2001年6月13日,在亞洲和大洋洲推動PKI行程的國際組織宣告成立,該國際組織的名稱為“亞洲PKI論壇”,其宗旨是在亞洲地區推動PKI標準化,為實作全球范圍的電子商務奠定基礎
PKI的場景:

3.2 PKI權威機構
- 中國金融認證中心( China Finance Certification Authority 縮寫 CFCA ),是由中國人民銀行牽頭,聯合中國工商銀行、等十二家商業銀行參加建設,由銀行卡資訊交換總中心承建的,
- ICAO(國際民用航空組織International Civil Aviation Organization)制定了PKI數字證書的電子護照標準
- 每個香港公民一人一個智能身份證,每個智能身份證上配發一個全球通用的由香港郵政局頒發的個人數字證書
- 認證機構的嚴格層次結構

四、PKI應用和訪問控制
4.1 網銀安全流程
-
柜臺注冊,開通網銀手機銀行 ,獲得U盾 (用戶的私鑰和用戶的數字證書)
-
網銀插件下載,手機銀行登錄
??用戶名、登錄密碼需要會話密鑰加密(對稱加密演算法),隨后需要RSA(非對稱加密演算法)加密會話密鑰,用銀行公鑰加密,銀行公鑰從數字證書獲得,存在網銀插件里,同時使用安全輸入鍵盤防止密碼被記錄,
??網銀插件下載:安全鍵盤、銀行數字證書、安全插件 -
網銀登錄,查詢賬戶余額
??資訊會用會話密鑰加密,查詢余額,查詢的資訊需要銀行簽名,比如列印各種資訊銀行會蓋章, 銀行數字簽名用銀行的私鑰簽,用銀行的公鑰來驗證簽名,
??余額查詢銀行要簽名并加密,會話密鑰由客戶端產生 -
轉賬,插入U盾
??轉賬需要我們自己簽字,需要自己的私鑰來加密,U盾里存著我們自己的私鑰,銀行通過我們的數字證書獲得公鑰,用我們的公鑰驗證簽名,插入U盾時,我們就會獲得我們自己的數字簽名,
??U盾中存著我們自己的私鑰和數字證書,
4.2 HTTPS(HTTP over SSL)
- SSL (Secure Sockets Layer)協議Internet網上安全通訊與交易的標準, 瀏覽器就支持此協議
- SSL協議使用通訊雙方的客戶證書以及CA根證書,在通訊雙方間建立起了一條安全的、可信任的通訊通道,它具備以下基本特征:資訊保密性、資訊完整性、相互鑒定,
- TLS(Transport Layer Security,傳輸層安全協議)是SSL3.0的后續版本,可以理解為SSL3.1
- 使用SSL協議時就是使用密文在傳輸了,不再使用明文傳輸!
4.2.1 SSL概述
SSL在應用層和傳輸層之間

一般查看網站都使用單向SSL功能:
??就像網上銀行的“查詢余額服務”一樣,只用查看服務器的數字證書,不會查看用戶客戶端自己的數字證書,會話密鑰每次訪問時都會重新獲得!

雙向認證 SSL 協議的具體程序:
??相當于網上銀行的轉賬程序,需要用戶提供自己的數字證書進行交換,
- 瀏覽器發送一個連接請求給安全服務器,
- 服務器將自己的證書等資訊發送給客戶瀏覽器,
- 客戶瀏覽器檢查證書是否是由自己信賴的 CA 中心所簽發的,如果是,就繼續執行協議;如果不是,給出警告訊息:警告客戶這個證書不是可以信賴的,詢問客戶是否需要繼續,
- 瀏覽器比較證書里的訊息,例如域名和公鑰,與服務器剛剛發送的相關訊息是否一致,如果是一致的,客戶瀏覽器認可這個服務器的合法身份,
- 服務器要求客戶發送客戶自己的證書,收到后,服務器驗證客戶的證書,如果沒有通過驗證,拒絕連接;如果通過驗證,服務器獲得用戶的公鑰,(單向認證沒有)
- 瀏覽器告訴服務器自己所能夠支持的通訊對稱密碼方案,
- 服務器從客戶發送過來的密碼方案中,選擇一種密碼方案通知瀏覽器,
- 瀏覽器針對這個密碼方案,隨機產生會話密鑰,用服務器的公鑰加過密后發送給服務器,
- 服務器接收到瀏覽器送過來的訊息,用自己的私鑰解密,獲得
會話密鑰, - 服務器、瀏覽器接下來的通訊都是用對稱密碼演算法加密,
常用的https不是雙向的,沒有 5
4.2.2 身份認證、密碼安全傳輸和存盤:

??SSL協議(Https),保證我們發送的資訊(比如:用戶名和密碼)都是會加密的,但到了服務器端是如何做到安全存盤,如何驗證我們是合法的呢?
身份認證有三個要素:
- 你所知道的:例如密碼、身份證號碼、密保問題等;
- 你擁有什么東西:例如手機短信驗證碼、一個動態口令卡、U盾;
- 你擁有什么特征:例如指紋、瞳孔等等,
登錄密碼安全存盤:

??服務器端不能明文存盤用戶名、密碼等資訊,必須采用MD5等方式的Hash運算得到的Hash值存盤在服務器中,防止管理員看見我們用戶的相關資訊,Hash演算法不可能還原,不可逆 得到明文,且具有 唯一性:密文修改一位,Hash值就會改變!

Hash演算法的問題:
- 一一對應,在哈希演算法被人知道的情況下,可以查表反查出密碼(密碼相對比較簡單的時候),
- 黑客手中也往往有一份碰撞庫,可以用來嘗試通過驗證,
- 用戶密碼越簡單,越容易暴力破解
拖庫,查表法獲得密碼:

防止黑客利用用戶“常用密碼庫”進行碰撞:
??Hash + Salt (對密碼進行一次哈希加密后,在哈希值中添加一串系統生成的亂數(無法獲取),再進行一次哈希加密)無法用哈希表反查出密碼,

4.3 身份認證方式舉例
4.3.1 動態口令牌
??通過認證服務器發放一次性口令卡,由于在認證服務器上擁有每一個口令卡的口令變化初始值(認證服務器管理員無法看到),這樣發放到口令卡上的數字將和認證服務器上的初始值基于相同的演算法進行同步變化,

4.3.2 指紋識別認證
指紋的三個特性是指紋識別技術的基礎:
- 每個人的指紋形狀終身不變,指紋的嵴線形狀在一生中不會改變;具有一定的復原性和難以毀滅性,
- 每個人的指紋各不相同,
- 指紋的觸物留痕:
人工采集時期—油墨;
電子化指紋采集設備—光學式、硅芯片式、超聲波式,
4.3.3 虹膜識別認證
-
虹膜是環繞在瞳孔四周有色彩的部分,每一個虹膜都包含一個獨一無二的基于像冠、水晶體、細絲、斑點、結構、凹點、射線、皺紋和條紋等特征的結
構, -
每一個人的虹膜各不相同,一個人的左眼和右眼就可能不一樣,即使是雙胞胎的虹膜也可能不一樣,
-
人的虹膜在出生后6-18個月成型后終生不再發生變化,
-
虹膜技術的優點:
識別精度高,錯誤率小于百萬分之一;
穩定性好,兩歲后虹膜終生不變,受損害的可能性小;
采集相對方便; -
虹膜技術的缺點:
很難將影像獲取設備的尺寸小型化;
需要昂貴的攝像頭聚焦;
黑眼睛極難讀取;
需要較好光源,
4.3.4 視網膜識別認證
- 視網膜識別原理是通過分析視網膜上的血管圖案來區分每個人的,視網膜掃描是用低強度紅外線照亮視網膜,以拍攝下主要血管構成的影像,
- 由于視網膜位于眼球的后面,因此采集程序需要用戶高度配合,要求站在2-3英寸的地方,保持靜止1-2秒的時間,
- 更重要的是被辨識者對視網膜掃描技術的憂慮,擔心會影響眼睛健康,由于這些原因視網膜識別技術并未成為生物識別技術中的主流技術,
4.3.5 臉型驗證
- 臉形識別,不僅僅是比對,還包括捕捉,需要從一堆移動著的影像中,識別出哪里是人相,并且把人相分離出來,再進行臉形成像,
- 在面部被捕捉之后,一些核心特征點被記錄,例如,眼睛,鼻子和嘴的位置以及它們之間的相對位置,熱成像技術是通過分析由面部的毛細血管的血液產生的熱線來勾畫出面部影像,
4.3.6 掌形識別技術
??手掌特征含手和手指的大小和形狀,它包括長度、寬度、厚度以及手掌和除大拇指之外的其余四個手指的表面特征,掌形采集的原理是通過紅外、CCD成像等方法獲得手掌的三維影像,作為掌形特征處理的輸入資料,

轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/342026.html
標籤:其他
