▌什么是證書/私鑰?

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

▌如何保護(hù)私鑰？

為了保護(hù)私鑰，現(xiàn)有的Web服務(wù)器都會提供私鑰的加密服務(wù)，即私鑰以文件形式持續(xù)化存儲在硬盤上時是被加過密的。在服務(wù)啟動階段，通過輸入對應(yīng)的密碼進(jìn)行解密并加載到服務(wù)器的進(jìn)程中去。這種比較初級的保護(hù)措施能達(dá)到的安全效果有限。在服務(wù)器進(jìn)程加載了解密的私鑰后，私鑰會以明文的形式存在于系統(tǒng)內(nèi)存中，任何可能導(dǎo)致內(nèi)存信息被探測的軟件或系統(tǒng)漏洞，如2014年爆發(fā)的OpenSSL心臟滴血漏洞，都可能造成私鑰內(nèi)容的泄露。

尤其是隨著互聯(lián)網(wǎng)規(guī)模的不斷擴(kuò)大，以前的單點服務(wù)模式已經(jīng)無法滿足互聯(lián)網(wǎng)大量用戶的請求。傳統(tǒng)的CDN或者新的基于Cloud的CDN被大規(guī)模部署使用以提供高質(zhì)量的互聯(lián)網(wǎng)內(nèi)容服務(wù)。CDN是通常由第三方服務(wù)商或者電信運營商提供的網(wǎng)絡(luò)基礎(chǔ)服務(wù)，這就意味著對CDN上內(nèi)容的安全控制已經(jīng)遠(yuǎn)遠(yuǎn)超出了網(wǎng)站運營者的控制，尤其是需要提供HTTPS服務(wù)的網(wǎng)站來說，如果想使用CDN對其內(nèi)容進(jìn)行緩存分發(fā)，必須要在CDN的服務(wù)節(jié)點上部署相應(yīng)的私鑰以滿足終端用戶接入HTTPS時的認(rèn)證需求。正如前面所述，對私鑰部署在外部CDN節(jié)點上安全的擔(dān)憂一直是網(wǎng)站運營者的顧慮。

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

▌ Keyless SSL方案

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

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

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

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

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

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

▌基于Intel® SGX 和 Intel® QAT的CDN密鑰保護(hù)和HTTPS加速方案

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

圖2. 結(jié)合Intel® SGX和Intel® QAT的CDN密鑰保護(hù)和HTTPS加速方案

圖2為我們展示了該方案的系統(tǒng)框圖。CDN節(jié)點上部署了Intel® SGX和Intel® QAT加速器。在Phase 1階段，密鑰分發(fā)中心（KDC）將相應(yīng)的私鑰通過SGX的Remote Attestation 流程安全的部署到相應(yīng)CDN節(jié)點的SGX enclave里面 （圖中KSC中的KS）。Phase 2階段KSC與Intel® QAT建立安全通道協(xié)商出用于保護(hù)私鑰的會話密鑰，并用此會話密鑰將私鑰加密導(dǎo)出至CDN服務(wù)器的硬盤上。Phase 3階段，相應(yīng)的Web service啟動后，將硬盤中加密的私鑰直接載入內(nèi)存。在SSL建鏈階段，所有需要私鑰的操作均伴隨著內(nèi)存中加密的私鑰卸載至Intel® QAT加速器中，QAT在硬件中完成私鑰的解密和相應(yīng)的運算并返回結(jié)果給上層的Web service以完成SSL握手。

整個過程中CDN對私鑰的內(nèi)容不可見。同時該方案中還包含撤銷機(jī)制，當(dāng)發(fā)現(xiàn)疑似有安全漏洞的CDN節(jié)點時，KDC可以撤銷其相應(yīng)的SGX enclave，保證私鑰及時銷毀并不再對其進(jìn)行密鑰部署。利用Intel® QAT對公鑰算法良好的加速性能 [5] ，可以將單個CDN節(jié)點的SSL建鏈能力提升數(shù)倍，并且不需要每次向KDC請求私鑰服務(wù)，消除了Keyless SSL網(wǎng)絡(luò)中密鑰中心的瓶頸同時提升了鏈接響應(yīng)時間。

▌總結(jié)

該方案是Intel®安全技術(shù)和加速技術(shù)的典型結(jié)合，為CDN網(wǎng)絡(luò)提供了安全保障的同時大幅提高HTTPS的處理性能。在Intel® QAT下一代的產(chǎn)品中引入了KPT（Key Protection Technology）技術(shù)，進(jìn)一步提供了更加完善和便捷的密鑰保護(hù)和加速方案，將在后續(xù)文章中詳細(xì)介紹。

天下數(shù)據(jù)idc提供CDN、SSL協(xié)議服務(wù)，詳詢在線客服！

本文鏈接：http://www.51huadong.com/cloundnews/11001943.html