張 臘， 盧 昱， 王增光

(陸軍工程大學石家莊校區(qū)裝備模擬訓練中心, 河北 石家莊 050003)

隨著互聯網+的提出，網絡進一步深入大眾生活，與之密切相關的網絡信息安全問題也受到越來越多的關注。眾多網絡應用需要一個安全可靠的信息傳輸環(huán)境，以確保數據的保密性、完整性和安全驗證等安全特性。目前廣泛應用的開放式安全套接層(Open Secure Sockets Layer，OpenSSL)是實現這一目標的關鍵一環(huán)。作為一個強大的安全套接層密碼庫，OpenSSL開源實現了常規(guī)的密碼算法和SSL。當會話雙方需要在網絡中進行敏感信息的交互時，OpenSSL還可以通過其內置的引擎(Engine)機制借力加密服務提供商(Cryptographic Service Provider, CSP)，使用CSP提供的硬件加密設備進行加密運算，以確保實現安全性更高的加解密。

由于OpenSSL允許CSP在提供Engine對象時對其代碼進行改動，因此在實際應用中各CSP實現的具體交互方式多種多樣[1]，概略分為3類：1)在OpenSSL和CSP兩端同時保存私鑰；2)實現方案需要傳遞私鑰或私鑰相關信息，進而得到私鑰副本；3)實現方案不傳遞私鑰或私鑰相關信息，卻需要對OpenSSL的Engine做出較大的代碼改動。前2類實現方案由于私鑰副本的出現，違背了私鑰唯一性原則，因而增大了私鑰泄漏的安全風險；第3類實現方案代碼工作量大，容易出現漏洞，不便實現和推廣[2]。

鑒于目前存在的這些安全缺陷，筆者提出一種OpenSSL與CSP構造虛擬私鑰和使用虛擬私鑰的交互方案。使用該方案可避免私鑰在網絡中傳播，并減少大量代碼工作，對進一步提高網絡信息傳輸的安全性具有指導作用。

1 交互方案總體思路

交互方案構想如圖1所示。總體思路為：CSP保存真實私鑰，并提供虛擬私鑰和Engine對象，交由OpenSSL保存；OpenSSL將虛擬私鑰當作真實私鑰加載使用，同時加載CSP提供的Engine對象；OpenSSL在需要進行私鑰簽名或解密運算時，利用該Engine對象登錄CSP，并傳遞相關數據；由CSP的硬件加密設備完成實際私鑰簽名或解密運算，再返回相應結果；OpenSSL得到運算結果后繼續(xù)執(zhí)行原工作任務。

2 交互方案設計

交互方案設計包括虛擬私鑰的構建和虛擬私鑰的使用，所涉及的符號及含義如表1所示。

表1 交互方案涉及的符號及含義

2.1 虛擬私鑰的構建

在CSP賬號注冊時完成虛擬私鑰的構建，即當OpenSSL端將真實私鑰導入CSP提供的硬件加密設備時，由CSP構建虛擬私鑰。虛擬私鑰構建過程如圖2所示。

主要步驟如下：

1) OpenSSL向CSP發(fā)送注冊請求ReqR；

2) 完成接收注冊信息的準備工作之后，CSP返回確認響應ACKP；

3) OpenSSL設置身份標志IDO、登錄口令PWO，并連同虛擬私鑰請求ReqV 發(fā)送給CSP；

4) CSP保存IDO和PWO，發(fā)送ACKP和私鑰請求ReqK；

5) OpenSSL向CSP發(fā)送ACKP，并提交私鑰skO；

6) CSP以安全的方式存儲skO，并返回ACKP和虛擬私鑰vskO；

7) OpenSSL發(fā)送ACKO，并用接收到的vskO替換skO。

上述步驟主要著眼于OpenSSL和CSP在加密通道中從注冊到完成虛擬私鑰替換真實私鑰的整體交互過程，虛擬私鑰的具體生成在CSP內部。步驟6)中，CSP利用真實私鑰在內部生成虛擬私鑰的構建過程如下：

1) CSP以安全的方式存儲skO，取得skO的存儲地址等相關信息MskO；

2) 按照事先設置的某種變換組合(可以采用任意密文長度固定的簡單、快捷、可逆的加密方法)將MskO、IDO、PWO變換形成多個字節(jié)的二進制碼串；

3) 將形成的二進制碼串級聯冗余碼R，得到一個與skO長度相同的新碼串；

4) CSP將此新碼串作為vskO，并將vskO返回到OpenSSL。

通過以上步驟，可以生成一個虛擬私鑰，但需要保證CSP提供的Engine對象能夠合理解釋該虛擬私鑰，從而能夠提取正確的身份標志和登錄口令，以及真實私鑰在CSP中的存儲地址等相關信息。

2.2 虛擬私鑰的使用

當使用CSP服務的OpenSSL端需要與其他進程建立安全鏈接時，握手過程用到簽名或私鑰解密的部分由CSP完成實際運算。這需要OpenSSL成功登錄CSP，將相關數據傳遞給CSP，并接收相應的返回信息[3]。以實現數字簽名為例，其交互過程如圖3所示。

主要步驟如下：

1) SSL加載虛擬私鑰vskO以及CSP提供的Engine對象；

2) SSL將需要私鑰簽名的相關數據X以及vskO傳遞給Engine對象；

3) Engine對象合理解釋vskO，取出登錄CSP所需的IDO、PWO和MskO，并在加密通道中用IDO、PWO向CSP提出數字簽名申請ReqS ；

4) CSP驗證Engine對象發(fā)來的IDO、PWO，驗證通過后在加密通道返回確認響應ACKP；

5) Engine對象將MskO、X由加密通道發(fā)送給CSP；

6) CSP通過MskO找到存儲的skO，利用自身的硬件加密設備和真實私鑰完成實際簽名運算，并由加密通道返回Engine對象需要的簽名數據signskO(X)；

7) Engine對象得到signskO(X)之后在加密通道回送自身的確認響應 ACKO；

8) Engine對象將signskO(X)返回SSL。

經過以上步驟,OpenSSL接收到簽名數據。隨后可通過繼續(xù)與其他進程的握手過程，建立起安全會話鏈接。

為了更加清楚地梳理整個過程，筆者綜合文獻[4-5]的表述方法，將OpenSSL端進一步分解為2部分，將其中由CSP提供的Engine對象單獨顯示出來。實際上,圖3中SSL與Engine對象的交互部分與OpenSSL原機制的主要區(qū)別僅僅在于用虛擬私鑰替換了原機制中使用真實私鑰的部分。

3 基于SVO邏輯的形式化分析

為分析安全協(xié)議執(zhí)行過程中主體信念和知識的演化過程，1989年由Burrows、Abadi和Needham提出了第一個說明和驗證密碼協(xié)議的信仰模態(tài)邏輯——BAN邏輯[6]。之后，隨著理論的發(fā)展演變出很多邏輯語言，其中：1994年Paul Syversot和Paul C. van Oorschot提出的SVO邏輯語言作為BAN及類BAN邏輯成熟的標志，其表達力更強，綜合性和可靠性更加突出，能成功發(fā)現協(xié)議設計中的安全缺陷和漏洞，為邏輯系統(tǒng)建立了用于推證合理性的優(yōu)質理論模型。

筆者針對虛擬私鑰使用方案中OpenSSL與CSP之間的交互部分利用SVO邏輯進行形式化分析，以證明方案的安全性與合理性。

本文用到的SVO推理規(guī)則及公理[7]如下：

A1.Pbelievesφ∧Pbelieves(φ→ψ)→Pbelievesψ。

A18.Pcontrolsφ∧Psaysφ→φ。

A19.fresh(Xi)→fresh(X1,…,Xl)。

A21.fresh(X)∧PsaidX→PsaysX。

1) 形式化分析基本假設

(1)初始假設

S1. P believes fresh(ReqS)，

P believes fresh(Msko)，

O believes fresh(signsko(X))。

S3. O believes(P controls sko)，

P believes(O controls IDO,PWO,Msko)。

S4. P believes(Msko→sko)。

(2) 收到的消息假設

S5. P received{|IDO,PWO,ReqS|}k。

S6. O received{|ACKp|}k。

S7. P received{|Msko,X|}k。

S8. O received{|signsko(X)|}k。

S9. P received{|ACKo|}k。

(3) 對假設的理解

S10.P believes P received{|IDO,PWO,*1|}k。

S11.P believes P received{|*2,X|}k。

(4) 目標假設

T1. P believes O says ReqS。

T2. O believes P says(signsko(X)}。

2) 對T1的推理

(1) P believes P received{|IDO,PWO,fresh(ReqS)|}k，

根據S10, A19, MP。

(2) P believes O said(fresh(ReqS))，

根據(1), S2, S3, A1, A5, Nec, MP。

(3) P believes fresh(IDO,PWO,fresh(ReqS))，

根據S1, A1, A19, Nec, MP。

(4) P believes O says(ReqS)，

根據(2),(3), A1, A21, Nec, MP。

T1得證。

3) 對T2的推理

(1) P believes P received{|fresh(Msko),X|}k，

根據S3, S11, A19, MP。

(2) P believes O said(fresh(Msko),X)，

根據(1), S2, S3, A1, A5, Nec, MP。

(3) P believes fresh(fresh(Msko),X)，

根據S1, S3, A1, A19, Nec, MP。

(4) P believes O says(fresh(Msko),X)，

根據(2),(3), A1, A21, Nec, MP。

(5) O believes P said(signsko(X))，

根據 S3, S6, A18, Nec, MP。

(6) O believes fresh(signsko(X))，

根據S1, S3, A1, A19, Nec, MP。

(7) O believes P says(signsko(X))，

根據(4),(6), A1, A21, Nec, MP。

T2得證。

上述形式化分析成功得到預期目標假設T1和T2，即由SVO邏輯形式化證明了交互方案的安全性與合理性。說明雙方完成的交互是安全可信的:CSP可以相信OpenSSL正在請求數字簽名服務；OpenSSL可以相信CSP正在返回數字簽名結果。

4 方案分析

筆者提出的交互方案旨在解決目前OpenSSL調用第三方加密服務時，各種商業(yè)實現存在的私鑰不唯一、代碼改動過多和不便推廣的問題。下面主要從這3方面對所提方案進行分析。

4.1 安全性分析

現代加密算法的安全性主要取決于私鑰的安全性[8]，確保私鑰安全的首要目標是確保私鑰是唯一的，不存在額外的副本。下面從私鑰唯一性的角度對本文所提交互方案進行安全論證，并做基于SVO邏輯的協(xié)議形式化分析。

一是虛擬私鑰的信息與真實私鑰并沒有直接關聯，通過此方法獲取的虛擬私鑰并非真實私鑰的副本，所包含信息亦不足以推斷出真實私鑰本身，不能直接用于數字簽名等非對稱算法的運算(實際上即使更換真實私鑰也可以不改變虛擬私鑰)。因此相比傳遞真實私鑰，傳遞虛擬私鑰的方式十分安全，確保了真實私鑰的唯一性，用于傳遞過程不會增加真實私鑰泄露的風險。

二是盡管OpenSSL可以通過CSP提供的Engine對象解釋虛擬私鑰，進而登錄CSP并調用真實私鑰實現簽名解密等運算。但虛擬私鑰也僅僅是在OpenSSL處能夠實現真實私鑰的原有功能，并且最終是通過調用真實私鑰的方式實現了功能。從根源上確保了私鑰功能只能由真實私鑰實現，虛擬私鑰不是第2個“私鑰”，保證了真實私鑰的唯一性。

4.2 性能分析

通過虛擬私鑰替代真實私鑰正常加載，以及OpenSSL借由Engine對象調用CSP的過程可以看出：本交互方案能夠保持與原OpenSSL端不同應用程序、不同調用方式相通用的調用效果，對現有應用程序和調用方式幾乎沒有影響?？梢缘韧贠penSSL端和CSP端同時保存真實私鑰的方式，最大限度減少了OpenSSL端的代碼改動量，不影響原OpenSSL性能，達到了良好效果。

4.3 通用性分析

OpenSSL作為一個非常成熟的開源實現，已經被大量網站和應用程序使用多年，因此OpenSSL不宜大規(guī)模變動[9]。由CSP負責主要改進工作且兼容OpenSSL本身的運行方式，符合少數服從多數的商業(yè)工程實現規(guī)律。本方案幾乎沒有改變OpenSSL本身的運行方式，代碼改動工作基本由CSP一方完成，因而能夠直接套用在現有各種應用中，具有較強的通用性。

5 結論

筆者設計的交互方案能夠避免現有調用方案的一些缺陷，提高OpenSSL采用第三方加密服務的安全性；不足在于加密通道的建立和維護成本較高，且目前沒有較好的替代方案。與文獻[10]設計方案相比，本方案安全性更高。下一步的研究可以考慮與云計算相結合，將CSP擴展為一個用于分擔OpenSSL服務器加解密運算壓力的公有云。充分利用云計算的優(yōu)勢，進一步提高運算能力，增強OpenSSL所能借用的加密性能。

參考文獻：

[1] KAMP P H.Please put OpenSSL out of its misery[J].Queue,2014,12(3):20-23.

[2] 杜在東.一種加密設備的配置方法及系統(tǒng)：CN106060022A[P].2016-10-26.

[3] 龔少麟.OpenSSL密碼安全平臺實現機制的研究[J].計算機與數字工程,2011,39(6):118-121.

[4] RASHTI M J,SABIN G,Kettimuthu R.Long-haul secure data transfer using hardware-assisted GridFTP[J].Future generation computer systems,2016,56:265-276.

[5] CHRISTIAN J D,CHOO K K R.A technique to circumvent SSL/TLS validations on iOS Devices [J].Future generation computer systems,2016,74:366-374.

[6] 李建華，張愛新.網絡安全協(xié)議的形式化分析與驗證[M].北京：機械工業(yè)出版社,2010:12-13.

[7] 王亞弟,束妮娜，韓繼紅，等.密碼協(xié)議形式化分析[M].北京：機械工業(yè)出版社,2006：82-86.

[8] 謝東良.基于國密算法的OpenSSL安全性優(yōu)化研究[D].哈爾濱：哈爾濱工程大學,2016:6-10.

[9] 王瑋,龍毅宏,唐志紅.OpenSSL引擎機制的研究[J].信息安全與通信保密,2011(10):60-62.

[10] 齊洪喜，周大水.基于OpenSSL的安全密碼平臺的設計與實現[J].計算機工程與設計,2007,28(2):314-319.