哈工大密碼學實驗CA

寫在前面的話，今天是2021.12.19，密碼學實驗已驗收，符合全部要求，本文是實驗報告，僅供學弟學妹參考

1.背景與意義

1.1 項目開發意義

隨著以信息網絡技術為代表的科學技術的迅猛發展，21 世紀，我們已步入了一個以電子商務為核心的數字化革命時代，全球經濟一體化程度進一步加強，金融企業的經營環境發生了巨大變化。隨之而來的是我們生活方方面面的巨大改變。
電子商務的重要特點是使用IT技術進行信息傳遞和數據處理。所以,電子商務安全應該包含兩方面:一方面是計算機網絡安全,另一方面是商務交易安全。商務交易安全需要圍繞傳統商務在互聯網中應用存在的安全隱患,基于計算機網絡安全基礎,確保電子商務過程順利進行。這樣能夠確保電子商務保密性、完整性、可靠性等目標如期實現。就計算機網絡安全來看，其與電子商務交易安全之間也是密切相關的,兩者相互影響、相輔相成,必須構建比較完善的計算機網絡安全體系和電子商務交易安全體系。
電子商務在應用中的信息泄露問題比較多,這主要是因為貿易雙方的信息沒有得到有效保護。例如在非法攻擊和竊取相關信息的過程中,一是通過竊聽手段對于傳輸路徑中的數據進行攔截、監聽等,以獲取其中有價值的信息，導致信息泄露;二是借助數據庫服務器發現Web程序和網絡數據庫的漏洞。一些網絡攻擊者借助數據庫攻擊、竊聽的方式非法獲取商務活動的用戶信息。一些攻擊者會使用合法用戶信息和身份與其他人進行交易,以謀取非法權益,這樣不僅會破壞貿易的可靠性,還會損壞貿易者的信譽。簡單來說，在一個網絡購物過程中，我們會想知道：購物的網站可信嗎？我存儲錢的網站可信嗎，會不會是一個釣魚網站。為了解決這個信任問題，由此我們便引出一個第三方認證——CA認證中心。
CA是認證中心的英文Certification Authority的縮寫。　CA中心，又稱為數字證書認證中心。CA中心作為電子交易中受信任的第三方，負責為電子商務環境中各個實體頒發數字證書，以證明各實體身份的真實性，并負責在交易中檢驗和管理證書；數字證書的用戶擁有自己的公鑰/私鑰對。證書中包含有證書主體的身份信息、其公鑰數據、發證機構名稱等，發證機構驗證證書主體為合法注冊實體后，就對上述信息進行數字簽名，形成證書。 在公鑰證書體系中，如果某公鑰用戶需要任何其它已向CA注冊的用戶的公鑰，可直接向該用戶索取證書，而后用CA的公鑰解密解密即可得到認證的公鑰；由于證書中已有CA的簽名來實現認證，攻擊者不具有CA的簽名密鑰，很難偽造出合法的證書，從而實現了公鑰的認證性。 數字證書認證中心是整個網上電子交易安全的關鍵環節,是電子交易中信賴的基礎。他必須是所有合法注冊用戶所信賴的具有權威性、信賴性及公正性的第三方機構。
在SET交易中，CA不僅對持卡人、商戶發放證書，還要對獲款的銀行、網關發放證書。它負責產生、分配并管理所有參與網上交易的個體所需的數字證書，因此是安全電子交易的核心環節。也可說，沒有第三方認證的存在，安全電子交易便不存在。

1.2 國內外現狀及技術綜述

目前數字證書，作為一種比較成熟的安全產品，數字證書已經發展到一個較高的技術水平，而且它將在我們將來的網絡生活中發揮越來越重要的作用。通俗地講，數字證書就是個人或單位在 Internet上的身份證。比較專業的數字證書定義是，數字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。最簡單的證書包含一個公開密鑰、名稱以及證書授權中心的數字簽名。一般情況下證書中還包括密鑰的有效時間，發證機關（證書授權中心）的名稱，該證書的序列號等信息，證書的格式遵循相關國際標準。有了數字證書，我們在網絡上就可以暢通無阻。數字證書需要十分可靠的安全保密技術，也就是說，必須保證網絡安全的四大要素，即信息傳輸的保密性、數據交換的完整性、發送信息的不可否認性、交易者身份的確定性。
ca技術在電子商務的領域應用的越來越普遍，大部分的商家和企業選擇的都是因為它的安全性，可是與外國發達，我國的數字證書尚在起步階段，很多企業只是在這一領域里進行嘗試，而且也難怪顯出各司其職的魚龍混雜的現象，所以進一步完善我們的數字證書領域是非常迫切的，而且，我們國家也需要這方面的人才。目前，我國的若認證機構分布在天津、北京、上海、廣州湖南、湖北、山西等地。
X.509標準是密碼學里公鑰證書的格式標準。X.509 證書己應用在包括TLS/SSL（WWW萬維網安全瀏覽的基石）在內的眾多 Internet協議里，同時它也有很多非在線的應用場景，比如電子簽名服務。X.509證書含有公鑰和標識（主機名、組織或個人），并由證書頒發機構（CA）簽名（或自簽名）。對于一份經由可信的證書簽發機構簽名（或者可以通過其它方式驗證）的證書，證書的擁有者就可以用證書及相應的私鑰來創建安全的通信，以及對文檔進行數字簽名。
X.509最早與X.500一起發布于1988年7月3日，它假定頒發證書的證書頒發機構（CA）具有嚴格的層次結構。這與Web信任模型（如PGP）形成了鮮明對比，因為PGP方案是任何人都以簽名（而不僅僅是地位特殊的CA），從而證明其他人的密鑰證書的有效性。X.509 V3證書的設計非常靈活，除了對網橋拓撲架構網絡的支持，還可以支持用于點對點方式的Mesh網，類似于OpenPGP那樣的web信任機制，不過這樣方式在2004年之前很少使用。
在X.509系統中，證書申請者通過發起“證書簽名請求（CSR）”來得到一份被簽名的證書。為此，它需要生成一個密鑰對，然后用其中的私鑰對CSR簽名（私鑰本身要妥善保存，對外保密），CSR包含申請人的身份信息、用于驗真CSR的申請人的公鑰，以及所請求證書的專有名稱（DN），CSR還可能帶有CA要求的其它有關身份證明的信息，然后CA對這個專有名稱發布一份證書，并綁定一個公鑰。
組織機構可以把受信的根證書分發給所有的成員，這樣就可以使用公司的PKI系統了。像Firefox, IE, Opera, Safari 以及Google Chrome這些瀏覽器都預裝了一組CA根證書，所以可以直接使用這些主流CA發布的SSL證書。瀏覽器的開發者直接影響它的用戶對第三方的信任。FireFox就提供了一份csv/html格式的列表。X.509還包括證書吊銷列表（CRL）實現標準，這是PKI系統經常被忽略的方面。IETF批準的檢查證書有效性的方法是在線證書狀態協議（OCSP），Firefox 3默認情況下啟用OCSP檢查，從Vista開始的高版本Windows也是如此。

2.需求分析

2.1 總體需求

完成一個認證系統的相關所需功能，本CA認證系統需可供商家、用戶、銀行等各個用戶進行申請證書認證，每個申請用戶均需在系統注冊身份賬號后申請證書，在網站申請頁面填寫正確信息后，由系統進行申請審核通過后，簽發格式為cer的證書，并分配私鑰，證書及私鑰分發途徑為系統提供下載接口，申請用戶直接下載后加入本網站中使用，此外，系統提供使用方法的相關函數，商家或銀行可根據相關方法并結合自己需求后正確使用自己的證書。
CA系統在各方面涉及到用戶信息的地方要進行加密，防止信息泄露，同時對證書，私鑰的保存，撤銷收回等方面擁有管理權。用戶擁有對自己信息查看修改等權力。
此外，系統會記錄用戶的操作，生成系統日志，便于管理員復核和審計。

2.2 功能需求

2.2.1系統功能

1)注冊：用戶名和密碼，開通CA賬戶（用戶的用戶名不能相同，用戶可并非真實名字）
2)登錄：輸入正確的用戶名和密碼進行登錄CA系統
3)填充/查看/修改詳細信息（CN、OU、O、L、郵箱等……）
4)證書申請：用戶點擊認證申請，在申請界面，輸入相關完整信息，系統審核成功后，進行分發證書
5)下載證書及相關文件：保存網站生成的口令，輸入口令解密私鑰，保障私鑰傳輸安全；分別有三個鏈接下載證書、公鑰和私鑰；點擊安全清除按鈕，保障私鑰傳輸安全
6)簽名及驗證的使用方法：點擊下載鏈接，下載三個文件，按照使用方法正確使用證書即可
7)申請撤銷證書：需要修改證書信息或者私鑰泄露時撤銷證書
8)私鑰恢復機制：當用戶本地丟失私鑰時，可向系統提供身份證明再次查看私鑰
9)查詢證書（有效性檢查）：查看/下載其他用戶的CA證書信息，非法用戶/該用戶最新證書過期提醒
10)日志功能：記錄系統中每一步操作，生成操作日志，供管理員審核，復查

2.2.2系統安全

賬戶安全：
1)用戶的密碼信息，不以明文方式存儲，哈希后進行傳輸與存儲，對用戶密碼進行存儲安全處理；傳輸時用對稱密鑰以及公私密鑰加密，保障傳輸安全
2)用戶的相關資料不能被其他人查看。只有本人登陸后才可查看
3)只有上傳個人資料管理員審核之后才能允許申請下載證書。所有賬戶必須保證身份信息真是可靠
傳輸安全：
1)加密相關操作均在傳輸前進行加密，保證傳輸中被竊聽，相關信息不被泄露
2)私鑰傳輸時也經過相關加密，在傳輸中不會保障安全，在客戶端解密、被客戶安全下載后安全刪除相關文件，只保留用戶本地文件
數據庫安全
1)數據庫作為信息存儲的重要平臺，需要有加密技術支持，備份防丟失
私鑰存儲安全
1)使用最小權限原則：加強對系統和網絡訪問的身份驗證;阻止除必要網絡端口之外的其他所有網絡端口；安裝所有可用的安全更新并運行防病毒掃描程序。
2)密鑰存儲在安全的加密硬件設備中：密鑰最好不要存儲在通用計算機上，這樣容易受到攻擊。加密的硬件設備不易受到攻擊，并受到大多數重要應用程序的信任。

2.3 性能需求

1.可以與電商平臺以及銀行連接；
2.系統可以 24 小時不間斷工作；
3.用戶認證過程需要安全可靠，速度快，普通用戶登錄時間小于 2s；

3.概要設計

3.1開發環境

操作系統：Windows 10
數據庫：Mysql
語言：java + html + jsp + css
框架：vue框架

3.2業務數據流

用戶注冊賬戶=>注冊證書相關詳細信息 => 用戶申請證書 => 系統審核 => 分發公私鑰下載接口和證書下載接口，且提供使用方法和相關函數 => 用戶根據相關方法和自己的需求使用

3.3數據庫設計

第一張表：賬戶信息表

Username采用明文存儲
Password 采用哈希后的密文存儲
例如：

第二張表：證書相關信息表，設計如下

例如：

第三張表：保存公鑰

例如：

3.4證書結構及設計

3.4.1證書格式

X.509，所有的證書都符合ITU-T X.509國際標準。
X.509證書的結構是用ASN1(Abstract Syntax Notation One)進行描述數據結構，并使用ASN.1語法進行編碼。X.509標準定義了證書中應該包含哪些信息，并描述了這些信息是如何編碼的(即數據格式)
目前使用最廣泛的標準為ITU和ISO聯合制定的X.509的 v3版本規范 (RFC5280）, 其中定義了如下證書信息域：
1)版本號(Version Number）：規范的版本號，目前為版本3，值為0x2；
2)序列號（Serial Number）：由CA維護的為它所發的每個證書分配的唯一的列號，用來追蹤和撤銷證書。只要擁有簽發者信息和序列號，就可以唯一標識一個證書，最大不能過20個字節；
3)簽名算法（Signature Algorithm）：數字簽名所采用的算法，如：sha256-with-RSA-Encryption、ccdsa-with-SHA2S6
4)頒發者（Issuer）：發證書單位的標識信息，如 “ C=CN，ST=Beijing, L=Beijing, O=org.example.com，CN=ca.org。example.com ”；
5)有效期(Validity): 證書的有效期很，包括起止時間。
6)主體(Subject) : 證書擁有者的標識信息（Distinguished Name），如：" C=CN，ST=Beijing, L=Beijing, CN=person.org.example.com “ ；
7)主體的公鑰信息(SubJect Public Key Info）：所保護的公鑰相關的信息：
1.公鑰算法 (Public Key Algorithm）公鑰采用的算法
2.主體公鑰：公鑰的內容
3.頒發者唯一號：代表頒發者唯一信息（可選）
4.主體唯一號：代表擁有實體證書的唯一信息（可選）
5.擴展

3.4.2證書設計

為了更加深入理解簽名這一過程，增加一個擴展，對用戶名進行簽名（用戶名在本系統中每個人有且只有一個，互不相同，相當于一種身份象征）保存至使用者密鑰標識符中，如下：

該簽名可通過驗證，若有人偽造證書，則會被發現。
用戶生成證書時，需要向CA提交相關信息（實際情況中，用戶本人可能需要帶上相關文件向CA提供申請者真實性的證明，若缺少文件或者文件存在問題則拒絕頒發證書，但在此系統中，默認用戶都是“好人”，“壞人”不會來申請證書）CA自動生成后將文件放在服務器本地（服務器認為是被加密后的，壞人不會攻破本地文件），生成文件夾結構如下所示

其他文件夾內容類似，在此不進行展示

4.實驗流程總覽

4.1注冊設計

輸入網址進入登錄頁面（更改hosts文件，將IP放入“本地服務器”，可跳過）

點擊注冊一個，轉跳至注冊頁面

信息完整性：即時檢測，密碼與確認密碼必須一致，三者不能為空

按照要求可成功注冊


點擊確認后直接跳轉至登錄頁面

4.2登錄設計

成功登錄后進入用戶頁面，左邊有工作面板

4.3完善基本信息設計

按照實際情況填寫后點擊提交信息，這里為了演示全部填寫example

4.4查看信息的設計

4.4.1查看自己的證書信息

4.4.2查詢別人的證書信息

輸入要查詢的用戶名（在本系統中，用戶名類似于身份證那種象征身份的東西，每個用戶均不同）若查詢對象存在且證書有效，則可以查看信息、下載證書和公鑰

4.5修改信息設計

修改頁面如下，再次填寫信息可覆蓋以前信息，為了演示我全部修改成examplee

再次查詢發現已經改變

4.6申請且下載證書（私鑰的安全傳輸）

頁面如下

第一步，為了保障私鑰的傳輸安全，需要一個隨機生成的密鑰加密私鑰文件，點擊第一個按鈕，會得到密鑰，保存下來。

第二步，將得到的口令輸入口令框

第三步，點擊按鈕進行安全解密密鑰文件，第四步就可以下載后端傳來的文件（私鑰經過安全傳輸）
公鑰文件（通過證書也可以獲得，在使用方法中詳細寫了如何從證書獲取公鑰的相關代碼）由于修改過一次，有上一次的公鑰記錄（但上一次的公鑰已失效）

私鑰文件（只有最后一次有效的私鑰）：

證書文件：可以看到是剛剛生成的examplee

最后一步，點擊安全清除按鈕，將前端私鑰文件清除掉，防止私鑰泄露，注：在下面附有使用方法，點擊可以下載

4.7撤銷證書

閱讀須知后選擇已閱讀，即可提交撤銷申請，后端會自動更改CRL。

5.詳細設計

在上一節已經看過一個完整的實驗流程，下面詳細說明設計中的安全細節與實現。

5.1注冊時的安全

用戶注冊時，輸入的用戶名和密碼屬于敏感信息，不應該用明文傳輸（傳輸時的安全，即敵手不會在信道中通過直接抓包獲得用戶名和密碼）其次，如果只是每次生成一個會話密鑰，使用AES對稱密鑰加密，敵手在有限的時間內也可以破解密碼，所以，應使用對稱密鑰加非對稱密鑰加密方案（混合加密方案），對稱密鑰每一次現生成，非對稱密鑰選取CA證書中的公私鑰，最后，密碼存在數據庫不應是明文，否則會產生不安全問題（數據庫泄露或者管理數據庫的工作人員泄露敏感信息）故密碼應經過單向函數（哈希函數）散列后放入數據庫中，過程如下。

會話密鑰（對稱密鑰）是臨時生成的，每一次的密鑰隨機生成且概率相等的，否則會有安全問題，其次，對稱加密使用AES加密方法，DES已經不再安全。
非對稱加密的公私鑰應是經過CA簽名認證的，發送方應確認自己得到的確實是對方的證書，且該證書有效（未過期且私鑰未泄露）非對稱加密方案使用RSA加密方案。簽名方案我使用了SHA256withRSA。

5.2登錄時的安全

登錄時的加密過程與上述相同，數據傳到后端后與數據庫中存儲的哈希值做對比，相同則登錄成功，不同則登錄失敗；其次，如果用戶沒有經過登錄頁面的“審核”，直接通過改變URL企圖繞開登錄頁面，將不能做多余的事情（即更改信息等），只被允許查詢他人證書（游客模式？）。

5.3私鑰安全

現在我們假設example已經提交了申請證書需要的信息，需要申請證書獲得證書文件和私鑰文件，證書文件和公鑰都是公開的，可以用明文傳輸，但是私鑰文件應該如何安全傳遞呢？自然而然的就想到了用上述方式（5.1）加密文件，但作為CA系統為對方頒發證書，對方的證書還沒有傳遞給對方，即對方還沒有自己的私鑰，不能用對方的公鑰加密，那用自己的私鑰加密（簽名）可以嗎？當然也是不行的，作為CA，任何人都可以獲得CA的公鑰，而獲得CA公鑰的人都可以解密該文件，即任何人都可以解密私鑰文件。
所以在此，我只能退而求其次，僅僅用對稱加密方法加密該文件，會話密鑰就是每一次需要保存的密鑰（4.5第一步）。下面展示文件在每一時刻的狀態。
第一，填充完申請證書的必要信息之后，申請證書，后端生成的密鑰文件存到本地（現實生活中，密鑰存儲在安全的加密硬件設備中，加密的硬件設備不易受到攻擊，并受到大多數重要應用程序的信任，其次，為私鑰設置復雜的保護密碼）
第二，點擊第一個按鈕，此時私鑰文件已經從后端傳送過來了，存在前端public\lab_certificate中，但是是以密文的方式存儲，如下：

第三，此時輸入口令，按下按鈕。這時相當于將會話密鑰傳遞到前端，前端對存儲加密文件進行解密，用戶應該迅速下載私鑰文件，因為此時，私鑰其實是不安全的。
第四，按下第四個按鈕，將前端解密后的文件徹底清除，私鑰此時不再暴露。
這里，我需要聲明，第一，認為 CA是完全可信的，即CA不會被敵手攻破，密鑰存儲在CA本地是安全的；第二，私鑰在傳輸過程中，會話密鑰暴露的概率忽略不計，即認為私鑰在傳輸過程中是安全的；第三，用戶在下載完私鑰文件之后會立刻按下安全清除按鈕，即認為敵手不會在用戶下載私鑰的同時下載私鑰文件，若滿足以上三個條件，則保證私鑰傳輸過程是安全的。
下面講述實現私鑰安全的另一種方法，即在客戶端生成公私鑰，具體做法如下：
第一，CA提供公私鑰生成器。
第二，客戶在本地生成公私鑰，將私鑰也保存在本地。這就不必在信道傳輸私鑰文件了。
第三，客戶直接將公鑰傳輸給服務器，服務器根據公鑰以及申請信息進行一系列簽名，生成證書。
第四，服務器將證書傳輸給客戶端。
完成申請證書操作。

5.4使用證書

5.4.1簽名的實現

本系統使用SHA256withRSA方法進行簽名，具體代碼放在SHA256withRSAUtil類中，里面包含兩種不同的簽名/驗證簽名的實現，均已通過驗證。

5.4.2證書的有效性查詢

查詢證書的有效性，在本系統中有兩個判斷準則：第一，證書是否過期；第二，證書是否由CA本系統頒發。
過期檢測：每一個證書在生成時默認有效期為10天，從生成時立即生效。有效期信息記錄在數據庫中，當用戶查詢其他用戶的證書時，后端會檢查當前時刻與過期日期，判斷該證書是否過期。若過期，則立刻刪除證書，返回前端證書已過期的提示；若未過期，則正常返回信息。
檢查證書是否由CA本系統頒發：生成證書的時候，每份證書均經過CA本系統的簽名，用戶可通過下載本系統提供的使用方法（SHA256withRSAUtil類）驗證是否由本系統簽名。具體使用方法，均已在SHA256withRSAUtil類中寫明。

5.4.3利用證書進行非對稱加密

本系統使用RSA方法加密，兩套具體代碼放在RsaUtil類以及CARSA類中，均已通過驗證。

5.5其他

5.5.1AES加密

對稱加密AES方法在后端也有兩套放在了AESUtile以及AESFileUtil類中，分別加解密字符串以及文件。前端在Utils里的secret.js里也有相應實現。

5.5.2日志

記錄的日志放在log文件夾下

里面對每一個用戶的信息都進行了清楚的記錄


其他細節請看詳細代碼。

總結

以上是生活随笔為你收集整理的哈工大密码学实验CA的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。