一種基于虛擬私鑰的OpenSSL與CSP交互方案

張 臘， 盧 昱， 王增光

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

隨著互聯網+的提出，網絡進一步深入大眾生活，與之密切相關的網絡信息安全問題也受到越來越多的關注。眾多網絡應用需要一個安全可靠的信息傳輸環境，以確保數據的保密性、完整性和安全驗證等安全特性。目前廣泛應用的開放式安全套接層(Open Secure Sockets Layer，OpenSSL)是實現這一目標的關鍵一環。作為一個強大的安全套接層密碼庫，OpenSSL開源實現了常規的密碼算法和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所示?？傮w思路為：CSP保存真實私鑰，并提供虛擬私鑰和Engine對象，交由OpenSSL保存；OpenSSL將虛擬私鑰當作真實私鑰加載使用，同時加載CSP提供的Engine對象；OpenSSL在需要進行私鑰簽名或解密運算時，利用該Engine對象登錄CSP，并傳遞相關數據；由CSP的硬件加密設備完成實際私鑰簽名或解密運算，再返回相應結果；OpenSSL得到運算結果后繼續執行原工作任務。

2 交互方案設計

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

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

2.1 虛擬私鑰的構建

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

主要步驟如下：

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

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

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

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

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

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

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

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

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

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

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對象發來的IDO、PWO，驗證通過后在加密通道返回確認響應ACKP；

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

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

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

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

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

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

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

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

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

本文用到的SVO推理規則及公理[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調用第三方加密服務時，各種商業實現存在的私鑰不唯一、代碼改動過多和不便推廣的問題。下面主要從這3方面對所提方案進行分析。

4.1 安全性分析

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

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

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

4.2 性能分析

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

4.3 通用性分析

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

5 結論

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

參考文獻：

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

[2] 杜在東.一種加密設備的配置方法及系統：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] 李建華，張愛新.網絡安全協議的形式化分析與驗證[M].北京：機械工業出版社,2010:12-13.

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

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

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

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