哈工大密碼學實驗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檔案夾下

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


其他細節請看詳細代碼，