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 介绍
- 知识点:知名CDNS: Akamai、Cloudflare
- 论文的现实背景:为了解决这个问题,CDN会保存他客户的密钥——这会导致:他们可以伪装,窃听,或篡改所有的客户,包括几乎所有的世界主要银行,网上商店,和许多政府网站;他们还会帮助它的客户做好防火墙的工作,检查SQL注入等,但是这种情况下需要信息是不加密的。
- 论文解决的核心问题:HTTPS and CDNs are, in some sense, pathologically incompatible 病理上是不相同的。
Problem and Goals 问题和目标
CDN 内容分发式网络
- 在这里,作者主要总结了CDN的作用:
- Low latency to clients 低延时,靠的是边缘节点
- Manage customers’ keys 保管其客户的私钥
- Absorb DDoS traffic 通过过滤DDoS流量来保护他们的客户
- Filter targeted attacks 在了解通信内容的前提下,做到WAF的功能;内容过滤策略。
Security Implications of CDNs CDNs的安全隐患
- 安全隐患: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 我们的目标是~
有五个:
- 保护私钥
- 保护会话密钥
- 安全的web应用防火墙功能
- 支持多租户:能够在一台计算机(甚至同一台Web服务器进程)上托管多个客户,但它们之间具有强大的隔离性
- 支持客户的应用程序
Threat Models 攻击模型
Honest but curious 就是使用CDN的客户担心流氓员工或管理员
Byzantine faulty behavior 就是在信任的CDNs边缘节点中出现了背叛者
Prior Work 之前的工作
TEE-less Solutions 减少的可信执行环境方法
- HTTP Solutions 主要就是将资源HASH一下,保证资源的完整性
- TLS Solutions 这个方法就是改变了一下TLS使用的方法,可以保证服务器的私钥不被泄露,但是会话密钥会被泄露。
- Cryptographic Solutions 用了完全同态加密,但速度很慢,违背了CDN的原始想法,而且不会支持遗留的应用程序目标。
Intel SGX (and Other TEEs)
- SGX有一个Enclave领域保障了在这领域的环境内执行的安全性。现在的SGX还不能够有网络连接的功能
- Running Legacy Applications on SGX
- 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。分别是:
- fsserver 用户应用的文件管理系统接口
- memserver 提供了一个用于创建,访问,操作和锁定共享内存的接口
- keyserver 存储私钥并执行加密操作(这不仅保持了私有密匙相对于不受信任的主机的保密性,而且还将地址空间的密匙从应用程序中隔离出来,从而防止关键的内存泄露漏洞)
- 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的整个设计过程中,描述的单租户,完全隔离的部署”的基础上,讨论了另外两个潜在的部署。
- Single-tenant, partially-enclaveddeployments 与之对应的是之前说过的Honest but curious。但是密钥只有keyserver和配置代理所有,所以不必担心。
- Multi-tenant (没太理解,就把翻译放上来了)
- CDN操作员可以轻松地将代理服务器(例如HAProxy [64])放在边缘服务器上;
- 其次,如果应用程序有利于多路复用,则CDN运营商可以在一个飞地中运行该应用程序的实例,并且该应用程序的配置可以反映客户分区。 每个客户然后运行他们自己的内核服务器中心。 作为示例,NGINX可以运行多个虚拟服务器。 每个虚拟服务器的资源都安装在应用程序中的挂载点上,该挂载点指向每个客户的相应内核服务器。
- 最后,内核服务器本身可以复用多个客户的资源。 这些代表了不同的权衡:更多的复用可以增加攻击面,但是需要更少的资源来实现高性能(SGX在给定CPU上的多个飞地之间切换时会产生大量开销)。
Implementation 实施
Graphene SGX libOS
Kernel Servers
- fsserver 作者开发了具有不同功能的三个服务器:
- bd-std 存放明文
- bd-crypt 存放密文,但是不能保证完整性
- bd-vericrypt 存放Merkle tree保证了完整性和保密性
- memserver 作者将共享内存实现为文件系统,这些文件系统实现了一组简化的文件系统API
- sm-vericrypt-basic
- sm-vericrypt
- sm-crypt
- keyserver keyserver由两个部分组成:密钥服务器本身,OpenSSL引擎
- timeserver
作者将Graphene系统调用处理程序修改为时间,时间和时钟获取时间,以将代理应用程序调用以可选方式代理到远程,受信任的时间戳签名服务器。(我没读懂~)
Graphene Modifications
增加缺少的功能,提高性能
- Exitless System Calls
系统退出不动,这样不用花销昂贵的enclave退出和相关的内容切换。 - BearSSL
作者将BearSSL库集成到Graphene中,以提供Graphene客户端和内核服务器之间的TLS连接,并验证时间服务器的响应。 - File Locking System Calls
NGINX Modifications
- Shared Memory Patch NGINX使用共享内存在服务HTTP(S)请求的工作进程之间协调状态。为了适应作者的设计,作者创建了一个小的补丁程序(约300行),该补丁程序更改了共享内存和相关联的互斥锁的创建。
- 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的各个子组件,以对我们的性能结果提供更细粒度的解释。
- 远程过程调用
图6显示,一般而言,SGX产生的延迟开销要比无出口高得多,但是随着有效负载大小的增加,此差距会缩小,并且在1 MiB有效负载下,无出口实际上比正常调用更差。
- Kernel Servers
- fsserver
图7显示了文件系统的每个变体的读取延迟。与bd-std相比,bd-crypt增加了相对较小的开销,而bd-vericrypt由于Merkle树的查找而显示了几乎一个数量级的下降,这取决于树的包内LRU缓存的大小
- fsserver
- 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 不止区块链
单词整理
- pathologically incompatible 病理上是不相容的
- distill down 提取
- amass 积累
- in short 简而言之
- overarching 非常重要的
- Security Implications 安全隐患
- multi-tenancy 多租户
- departure 背离
- infer 推测
- rogue 流氓
- deviate 脱离
- latency潜在因素
- susceptible 易得病的人
- enclave 领地
- retrieve 恢复
- paradoxically 自我矛盾的
- reside 居住
- replica 副本
- coordinate 协调
- encapsulates 压缩