CDN私鑰保護與HTTPS加速如何兼得？

▌什麼是證書/私鑰?

在數字化的網絡世界中，證書是一個人或者一個實體的有效標識，就像日常生活中的身份證，可以唯一的標識一個實體，比如網站。而與證書相對應的“私鑰”則是證明該實體是證書持有者的關鍵。在目前廣泛部署的SSL/TLS協議中，網站通過傳遞自己的證書以及相對應的“私鑰”簽名信息，來向網絡另一端的用戶證明自己的真實性。因此私鑰在網絡的認證中具有極其重要的地位。換句話說任何形式的私鑰竊取或者濫用，會導致網站被克隆，惡意的攻擊者進而可以對訪問的用戶進行“釣魚”。私鑰的保護在互聯網中是至關重要的，私鑰對於一個提供互聯網服務的公司來說屬於其核心資產。

▌如何保護私鑰？

爲了保護私鑰，現有的Web服務器都會提供私鑰的加密服務，即私鑰以文件形式持續化存儲在硬盤上時是被加過密的。在服務啓動階段，通過輸入對應的密碼進行解密並加載到服務器的進程中去。這種比較初級的保護措施能達到的安全效果有限。在服務器進程加載瞭解密的私鑰後，私鑰會以明文的形式存在於系統內存中，任何可能導致內存信息被探測的軟件或系統漏洞，如2014年爆發的OpenSSL心臟滴血漏洞，都可能造成私鑰內容的泄露。

尤其是隨着互聯網規模的不斷擴大，以前的單點服務模式已經無法滿足互聯網大量用戶的請求。傳統的CDN或者新的基於Cloud的CDN被大規模部署使用以提供高質量的互聯網內容服務。CDN是通常由第三方服務商或者電信運營商提供的網絡基礎服務，這就意味着對CDN上內容的安全控制已經遠遠超出了網站運營者的控制，尤其是需要提供HTTPS服務的網站來說，如果想使用CDN對其內容進行緩存分發，必須要在CDN的服務節點上部署相應的私鑰以滿足終端用戶接入HTTPS時的認證需求。正如前面所述，對私鑰部署在外部CDN節點上安全的擔憂一直是網站運營者的顧慮。

爲了解決這一問題，不同的安全策略被各大CDN服務商提出。CDN服務商根據用戶的需求提供的不同的私鑰管理解決方案。第一種是私鑰完全託管，即網站運營者將自己網站使用的私鑰通過安全渠道發送給CDN服務商，由CDN服務商代其部署相應的HTTPS節點，當然這種做法是完全無法打消之前的安全的顧慮的。因此，CDN服務商還會提供另一種策略即共享證書，這種方式實際上相當於CDN服務商重新申請頒發一套新的證書，證書可以認證的實體包含了CDN服務商所支持的網站，私鑰由CDN服務商持有。這種做法一定程度上緩解了網站運營者對自身私鑰安全的擔憂——因爲使用的是CDN服務商共享證書的私鑰而不是自己網站的私鑰，但另一方面，對CDN服務商而言，如何保證共享證書的私鑰的安全，同樣也是一個難題。同時，這種共享證書的方式也增加了網站運營的管理負擔以及需要承擔的額外證書維護費用。

▌ Keyless SSL方案

2015年某CDN服務商提出了”Keyless SSL” [1] 方案。該方案在私鑰安全性和網絡性能之間做了一個折中，引入了由網站運營者負責維護的“密鑰中心”來保存密鑰，對於CDN節點接受的每一個SSL請求，在CDN節點和密鑰中心間引入一條新的安全連接用於請求相應的“私鑰服務”。儘管通過SSL session reuse和長鏈接的形式可以減少一定的開銷，但CDN節點和密鑰中心額外的安全鏈接的引入不可避免的帶來了網絡延時的增加和吞吐率的下降。

圖1. Keyless SSL 的建鏈流程 (RSA wrapping密鑰交換)

圖1 是Keyless SSL工作的典型流程，我們以TLS協議中最典型的RSA wrapping的密鑰交換形式爲例說明Keyless SSL是如何工作的。在這類密鑰交換套件中，如圖示第3步，客戶端在驗證了服務端證書的有效性之後，使用證書中的公鑰對一個預主密鑰（後續導出鏈接會話密鑰的種子）進行加密。根據RSA算法的特性，只有對應的私鑰才能正確解密出上述密文。當被加密的預主密鑰到達CDN節點時，爲了完成內容的檢索和分發的請求，CDN必須使用正確的私鑰對其進行解密來完成SSL的握手，這也是爲什麼CDN節點需要知道其託管網站的私鑰。

Keyless SSL在這裏引入了步驟4和5，在CDN節點不知道私鑰的情況下，向後端的密鑰中心（由真正的網站運營者管理）建立另一條安全連接，將需要被解密的報文轉發給對應網站的密鑰管理中心，在網站運營者自己管理的密鑰中心裏，預主密鑰被相應的私鑰正確解密併發還給CDN節點，CDN節點利用預主密鑰即可完成SSL鏈接的建立。在整個過程中，網站私鑰始終由自己的密鑰中心管理，不必對外託管，CDN節點在不知道任何私鑰信息的情況成功完成了SSL的建鏈，整個過程中保證了私鑰的安全。

Keyless SSL在提高私鑰安全性的同時也引入了更多的限制。首先，顯而易見的對每一個客戶端發起的SSL請求，都會增加一個CDN到後端密鑰中心的交互，即增加了網絡延遲，這與CDN就近訪問原則相悖。另一方面，通過分佈在全球各地的CDN節點，任何網站可以對不同地區的用戶提供高質量的內容服務，然而後端密鑰中心的引入，再次在分佈式的網絡中引入了一箇中心節點，使得所有的安全連接的建立都要回溯到一個密鑰中心，增加了網絡瓶頸。

現實中的一些大型網站運營方，爲了緩解匯聚來的大量的SSL/TLS建鏈請求，即SSL握手中CDN節點傳送來的私鑰服務請求，往往會使用硬件加速器，比如Intel® QAT，來卸載高CPU消耗的私鑰運算。另一方面，憑着硬件加速器在HTTPS服務中出色的性能加速效果，越來越多的網站和CDN服務商都開始標準化的部署硬件加速器，然而在Keyless SSL的方案中，CDN節點上部署的硬件加速器只能在數據傳輸階段提供幫助，對於運算量最大的建鏈握手階段卻無法爲客戶的密鑰中心分擔壓力，一定程度上造成了資源重複配置和浪費。

▌基於Intel® SGX 和 Intel® QAT的CDN密鑰保護和HTTPS加速方案

爲了徹底解決這一問題，Intel® QuickAssist Technology (QAT)[2]技術團隊在2017年提出了一種針對CDN私鑰保護的安全密鑰管理和分發體系。該方案利用Intel® Software Guard Extensions (SGX) [3] 技術構建了安全的密鑰分發和保護體系，使用了Intel® QAT硬件加速器在CDN節點上對SSL建鏈握手提供加速，擺脫了SSL請求中對後端密鑰中心的依賴，充分利用CDN分佈式的特性大大提高了網絡性能。具體內容發表在2017年的ACM Symposium on Cloud Computing會議上[4].

圖2. 結合Intel® SGX和Intel® QAT的CDN密鑰保護和HTTPS加速方案

圖2爲我們展示了該方案的系統框圖。CDN節點上部署了Intel® SGX和Intel® QAT加速器。在Phase 1階段，密鑰分發中心（KDC）將相應的私鑰通過SGX的Remote Attestation 流程安全的部署到相應CDN節點的SGX enclave裏面（圖中KSC中的KS）。Phase 2階段KSC與Intel® QAT建立安全通道協商出用於保護私鑰的會話密鑰，並用此會話密鑰將私鑰加密導出至CDN服務器的硬盤上。Phase 3階段，相應的Web service啓動後，將硬盤中加密的私鑰直接載入內存。在SSL建鏈階段，所有需要私鑰的操作均伴隨着內存中加密的私鑰卸載至Intel® QAT加速器中，QAT在硬件中完成私鑰的解密和相應的運算並返回結果給上層的Web service以完成SSL握手。

整個過程中CDN對私鑰的內容不可見。同時該方案中還包含撤銷機制，當發現疑似有安全漏洞的CDN節點時，KDC可以撤銷其相應的SGX enclave，保證私鑰及時銷燬並不再對其進行密鑰部署。利用Intel® QAT對公鑰算法良好的加速性能 [5] ，可以將單個CDN節點的SSL建鏈能力提升數倍，並且不需要每次向KDC請求私鑰服務，消除了Keyless SSL網絡中密鑰中心的瓶頸同時提升了鏈接響應時間。

▌總結

該方案是Intel®安全技術和加速技術的典型結合，爲CDN網絡提供了安全保障的同時大幅提高HTTPS的處理性能。在Intel® QAT下一代的產品中引入了KPT（Key Protection Technology）技術，進一步提供了更加完善和便捷的密鑰保護和加速方案，將在後續文章中詳細介紹。

*性能測試中使用的軟件和工作負荷可能僅在英特爾微處理器上進行了性能優化。諸如SYSmark和MobileMark等測試均系基於特定計算機系統、硬件、軟件、操作系統及功能。上述任何要素的變動都有可能導致測試結果的變化。請參考其他信息及性能測試（包括結合其他產品使用時的運行性能）以對目標產品進行全面評估。