4.3 論文筆記 | Achieving Keyless CDNs with Conclaves

Achieving Keyless CDNs with Conclaves

作者	大學	信息	主頁
Stephen Herwig	University of Maryland	馬里蘭大學·博士，系統安全。照片上看起來是一個讀了挺久的博士，近幾年有發幾個頂會（如果我也能在博士期間發2篇頂會就很知足了）	https://www.cs.umd.edu/~smherwig/
Christina Garman	Purdue University	女老師！！從馬里蘭大學畢業的最近的頂會除了這篇就只有CCS了，不過14-16年很高產了！也是做系統安全性評估的，	cs.purdue.edu/homes/clg/
Dave LevinUniversity of Maryland	University of Maryland	和我現在做的工作很像很像，衡量Internet安全性，measure security,鎖了鎖了，發了不少頂會，最近的讀論文計劃完成後，趕緊讀一讀他的論文	https://www.cs.umd.edu/~dml/

（馬里蘭大學，整體一般般，但犯罪心理學很棒，《他來了請閉眼》好像和他相關）

哈哈哈，我也想要有一個！！！開始讀論文了~

Abstract

和上篇論文巧合的是，這篇論文做的也是內容分發網絡。但是它關注的是密鑰管理方向。因爲當服務器部署了HTTPS時，如果再使用內容分發網絡，那麼密鑰也需要保存在邊緣節點上，這樣是不安全的，因此他設計了一個“Keyless CDN” 。

Introduction 介紹

1. 知識點：知名CDNS: Akamai、Cloudflare
2. 論文的現實背景：爲了解決這個問題，CDN會保存他客戶的密鑰——這會導致：他們可以僞裝，竊聽，或篡改所有的客戶，包括幾乎所有的世界主要銀行，網上商店，和許多政府網站；他們還會幫助它的客戶做好防火牆的工作，檢查SQL注入等，但是這種情況下需要信息是不加密的。
3. 論文解決的核心問題：HTTPS and CDNs are, in some sense, pathologically incompatible 病理上是不相同的。

Problem and Goals 問題和目標

CDN 內容分發式網絡

1. 在這裏，作者主要總結了CDN的作用：
   1. Low latency to clients 低延時，靠的是邊緣節點
   2. Manage customers’ keys 保管其客戶的私鑰
   3. Absorb DDoS traffic 通過過濾DDoS流量來保護他們的客戶
   4. Filter targeted attacks 在瞭解通信內容的前提下，做到WAF的功能；內容過濾策略。

Security Implications of CDNs CDNs的安全隱患

1. 安全隱患：It is therefore little surprise that CDNs have amassed thevast majority of private keys on the web. 因此，CDN積累了網絡上絕大多數的私鑰也就不足爲奇了； To protect their customers’ keys, some CDNs refuse to deployHTTPS content anywhere but at the data centers they havefull physical control over 爲了保護客戶的密鑰，某些CDN拒絕在任何地方部署HTTPS內容，但在數據中心，以便他們可以完全控制。

Our Goals 我們的目標是~

有五個：

1. 保護私鑰
2. 保護會話密鑰
3. 安全的web應用防火牆功能
4. 支持多租戶：能夠在一臺計算機（甚至同一臺Web服務器進程）上託管多個客戶，但它們之間具有強大的隔離性
5. 支持客戶的應用程序

Threat Models 攻擊模型

Honest but curious 就是使用CDN的客戶擔心流氓員工或管理員
Byzantine faulty behavior 就是在信任的CDNs邊緣節點中出現了背叛者

Prior Work 之前的工作

TEE-less Solutions 減少的可信執行環境方法

1. HTTP Solutions 主要就是將資源HASH一下，保證資源的完整性
2. TLS Solutions 這個方法就是改變了一下TLS使用的方法，可以保證服務器的私鑰不被泄露，但是會話密鑰會被泄露。
3. Cryptographic Solutions 用了完全同態加密，但速度很慢，違背了CDN的原始想法，而且不會支持遺留的應用程序目標。

Intel SGX (and Other TEEs)

1. SGX有一個Enclave領域保障了在這領域的環境內執行的安全性。現在的SGX還不能夠有網絡連接的功能
2. Running Legacy Applications on SGX
3. TEEs and Middleboxes 可信執行環境和中間件

Design設計

之前設計的缺陷：它們全部要麼完全缺乏多進程支持，要麼僅在受限環境中支持多個進程。 相反，我們希望能夠支持Web服務器，租戶配置和安全狀況的動態伸縮。
作者的工作：We first describe the conclave design, and then howwe compose them to build the first “keyless CDN,” Phoenix.

Conclaves Design

作者的工作是在Graphene的基礎上進行了進一步的拓展，因爲Graphene之前沒有安全、完整性的保障。Conclaves通過探究分佈式系統的本質來擴展現有設計。

Conclave Kernel Servers

Graphene是一個分佈式的enclaves，然後Conclave利用這個分佈式服務器的概念設計了具備不同功能的分佈式enclaves。分別是：

1. fsserver 用戶應用的文件管理系統接口
2. memserver 提供了一個用於創建，訪問，操作和鎖定共享內存的接口
3. keyserver 存儲私鑰並執行加密操作（這不僅保持了私有密匙相對於不受信任的主機的保密性，而且還將地址空間的密匙從應用程序中隔離出來，從而防止關鍵的內存泄露漏洞）
4. timeserver 使欺騙該安全區接受已過期證書的攻擊，因此SGX本身不提供trusted time

Phoenix Design (專屬於CDN的設計）

Phoenix 設計的核心是在保證客戶信息安全的情況下管理用戶的資產。

Bootstrapping Trust 引導程序地址

我們首先討論如何將conclave（視爲分佈式系統）建立每個成員節點的信任關係，就是圖中紅色的大框是怎樣爲黃色的小框框之間的聯繫建立信任通道——使用證書，就是分佈式的enclave需要向conclave證明自己的身份。

Provisioning Server and Provisioning Agents 配置服務器和配置代理

這裏講述了怎樣將客戶的祕密發送給Conclave——還是用了自簽名證書的方法。

Key Management

利用了剛纔所描述的服務器代理。將用戶的密鑰和證書祕密的傳送給CDN邊緣服務器的Conclave。

Deployment Scenarios (部署場景）

在本節，作者在之前“Phoenix的整個設計過程中，描述的單租戶，完全隔離的部署”的基礎上，討論了另外兩個潛在的部署。

1. Single-tenant, partially-enclaveddeployments 與之對應的是之前說過的Honest but curious。但是密鑰只有keyserver和配置代理所有，所以不必擔心。
2. Multi-tenant (沒太理解，就把翻譯放上來了）
   1. CDN操作員可以輕鬆地將代理服務器（例如HAProxy [64]）放在邊緣服務器上；
   2. 其次，如果應用程序有利於多路複用，則CDN運營商可以在一個飛地中運行該應用程序的實例，並且該應用程序的配置可以反映客戶分區。 每個客戶然後運行他們自己的內核服務器中心。 作爲示例，NGINX可以運行多個虛擬服務器。 每個虛擬服務器的資源都安裝在應用程序中的掛載點上，該掛載點指向每個客戶的相應內核服務器。
   3. 最後，內核服務器本身可以複用多個客戶的資源。 這些代表了不同的權衡：更多的複用可以增加攻擊面，但是需要更少的資源來實現高性能（SGX在給定CPU上的多個飛地之間切換時會產生大量開銷）。

Implementation 實施

Graphene SGX libOS

Kernel Servers

1. fsserver 作者開發了具有不同功能的三個服務器：

• bd-std 存放明文
• bd-crypt 存放密文，但是不能保證完整性
• bd-vericrypt 存放Merkle tree保證了完整性和保密性

2. memserver 作者將共享內存實現爲文件系統，這些文件系統實現了一組簡化的文件系統API

• sm-vericrypt-basic
• sm-vericrypt
• sm-crypt

3. keyserver keyserver由兩個部分組成：密鑰服務器本身，OpenSSL引擎
4. timeserver
   作者將Graphene系統調用處理程序修改爲時間，時間和時鐘獲取時間，以將代理應用程序調用以可選方式代理到遠程，受信任的時間戳簽名服務器。（我沒讀懂~）

Graphene Modifications

增加缺少的功能，提高性能

1. Exitless System Calls
   系統退出不動，這樣不用花銷昂貴的enclave退出和相關的內容切換。
2. BearSSL
   作者將BearSSL庫集成到Graphene中，以提供Graphene客戶端和內核服務器之間的TLS連接，並驗證時間服務器的響應。
3. File Locking System Calls

NGINX Modifications

1. Shared Memory Patch NGINX使用共享內存在服務HTTP（S）請求的工作進程之間協調狀態。爲了適應作者的設計，作者創建了一個小的補丁程序（約300行），該補丁程序更改了共享內存和相關聯的互斥鎖的創建。
2. Request Lifecycle
   當NIGNX用作緩存服務器時，默認情況下它將運行四個進程：（1）初始化服務器並響應軟件信號的主進程；（2）爲HTTPS請求提供服務的可配置數量的工作進程；（3）緩存管理器；以及 （4）一個緩存加載器。

6. Evaluation

這一節的目標是：

• 性能的評估
• 多租戶的情況下的表現
• 對WAF的影響
  作者研究了三種情況下的安全配置：
• Linux-keyless
• Graphene-crypt
• Graphene-vericrypt
  並與Nginx在Linux上運行做了比較

6.1 Standard ocalls vs. exitless

不是很懂到底在比較哪兩個。

6.2 Single-Tenant

6.3 Scaling to Multi-tenants

作者評估了兩種用於多租戶的方法：（1）共享虛擬化，其中每個客戶都運行自己的安全區，包括一個NGINX的安全區實例；以及（2）共享NGINX，每個客戶都運行自己的安全區的內核服務器，但是共享 NGINX的特定版本：NGINX配置文件可多路複用客戶資源。

圖4比較了這三個部署的平均延遲和聚合吞吐量，將經常性的數量從一增加到六。 在最初有兩個租戶參與之後，Linux能夠以適度的增長來增加吞吐量，以請求延遲。 共享的NGINX Graphene-crypt以增加的延遲爲代價來保持大致恆定的總吞吐量，而沒有共享的配置無法維持超過兩個租戶的吞吐量。

6.4 Web Application Firewall

對於正常的Linux和Graphene-crypt，它們都作爲獨立的非緩存服務器運行，我們增加了規則的數量，並觀察了對圖5中服務器HTTPS請求吞吐量和延遲的影響。 作者看到，僅啓用ModSecurity會導致Linux的吞吐量降低5％，而石墨烯加密的吞吐量降低16％。 在1000條規則下，Linux和Graphene-crypt的相對成本收斂，因爲每個端口的吞吐量是ModSecurity關閉時的吞吐量的2/3，並且延遲降低了1.5倍。 在10,000條規則下，這些相對成本將顯着增加，僅爲吞吐量的14％，而延遲是ModMod禁用時的7倍。

6.5 Micro-benchmarks

現在，我們評估Phoenixconclave的各個子組件，以對我們的性能結果提供更細粒度的解釋。

1. 遠程過程調用
   圖6顯示，一般而言，SGX產生的延遲開銷要比無出口高得多，但是隨着有效負載大小的增加，此差距會縮小，並且在1 MiB有效負載下，無出口實際上比正常調用更差。
   
2. Kernel Servers
   • fsserver
     圖7顯示了文件系統的每個變體的讀取延遲。與bd-std相比，bd-crypt增加了相對較小的開銷，而bd-vericrypt由於Merkle樹的查找而顯示了幾乎一個數量級的下降，這取決於樹的包內LRU緩存的大小
     

• fsserver
• keyserver
• timeserver

Conclusion

終於到這裏了！！！！！
真是戰戰兢兢的看完了，如果有一天我也能寫出來這個，畢業以後就不愁找不到工作了。這篇論文是把CDN的工作遷移到了SGX中做，不知道算不算舊工作，新場景。最開始讀以爲是一篇web論文，讀到後面才發現是做系統安全的。
我雖然給自己定義爲是Web安全，但是希望可以給自己定好一個大方向和一個小方向，小方向大概就是做系統安全的，爭取博士後期可以發一篇web和系統結合起來的論文，就像這篇一樣，足夠硬核。那麼我就無憾了！

To do list

• SGX的基本原理
• ModSecurity 想起來了 畢設用過！是用來加規則的！！
• 拜占庭容錯
• TEE trusted execution environmen可信執行環境
• web application firewalls web應用程序防火牆
• SSL拆分
• multiplexing 多路複用
• 事件驅動服務器
• 紅黑樹
• merkle tree 不止區塊鏈

單詞整理

1. pathologically incompatible 病理上是不相容的
2. distill down 提取
3. amass 積累
4. in short 簡而言之
5. overarching 非常重要的
6. Security Implications 安全隱患
7. multi-tenancy 多租戶
8. departure 背離
9. infer 推測
10. rogue 流氓
11. deviate 脫離
12. latency潛在因素
13. susceptible 易得病的人
14. enclave 領地
15. retrieve 恢復
16. paradoxically 自我矛盾的
17. reside 居住
18. replica 副本
19. coordinate 協調
20. encapsulates 壓縮