论文需要一个更有创新点的设计，一个没被解决的有隐私问题的场景，或是一个更高效的区块链与TEE交互的方式。

所以开看论文。

1 区块链互操作性的安全和隐私

跨链交换信息的过程中如何保证隐私和安全性。

互操作性概述

• 资产交换：

  l1：A1持有X，l2：A2持有Y

  l1：A2持有X，l2：A1持有Y

  资产与账本是绑定的，但是可以把其他账户的地址写到任意账本里。

• 资产转移：

  锁定-铸造、销毁-铸造

• 数据传输

互操作性依赖于底层的区块链。如果原区块链发生回滚等操作，就会让某些跨链数据不可信。

比如：

L1 锁定了资产 A，同时通过跨链协议让 L2 上铸造了一个资产A，但是之后 L1把锁定的操作回滚了。此时L2上的资产A就没有支持了。

跨链安全性和隐私模型

• 网络层

  基础，关心底层区块链安全。

  区块链本身不安全

• 协议层

  关注跨链协议设计，描述跨链操作的规则和机制

  设计的跨链协议有漏洞

• 实现层

  实现跨链协议的实际过程

  实现跨链协议的过程中有漏洞

• 操作层

  跨链系统的部署、升级、运行、监控等过程，如何在实际运行环境中保证安全性

安全性方法

• 可信第三方：由第三方全程管理跨链过程
• 分布式信任：不依赖于单一的第三方，而是依赖于一个外部网络
• 本地状态验证：链下的参与方仅负责将信息传递到目标链，而跨链交易的有效性是在链上验证的。
• 本地验证：本地验证方法依赖最终用户手动验证彼此在各自链上的交易。

进一步细分：

• 中心化：有一个第三方作为信息中继器，链1要向链2转账，先发给中继器，由中继器传递数据
• 可信计算：信息中继器不再是一个可信第三方，而是一个TEE，通过证明秘钥证明TEE可信
• 无许可网络：不再由单一的第三方（包括中心化和TEE），而是通过该分布式网络来验证
• 有许可网络：在无许可网络的基础上，验证者都是可信或有声望的实体。
• 包容性证明：要求用户提供可验证的证据，证明某个操作已经在另一个链上触发。依赖于区块链共识机制。
• 有效性证明：依赖于零知识证明。挑战在于生成证明的效率。
• 欺诈证明：交易数据可以立刻被接受，但是需要有一个外部观察者实时检查这些交易有没有问题，如果发现有问题则提交欺诈证明。即先接受，再证伪。前面都是先证明，再接受。
• 哈希锁和时间锁：双方预先约定一个哈希值，规定时间内交易才能被完成。

隐私属性

• 跨链不可链接性：外部无法推断出链1上的交易t1和链2上的交易t2是有关联的。
• 跨链匿名性：发起交易的账户不能与他发起的交易相关联
• 跨链交易数据保密性：攻击者不能以超过50%的概率猜测哪一个载荷对应哪个交易。

隐私保护方法

• 零知识证明

• 可信执行环境

• 适配签名（Adaptor Signatures）：

  适配签名是一种能够在不暴露秘密的情况下，验证消息和秘密的签名方案。通过这种方式，双方可以在不公开关键信息的情况下达成协议。尽管在某些情况下可能无法完全保证交易的不可链接性（例如，可以分析交易金额），但仍然能够在没有公开加密货币和汇率的情况下保持一定的隐私性。

• 盲签名（Blind Signatures）：

  盲签名的主要优势在于它能在不揭露具体内容的情况下对消息进行签名，从而保护用户的隐私。这使得跨链交易能够在保护参与方隐私的同时，保证交易的有效性，并且能防止第三方的监控或定制交易排序。

• 环签名（Ring Signatures）：

  环签名的特点是能在多个用户之间隐藏发件人的身份。这为跨链交易提供了匿名性，但也带来了一些挑战，特别是在问责制和交易追溯性方面。由于无法确定签名者的身份，这种方式可能会影响交易数据的透明度，尤其是当涉及到重要的身份验证时。

• 同态加密（Homomorphic Encryption）：

  同态加密技术允许在加密数据上进行计算，而不需要先解密数据。这在某些跨链交易场景中能够保证交易的隐私性。不过，这种技术通常会带来较高的计算成本，因此在实际应用中还需要优化以提高效率。

总结

这篇文章聚焦于跨链的安全和隐私，对我目前的研究没直接帮助。但是提供了一些通用的隐私保护方法和安全方法。

2 TEE辅助的机密智能合约

智能合约存在隐私问题，因为合约的状态和指令代码是公开的。TEE辅助智能合约，可以用于保护合约状态的机密性。

以投票举例：

• 投票者需要参与投票，但是不想暴露自己投票给了谁
• 投票者将自己的投票信息加密 $votedata \rightarrow c_u$ ，把加密后的信息添加到事务 $c_u \rightarrow T_x$
• 于此同时，区块链上存在加密的合约状态 $c_b$
• 节点处理这个交易时，需要把交易中的加密投票信息 $c_u$ ，和区块链上的加密合约状态发送给 TEE
• TEE 解密数据和合约状态 $c_u \rightarrow data$ ; $c_b \rightarrow m_b$
• TEE 在内部计算得到新的状态 $data, m_b \rightarrow m_b'$
• TEE 加密状态，返回给节点 $m_b' \rightarrow c_b'$
• 节点把加密后的新合约状态保存到区块链

系统化方法

分为一层解决方案和二层解决方案。

• 一层解决方案：合约执行都在区块链内的TEE中。
• 二层解决方案：在链下执行智能合约的计算。

TEE提供的隐私保护属性：

• 智能合约源代码对公众隐藏
• 输入隐私：输入到智能合约的数据对公众隐藏
• 输出隐私：智能合约输出的结果对公众隐藏
• 执行过程隐私
• 地址不可链接性：防止对手通过观察用户活动来学习地址之间的关联性。
• 地址匿名性：公众不知道谁调用了智能合约

威胁模型

• T1. 用户攻击者（主动/被动）：攻击者可能控制用户与TEE主机节点之间的网络。
• T2. TEE攻击者（主动/被动）：攻击者可能控制TEE主机或控制TEE与区块链平台之间的网络。
• T3. 区块链攻击者（主动/被动）：攻击者可能丢弃、修改或延迟区块链消息。但假设大多数（或三分之二）区块链节点是诚实的。

增强TEE主机安全性的方法

• P1. 主机惩罚机制：通过惩罚机制降低TEE主机作恶的风险。
• P2. 主机激励机制：通过激励机制促进TEE主机诚实行为。
• P3. 主机容错性：使系统能够在出现故障或失效时继续运行的解决方案。
• P4. 主机认证：检查TEE主机身份和能力的方法。

缓解TEE固有问题的对策

TEE存在不可避免的弱点。例如，TEE容易受到侧信道攻击。这些固有弱点对TEE辅助合约系统的设计和实现直接带来了严峻挑战。此部分定义了针对这些威胁的防御方法：

• P5. TEE证明安全性：防止TEE证明服务异常中断的方法。
• P6. TEE内存限制：优化内存大小以防止机密数据溢出的方法。
• P7. TEE物理攻击：防止物理攻击（如Spectre漏洞或Meltdown漏洞[57]）的方法。
• P8. TEE可信计时器：为TEE运行时提供可信计时器的方法。

防止TEE内部程序漏洞或缺陷的方法

即使TEE被假定为安全，程序漏洞可能会在现实世界中破坏合约的机密性。本部分重点关注防止TEE程序出现缺陷或漏洞的措施：

• P9. 工作负载测量：防止无限循环攻击的工作负载测量方法。
• P10. 缺陷检测：用于建模和验证智能合约源代码的形式化技术，以减少漏洞。
• P11. 用户查询限制：限制用户查询，以避免因差分隐私分析[58]导致的数据泄露。
• P12. 区块链数据确认：允许TEE检查来自区块链的输入数据是否已确认，以防止回滚攻击[59]。
• P13. TEE输出冲突：防止多个TEE产生冲突结果的方法。

解决TEE密钥安全困境的方案

合同执行中涉及多种密钥（详见附录A），包括用于状态加密/解密的TEE内部密钥（如证明密钥和TEE服务密钥）。由于服务密钥直接影响合约状态的保护，此SoK的密钥安全评估主要集中于TEE服务密钥的生成、交换和存储。

• P14. 分布式密钥协议：机密合约的密钥由分布式协议管理。
• P15. 密钥轮换协议：TEE用新密钥替换旧密钥以用于未来的合约加密。
• P16. 独立合约密钥：每个合约与一个独特密钥相关联，且独立于TEE。
• P17. 独立TEE密钥：每个TEE拥有一个独特密钥，不同合约共享相同的密钥。

一层解决方案

一层解决方案使区块链节点能够在其隔离区域内运行智能合约，同时进行共识操作（见图3）。该方法将共识过程和状态执行在逻辑或物理层面上结合在一起。之所以称之为“一层”方法，是因为所有的执行都在区块链网络的同一层完成。此方法的关键在于为每个区块链节点配备TEE。这确实需要更多的集成工作，但也带来了几个优势。智能合约可以实现接收参数并即时更新状态的有状态功能。尤其是，智能合约可以直接访问存储在本地磁盘上的账本数据，从而大大节省了通常浪费在交互式网络通信上的时间。

The smart contract can implement stateful functionalities that receive arguments and update states instantly.

优势：节省网络通信时间。

此外，我们注意到当前的一层解决方案仅关注内部过程，而忽略了地址和交易的可链接性以及匿名性。这表明保密智能合约只保护加载到TEE中的内容，而与外部用户相关的数据不在该方法的保护范围之内。

最后，我们分析 TEE 的密钥管理。在一层系统中，密钥管理服务负责为证明、验证、加密等活动创建和管理密钥。为了在分布式节点之间实现密钥管理服务，提出了几种设计。

CCF [45] 依赖于公共密钥基础设施 (PKI) 来处理证书的颁发、管理和撤销。它创建密钥对并将其分发给每个参与的 TEE，其中每个 TEE 持有者通过证书进行身份验证。

Fabric [60] 采用了一个管理员节点在启动期间为链码 enclave 提供特定的解密密钥。

Enigma [61] 设置了一个独立的密钥管理组件，用于响应加密请求。

这些设计有助于简化复杂的管理过程，同时为每个 TEE 提供独立的密钥。然而，即使这些独立的密钥管理服务由委员会中的一组节点维护，也会导致一定程度的中心化。

CONFIDE [37] 通过提出去中心化密钥管理协议缓解了这一问题。在此协议中涉及两种密钥：

1.用于解密来自客户端的保密交易的非对称私钥；

2.在保密引擎和存储服务之间用于状态加密/解密的对称状态根密钥。

至于漏洞检测，根据我们的观察，一层系统中尚未应用任何形式化技术或验证工具。这一空白需要进一步探索。

一层系统中没有对智能合约的漏洞检查。（截止2022年）通过提前的漏洞检查来预防智能合约可能造成的危害。

针对 Wasm 智能合约，可能更容易进行漏洞检查。原来需要分析各种不同的源代码，有了Wasm之后，直接分析目标代码Wasm即可。

flaw detection

C. 优缺点

一层解决方案为保密智能合约提供了一种高度集成的方法。这种方法（L1）保留了大多数区块链特性，例如高可用性、抗回滚攻击和去中心化执行，因为其合约工作流程、数据结构和使用模型与现有系统一致。一层解决方案为用户提供了一个一致的界面，无需改变用户从非TEE区块链系统转变过来的使用习惯。用户可以直接通过区块链界面使用一层系统，而无需考虑TEE和区块链之间繁琐复杂的操作。

然而，一层解决方案仍然面临一些常见的缺点：

1. 可信计算基（TCB）规模增大：最小化可信计算基（TCB）的规模有助于增强TEE的安全性[67]，特别是因为较小的TCB具有更少的错误，并能减少攻击面。

   然而，在L1解决方案中，合约执行和共识协议的复杂交互操作大大增加了TCB的规模。

2. TEE的安全内存限制：

   当前的TEE产品安全内存有限。例如，在Intel SGX [35]的当前实现中，Enclave页缓存被限制为128 MB，其中只有93 MB可用于应用程序。这限制了并发执行的能力。

3. 兼容性不足：

   一层解决方案缺乏与现有区块链系统的兼容性。该方案将共识过程和合约执行集成到同一区块链节点中，要求每个节点都必须配备TEE硬件。

   然而，这一要求难以在已经投入使用的公共区块链（例如以太坊[2]）中实现。

二层解决方案

疑问，二层和一层比能有什么优势？

智能合约和区块链共识解耦。

总结

列举了一层二层的区块链+TEE的解决方案，让我了解了哪些具体的隐私情况适合使用TEE。

论文里有很多现有方案，用于增强TEE的安全性，增强秘钥管理的安全性。

并且提供了一个关于智能合约漏洞检测的研究方向。（这两年应该已经有很多先例了，先继续看第三篇论文，之后查智能合约漏洞检测相关的内容）flaw detection

另一个想法，简单一点，结合数字身份，提出一个系统，利用TEE实现一个更安全、更保护隐私的系统。（感觉在水论文）

3 SGX 的攻击策略

一个大纲，各种硬件和系统层面的攻击策略，得先熟悉一点SGX才好看。目前没得到什么启发。

总结

之后还是得换个大方向：

一个方向是智能合约安全

一个方向是并行计算加速

可以先把群里那两篇论文看一下，然后去了解一下ethernaut

• 原来的出发点绝对有问题
  • 当时说智能合约 + Wasm + TEE，刚开始误把 Wasm 当成什么更先进的指令集能加速运算，实际上Wasm的性能是相对于原生Js有很大提升，和C/Rust这些相比是接近原生的性能，所以并不能依靠使用Wasm就提高合约执行效率。
  • Wasm+智能合约，本质上就是智能合约；TEE+智能合约，是智能合约安全与隐私；这是两个很独立的东西，我说的SC+Wasm+TEE，本质就是SC+TEE，Wasm并没有提供任何优势。
  • Wasm智能合约的优势可以是易于开发，易于再各个平台中执行，甚至是在TEE中执行。
  • 之前看的论文都是侧重智能合约安全，Wasm不能提供什么安全上的帮助
• 这几天去看了一些智能合约安全的基础知识，一些攻击智能合约的策略；
• 之后计划
  • 毕设继续做，我后续不要太强调Wasm，单纯通过TEE给数字身份系统提升隐私，还是可以的
  • Wasm再毕设里可以用于更方便的操作进行TEE操作，简化智能合约和TEE的操作。
  • 论文之前说的 SC + Wasm + TEE 实在有问题，这个出发点太强行了，当时不了解，现在算了解这是什么东西了
  • 之后要么我合约安全？要么做群里发的并行计算的加速；