中国东北老熟妇做爰网视频,色婷婷av久久久久久久 ,麻豆md传媒md0049入口

"證書 -- 為公鑰加上數字簽名"

要開車得先考駕照.駕照上面記有本人的照片、姓名、出生日期等個人信息.以及有效期、準駕車輛的類型等信息，并由公安局在上面蓋章。我們只要看到駕照，就可以知道公安局認定此人具有駕駛車輛的資格。

公鑰證書(Public-Key Certificate，PKC)其實和駕照很相似，里面記有姓名、組織、郵箱地址等個人信息，以及屬于此人的公鑰，并由認證機構(Certification Authority、Certifying Authority, CA)施加數字簽名。只要看到公鑰證書，我們就可以知道認證機構認定該公鑰的確屬于此人。公鑰證書也簡稱為證書(certificate)。

可能很多人都沒聽說過認證機構，認證機構就是能夠認定 “公鑰確實屬于此人"，并能夠生成數字簽名的個人或者組織。認證機構中有國際性組織和政府所設立的組織，也有通過提供認證服務來盈利的一般企業，此外個人也可以成立認證機構。

1. 證書的應用場景

下面我們來通過證書的代表性應用場景來理解證書的作用。

下圖展示了Alice向Bob發送密文的場景，在生成密文時所使用的Bob的公鑰是通過認證機構獲取的。

認證機構必須是可信的，對于“可信的第三方”，下圖中會使用Trent這個名字，這個詞是從trust(信任)一詞演變而來的。

證書的代表性應用場景.png

下面讓我們對照著上圖來看一看這些步驟具體都做了些什么。

Bob生成密鑰對
要使用公鑰密碼進行通信，首先需要生成密鑰對。Bob生成了一對公鑰和私鑰，并將私鑰自行妥善保管。在這里，密鑰對是由Bob自己生成的，也可以由認證機構代為生成。
Bob在認證機構Trent注冊自己的公鑰
- 在這里Bob則將公鑰發送給了認證機構Trent，這是因為Bob需要請認證機構Trent對他的公鑰加上數字簽名(也就是生成證書)。
- Trent收到Bob的公鑰后，會確認所收到的公鑰是否為Bob本人所有(參見專欄:身份確認和認證業務準則)

專欄:身份確認和認證業務準則
認證機構確認"本人"身份的方法和認證機構的認證業務準則(CertificatePractice Statement, CPS，的內容有關。如果認證機構提供的是測試用的服務，那么可能完全不會進行任何身份確認。如果是政府部門運營的認證機構，可能就需要根據法律規定來進行身份確認。如果是企業面向內部設立的認證機構，那就可能會給部門負責人打電話直接確認。
例如，VeriSign的認證業務準則中將身份確認分為Class1 ~ 3共三個等級

Class1:通過向郵箱發送件來確認本人身份

Class2:通過第三方數據庫來確認本人身份

Class3:通過當面認證和身份證明來確認本人身份

等級越高，身份確認越嚴格。

認證機構Trent用自己的私鑰對Bob的公鑰施加數字簽名并生成證書
Trent對Bob的公鑰加上數字簽名。為了生成數字簽名，需要Trent自身的私鑰，因此Trent需要事先生成好密鑰對。
Alice得到帶有認證機構Trent的數字簽名的Bob的公鑰(證書)
現在Alice需要向Bob發送密文，因此她從Trent處獲取證書。證書中包含了Bob的公鑰。
Alice使用認證機構Trent的公鑰驗證數字簽名，確認Bob的公鑰的合法性
Alice使用認證機構Trent的公鑰對證書中的數字簽名進行驗證。如果驗證成功，就相當于確認了證書中所包含的公鑰的確是屬于Bob的。到這里，Alice就得到了合法的Bob的公鑰。
Alice用Bob的公鑰加密消息并發送給Bob
Alice用Bob的公鑰加密要發送的消息，并將消息發送給Bob。
Bob用自己的私鑰解密密文得到Alice的消息
Bob收到Alice發送的密文，然后用自己的私鑰解密，這樣就能夠看到Alice的消息了。

上面就是利用認證機構Trent進行公鑰密碼通信的流程。其中1、2、3這幾個步驟僅在注冊新公鑰時才會進行，并不是每次通信都需要。此外，步驟 4 僅在Alice第一次用公鑰密碼向Bob發送消息時才需要進行，只要Alice將Bob的公鑰保存在電腦中，在以后的通信中就可以直接使用了。

2. 證書標準規范X.509

證書是由認證機構頒發的，使用者需要對證書進行驗證，因此如果證書的格式千奇百怪那就不方便了。于是，人們制定了證書的標準規范，其中使用最廣泛的是由ITU(International Telecommumcation Union，國際電信聯盟)和ISO(Intemational Organization for Standardization, 國際標準化組織)制定的X.509規范。很多應用程序都支持x.509并將其作為證書生成和交換的標準規范。

X.509是一種非常通用的證書格式。所有的證書都符合ITU-T X.509國際標準，因此(理論上)為一種應用創建的證書可以用于任何其他符合X.509標準的應用。X.509證書的結構是用ASN1(Abstract Syntax Notation One)進行描述數據結構，并使用ASN.1語法進行編碼。

在一份證書中，必須證明公鑰及其所有者的姓名是一致的。對X.509證書來說，認證者總是 CA 或由CA指定的人，一份X.509證書是一些標準字段的集合，這些字段包含有關用戶或設備及其相應公鑰的信息。X.509標準定義了證書中應該包含哪些信息，并描述了這些信息是如何編碼的(即數據格式)。

一般來說，一個數字證書內容可能包括基本數據(版本、序列號) 、所簽名對象信息( 簽名算法類型、簽發者信息、有效期、被簽發人、簽發的公開密鑰)、CA的數字簽名，等等。

2.1. 證書規范

前使用最廣泛的標準為ITU和ISO聯合制定的X.509的 v3版本規范 (RFC5280), 其中定義了如下證書信息域:

版本號(Version Number):規范的版本號，目前為版本3，值為0x2;
序列號(Serial Number):由CA維護的為它所發的每個證書分配的一的列號，用來追蹤和撤銷證書。只要擁有簽發者信息和序列號，就可以唯一標識一個證書，最大不能過20個字節;
簽名算法(Signature Algorithm):數字簽名所采用的算法，如:

sha256-with-RSA-Encryption

ecdsa-with-SHA2S6

頒發者(Issuer):發證書單位的標識信息，如 ” C=CN，ST=Beijing, L=Beijing, O=org.example.com，CN=ca.org。example.com ”;
有效期(Validity): 證書的有效期很，包括起止時間。
**主體(Subject) : 證書擁有者的標識信息(Distinguished Name)，如:" C=CN，ST=Beijing, L=Beijing, CN=person.org.example.com”;
主體的公鑰信息(SubJect Public Key Info):所保護的公鑰相關的信息:

公鑰算法 (Public Key Algorithm)公鑰采用的算法;

主體公鑰(Subject Unique Identifier):公鑰的內容。

頒發者唯一號(Issuer Unique Identifier):代表頒發者的唯一信息，僅2、3版本支持，可選;
主體唯一號(Subject Unique Identifier):代表擁有證書實體的唯一信息，僅2，3版本支持，可選;
擴展(Extensions，可選):可選的一些擴展。中可能包括:

Subject Key Identifier:實體的秘鑰標識符，區分實體的多對秘鑰;

Basic Constraints:一指明是否屬于CA;

Authority Key Identifier:證書頒發者的公鑰標識符;

CRL Distribution Points: 撤銷文件的頒發地址;

Key Usage:證書的用途或功能信息

此外，證書的頒發者還需要對證書內容利用自己的私鑰添加簽名，以防止別人對證書的內容進行篡改。

2.2. 證書格式

X.509規范中一般推薦使用PEM(Privacy Enhanced Mail)格式來存儲證書相關的文件。證書文件的文件名后綴一般為 .crt 或 .cer 。對應私鑰文件的文件名后綴一般為 .key。證書請求文件的文件名后綴為 .csr 。有時候也統一用 pem作為文件名后綴。

PEM格式采用文本方式進行存儲。一般包括首尾標記和內容塊，內容塊采用Base64進行編碼。

編碼格式總結:

X.509 DER(Distinguished Encoding Rules)編碼，后綴為:.der
.cer .crt X.509 BASE64編碼(PEM格式)，后綴為:.pem .cer .crt

例如，一個PEM格式(base64編碼)的示例證書文件內容如下所示:

證書中的解析出來的內容:

Certificate:
    Data:
G2
    Version: 3 (0x2)
    Serial Number:
        10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6
Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA-SHA256-
    Validity
        Not Before: Nov 21 08:00:00 2016 GMT
        Not After : Nov 22 07:59:59 2017 GMT
        Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc.,
CN=*.wikipedia.org
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:
                    af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:
                    ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:
                    c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:
                    9d:3b:ef:d5:c1
  ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Agreement
            Authority Information Access:
                CA Issuers -
URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
                OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2
            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.4146.1.20
                  CPS: https://www.globalsign.com/repository/
                Policy: 2.23.140.1.2.2
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
            X509v3 Subject Alternative Name:
                DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org,
DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org,
DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org,
DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org,
DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org,
DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org,
DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org,
DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org,
DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki,
DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org,
DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org,
DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36
            X509v3 Authority Key Identifier:
                keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
    Signature Algorithm: sha256WithRSAEncryption
         8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:
         ...

2.3. CA證書

證書是用來證明某某東西確實是某某東西的東西(是不是像繞口令?)。通俗地說，證書就好比上文里面的公章。通過公章，可以證明對應的證件的真實性。

理論上，人人都可以找個證書工具，自己做一個證書。那如何防止壞人自己制作證書出來騙人呢?請看后續 CA 的介紹。

CA是Certificate Authority的縮寫，也叫“證書授權中心”。

它是負責管理和簽發證書的第三方機構, 好比一個可信任的中介公司。一般來說，CA必須是所有行業和所有公眾都信任的、認可的。因此它必須具有足夠的權威性。就好比A、B兩公司都必須信任C公司，才會找 C 公司作為公章的中介。

2.3.1. 證書信任鏈

證書直接是可以有信任關系的, 通過一個證書可以證明另一個證書也是真實可信的. 實際上，證書之間的信任關系，是可以嵌套的。比如，C 信任 A1，A1 信任 A2，A2 信任 A3......這個叫做證書的信任鏈。只要你信任鏈上的頭一個證書，那后續的證書，都是可以信任的。

假設 C 證書信任 A 和 B;然后 A 信任 A1 和 A2;B 信任 B1 和 B2。則它們之間，構成如下的一個樹形關系 (一個倒立的樹)。

證書信任鏈.png

處于最頂上的樹根位置的那個證書，就是“ 根證書 ”。除了根證書，其它證書都要依靠上一級的證書，來證明自己。那誰來證明“根證書”可靠呢?實際上，根證書自己證明自己是可靠的(或者換句話說，根證書是不需要被證明的)。

2.3.2. 證書有啥用

1. 驗證網站是否可信(針對HTTPS)

通常，我們如果訪問某些敏感的網頁(比如用戶登錄的頁面)，其協議都會使用 HTTPS 而不是 HTTP。因為 HTTP 協議是明文的，一旦有壞人在偷窺你的網絡通訊，他/她就可以看到網絡通訊的內容(比如你的密碼、銀行帳號、等);而 HTTPS 是加密的協議，可以保證你的傳輸過程中，壞蛋無法偷窺。

但是，千萬不要以為，HTTPS 協議有了加密，就可高枕無憂了。再舉一個例子來說明，光有加密是不夠的。假設有一個壞人，搞了一個假的網銀的站點，然后誘騙你上這個站點。假設你又比較單純，一不留神，就把你的帳號，口令都輸入進去了。那這個壞蛋的陰謀就得逞了。

為了防止壞人這么干，HTTPS 協議除了有加密的機制，還有一套證書的機制。通過證書來確保，某個站點確實就是某個站點。

有了證書之后，當你的瀏覽器在訪問某個 HTTPS 網站時，會驗證該站點上的 CA 證書(類似于驗證介紹信的公章)。如果瀏覽器發現該證書沒有問題(證書被某個根證書信任、證書上綁定的域名和該網站的域名一致、證書沒有過期)，那么頁面就直接打開;否則的話，瀏覽器會給出一個警告，告訴你該網站的證書存在某某問題，是否繼續訪問該站點?

大多數知名的網站，如果用了 HTTPS 協議，其證書都是可信的(也就不會出現上述警告)。所以，今后你如果上某個知名網站，發現瀏覽器跳出上述警告，你就要小心啦!

3. 公鑰基礎設施(PKI)

僅制定證書的規范還不足以支持公鑰的實際運用，我們還需要很多其他的規范，例如證書應該由誰來頒發，如何頒發，私鑰泄露時應該如何作廢證書，計算機之間的數據交換應采用怎樣的格式等。這一節我們將介紹能夠使公鑰的運用更加有效的公鑰基礎設施。

3.1. 什么是公鑰基礎設施

公鑰基礎設施(Public-Key infrastructure)是為了能夠更有效地運用公鑰而制定的一系列規范和規格的總稱。公鑰基礎設施一般根據其英語縮寫而簡稱為PKI。

PKI只是一個總稱，而并非指某一個單獨的規范或規格。例如，RSA公司所制定的PKCS(Public-Key Cryptography Standards，公鑰密碼標準)系列規范也是PKI的一種，而互聯網規格RFC(Requestfor Comments)中也有很多與 PKI相關的文檔。此外，X.509這樣的規范也是PKI的一種。在開發PKI程序時所使用的由各個公司編寫的 API(Application Programming Interface, 應用程序編程接口)和規格設計書也可以算是PKI的相關規格。

因此，根據具體所采用的規格，PKI也會有很多變種，這也是很多人難以整體理解PKI的原因之一。

為了幫助大家整體理解PKI,我們來簡單總結一下PKI的基本組成要素(用戶、認證機構、倉庫)以及認證機構所負責的工作。

3.2. 什么是公鑰基礎設施

PKI的組成要素主要有以下三個:

用戶 --- 使用PKI的人
認證機構 --- 頒發證書的人
倉庫 --- 保存證書的數據庫

公鑰基礎設施.png

3.2.1. 用戶

用戶就是像Alice、Bob這樣使用PKI的人。用戶包括兩種:一種是希望使用PKI注冊自己的公鑰的人，另一種是希望使用已注冊的公鑰的人。我們來具體看一下這兩種用戶所要進行的操作。

注冊公鑰的用戶所進行的操作
- 生成密鑰對(也可以由認證機構生成)
- 在認證機構注冊公鑰
- 向認證機構申請證書
- 根據需要申請作廢已注冊的公鑰
- 解密接收到的密文
- 對消息進行數字簽名
使用已注冊公鑰的用戶所進行的操作
- 將消息加密后發送給接收者
- 驗證數字簽名

3.2.2. 認證機構(CA)

認證機構(Certification Authority，CA)是對證書進行管理的人。上面的圖中我們給它起了一個名字叫作Trent。認證機構具體所進行的操作如下:

生成密鑰對 (也可以由用戶生成)
生成密鑰對有兩種方式:一種是由PKI用戶自行生成，一種是由認證機構來生成。在認證機構生成用戶密鑰對的情況下，認證機構需要將私鑰發送給用戶，這時就需要使用PKCS#12(Personal Information Exchange Syntax Standard)等規范
在注冊公鑰時對本人身份進行認證, 生成并頒發證書
在用戶自行生成密鑰對的情況下，用戶會請求認證機構來生成證書。申請證書時所使用的規范是由 PKCS#10(Certification Request Syntax Standard)定義的。
認證機構根據其認證業務準則(Certification Practice Statement，CPS)對用戶的身份進行認證，并生成證書。在生成證書時，需要使用認證機構的私鑰來進行數字簽名。生成的證書格式是由PKCS#6 (Extended- Certificate Syntax Standard)和 X.509定義的。
作廢證書
當用戶的私鑰丟失、被盜時，認證機構需要對證書進行作廢(revoke)。此外，即便私鑰安然無恙，有時候也需要作廢證書，例如用戶從公司離職導致其失去私鑰的使用權限，或者是名稱變更導致和證書中記載的內容不一致等情況。
紙質證書只要撕毀就可以作廢了，但這里的證書是數字信息，即便從倉庫中刪除也無法作廢，因為用戶會
保存證書的副本，但認證機構又不能人侵用戶的電腦將副本刪除。
要作廢證書，認證機構需要制作一張證書作廢清單(Certificate Revocation List),簡稱為CRL 。
CRL是認證機構宣布作廢的證書一覽表，具體來說，是一張已作廢的證書序列號的清單，并由認證機構加
上數字簽名。證書序列號是認證機構在頒發證書時所賦予的編號，在證書中都會記載。
PKI用戶需要從認證機構獲取最新的CRL,并查詢自己要用于驗證簽名(或者是用于加密)的公鑰證書是否已經作廢這個步驟是非常重要的。
假設我們手上有Bob的證書，該證書有合法的認證機構簽名，而且也在有效期內，但僅憑這些還不能說明該證書一定是有效的，還需要查詢認證機構最新的CRL，并確認該證書是否有效。一般來說，這個檢查不是由用戶自身來完成的，而是應該由處理該證書的軟件來完成，但有很多軟件并沒有及時更能CRL。

認證機構的工作中，公鑰注冊和本人身份認證這一部分可以由注冊機構(Registration Authority，RA) 來分擔。這樣一來，認證機構就可以將精力集中到頒發證書上，從而減輕了認證機構的負擔。不過，引入注冊機構也有弊端，比如說認證機構需要對注冊機構本身進行認證，而且隨著組成要素的增加，溝通過程也會變得復雜，容易遭受攻擊的點也會增。

3.2.2. 倉庫

倉庫(repository)是一個保存證書的數據庫，PKI用戶在需要的時候可以從中獲取證書.它的作用有點像打電話時用的電話本。在本章開頭的例子中，盡管沒特別提到，但Alice獲取Bob的證書時，就可以使用倉庫。倉庫也叫作證書目錄。

3.3. 各種各樣的PKI

公鑰基礎設施(PKI)這個名字總會引起一些誤解，比如說“面向公眾的權威認證機構只有一個"，或者“全世界的公鑰最終都是由一個根CA來認證的"，其實這些都是不正確的。認證機構只要對公鑰進行數字簽名就可以了，因此任何人都可以成為認證機構，實際上世界上已經有無數個認證機構了。

國家、地方政府、醫院、圖書館等公共組織和團體可以成立認證機構來實現PKI,公司也可以出于業務需要在內部實現PKI,甚至你和你的朋友也可以以實驗為目的來構建PKI。

在公司內部使用的情況下，認證機構的層級可以像上一節中一樣和公司的組織層級一一對應，也可以不一一對應。例如，如果公司在東京、大阪、北海道和九州都成立了分公司，也可以采取各個分公司之間相互認證的結構。在認證機構的運營方面，可以購買用于構建PKI的軟件產品由自己公司運營，也可以使用VeriSign等外部認證服務。具體要采取怎樣的方式，取決于目的和規模，并沒有一定之規。

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

密碼學之證書

密碼學之證書

1. 證書的應用場景

2. 證書標準規范X.509

2.1. 證書規范

2.2. 證書格式

2.3. CA證書

2.3.1. 證書信任鏈

2.3.2. 證書有啥用

3. 公鑰基礎設施(PKI)

3.1. 什么是公鑰基礎設施

3.2. 什么是公鑰基礎設施

3.2.1. 用戶

3.2.2. 認證機構(CA)

3.2.2. 倉庫

3.3. 各種各樣的PKI

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

密碼學之證書

1. 證書的應用場景

2. 證書標準規范X.509

2.1. 證書規范

2.2. 證書格式

2.3. CA證書

2.3.1. 證書信任鏈

2.3.2. 證書有啥用

3. 公鑰基礎設施(PKI)

3.1. 什么是公鑰基礎設施

3.2. 什么是公鑰基礎設施

3.2.1. 用戶

3.2.2. 認證機構(CA)

3.2.2. 倉庫

3.3. 各種各樣的PKI

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频