本發(fā)明屬于計算機網(wǎng)絡(luò)安全技術(shù)與密碼學(xué)技術(shù)領(lǐng)域，具體涉及到一種基于區(qū)塊鏈(Blockchain)的公鑰基礎(chǔ)設(shè)施(Public Key Infrastructure，PKI)系統(tǒng)及半隨機聯(lián)合證書簽名方法。

背景技術(shù)：

公鑰基礎(chǔ)設(shè)施(PKI)的本質(zhì)是將非對稱密鑰管理標(biāo)準(zhǔn)化，及身份與公鑰的映射關(guān)系。公鑰密碼的誕生，標(biāo)志著密碼學(xué)進入了一個新的時代，密碼技術(shù)的應(yīng)用從單純的保密通信發(fā)展到了身份認證。簡單來說，在現(xiàn)實生活中，每個人都有一張身份證，用于鑒別身份，買火車票、住酒店、辦理銀行業(yè)務(wù)都需要確定身份，而身份證的發(fā)行機關(guān)——派出所充當(dāng)可信第三方，只有派出所頒發(fā)的身份證才會被接受，任何人和單位不得頒發(fā)、修改、撤銷身份證。而在網(wǎng)絡(luò)世界，如何確定一個用戶的身份呢？網(wǎng)絡(luò)世界的數(shù)字證書就充當(dāng)了現(xiàn)實世界身份證的角色了。公鑰密碼是數(shù)字證書的基礎(chǔ)，數(shù)據(jù)的發(fā)送者A利用自己的私鑰對數(shù)據(jù)進行簽名，將消息與簽名一起發(fā)送給接收者B，接收者B收到之后，利用發(fā)送者A的公鑰驗證簽名是否正確，若正確，則接收者B認為該證書是發(fā)送者A發(fā)送的。在小范圍的網(wǎng)絡(luò)里，可以靠人工識別公鑰與身份的映射關(guān)系，可是在龐大的因特網(wǎng)里，又如何才能找到身份與公鑰的對應(yīng)關(guān)系呢？用戶的身份又由誰來驗證呢？這就是PKI要解決的問題了。

PKI包含引入證書授權(quán)中心(Certificate Authority，CA)、證書撤銷列表(Certificate Revocation List，CRL)/在線證書狀態(tài)協(xié)議(OCSP)以及輕量級目錄訪問協(xié)議(LDAP)等技術(shù)制定相應(yīng)標(biāo)準(zhǔn)，有效的管理身份與公鑰的映射關(guān)系，一般用戶可以通過驗證其連接的實體的數(shù)字證書是否合法，來判斷該實體身份的合法性，有效的解決了網(wǎng)絡(luò)中的身份認證問題。

然而，CA作為可信第三方，也有被黑客攻擊的可能，倘若CA被攻擊者操控，則可以為任何惡意的網(wǎng)站或用戶頒發(fā)證書，用戶無法通過驗證CA簽名來辨別這些惡意網(wǎng)站及用戶的身份，導(dǎo)致用戶遭受釣魚網(wǎng)站欺騙等，使用戶蒙受經(jīng)濟損失，個人隱私信息遭到泄露。因此這類問題是亟待解決的。

技術(shù)實現(xiàn)要素：

為了解決上述技術(shù)問題，本發(fā)明提供了一種基于區(qū)塊鏈的公鑰基礎(chǔ)設(shè)施系統(tǒng)及半隨機聯(lián)合證書簽名方法。

本發(fā)明的系統(tǒng)所采用的技術(shù)方案是：一種基于區(qū)塊鏈的公鑰基礎(chǔ)設(shè)施系統(tǒng)，其特征在于：由用戶Client、Web服務(wù)器和若干證書授權(quán)中心CA組成；若干證書授權(quán)中心CA組成CA聯(lián)盟，所述Web服務(wù)器向若干證書授權(quán)中心CA申請證書，若干證書授權(quán)中心CA聯(lián)合簽名后，將證書存儲在區(qū)塊鏈中，存儲完成之后，證書授權(quán)中心CA將證書頒發(fā)給Web服務(wù)器，然后用戶Client與Web服務(wù)器進行TLS連接時，用戶需要驗證Web服務(wù)器的證書的合法性。

本發(fā)明的方法所采用的技術(shù)方案是：一種半隨機聯(lián)合證書簽名方法，應(yīng)用于基于區(qū)塊鏈的公鑰基礎(chǔ)設(shè)施系統(tǒng)中；其特征在于，包括以下步驟：

步驟1：證書注冊；

步驟2：證書撤銷；

步驟3：證書更新；

步驟4：證書驗證。

本發(fā)明提出了一種基于區(qū)塊鏈的公鑰基礎(chǔ)設(shè)施(Public Key Infrastructure,PKI)系統(tǒng)，將傳統(tǒng)PKI系統(tǒng)中的單個獨立的中心CA擴展到CA聯(lián)盟，打破了以單個CA為信任中心的機制，由多個CA協(xié)同進行證書管理。另外，由于區(qū)塊鏈的分布式存儲以及防篡改的特性，保證了簽發(fā)的證書不被篡改和偽造。再者，以CA聯(lián)盟為核心的成員結(jié)構(gòu)，打破了傳統(tǒng)的以根CA為核心分層結(jié)構(gòu)，使得CA之間的平等競爭關(guān)系。

本發(fā)明提出了半隨機聯(lián)合證書簽名方法，避免CA作為中心被攻擊造成的證書濫用的情況，本發(fā)明采用了在系統(tǒng)中選擇少量的CA進行聯(lián)合簽名，依然能夠保證系統(tǒng)安全性。從理論上來考慮，參與聯(lián)合簽名的成員越多，系統(tǒng)越安全。然而從實際來考慮，證書簽名的頒發(fā)直接與CA的經(jīng)濟利益掛鉤，CA之間是一種競爭關(guān)系，并不適合與多數(shù)CA聯(lián)合簽名。另一方面，聯(lián)合簽名的驗證需要聯(lián)合公鑰，這個對于用戶來說，如果用戶瀏覽器存有CA聯(lián)盟的所有成員公鑰，那么合成聯(lián)合公鑰的挑戰(zhàn)并不大，但是當(dāng)新加入聯(lián)盟的CA的公鑰并未被添加到用戶瀏覽器可信CA列表時，用戶就需要去驗證CA的身份與公鑰是否一致。特別是聯(lián)合簽名中，多個CA為新加入的成員，用戶的計算通信開銷就會比較大。本發(fā)明提出的半隨機的聯(lián)合證書簽名方案中，參與簽名的CA一個是由Web服務(wù)器指定，另一個由系統(tǒng)隨機選擇。Web服務(wù)器指定CA的優(yōu)勢在于，Web服務(wù)器可以選擇可信且地理位置相對較近的CA，這個CA既可以是CA聯(lián)盟中的成員，也可以非聯(lián)盟成員。為了避免惡意的Web服務(wù)器成功攻擊CA后與之合謀，參與聯(lián)合簽名的另個CA為系統(tǒng)隨機選擇。當(dāng)CA聯(lián)盟成員數(shù)量較多時，本發(fā)明適當(dāng)擴大參與聯(lián)合簽名成員的數(shù)量，可以實現(xiàn)快速檢測系統(tǒng)中被攻擊的CA。

附圖說明

圖1為本發(fā)明實施例的系統(tǒng)框架圖；

圖2為本發(fā)明實施例的Merkle Hash樹結(jié)構(gòu)

圖3為本發(fā)明實施例的區(qū)塊與區(qū)塊頭結(jié)構(gòu)圖；

圖4為本發(fā)明實施例的區(qū)塊數(shù)據(jù)存儲。

具體實施方式

為了便于本領(lǐng)域普通技術(shù)人員理解和實施本發(fā)明，下面結(jié)合附圖及實施例對本發(fā)明作進一步的詳細描述，應(yīng)當(dāng)理解，此處所描述的實施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明。

本發(fā)明旨在解決三個問題：1.PKI系統(tǒng)中多級CA的去中心化；2.PKI系統(tǒng)中CA的單點失效；3.證書防篡改、易于管理。這三類問題造成的影響分別是：1.上層CA被攻擊，容易造成下層CA被控制；2.CA單點失效，造成惡意證書泛濫的問題；3.證書被篡改偽造，無法保證用戶與Web服務(wù)器的安全鏈接。本發(fā)明涉及的技術(shù)包括密碼學(xué)隨機選擇算法，多重簽名算法，區(qū)塊鏈(blockchain)技術(shù)，提高PKI系統(tǒng)的安全性。

本發(fā)明包含的實體主要有3類：用戶(Client)、Web服務(wù)器、證書授權(quán)中心(CA)，系統(tǒng)框架如圖1所示，Web服務(wù)器向2個CA申請證書，2個CA聯(lián)合簽名后，將證書存儲在區(qū)塊鏈中，存儲完成之后，CA將證書頒發(fā)給Web服務(wù)器，然后用戶(Client)與Web服務(wù)器進行TLS連接時，用戶需要驗證Web服務(wù)器的證書的合法性。

1.證書注冊流程：

①證書申請：Web服務(wù)器生成公私鑰對(pk，sk)，將公鑰pk與身份id進行綁定成證書提交給兩個CA進行簽名。其中，CA₁由Web服務(wù)器指定，CA_i為系統(tǒng)隨機選擇算法在CA聯(lián)盟中選定；

②證書簽名：CA₁、CA_i各自運行聯(lián)合簽名算法，分別計算子簽名、，然后將子簽名發(fā)送給對方，雙方分別根據(jù)聯(lián)合簽名子簽名驗證算法驗證對方的子簽名，若簽名無效，則將錯誤廣播到CA聯(lián)盟中；若無誤，CA_i合成聯(lián)合簽名σ并計算聯(lián)合簽名證書的hash值；

③證書存儲：CAi將簽名證書的hash值廣播發(fā)送給礦工，礦工挖出區(qū)塊后將其存放于區(qū)塊中，所有的證書均是以Merkle Hash樹的數(shù)據(jù)結(jié)構(gòu)存放，Merkle Hash樹的格式如圖2所示；

④證書頒發(fā)：當(dāng)下一個區(qū)塊生成之后，即當(dāng)前區(qū)塊被確認，CA_i將證書及其所在區(qū)塊鏈的高度值h發(fā)送給Web服務(wù)器；

當(dāng)用戶Client與Web服務(wù)器進行安全連接的時候，Web服務(wù)器提供簽名證書及高度值h，用戶可以通過高度值h找到該證書所在區(qū)塊，然后驗證證書的合法性，若合法，則可以進行安全連接，否則彈出“非安全連接”警告。

2.證書撤銷流程：

①撤銷申請：當(dāng)Web服務(wù)器需要撤銷證書時，可依照傳統(tǒng)PKI系統(tǒng)處理方式，由Web服務(wù)器向CA_i提交證書撤銷申請，CA_i驗證該證書的聯(lián)合簽名σ以及Web服務(wù)器身份，若無誤，將該證廣播到CA聯(lián)盟中。

②證書撤銷列表(CRL)生成：當(dāng)區(qū)塊生成，礦工將當(dāng)前區(qū)塊生成時間段內(nèi)收到的撤銷申請的證書存放于區(qū)塊中，并刪除已經(jīng)存在于CRL列表但已經(jīng)過期的證書，建立最新的證書撤銷列表，仍然是以Merkle Hash樹的結(jié)構(gòu)數(shù)據(jù)記錄當(dāng)前撤銷證書。

值得注意的是，雖然證書撤銷操作與證書申請操作類似，但是證書驗證時需要知道該證書hash值所在的區(qū)塊高度值，而檢驗證書是否被撤銷時，只需要找當(dāng)前最新的區(qū)塊驗證即可，因為當(dāng)前區(qū)塊保存了最新的證書撤銷列表，并且使以區(qū)塊生成時間為周期更新撤銷列表。

3.證書更新流程：

Web服務(wù)器在當(dāng)前證書即將過期或者私鑰泄露的時候會向CA申請證書更新服務(wù)，在本發(fā)明中，證書的更新過程與證書注冊過程基本一致，Web服務(wù)器向兩個CA申請新證書即可。當(dāng)Web服務(wù)器與用戶Client建立TLS安全連接時，Web服務(wù)器將當(dāng)前最新證書及其所在區(qū)塊鏈高度值h發(fā)送給用戶。舊證書的hash值永久保存與區(qū)塊鏈中，它們可以為CA審查Web服務(wù)器身份時提供參考。

4.證書驗證流程

用戶Client需要驗證證書時，有三個步驟：

①證書聯(lián)合簽名簽證：先合成聯(lián)合公鑰，根據(jù)聯(lián)合簽名驗證算法驗證簽名是否合法，若合法則進行第二步操作，否則直接向CA聯(lián)盟舉報證書不合法。

②證書存在性驗證：根據(jù)該證書hash值所在區(qū)塊高度值，查找到對應(yīng)區(qū)塊，根據(jù)Merklehash樹特性，可快速查詢該證書是否存在于區(qū)塊鏈中，若存在，則驗證通過，則進行第三步驗證，否則向CA聯(lián)盟舉報證書不存在。

③證書撤銷驗證：查找當(dāng)前最新區(qū)塊，驗證證書是否存在于證書撤銷列表中，若存在，則說明該證書被撤銷，中止TLS連接，若不存在，則說明證書可使用，可以進行TLS安全連接。

本發(fā)明的方法主要步驟包含四類，分別是證書注冊、撤銷、更新與驗證，由于證書的更新與注冊過程幾乎一致，證書的撤銷需要操作證書撤銷列表(CRL)，其它操作也與注冊類似，因此本發(fā)明詳細描述了證書注冊的具體實施過程，以及證書撤銷列表(CRL)操作過程。本發(fā)明的具體實施主要包含以下幾個過程：1.系統(tǒng)隨機選擇CA；2.2個CA為Web服務(wù)器提交的證書進行簽名；3.區(qū)塊的產(chǎn)生以及礦工之間的激勵機制；4.區(qū)塊數(shù)據(jù)存儲。

1.系統(tǒng)隨機選擇CA

為了防止CA的單點失效而導(dǎo)致惡意證書泛濫，本發(fā)明采用多個CA聯(lián)合簽名機制為證書進行簽名。由于在現(xiàn)實過程中，多個CA并非利益合作關(guān)系，而是競爭關(guān)系，因此多個CA中若有部分CA消極工作，將會成為整個系統(tǒng)的瓶頸。另外，由于聯(lián)合證書的驗證需要聯(lián)合公鑰，聯(lián)合公鑰是由證書聯(lián)合簽名涉及到的所有CA的公鑰生成，因此，用戶在驗證聯(lián)合簽名時，需要花費一定的計算開銷合成聯(lián)合公鑰，甚至需要驗證個別CA的身份，這對用戶特別是移動設(shè)備用戶來說，操作代價比較大。

因此本發(fā)明考慮減少聯(lián)合簽名CA的數(shù)量的同時又不失安全性，解決方案是CA由系統(tǒng)隨機選擇，那么即使某個CA被惡意攻擊者控制，但是系統(tǒng)不一定能隨機選擇到，即使選擇到惡意CA了，在處理Web服務(wù)器提交的證書注冊申請過程中，合法的CA在合成聯(lián)合簽名的時候會探測到惡意CA的行為。另外，考慮到實際過程中，如果指定給Web服務(wù)器簽名的CA過于遙遠，不便于注冊資料的提交，因此本發(fā)明采用“指定+隨機”相結(jié)合的方式選定進行聯(lián)合簽名的2個CA。

具體實施過程如下，當(dāng)Web服務(wù)器提交證書注冊申請的時候，在X.509證書擴展域內(nèi)指定可信CA作為聯(lián)合簽名的成員(該CA可以是CA聯(lián)盟成員，也可以在聯(lián)盟之外)，另外一個CA由系統(tǒng)隨機選擇，隨機算法部署于CA聯(lián)盟中的所有成員。當(dāng)Web提交證書請求時，CA聯(lián)盟隨機算法被觸發(fā)，算法輸出一個CA，與Web服務(wù)器制定的CA進行聯(lián)合簽名。這樣，既能解決CA單點失效的問題，提高安全性，也符合實際，便于Web服務(wù)器的操作。CA之間的競爭關(guān)系可以通過區(qū)塊鏈的激勵機制轉(zhuǎn)變?yōu)榉e極的合作關(guān)系。

隨機選擇算法設(shè)計思路如下，Web服務(wù)器將證書請求消息廣播到CA聯(lián)盟中，各成員計算證書請求消息的hash值以及自身id的hash值，取兩個hash值的差值的絕對值，絕對值最小的CA即被選定。當(dāng)有多個CA差值一致時，對證書請求消息的hash值再進行一次hash，直到最終確定一個CA即可。

2.2個CA為Web服務(wù)器提交的證書進行簽名

這個步驟主要負責(zé)給Web服務(wù)器提交的證書進行聯(lián)合簽名，其目的是為了避免CA的單點失效造成的影響。

聯(lián)合簽名方案使基于BLS簽名擴展而來，BLS簽名方案由三個算法組成：密鑰生成算法KeyGen(λ)->(x，g^x)，簽名算法：Sign(x，m)->σ，驗證算法Verify(σ，m，g^x)->b，b∈(0，1)，當(dāng)b＝1時驗證通過，否則未通過。簽名算法的操作為σ＝H(m)^x，H(m)為消息m的hash函數(shù)。

聯(lián)合簽名方案設(shè)計如下：

設(shè)群G為p(p為素數(shù))階乘法循環(huán)群，為模p加法群，其生成元為g，H()為hash函數(shù)，m為需要簽名的證書消息，λ為安全參數(shù)。

1密鑰生成算法keyGen(λ)：各成員選擇隨機數(shù)生成公私鑰對

2子簽名生成算法PSign(，):參與簽名的CA分別計算自簽名

3聯(lián)合簽名生成算法CoSign(，…，)：聯(lián)合簽名σ＝∏；

4聯(lián)合簽名驗證算法Verify(，…，，，σ):先合成聯(lián)合公鑰再根據(jù)BLS簽名驗證算法對聯(lián)合簽名進行驗證，驗證通過時輸出1，否則輸出0。

具體實施過程如下，當(dāng)2個CA(一個由Web服務(wù)器指定CA₁，另一個由系統(tǒng)隨機選擇CA_i)接收到證書申請的時候，利用BLS聯(lián)合簽名算法分別為該證書計算子簽名，，然后分別將子簽名發(fā)給對方，此時雙方可以驗證對方簽名是否合法，當(dāng)CA_i發(fā)現(xiàn)簽名無誤時，通過簽名合成算法生成聯(lián)合簽名σ并計算相應(yīng)的hash值，然后將其廣播到CA聯(lián)盟(CA充當(dāng)區(qū)塊鏈中的礦工)，當(dāng)某個CA即礦工生成區(qū)塊之后，將該hash值存在區(qū)塊里，當(dāng)下一個區(qū)塊生成即當(dāng)前區(qū)塊被確認，CA_i將簽名證書即證書hash所在區(qū)塊高度值h發(fā)送給Web服務(wù)器。

3.區(qū)塊鏈及相關(guān)操作

由于引入了區(qū)塊鏈技術(shù)，必不可少的需要礦工產(chǎn)生區(qū)塊，以及共識協(xié)議。在本發(fā)明中，CA聯(lián)盟中的CA充當(dāng)?shù)V工，共同維護一個聯(lián)盟鏈。由于工作量證明(Proof Of Work，POW)共識協(xié)議需要耗費極大的計算代價，對于CA來說，造成極大資源浪費，本發(fā)明采用權(quán)益證明(Proof Of State，POS)，不僅可以避免計算資源的浪費，也符合聯(lián)盟鏈的要求。

在這個過程中，CA聯(lián)盟中的每一個CA充當(dāng)?shù)V工，以信譽值獎勵作為激勵機制。信譽值的意義在于，CA簽發(fā)證書的數(shù)量直接與其經(jīng)濟利益掛鉤，而信譽值作為Web服務(wù)器指定CA時的一個重要的參考依據(jù)，換句話說，當(dāng)CA的信譽值越高，Web服務(wù)器指定該CA為其簽名的概率就越大，這樣CA獲得的經(jīng)濟利益也越高。

值得注意的是，被系統(tǒng)隨機選擇簽名的CA與挖礦成功的CA并不是同一個CA，因為，在一段時間內(nèi)，產(chǎn)生區(qū)塊的礦工CA只有一個，而簽名證書的數(shù)量卻有多個，即參與簽名CA有多個，這樣是為了保證每次給證書簽名的2個CA中一定有一個是隨機的。

區(qū)塊鏈技術(shù)的引入，保證了證書的不可篡改，省略了證書專用存儲服務(wù)器及相應(yīng)的監(jiān)督審計服務(wù)器，打破了CA之間的層次關(guān)系，去除了CA之間的中心，使得CA之間形成一種相互合作，又相互監(jiān)督的關(guān)系，允許系統(tǒng)中少部分CA被攻擊，不影響合法簽名證書的生成。

4.區(qū)塊數(shù)據(jù)存儲

在本發(fā)明中，區(qū)塊鏈保證了兩類證書的不可篡改，一類是合法證書列表，第二類證書是撤銷證書列表。兩類證書均是以Merklehash樹的數(shù)據(jù)結(jié)構(gòu)存儲，如圖4所示。二者的區(qū)別在于，簽名證書存在于該證書提交到礦工的時間段內(nèi)產(chǎn)生的區(qū)塊中，合法證書的驗證需要依據(jù)該證書hash值所在區(qū)塊的高度值，找到相應(yīng)的區(qū)塊即可驗證。而驗證證書是否被撤銷，只需要找當(dāng)前最新區(qū)塊，因為，每一次區(qū)塊的生成，就意味著證書撤銷列表(CRL)被更新一次，去掉已經(jīng)過期的撤銷證書，添加新的被撤銷的證書，重新構(gòu)建Merklehash樹。因此，區(qū)塊鏈中同步保存了兩個Merkleroot hash。

應(yīng)當(dāng)理解的是，本說明書未詳細闡述的部分均屬于現(xiàn)有技術(shù)。

應(yīng)當(dāng)理解的是，上述針對較佳實施例的描述較為詳細，并不能因此而認為是對本發(fā)明專利保護范圍的限制，本領(lǐng)域的普通技術(shù)人員在本發(fā)明的啟示下，在不脫離本發(fā)明權(quán)利要求所保護的范圍情況下，還可以做出替換或變形，均落入本發(fā)明的保護范圍之內(nèi)，本發(fā)明的請求保護范圍應(yīng)以所附權(quán)利要求為準(zhǔn)。