大概了解SGX以后，SGX应用有哪些？

第一种，SGX应用于服务器端，云端

这一类个人觉得很需要结合代码、它们所描述的行业需求和以前的行业产品去考虑问题，毕竟是应用，不然可能体会不到精髓。

我对SGX应用的理解也停留在表层，就是他们拿SGX大概做了个啥，但是有些细节，我目前也说不太上来。

DelegaTEE(SEC’18) Siniša Matetić (ETH Zurich)下一篇也是他

以前Alice（Owner）想将自己部分Paypal中的资产给Bob（Delegatee），需要将账户密码交给对方，这很不安全。（我们不考虑钱能直接通过转账，因为有的资产并不像转账那样可以简单实现，那样单纯是金额的加减。我们讨论的是一大类授权的问题）。

那么现在用上一个凭证和对凭证以及用户身份信息验证的一个服务器Brokered System。Brokered System能够根据Alice具体将多少资产以怎么样的形式分享给Bob这件事生成凭证，并且凭证一方面分享给Bob，另一方面储存在服务器中，Bob登录服务器后，证明自己是Bob，并且把凭证给服务器一看，服务器觉得OK并且Bob想用掉这笔资产的时候，服务器就让Paypal去完成比如支付Money的操作，可以看到验证的事情被放到了Brokered System服务器上面去做，Paypal直接和Brokered System合作，而不再和用户直接接触。带来的好处是什么呢？是Paypal和Bob、Alice之前不需要互相信任，再无瓜葛，只需要信任Brokered System即可。这里可能看起来是一个妖异的设定：我的理解是因为本来Paypal没有这个功能，Brokered System作为第三方模块来实现这个功能，想尽办法完成这种类似可信红娘的牵线工作。

那么我们似乎还没说到SGX。我们可以看到这时Brokered System中凭证的存储、验证、使用非常敏感，同时Alice和Bob的个人信息也需要被严格保护，作者就想到使用SGX来对这个服务器来进行保护。所以这里应该来说时SGX在服务器端的简单尝试，更多的是授权的内容，但是授权的方式已经就有类似的（Kerberos系统也是授予ticket，和使用ticket的模式），所以它讨论的亮点还是SGX的应用，难度可能在于SGX的开发并且做成一个实际产品。

这篇论文通过视频看的，可能理解不到位，有错误欢迎反馈。

BITE(SEC’19) Siniša Matetić (ETH Zurich)上一篇也是他的

区块链中，我们知道手机等资源有限设备是不可能承载一个区块链的完全节点，所以手机上一般都是轻节点，并且轻节点是根据需求向完全节点申请当前涉及的区块等信息。但是Light Node向Full Node请求地址对应内容时，Full Node势必要知道你所请求的啥，导致信息泄露。之前有个Bloom Filter试图通过一个类似哈希表（或者是个承载多个对等数据单元的数据结构）并且模糊化访问这个数据结构的过程来解决这个信息泄露的问题，但是作者说共享Bloom Filter依然会导致信息泄露（Bloom Filter这一块我只是大概听说过，不了解）。

那么有了SGX这个东西，作者就利用SGX内部部署Full Node端用来接收Address请求的模块，这样部署在服务器上也不用担心Ring0攻击者的迫害了。所以本质也是SGX对原有产品的改进。此外有一些细节是说：通过Scan Window或者ORAM来返回结果值，为了保证SGX执行中的侧信道问题。ORAM已经有挺多论文用来防止访存侧信道问题，后面也会提到（【写到后面时把名字贴上来】）。现实中，走路时拐七绕八的方式让陌生人不知道我们具体要去哪里。你可能说，陌生人会看到我们最终进入哪个建筑，那么如果说有那么一个传送门，进的看起来是A建筑，实际传送到了B建筑，（这是通过查表转换实现），那么陌生人就只能犯糊涂了。这里需要知道的就是说ORAM可以通过类似上述方式让攻击者无法得知受害者的访存情况。

可以看到目前SGX应用在某些知名产品上，对原有模块的替换或改进，会受到大家很大的关注。

EnclaveDB(S&P’18)微软和伦敦帝国学院合作的

数据库DB可以说是大部分产品都要依赖的东西，计算机世界基础中的基础。但是现在服务器里面大家都考虑Ring0攻击者的威胁了，那么DB里面的资料可不能让Ring0攻击者偷取，因为人们对于敏感信息的保密要求是越来越高。以前有通过加密方式的DB，加密的方式效率低，这个可想而知，加密算法固有的缺陷。

那么服务器有了SGX，我们就干脆将部分敏感的数据库放入Enclave，通过SGX而不是加密方式来保证安全，同时通过完善的日志记录模式和事务备份恢复来保证完整性。上图蓝色是可信的部分，客户端默认是可信的，一般用户自己不会坑自己，这里不考虑自己电脑被攻击了，只考虑服务端有Ring0攻击。第一步，我们在右上角的东西比如可信DB、预编译的Stored Procs会被通过签名加密等安全措施，被部署到服务器端的Enclave。第二步，其他客户端申请查询请求时候，通过自己的Client库通过左边Host Process间接和Enclave搭上勾并进行真正的查询操作。

这一篇从视频上来看，它告诉我们SGX应用要考虑部署和使用两件事。

小结

上图是CCS’17上一位大佬讲的SGX服务端应用的论文列表（部分文章其实也可以归于SGX Shield Framework类，后面单独拎出来），和我随机看的那几篇有交集。但是我有一个明确的感受就是，想要做SGX应用，得有原来那种产品的很清楚的了解，我光看视频没法深入理解SGX应用的真正意义。以后若有需求会去看论文或者相关的代码框架。

不过总的来说，SGX应用是真正体现SGX价值的地方，现阶段的SGX应用可能思路上简单（实现可能也复杂），但是这将代表SGX这项技术是有意义的。并且服务端的SGX应用你需要考虑SGX应用部署和使用两件事。

另外值得一题的是，我们多多少少可以看出SGX是同态加密的一个好的替换品。同态加密是通过密码学的方法让你无法感知（秘密+秘密=秘密）这个过程，而SGX就是在保险箱里面完成（秘密明文+秘密明文=秘密明文）的工作，明文算起来就很快。

第二种，应用于客户端

这一块的内容相对少一些，目前大家所能想到的就是比如游戏开发商在下放游戏许可证等版权信息的时候，那么就用SGX内部来保存版权信息，你想玩游戏，得通过SGX内部版权信息的验证。但是我觉得这一点上，可能对于很强的逆向工程高手来说，可能无意义，因为逆向工程逆向的是代码，SGX内部的敏感数据显得不重要了。除非游戏里面的部分关键代码也在SGX里面（个人猜测，正常情况下，Enclave代码是公开可见的，SGX保护的是代码完整性，SGX保护的机密性是隐私数据的机密性，不过也有论文是能够将Enclave代码秘密地加载到SGX中），那么逆向工程会变得极其困难。

这张图大概展示了客户端SGX应用的大概样子，主要我个人对OTP不懂，所以不太好阐述，但是我们可以看到这个框架就是客户端SGX和开发商之间有安全授权、配置的过程，那么Enclave可以看作开发商的飞地了（可以联想领事馆这个概念）

第三点，SGX应用于分布式客户端

这类的论文和工作也不多，主要可能大家想法有限。我自己有一个想法就是分布式SGX客户端下，我们可以将服务端的某些贴近客户端的部分功能（或者全部功能）给移到客户端来降低服务端的攻击范围和单点失效问题。有一点像客户端冗余来弥补服务端单点的种种问题。

分布式SGX可能的应用模式

有了SGX，我们可以将中心化任务做成分布式，而不用担心分布式客户端上的用户会故意不按照预期流程执行，因为SGX已经不能被Ring0攻击了。这有点像我有个公司，我把我们公司的会计、法务都给派到了顾客家里，而且这会计和法务是绝对忠诚的。

以前也有分布式相关的工作，但是方式都通过加密、冗余备份来实现可靠性。而我们通过SGX先天提供可信执行环境，那么就不再需要加密、冗余备份的操作，而且将流程化简，功能性和扩展性也可以很好的提升。因此又体现了：SGX是加密方案的高效替代品。

中心化任务分布式程度理论上是可以调节的，就是具体有多少模块贴近客户端。借此我们可以可以根据分布式SGX的计算资源和存储资源的多少来进行一个具体的中心化任务分布式程度的界定。

其实上述这种抗Ring0攻击的Enclave其实不单单只有SGX可以做到，还有其他SGX的小伙伴也能。有一篇【SecTEE】讲的是Trust Zone下提供Enclave的概念，它里面说只要提供隔离机制的CPU均有望实现Enclave。

上面大概讲了下SGX分布式应用的一种可能模式，那么具体的可能可以用于分布式存储、分布式计算、分布式授权。

有一个功能这里也值得一提，【VC3、SGX-Shield】能够做到Enclave代码隐蔽载入Enclave内存（通过远程载入具体代码），或者我想有可能本地Enclave代码加壳也能够做到Enclave代码保密的效果【目前可能尚未实现】（但是一般来说代码加壳可以抗静态分析，能否抗动态分析尚不清楚，而且可能有赖于具体实现）。对此我想利用的点是说，可以将Enclave代码对分布式客户端隐藏，就是悄悄地带入分布式客户端的SGX内，避免不必要的Enclave代码公开。

现在，我们再考虑分布式客户端会有Enclave被开、关、重启的情况，为了保证Enclave内数据在不同时间段依然一致且有效，可以通过密封操作来保证状态连续性。目前密封操作有回滚攻击的危险。对此，密封操作的抗回滚方案有【SGX Monotone Counter、ROTE……】。

单独考虑分布式授权案例，将授权和验证的功能（相当于公司工作人员）派到客户端。为了防止分布式SGX某个节点被攻陷然后对全局产生危害，那就依然可以采用中心化+分布式相结合的方案，也就是说有多少功能下放到分布式SGX的程度进行考量（比如分布式SGX节点只被赋予有限的权限，但也能很大程度满足正常验证需求，使得攻击者攻破分布式SGX节所能获得的权力有限）。

最后，审计的需求、日志的维护可以参考【EnclaveDB、ROTE】的做法。此外，日志管理细节上可以做冗余备份，然后借鉴Counter【SGX Monotone Counter、ROTE……】实现一致性维护。