維基百科

公開金鑰認證

用于证明公开密钥所有权的电子文档

公開金鑰認證（英語：Public key certificate），又稱數位憑證（digital certificate）或身份憑證（identity certificate）。是用於公開金鑰基礎建設的電子檔案，用來證明公開金鑰擁有者的身份。此檔案包含了公鑰資訊、擁有者身份資訊（主體）、以及數字證書認證機構（發行者）對這份文件的數位簽章，以保證這個文件的整體內容正確無誤。擁有者憑著此檔案，可向電腦系統或其他使用者表明身分，從而對方獲得信任並授權存取或使用某些敏感的電腦服務。電腦系統或其他使用者可以透過一定的程序核實憑證上的內容，包括憑證有否過期、數位簽章是否有效，如果你信任簽發的機構，就可以信任憑證上的金鑰，憑公鑰加密與擁有者進行可靠的通訊。

維基百科網站所使用的數位憑證，可見載有維基媒體基金會的名稱、簽發的數字證書認證機構、有效期及公開密鑰指紋

簡而言之，認證機構用自己的私鑰對需要認證的人（或組織機構）的公鑰施加數字簽名並生成證書，即證書的本質就是對公鑰施加數字簽名。[1]

數位憑證的其中一個最主要好處是在認證擁有者身分期間，擁有者的敏感個人資料（如出生日期、身分證號碼等）並不會傳輸至索取資料者的電腦系統上。透過這種資料交換模式，擁有者既可證實自己的身分，亦不用過度披露個人資料，對保障電腦服務存取雙方皆有好處。

人們透過信任數字證書認證機構的根證書、及其使用公開密鑰加密作數位簽章核發的公開金鑰認證，形成信任鏈架構，已在TLS實作並在萬維網的HTTPS、在電子郵件的SMTPS和STARTTLS廣泛應用。業界現行的標準是國際電信聯盟電信標準化部門制定的X.509[2]，並由IETF發行的RFC 5280詳細述明。而在不少國家/地區，都已立法承認使用數位憑證所作的數位簽章擁有等同親筆簽名的法律效力（如歐洲聯盟[3][4]、香港[5][6]、台灣[7]、美國、加拿大）。

證書種類

編輯
 
根證書（自簽證書）、中介證書和終端實體（TLS伺服器/客戶端）證書的關係

自簽證書

編輯
主條目：自簽證書

在用於小範圍測試等目的的時候，用戶也可以自己生成數字證書，但沒有任何可信賴的人簽名，這種自簽名證書通常不會被廣泛信任，使用時可能會遇到電腦軟件的安全警告[8]。

根證書

編輯
主條目：根證書

根證書獲得廣泛認可，通常已預先安裝在各種軟體（包括操作系統、瀏覽器、電郵軟件等），作為信任鏈的起點，來自於公認可靠的政府機關（如香港郵政[9]、台灣網路資訊中心）、證書頒發機構公司（如DigiCert、Google[10]）、非營利組織（如Let's Encrypt）等，與各大軟件商透過嚴謹的核認程序才在不同的軟件廣泛部署。由於部署程序複雜費時，需要行政人員的授權及機構法人身份的核認，一張根證書有效期可能長達二十年以上。在某些企業，也可能會在內部電腦自行安裝企業自簽的根證書，以支援內部網的企業級軟件；但是這些證書可能未被廣泛認可，只在企業內部適用。

中介證書

編輯

認證機構的一個重要任務就是為客戶簽發證書，雖然廣泛認可的認證機構都已擁有根證書，相對應的私鑰可用以簽署其他證書，但因為密鑰管理和行政考慮，一般會先行簽發中介證書，才為客戶作數位簽署。中介證書的有效期會較根證書為短，並可能對不同類別的客戶有不同的中介證書作分工。

授權憑證

編輯
主條目：授權憑證

授權憑證又稱屬性憑證，本身沒有公鑰，必須依附在一張有效的數位憑證上才有意義，其用處是賦予相關擁有人簽發終端實體憑證的權力；某些情況下，如果只在短期內授予憑證機構簽發權力，便可以不改變（縮短）該機構本身持有的憑證的有效期。這種情況，類似於某人持有長達十年期的護照，而只透過簽發短期入境簽證，來個別賦予護照持有人額外權力。

終端實體證書

編輯

其他不會用作簽發其他證書的，都可稱為終端實體證書，在實際的軟件中部署，以便建立加密通道時應用。

TLS伺服器證書

編輯

伺服器通常以域名形式在互聯網上提供服務，伺服器證書上主體的通用名稱就會是相應的域名，相關機構名稱則寫在組織或單位一欄上。伺服器證書（包括公鑰）和私鑰會安裝於伺服器（例如Apache），等待客戶端連接時協議加密細節。客戶端的軟件（如瀏覽器）會執行認證路徑驗證算法（英語：Certification path validation algorithm）以確保安全，如果未能肯定加密通道是否安全（例如證書上的主體名稱不對應網站域名、伺服器使用了自簽證書、或加密算法不夠強），可能會警告用戶。

通配符證書
編輯
主條目：通配符證書

如果伺服器證書上主體的通用名稱（或主體別名（英語：Subject Alternative Name））一欄以通配符前綴，則該證書可以用於旗下的所有子域名，特別適合較具規模、或設有多個子網站的機構一次過申領，套用於多個伺服器上；即使未來建立新的子域名，也可以套用。但通配符不可用於擴展認證證書上。

TLS客戶端證書

編輯

有時候，某些TLS伺服器可能會在建立加密通道時，要求客戶端提供客戶端證書，以驗證身份及控制存取權限。客戶端證書包含電子郵件地址或個人姓名，而不是主機名。但客戶端證書比較不常見，因為考慮到技術門檻及成本因素，通常都是由服務提供者驗證客戶身份，而不是依賴第三方認證機構。通常，需要使用到客戶端證書的服務都是內部網的企業級軟件，他們會設立自己的內部根證書，由企業的技術人員在企業內部的電腦安裝相關客戶端證書以便使用。在公開的互聯網，大多數網站都是使用登入密碼和Cookie來驗證用戶，而不是客戶端證書。

在台灣，中華民國內政部憑證管理中心根據電子簽章法負責簽發自然人憑證，讓國民在網路使用各種政府服務[11]。

客戶端證書在RPC系統中更常見，用於驗證連接設備的許可授權。

內容欄位

編輯

一般遵從X.509格式規範的憑證，會有以下的內容，它們以欄位的方式表示[12]：

  • 版本：現行通用版本是 V3
  • 序號：用以辨識每一張憑證，特別在撤消憑證的時候有用
  • 主體：擁有此憑證的法人或自然人身份或機器，包括：
    • 國家（C，Country）
    • 州/省（S，State）
    • 地域/城市（L，Location）
    • 組織/單位（O，Organization）
    • 通用名稱（CN，Common Name）：在TLS應用上，此欄位一般是網域
  • 發行者：以數位簽章形式簽署此憑證的數字證書認證機構
  • 有效期開始時間：此憑證的有效開始時間，在此前該憑證並未生效
  • 有效期結束時間：此憑證的有效結束時間，在此後該憑證作廢
  • 公開金鑰用途：指定憑證上公鑰的用途，例如數位簽章、伺服器驗證、用戶端驗證等
  • 公開金鑰
  • 公開密鑰指紋
  • 數位簽章
  • 主體別名（英語：Subject Alternative Name）：例如一個網站可能會有多個網域（www.wikipedia.org, zh.wikipedia.org, zhwiki.oracleblog.org 都是維基百科）、一個組織可能會有多個網站（*.wikipedia.org, *.wikibooks.org, *.wikidata.org 都是維基媒體基金會旗下的網域），不同的網域可以一併使用同一張憑證，方便實作應用及管理

申領及使用

編輯
 
向憑證機構申領簽發電子證書的過程

數字證書一般由數字證書認證機構簽發，簡單的程序如下：

申領

編輯
  1. 鮑伯在自己的機器上使用密碼學安全偽隨機數生成器產生一對足夠強的密鑰，鮑伯的私鑰不會向任何人傳送。
  2. 鮑伯把他的公鑰，連同主體訊息、使用目的等組成憑證簽署請求（英語：Certificate signing request），傳送給認證機構伊凡。
  3. 伊凡（用另外一些渠道）核實鮑伯的身份。
  4. 如果伊凡信任這個請求，他便使用鮑伯的公鑰和主體訊息，加上憑證有效期、用途等限制條件，組成憑證的基本資料。
  5. 伊凡用自己的私鑰對鮑勃的公鑰加上數字簽名並生成證書。
  6. 伊凡把生成的憑證傳送給鮑伯（伊凡也可以透過證書透明度公佈他簽發了新的證書）。

使用

編輯
主條目：公開密鑰加密 § 加密過程
  1. 鮑伯可以隨便把憑證向外發佈。
  2. 鮑伯與愛麗絲事先可能互不認識，但鮑伯與愛麗絲都信任伊凡，愛麗絲使用認證機構伊凡的公鑰驗證數字簽名，如果驗證成功，便可以信任鮑勃的公鑰是真正屬於鮑伯的。[1]
  3. 愛麗絲可以使用憑證上的鮑勃的公鑰加密明文，得到密文並傳送給鮑伯。
  4. 鮑伯可以可以用自己的私鑰把密文解密，得到明文。

儲存格式

編輯

電子證書可以二進制或Base64形式儲存，常見的文件擴展名有 .cer、.crt、.der和.pem。如果把證書和私鑰一起儲存，則可以使用PKCS#12（.p12）格式[13]。

  • DER用於二進制DER編碼的證書。
  • PEM用於不同類型的X.509v3文件，是以「 - BEGIN ...」前綴的ASCII（Base64）數據。
  • CER和CRT幾乎同義，證書可以被編碼為二進制DER或ASCII PEM。
  • PKCS7 文件，也被稱為 P7B，通常用於 Java Keystores 和 Microsoft IIS（Windows）。它們是 ASCII 文件，可以包含證書和 CA 證書。
  • PKCS12 文件，也被稱為 PFX 文件，通常用於在 Micrsoft IIS（Windows）中導入和導出證書鏈。

審核級別

編輯

法人團體申領數位憑證的時候，可以視乎其法人的地位及其實際需要申領不同級別的憑證，認證機構會作相應的審核，越高級別的通常都牽涉越嚴謹的行政程序，及需付出更高昂的費用。各大憑證機構和網頁瀏覽器軟件商透過CA/瀏覽器論壇共同建立和維護相關的指導方針[14]。

域名驗證（DV）

編輯
主條目：域名驗證型證書

這是最基本的審核級別，如果申領代表可以證明他擁有管理某域名的權力，認證機構就可以發放域名驗證（DV）證書。認證機構通常使用自動機制（例如自動證書管理環境（英語：Automated Certificate Management Environment）[15]或透過電郵確認）審核域名擁有權，所以成本也較低[16]。

組織驗證（OV）

編輯

如果申領代表可以證明他擁有管理某域名的權力，而且相關組織是實際存在的法人，認證機構可以發放組織驗證（OV）證書。審核程序通常需要經過人手處理。

擴展驗證（EV）

編輯
主條目：擴展驗證證書

這是最嚴格的審核級別，審核過程可能牽涉專業法律人員的調查及獨立審計人員的確認，成本也自然更高[17]；成功獲得擴展驗證證書的網站，現代瀏覽器通常會在位址列以綠色表示相關機構的法人名稱及所屬國家代碼[18]。擴展驗證證書的主體名稱或主體別名上不可以有通配符。

弱點與防禦

編輯

公開金鑰基礎建設的弱點，在於人們必須循數位憑證上的信任鏈找到根證書，並信任核發根證書的數字證書認證機構，一旦憑證機構被黑客入侵，黑客可以在人們不知情下簽發了偽冒他人身份的證書，以中間人攻擊進行欺詐。業界已研發不同的防禦方法，例如憑證機構可以透過證書透明度公布新簽發的電子憑證，讓大眾檢查手上收到的電子憑證是否可能未被正式授權（中間人攻擊不會「公布」他偽冒了別人簽發了欺詐憑證），網站管理員也可以定期檢查是否有不明機構發出了未被授權的憑證。另一方面，HTTPS網站可以使用HPKP指明其固定的公鑰，讓中間人的欺詐憑證無法使用。另外，而OCSP和OCSP裝訂也在發展中，讓用戶軟體可以透過第三方檢查憑證是否有効。

在公鑰基礎設施以外，信任網絡則採用去中心化的概念，取代了依賴數字證書認證機構的公鑰基礎設施，因為每一張電子證書在信任鏈中最終只由一個根證書授權信任，信任網絡的公鑰則可以累積多個用戶的信任。

根證書弱點與爭議事件

編輯

中國互聯網絡信息中心發行假憑證事件

編輯

2009年，中國互聯網絡信息中心（CNNIC）的一名員工向Mozilla申請要求將 CNNIC 加入 Mozilla 的 根證書列表[19]，並且得到了批准。後來微軟也把 CNNIC加到了Windows的根證書列表裏。

2015年，因CNNIC發行的一個中級CA被發現發行了Google域名的假證書[20]，許多用戶選擇不信任CNNIC頒發的數字證書[21]。並引起對CNNIC濫用證書頒發權力的擔憂[22]。

2015年4月2日，Google宣布不再承認CNNIC所頒發的電子證書[23][24]。4月4日，繼Google之後，Mozilla也宣布不再承認CNNIC所頒發的電子證書[25]。2016年8月，CNNIC官方網站已放棄自行發行的根證書，改用由DigiCert頒發的證書。

沃通及StartCom遭封殺事件

編輯

2016年，擁有奇虎360背景的中國最大CA證書籤發機構沃通（WoSign）[26]及其以色列子公司StartCom，遭谷歌拒絕承認其憑證。 ]] 沃通被揭發在短短5日內發行了幾百個相同序列號的証書，以及對證書日期上造假[27]。

參見

編輯

參考文獻

編輯
  1. ^ 1.0 1.1 結城浩. 图解密码技术（第3版）. 人民郵電出版社. 2016: 231頁. ISBN 978-7-115-42491-4. 
  2. ^ Public-key and attribute certificate frameworks. ITU-T. 2016-12-08 [2017-07-10]. （原始內容存檔於2020-09-30） （英語）. 
  3. ^ EU Trusted Lists. 歐洲聯盟委員會. 2017-05-09 [2017-07-18]. （原始內容存檔於2020-08-25） （英語）. Under the Regulation (EC) No 910/2014/EU (eIDAS Regulation), national Trusted Lists have a constitutive effect. In other words, a trust service provider and the trust services it provides will be qualified only if it appears in the Trusted Lists. Consequently, the users (citizens, businesses or public administrations) will benefit from the legal effect associated with a given qualified trust service only if the latter is listed (as qualified) in the Trusted Lists. 
  4. ^ REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. EUR-Lex. 2014-08-28 [2017-07-18]. （原始內容存檔於2018-01-15） （英語）. A qualified electronic signature shall have the equivalent legal effect of a handwritten signature. 
  5. ^ 香港的認可核證機關. 政府資訊科技總監辦公室. 2017-06-30 [2017-07-18]. （原始內容存檔於2017-10-27） （中文（香港））. 核證機關在確保公開密碼匙基礎建設的有效運作方面擔當重要角色，並作為可信賴的第三方，負責證明電子交易所涉及有關各方的身分。目前，香港有兩間根據《電子交易條例》（第553章）獲得認可的核證機關。根據《電子交易條例》，郵政署署長是認可核證機關，提供香港郵政核證機關服務，而電子核證服務有限公司則是根據《電子交易條例》下核證機關自願認可計劃獲得認可的商營核證機關。 
  6. ^ 《電子交易條例》(第553章). 政府資訊科技總監辦公室. 2017-06-30 [2017-07-18]. （原始內容存檔於2017-06-29） （中文（香港））. 政府於2000年1月制定《電子交易條例》(第553章)（「條例」），並於2004年6月作出修訂。大體上，條例旨在：賦予電子紀錄及電子簽署（請看下文的註釋1）跟紙張文件上的紀錄和簽署同等的法律地位；以及設立核證機關自願認可計劃以加強社會人士對電子交易的信心。（註釋1︰就不涉及政府單位的電子交易而言，任何形式的電子簽署，只要可靠恰當並獲簽署的接受人認同，已能符合法律有關簽署的規定。就涉及政府單位的電子交易而言，有認可數碼證書證明的數碼簽署，便符合法律上的簽署規定。） 
  7. ^ 電子簽章法. 中華民國法務部全國法規資料庫工作小組. 2001-11-14 [2017-07-18]. （原始內容存檔於2020-08-08） （中文（臺灣））. 依法令規定應簽名或蓋章者，經相對人同意，得以電子簽章為之。 
  8. ^ 什麼是「您的連線並不安全」？. mozilla.org. [2017-07-07]. （原始內容存檔於2020-08-20）. Firefox 會檢驗網站憑證的正確性以及連線的加密強度以確保您的隱私。如果憑證無法被驗證，或連線使用了不夠強的加密演算法，Firefox 會中斷與網站的連線，並顯示下列錯誤頁面……自我簽署的憑證能保護您的資料免受竊聽，但無法讓您確認資料的接收者是誰。常見於無法公開連線的企業內部網路，您可以對這類網站忽略此警告。 
  9. ^ 關於香港郵政電子證書. 香港郵政. [2017-07-12]. （原始內容存檔於2020-08-20）. 香港郵政在二零零零年成立香港第一家在《電子交易條例》（香港法例第553章）下的認可公共核證機關。現時，香港郵政核證機關發出符合電子交易條例要求的「認可數碼證書」。根據《電子交易條例》，使用該條例下認可的數碼證書作出的數碼簽署與書面的簽署具同等法律效力。 
  10. ^ Repository of Documentation and Certificates. Google Trust Services. [2017-07-10]. （原始內容存檔於2020-12-19） （英語）. The Google Public Key Infrastructure (「Google PKI」), has been established by Google Trust Services, LLC (「Google」), to enable reliable and secure identity authentication, and to facilitate the preservation of confidentiality and integrity of data in electronic transactions. 
  11. ^ 內政部憑證管理中心. 內政部憑證管理中心. [2017-07-10]. （原始內容存檔於2020-05-09） （中文）. 內政部憑證管理中心是電子化政府資訊安全基礎建設計劃之一，是一個我國電子簽章法所謂的「憑證機構」，負責簽發我國滿 18歲以上國民之公鑰憑證， 並提供其他自然人之電子化政府應用服務網路通訊的安全基礎。 
  12. ^ Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF. [2017-07-10]. （原始內容存檔於2018-03-15） （英語）. This section presents a profile for public key certificates that will foster interoperability and a reusable PKI. This section is based upon the X.509 v3 certificate format and the standard certificate extensions defined in [X.509]. [...] This section also defines private extensions required to support a PKI for the Internet community. 
  13. ^ Mac OS X 10.6: 關於憑證格式. 蘋果電腦. [2017-07-18]. （原始內容存檔於2018-03-17） （中文（臺灣））. 
  14. ^ About the CA/Browser Forum. CA/瀏覽器論壇. [2017-07-14]. （原始內容存檔於2016-01-27） （英語）. the CA/Browser Forum advances industry best practices to improve the ways that certificates are used to the benefit of Internet users and the security of their communications 
  15. ^ Automated Certificate Management Environment (acme). IETF. [2017-07-12]. （原始內容存檔於2020-10-28） （英語）. ACME certificate management must allow the CA to verify, in an automated manner, that the party requesting a certificate has authority over the requested identifiers, including the subject and subject alternative names. The processing must also confirm that the requesting party has access to the private key that corresponds to the public key that will appear in the certificate. 
  16. ^ Information for the Public／Domain Validation (DV). CA/瀏覽器論壇. [2017-07-12]. （原始內容存檔於2020-11-06） （英語）. A Domain Validated SSL certificate is issued after proof that the owner has the right to use their domain is established. This is typically done by the CA sending an email to the domain owner (as listed in a WHOIS database). Once the owner responds, the certificate is issued. [...] The certificate only contains the domain name. Because of the minimal checks performed, this certificate is typically issued quicker than other types of certificates. 
  17. ^ About EV SSL. CA/瀏覽器論壇. [2017-07-12]. （原始內容存檔於2020-10-25） （英語）. The primary objectives of an EV SSL Certificate are to: Identify the legal entity that controls a web site by providing reasonable assurance to the user of an Internet browser that the web site the user is accessing is controlled by a specific legal entity identified in the EV Certificate by name, address of Place of Business, Jurisdiction of Incorporation or Registration and Registration Number or other disambiguating information 
  18. ^ 我怎麼知道是否連上安全的網站？／綠色鎖頭. mozilla.org. [2017-07-12]. （原始內容存檔於2020-08-20） （中文（臺灣））. 綠色鎖頭圖示將另外以綠色字體呈現公司或組織的名稱，代表該網站使用了 Extended Validation (EV) certificate。與其他類型的憑證相較，EV 屬於特別的網站憑證，需完成極繁複的檢驗程序。／在使用 EV 憑證的網站，網站識別鈕會顯示綠色鎖頭、合法的公司或組織的名稱和網站擁有者的位置，因此你可以知道是誰在營運這個網站。舉例來說，網站識別鈕會顯示 mozilla.org 是由 Mozilla 基金會所擁有。 
  19. ^ 476766 - Add China Internet Network Information Center (CNNIC) CA Root Certificate. bugzilla.mozilla.org. [2020-01-03]. （原始內容存檔於2020-02-22） （英語）. 
  20. ^ CNNIC发行的中级CA发行了Google的假证书. solidot. 2015-03-24 [2015-03-24]. （原始內容存檔於2015-03-26）. 
  21. ^ 編程隨想. CNNIC 证书的危害及各种清除方法. [2015-03-24]. （原始內容存檔於2015-03-25）. 
  22. ^ 最危险的互联网漏洞正在逼近. [2015-03-26]. （原始內容存檔於2015-11-21）. 
  23. ^ 谷歌不再承認中國CNNIC頒發的信任證書. 華爾街日報. 2015-04-03 [2015-04-03]. （原始內容存檔於2015-04-07）. 
  24. ^ 谷歌不再信任中国CNNIC 的网站信任证书. 美國之音. 2015-04-03 [2015-04-03]. （原始內容存檔於2015-04-05）. 
  25. ^ Mozilla紧随谷歌 拒绝承认中国安全证书. 美國之音. 2015-04-04 [2015-04-04]. （原始內容存檔於2015-04-10）. 
  26. ^ 谷歌宣布开始全面封杀使用沃通CA证书网站，信誉破产的恶果 - 超能网. www.expreview.com. [2020-01-03]. （原始內容存檔於2020-08-20）. 
  27. ^ CA:WoSign Issues - MozillaWiki. wiki.mozilla.org. [2020-01-03]. （原始內容存檔於2016-10-28）. 


取自「https://zh.wikipedia.org/w/index.php?title=公開金鑰認證&oldid=67181761」