計算機網(wǎng)絡(luò)安全原理（第2版）課件 第4章 PKI與數(shù)字證書

第四章PKI與數(shù)字證書內(nèi)容提綱數(shù)字證書2PKI3證書透明性4密鑰管理1密鑰管理基于密鑰保護的安全策略：保護密鑰密鑰管理包括密鑰的產(chǎn)生、存儲、分發(fā)、組織、使用、停用、更換、銷毀等一系列問題，涉及每個密鑰的從產(chǎn)生到銷毀的整個生命周期。如何安全可靠、迅速高效地分配和管理密鑰是密碼學(xué)領(lǐng)域的重要研究課題。密鑰管理重要階段密鑰生成：包括對密鑰密碼特性方面的測量，以保障生成密鑰的隨機性和不可預(yù)測性，以及生成算法或軟件在密碼上的安全性。用戶可以自己生成所需的密鑰，也可以從可信中心或密鑰管理中心申請，密鑰長度要適中。密鑰使用：利用密鑰進行正常的密碼操作，如加密、解密、簽名等，注意應(yīng)用環(huán)境對密鑰的安全性的影響。密鑰更新：在密鑰過期之前，為保證密鑰的安全性，以新密鑰代替舊的密鑰，包括密鑰的生成、密鑰的推導(dǎo)、執(zhí)行密鑰交換協(xié)議等。密鑰管理重要階段密鑰備份：以安全方式存儲密鑰，用于密鑰恢復(fù)。密鑰恢復(fù)：若密鑰喪失但未被泄露，就可以用安全方式從密鑰備份中恢復(fù)。密鑰存檔：不再正常使用的密鑰可以存入檔案中，用于解決爭執(zhí)。它是密鑰的后運行階段工作。密鑰吊銷：若密鑰丟失或在密鑰過期之前，需要將它從正常使用的集合中刪除。密鑰銷毀：對于不再需要使用的密鑰，要將其所有復(fù)本銷毀，而不能再出現(xiàn)。不同性質(zhì)密鑰的管理問題對稱加密：通信雙方必須共享一個密鑰，這個密鑰還要防止被他人獲得；公開加密：通信各方必須發(fā)布其公開密鑰，并防止其私鑰被其他人獲得。

密鑰還需經(jīng)常更換，以便攻擊者知道密鑰的情況下使得泄漏的數(shù)據(jù)量最小2024/7/226對稱密鑰分配的幾種方法

人工方法：A選定密鑰，通過物理方法安全傳遞給B?？尚湃蔚谌紺選定密鑰，通過物理方法安全傳遞給A和B。人工方法不適用于大量連接的現(xiàn)代通信對稱密鑰分配的幾種方法

通信方法：如果A和B先前或者最近使用過一個密鑰，則一方可以將新密鑰用舊密鑰加密后發(fā)送給另一方如果A和B到第三方C（密鑰分配中心，KDC）有加密連接，C可以通過該加密連接將密鑰傳送給A和B若第三方C（認(rèn)證中心CA）發(fā)布A和B的公鑰，A和B可用彼此的公鑰來加密通信公開密鑰的管理公開密碼體制的密鑰管理：私鑰的分發(fā)與對稱密碼體制類似，公鑰的分發(fā)問題：將產(chǎn)生的公開密鑰安全地發(fā)送給相關(guān)通信參與方的技術(shù)和方法問題：如果公鑰的完整性和真實性受到危害，則基于公鑰的各種應(yīng)用的安全性將受到危害。在公鑰管理過程中采取了將公鑰和公鑰所有人信息綁定的方法，這種綁定產(chǎn)生的就是用戶數(shù)字證書（DigitalCertificate,DC）內(nèi)容提綱數(shù)字證書2PKI3證書透明性4密鑰管理1數(shù)字證書是一種由一個可信任的權(quán)威機構(gòu)（CA）簽署的信息集合。在不同的應(yīng)用中有不同的證書，如公鑰證書（PublicKeyCertificate,PKC）、PGP證書、SET證書等。數(shù)字證書公鑰證書公鑰證書主要用于確保公鑰及其與用戶綁定關(guān)系的安全，一般包含持證主體身份信息、主體的公鑰信息、CA信息以及附加信息，再加上用CA私鑰對上述信息的數(shù)字簽名。目前應(yīng)用最廣泛的證書格式是國際電信聯(lián)盟（InternationalTelecommunicationUnion,ITU）制定的X.509標(biāo)準(zhǔn)中定義的格式數(shù)字證書X.509最初是在1988年的7月3日發(fā)布的，版本是X.509v1，當(dāng)時是作為ITUX.500目錄服務(wù)標(biāo)準(zhǔn)的一部分。在此之后，ITU分別于1993年和1995年進行過兩個修改，分別形成了X.509版本2(X.509v2)和版本3(X.509v3)，其中v2證書并未得到廣泛使用X.509證書X.509數(shù)字證書360瀏覽器中的數(shù)字證書證書保存格式證書保存格式aDERencodedcertificateopenedinaHEXeditorthesamecertencodedasBase64alsoopenedinaHEXeditor證書保存格式FinallyhereisthesamecertificateinASN.1humanreadableform(thisisn’tthewholecert)數(shù)字證書數(shù)字證書數(shù)字證書數(shù)字證書數(shù)字證書數(shù)字證書數(shù)字證書?關(guān)于證書指紋1、瀏覽器顯示的指紋就是證書簽名嗎？2、YES，那為什么長度都是160位？3、NO，那它跟證書簽名有什么關(guān)系？是證書簽名值的一部分還是完全獨立的？攤銷證書列表（CRL）證書有效性驗證內(nèi)容提綱數(shù)字證書2PKI3證書透明性4密鑰管理1有了證書以后，將涉及證書的申請、發(fā)布、查詢、撤銷等一系列管理任務(wù)，因此需要一套完整的軟硬件系統(tǒng)、協(xié)議、管理機制來完成這些任務(wù)，由此產(chǎn)生了公鑰基礎(chǔ)設(shè)施（PKI）PKI一、PKI組成PKI系統(tǒng)組成PKI認(rèn)證體系2024/7/2233在PKI中，CA是所有注冊用戶所依賴的權(quán)威機構(gòu)，它嚴(yán)格遵循證書策略機制所制定的PKI策略來進行證書的全生命周期的管理，包括簽發(fā)證書，管理和撤銷證書。CA是信任的起點，只有信任某個CA，才信任該CA給用戶簽發(fā)的數(shù)字證書。為確保證書的真實性和完整性，CA需要在給用戶簽發(fā)證書時加上自己的簽名CA對于大范圍的應(yīng)用，特別是在互聯(lián)網(wǎng)環(huán)境下，由于用戶眾多，建立一個管理全世界所有用戶的全球性PKI是不現(xiàn)實的，因此往往需要很多個CA才能滿足應(yīng)用需要，這就涉及到CA間的信任問題，即CA信任模型CA對于具有明顯層次結(jié)構(gòu)的行業(yè)或組織，如政府（國家省市縣）、全國性的公司（如銀行、中石油、中石化、稅務(wù)、工商等）等，可以將組織中的最高層次的機構(gòu)作為信任的起點。等級層次高的CA為下層的CA頒發(fā)數(shù)字證書，其中最高層的CA被稱為根CA（RootCA），面向終端用戶的一般是最下層的CA，這就是“樹模型（treemodel）”或“層次模型（hierarchymodel）”CA樹模型CA樹模型信任樹（treeoftrust）信任錨（trustanchor）要驗證一份證書（C1）的真?zhèn)危打炞CCA對該證書信息的簽名是否有效），需要用簽發(fā)該證書（C1）的CA的公鑰進行驗證，而CA的公鑰保存在對這份證書進行簽名的CA證書（C2）內(nèi)，故需要下載該CA證書（C2），但使用該證書驗證又需先驗證該證書本身的真?zhèn)?，故又要用簽發(fā)該證書的證書（C3）來驗證，這樣一來就構(gòu)成一條證書鏈的關(guān)系（C1-C2-C3……），這條證書鏈在哪里終結(jié)呢？CA樹模型根證書是一份特殊的證書，它的簽發(fā)者是它本身（根CA），安裝了根證書就表明你對該根證書以及用它所簽發(fā)的證書都表示信任，不需要再通過其他證書來驗證，證書的驗證追溯至根證書即結(jié)束。CA信任模型如果一個組織本身就采用層次結(jié)構(gòu)，則上述層次結(jié)構(gòu)的CA組織方式就非常有效。但是，對于內(nèi)部不采用層次結(jié)構(gòu)的組織以及組織之間，則很難使用層次結(jié)構(gòu)的CA組織方式。解決這個問題的一般方式是權(quán)威證書列表，即將多個CA證書機構(gòu)內(nèi)受信任的、含有公鑰信息的證書安裝到驗證證書的應(yīng)用中。一個被廣泛使用的典型應(yīng)用就是Web瀏覽器。權(quán)威證書列表：Web模型權(quán)威證書列表：Web模型★

Web模型依賴于流行的瀏覽器瀏覽器CA的公鑰（如Verisign）

CA的私鑰Web服務(wù)器的數(shù)字證書瀏覽器廠商起到信任錨的作用，預(yù)裝公鑰的CA就是它所認(rèn)證的CA——有隱含根的嚴(yán)格層次結(jié)構(gòu)。預(yù)裝

簽發(fā)

信任的傳遞瀏覽器用戶得到Web服務(wù)器的公鑰大多數(shù)Web瀏覽器中包含有50個以上的受信任的CA證書，并且用戶可以向瀏覽器中增加受信任的CA證書，也可以從中刪除不受信任的證書。當(dāng)接收到一個證書時，只要瀏覽器能在待驗證證書與其受信任的CA證書之間建立起一個信任鏈，瀏覽器就可以驗證證書。權(quán)威證書列表：Web模型360瀏覽器預(yù)置的CA數(shù)字證書權(quán)威證書列表：Web模型(a)根CA證書(b)中間CA證書從本質(zhì)上講，上述Web瀏覽器信任模型是一種隱含根（將權(quán)威證書列表中的證書作為受信任的根CA）的嚴(yán)格層次模型，通常稱為“Web模型（WebModel）”。權(quán)威證書列表：Web模型Web模型有什么問題呢？信任“不稱職的”CA帶來的安全問題信任“壞的”CA帶來的安全問題撤銷一個受信任的CA根證書的困難性權(quán)威證書列表：Web模型當(dāng)前，CA的信任體系沒有唯一的信任根（信任錨點，TrustAnchor），預(yù)裝到瀏覽器或操作系統(tǒng)中的可信根CA證書有一百多個，他們又通過成千上萬個二級或三級CA簽發(fā)最終的Web服務(wù)器證書。這種信任模型最大的安全問題是，任何一個CA都可以為任何一個網(wǎng)站（域名）簽發(fā)公鑰證書，而不需要該網(wǎng)站的授權(quán)討論：Web信任模型的安全問題討論：Web信任模型的安全問題如果CA出了問題，如私鑰泄露了該怎么辦？2011年8月，荷蘭CA安全證書提供商DigiNotar的服務(wù)器被發(fā)現(xiàn)遭黑客入侵。黑客為包括G在內(nèi)的20多個領(lǐng)域的531個網(wǎng)站發(fā)行了偽造的CA證書，經(jīng)分析DigiNotar的8臺證書服務(wù)器均遭入侵。2011年7月19被發(fā)現(xiàn)入侵，但外界直到8月份才知道。出了這種事，后果是什么？用戶如何應(yīng)對？討論：Web信任模型的安全問題如果根CA不可信，會有什么后果？如果互聯(lián)網(wǎng)接入服務(wù)提供商（ISP）能作為CA簽發(fā)證書，它能做什么？交叉認(rèn)證（crosscertification）是指通過某種方法將以前無關(guān)的CA連接在一起，建立起信任關(guān)系，彼此可以進行安全認(rèn)證。它通過信任傳遞機制來完成兩者信任關(guān)系的建立，是第三方信息關(guān)系的拓展，即一個CA的用戶信任所有與自己CA有交叉認(rèn)證的其他CA的用戶。CA交叉信任模型三種實現(xiàn)方式各PKI的CA之間互相簽發(fā)證書，從而在局部PKI之間建立起了信任關(guān)系由用戶控制交叉認(rèn)證，即由用戶自己決定信任哪個CA或拒絕哪個CA由橋接CA控制交叉認(rèn)證。橋接CA（BridgeCA）是一個第三方CA，由它來溝通各個根CA之間的連接和信任關(guān)系。CA交叉信任模型CA交叉信任模型一般將上述交叉認(rèn)證建立的CA信任模型稱為“森林模型”CA交叉信任模型假設(shè)Alice有CA1公鑰，Bob有CA2公鑰，交叉認(rèn)證后，Alice的信任能擴展到CA2的主體群（包括Bob），反之亦然。CA交叉信任模型雙向交叉認(rèn)證有什么問題？只適用于CA數(shù)量較少的情況，但當(dāng)CA數(shù)量較大時，大量CA兩兩進行交叉認(rèn)證就會形成復(fù)雜的網(wǎng)狀結(jié)構(gòu)，且證書策略經(jīng)過多次映射之后會使證書用途大大受限CCS2020論文：PKIs是目前網(wǎng)絡(luò)安全建設(shè)的基礎(chǔ)和核心，其中CAs是PKI的核心。CAs能夠為服務(wù)器，應(yīng)用或者用戶簽發(fā)證書，證書可以被用來證明所有者的身份。論文對證書交叉簽名的使用和安全性進行了系統(tǒng)性研究，分析了WebPKI系統(tǒng)中交叉驗證現(xiàn)狀，展示了交叉驗證的優(yōu)點和風(fēng)險交叉認(rèn)證問題交叉認(rèn)證問題交叉認(rèn)證的四種類型交叉認(rèn)證問題交叉簽名在帶來好處的同時，也承擔(dān)著一定的風(fēng)險：一方面，交叉簽名沒有被系統(tǒng)的跟蹤，這給HTTPS安全審計帶來了挑戰(zhàn)；另一方面，中間證書的撤銷機制一般由CA完成，因此被交叉驗證的中間證書的撤銷也可能存在問題。交叉認(rèn)證問題Let’sEncrypt提供免費加密證書服務(wù)，在獲得IdenTrust交叉簽名認(rèn)證后為主流瀏覽器支持。Let’sEncrypt證書已經(jīng)被黑客用的極度泛濫了交叉認(rèn)證問題基于區(qū)塊鏈實現(xiàn)的分布式信任模型CA機構(gòu)以聯(lián)盟鏈的方式，通過共識完成CA證書的驗證工作。經(jīng)過共識的證書將記錄到區(qū)塊鏈當(dāng)中，這些證書就被區(qū)塊鏈中所有CA認(rèn)為是可信的證書。CA分布式信任模型CA分布式信任模型以用戶為中心的信任模型（usercentrictrustmodel）每個用戶自己決定信任其他哪些用戶，還可以信任介紹人介紹的對象，從而形成一種信任網(wǎng)（Weboftrust）。但是，這種信任關(guān)系的傳遞不一定是必須的（A信任B，B信任C，并不代表A也要完全信任C。在信任傳遞過程中，信任的程度可能是遞減的）。PGP采用的就是這種信任模型用戶為中心的信任模型RA（RegistrationAuthority）是專門負(fù)責(zé)受理用戶申請證書的機構(gòu)，它是用戶和CA之間的接口RA和CA可以合一（小型PKI），最好分離支持在線受理和離線受理RA為方便證書的查詢和使用，CA采用“證書目錄”的方式集中存儲和管理證書，通過建立目錄服務(wù)器證書庫的方式為用戶提供證書服務(wù)。大多數(shù)PKI中的證書目錄遵循的標(biāo)準(zhǔn)是X.500，在互聯(lián)網(wǎng)環(huán)境下更多采用了簡化版的X.500：輕量級目錄存取協(xié)議LDAP。證書發(fā)布系統(tǒng)PKI策略是指一個組織建立和定義的公鑰管理方面的指導(dǎo)方針、處理方法和原則。在PKI中有兩種類型的策略：一是證書策略，用于管理證書的使用；另一個是證書實踐指南（CertificatePracticeStatement,CPS）PKI策略二、證書簽發(fā)和撤銷證書簽發(fā)和撤銷流程簽發(fā)流程：申請用戶向RA申請注冊經(jīng)RA批準(zhǔn)后由CA產(chǎn)生密鑰，并簽發(fā)證書將密鑰進行備份將證書存入證書目錄。CA將頒發(fā)的證書信息存入證書目錄，以便用戶下載或查詢CA將證書副本送給RA，RA進行登記RA將證書副本送給用戶證書簽發(fā)什么情況下需要撤銷證書?過了有效期證書公鑰對應(yīng)的私鑰被泄露或證書的持有企業(yè)倒閉，或證書的持有人嚴(yán)重違反證書的規(guī)定等情況證書持有人還可申請臨時停用證書，稱為“證書凍結(jié)”證書撤銷撤銷流程：申請、批準(zhǔn)、撤銷兩種發(fā)布證書撤銷消息的方式一是CA定期公布證書撤銷列表（CRL），時間間隔由CA的證書策略決定（實時性和效率）二是用戶在線查詢：IETFPKIX制定的在線證書狀態(tài)查詢協(xié)議（OnlineCertificateStatusProtocol,OCSP）支持用戶在線查詢，實時獲得證書的狀態(tài)（有效、撤銷、凍結(jié)）證書撤銷CA的證書也需要撤銷，描述CA等證書機構(gòu)的撤銷證書的列表稱為機構(gòu)撤銷列表（AuthorityRevocationList,ARL）證書撤銷三、證書使用證書使用查詢首先獲取證書，以及一些額外輔助驗證的證書（如CA的證書，用于驗證發(fā)送者證書的有效性）然后，驗證證書證書使用驗證證書過程用CA根證書中的CA的公鑰驗證證書上的CA簽名（這個簽名是用CA的私鑰生成的）是否正確檢查證書的有效期項是否處在有效期內(nèi)驗證證書內(nèi)容的真實性和完整性驗證證書是否已被撤銷或凍結(jié)（OCSP在線查詢方式或CRL發(fā)布方式）驗證證書的使用方式是否與證書策略和使用限制相一致。證書使用從使用過程來看，CA用于簽發(fā)證書的私鑰的保密性非常重要，如果一旦泄露，所有由該CA簽發(fā)的證書將不能再使用。因為獲得該CA私鑰的任何人都可以簽發(fā)證書，導(dǎo)致用戶無法區(qū)分是真正CA簽發(fā)的，還是獲得泄露出來的CA私鑰的人簽發(fā)的。2011年8月，荷蘭CA供應(yīng)商DigiNotar的8臺證書服務(wù)器被黑客入侵事件

證書使用擴展：常見證書錯誤擴展：常見證書錯誤擴展：常見證書錯誤擴展：常見證書錯誤擴展：常見證書錯誤擴展：常見證書錯誤擴展：常見證書錯誤四、PKIXIETF成立了PKI工作組，制定了PKIX系列標(biāo)準(zhǔn)（Public

Key

Infrastructure

on

X.509,PKIX）。PKIX定義了X.509證書在Internet上的使用規(guī)范，包括證書的產(chǎn)生、發(fā)布、獲取、撤銷，各種產(chǎn)生和發(fā)布密鑰的機制，以及怎樣實現(xiàn)這些標(biāo)準(zhǔn)的框架結(jié)構(gòu)等PKIX標(biāo)準(zhǔn)PKIX標(biāo)準(zhǔn)PKIX標(biāo)準(zhǔn)PKIX內(nèi)容提綱數(shù)字證書2PKI3證書透明性4密鑰管理1PKI體系中，用戶無條件信任由可信第三方（CA）簽發(fā)的證書。但是，如果CA服務(wù)器被攻擊或CA在簽發(fā)證書時沒有對申請者進行嚴(yán)格的盡職調(diào)查，就會產(chǎn)生嚴(yán)重的安全問題。幾起典型CA問題事件CA有問題怎么辦？為了解決盲目信任CA簽發(fā)的證書所存在的潛在風(fēng)險，Google于2013年3月提出了數(shù)字證書透明性（CertificateTransparency,CT)技術(shù)，用于提升服務(wù)器證書的可信性，從而提高使用證書的系統(tǒng)的安全性。同年6月，IETF發(fā)布CT試驗性標(biāo)準(zhǔn)：RFC6962(CertificateTransparency)。2014年1月，IETF成立PublicNotaryTransparency(TRANS)工作組，專門討論設(shè)計、部署、使用CF時碰到的各種問題CA有問題怎么辦？證書透明性Gossip協(xié)議

CT能夠?qū)ψC書進行公開審計，確保網(wǎng)站訪問者不受惡意或者錯誤的證書所害。安全風(fēng)險：CT也引入了新的運行風(fēng)險，如Log服務(wù)器為虛假證書創(chuàng)建了一條日志，Monitor不通知域名所有者存在針對其域名的虛假證書等證書透明性本章小結(jié)作業(yè)參考內(nèi)容一、證書指紋關(guān)于證書指紋用openssl讀出來的google的證書的數(shù)字簽名算法和數(shù)字簽名,證書里沒有“指紋”這個字段關(guān)于證書指紋用openssl讀出來的apple的證書的數(shù)字簽名算法和數(shù)字簽名,證書里也沒有“指紋”這個字段關(guān)于證書指紋用openssl的命令查看google證書的sha1指紋：與瀏覽器中看到的指紋一致！關(guān)于證書指紋指紋并不是證書本身的一個字段，而是瀏覽器額外計算出來顯示的，進一步驗證結(jié)果和瀏覽器顯示的指紋一致=整個證書的sha1散列值關(guān)于證書指紋指紋并不是證書本身的一個字段，而是瀏覽器額外計算出來顯示的，IE/360瀏覽器默認(rèn)用sha1計算指紋(160位)，而google的chrome默認(rèn)計算了sha1和sha256指紋1、瀏覽器顯示的指紋就是證書簽名嗎？2、YES，那為什么長度都是160位？3、NO，那它跟證書簽名有什么關(guān)系？是證書簽名值的一部分還是完全獨立的？關(guān)于證書指紋1、瀏覽器為什么要計算整個證書的指紋？關(guān)于證書指紋1、瀏覽器為什么要計算整個證書的指紋？關(guān)于證書指紋2、證書中哪些字段參與哈希簽名計算？關(guān)于證書指紋2、證書中哪些字段參與哈希簽名計算？關(guān)于證書指紋2、證書中哪些字段參與哈希簽名計算？關(guān)于證書指紋3、證書中哪些字段參與指紋計算？關(guān)于證書指紋/2013/04/16/understanding-x-509-digital-certificate-thumbprints/關(guān)于證書指紋關(guān)于證書指紋關(guān)于證書指紋關(guān)于證書指紋二、Web證書信任問題證書共享：隨著技術(shù)的發(fā)展，多個實體（如網(wǎng)站）共享一個證書的情況已經(jīng)比比皆是了CDN場景集團公司和子公司場景討論：證書共享的安全問題類似IBM和nic.weatherchannel的情況非常普遍，由于Web網(wǎng)站的HTTPS部署比較復(fù)雜而且技術(shù)仍在進一步發(fā)展，共享證書的多個網(wǎng)站之間難免會出現(xiàn)配置故障或者策略不一致的現(xiàn)象。討論：證書共享的安全問題用自簽名證書偽造知名網(wǎng)站證書2020.3.26