Skip to content

Smart Account(TEE 钱包)技术实现

本文档介绍 Smart Account 的技术架构,包括 TEE 机密计算原理、私钥安全上传、自动化交易签名等核心流程。Smart Account 是唯一实现服务端非托管钱包的方式。


一、什么是 Smart Account?

1.1 定义

Smart Account(SA)是一个 Web3 附加功能:允许用户将私钥上传到 TEE(可信执行环境),实现自动化策略交易。

1.2 为什么需要 Smart Account?

方案自动交易安全性合规性
客户端非托管钱包❌ 无法自动交易✅ 用户完全控制
服务端托管钱包✅ 可自动交易❌ 服务方控制私钥❌ 合规风险
Smart Account (TEE)✅ 可自动交易✅ TEE 内运行,服务方无法获取

核心价值:TEE 是唯一能实现"服务端运行但非托管"的方式。


二、机密计算与 TEE

2.1 机密计算(Confidential Computing)

问题:当应用在平台上处理机密数据时,数据是否会泄露?

攻击场景

  1. 恶意平台管理员
  2. 含恶意软件的操作系统
  3. 有后门的平台

数据保护全生命周期

阶段技术
处理中机密计算(Confidential Computing)
传输中TLS/SSL
存储时磁盘加密

2.2 TEE(Trusted Execution Environment)

定义:一个隔离的安全计算环境,平台保证其中代码和数据的机密性完整性

  • 机密性:数据不泄露
  • 完整性:代码正确运行(否则攻击者可能输错 PIN 却取走资金)

2.3 Enclave 架构

AWS Nitro

特性说明
无持久化临时性(Ephemeral),重启即清空
无网络只能通过 vsock 与宿主机通信
内存隔离AWS Hypervisor 禁止访问 Enclave 内存

Intel SGX

特性说明
内存加密数据传输到内存时加密
CPU级隔离Enclave Page Cache (EPC) 仅 enclave 代码可访问
防窥探操作系统和 hypervisor 均无法读取

2.4 如何验证 Enclave 中运行的代码?

  • 平台运营者:在 Enclave 中运行敏感操作,证明自身清白
  • 用户:通过 Attestation(远程证明) 验证代码和数据的完整性

三、核心术语

术语说明
TEE可信执行环境(AWS Nitro System)
市价单DEX 快交易,提交后尽快执行
策略单跟单、限价等慢交易,依赖触发条件
用户意图DEX 下单的 JSON 参数
用户意图签名端上本地私钥对用户意图签名
静默签名免弹出签名 UI,直接完成签名
TEE_IDSHA256(toLower(EVM-Address) + "platform-TEE")

四、安全通信架构

4.1 HPKE 加密信道(防中间人攻击)

安全保证:即使用户设备被恶意植入 VPN/CA 证书,只要 APP 未被篡改,私钥传输仍然安全。

sequenceDiagram
    participant Client as 客户端
    participant WS as Wallet Server
    participant TEE as TEE Enclave

    Note over Client,TEE: ① 建立信道阶段
    Client->>TEE: 信道创建请求
    TEE->>TEE: 生成【证明文件】<br/>(包含服务身份公钥)
    TEE->>WS: 【证明文件】
    WS->>WS: RSA私钥签名证明文件
    WS-->>Client: 证明文件 + RSA签名
    Client->>Client: 验证证明文件 + RSA签名
    Client->>Client: 解析出【服务身份公钥】

    Note over Client,TEE: ② 加密提交数据阶段
    Client->>Client: ETH私钥衍生出【用户身份钥对】
    Client->>Client: HPKE.Seal(私钥明文, 附属数据, 服务身份公钥)<br/>→ 密文 + 一次性HPKE密钥
    Client->>Client: RSA公钥加密密文 → 双重密文
    Client->>WS: 双重密文 + 附属数据 + HPKE密钥
    WS->>WS: RSA私钥解密 → 密文
    WS->>TEE: 密文 + 附属数据 + HPKE密钥

    Note over Client,TEE: ③ 解密数据阶段
    TEE->>TEE: HPKE.Open → 私钥明文
    TEE->>TEE: 保存私钥到内存

双重加密机制

  1. HPKE 加密:端到端加密,Wallet Server 无法看到明文
  2. RSA 加密:防止传输过程中被劫持

4.2 预埋公钥版本协商

客户端预埋多个版本的 RSA 公钥,通过协商机制选择双方都支持的版本:

# 客户端告知支持的版本
frontendPubkeyVersionList: "v4,v3,v2,v1"

# 后端选择使用的版本
frontendPubkeyVersionSelected: "v3"

如果所有版本都不可用 → 提示用户强制升级。

4.3 TEE 服务调用鉴权

使用 HMAC-based API 签名认证:

消息格式: METHOD=xxx&&PATH=xxx&&TIMESTAMP=xxx&&BODY_SHA256=xxx
签名方式: HMAC-SHA256(signSecret, message)
头部注入: X-Signature + X-Timestamp

五、核心生命周期

5.1 激活 Smart Account

sequenceDiagram
    participant Client as 客户端
    participant WS as Wallet Server
    participant TEE as TEE Enclave

    Client->>Client: 使用EVM私钥签名消息<br/>(hash(hpke), accountId, 有效期, teeId)
    Client->>WS: 上传 HPKE加密的私钥 + 签名串
    WS->>WS: ① 验签 ② 对比TEE_ID
    WS->>TEE: 请求创建 TEE 账户
    TEE->>TEE: HPKE解密获取私钥
    TEE->>TEE: 存储私钥到内存
    TEE-->>WS: 创建成功
    WS->>WS: 标记为开启状态 + 记录更新时间
    WS-->>Client: 升级成功

激活条件

  • 必须是助记词钱包(非私钥导入)
  • 必须已备份

5.2 续期

sequenceDiagram
    participant Client as 客户端
    participant WS as Wallet Server
    participant TEE as TEE Enclave

    Client->>Client: EVM私钥签名续期消息
    Client->>WS: 续期请求 + 签名串
    WS->>WS: 验签 + 对比 TEE_ID
    WS->>TEE: 请求续期
    TEE->>TEE: 验签 + 修改过期时间
    TEE-->>WS: 续期成功
    WS-->>Client: 成功

5.3 过期处理

graph TB
    A[签名请求到达TEE] --> B{检查有效期}
    B -->|未过期| C[正常签名]
    B -->|已过期| D[拒绝签名]

    E[TEE定时任务] --> F[扫描过期TEE_ID]
    F --> G[删除对应私钥数据]

    H[数仓定时任务] --> I[扫描即将过期用户]
    I --> J[推送通知]

5.4 关闭 Smart Account

sequenceDiagram
    participant User as 用户
    participant Client as 客户端
    participant WS as Wallet Server
    participant DEX as DEX Server
    participant TEE as TEE Enclave

    User->>Client: 确认关闭
    Client->>User: 提示生物识别
    User->>Client: 生物识别通过
    Client->>Client: 对明文msg签名
    Client->>WS: 请求关闭 + 签名
    WS->>WS: 验签 + 对比TEE_ID
    WS->>TEE: 请求删除私钥
    TEE->>TEE: 验签 → 删除私钥
    TEE-->>WS: 删除成功
    WS->>WS: 标记关闭状态
    WS->>DEX: 通知暂停存量订单
    WS-->>Client: 关闭成功

六、交易签名流程

6.1 市价单(快交易)

sequenceDiagram
    participant User as 用户
    participant DEX as DEX前端
    participant Client as 端上钱包
    participant DServer as DEX后端
    participant WS as Wallet后端
    participant KYS as KYS服务
    participant TV as TEE验证服务
    participant TEE as TEE签名服务

    User->>DEX: 下单
    DEX->>DEX: 构建订单参数
    DEX->>Client: 订单参数(用户意图)
    Client->>Client: 签名用户意图
    Client-->>DEX: 签名结果
    DEX->>DServer: [订单参数, 签名]
    DServer->>DServer: 构建 calldata
    DServer->>WS: 交易结构体
    WS->>KYS: 交易检查
    KYS-->>WS: 检查通过
    DServer->>TV: [订单参数, 签名, 待签名交易]
    TV->>TV: ① 验证参数签名<br/>② 交易意图检查
    TV->>TEE: 签名交易
    TEE-->>TV: 签名结果
    TV-->>DServer: 签名结果
    DServer->>WS: 广播
    WS-->>DEX: 上链状态

6.2 策略单(慢交易)

sequenceDiagram
    participant User as 用户
    participant Client as 端上
    participant DServer as DEX后端
    participant WS as Wallet后端
    participant TEE as TEE

    User->>Client: 下策略单
    Client->>User: 生物识别
    User->>Client: 识别通过
    Client->>Client: 签名策略单参数
    Client->>DServer: [策略单参数, 签名]
    DServer->>WS: 验证签名
    DServer->>DServer: 保存策略单

    Note over DServer,TEE: 触发时执行
    DServer->>DServer: 组装待签交易
    DServer->>TEE: [策略单参数, 签名, 待签交易]
    TEE->>TEE: ① 验签 ② 验有效期<br/>③ 校验交易与下单参数一致
    TEE->>TEE: 签名交易
    TEE->>WS: 签名结果
    WS->>WS: 广播上链

关键安全校验

  • TEE 验证用户意图签名
  • TEE 验证订单有效期
  • TEE 校验待签交易与下单参数一致性(防止服务方签署任意交易)

七、Enclave 间私钥同步

由于 Enclave 无持久化,多个 Enclave 实例间需要同步私钥:

graph TB
    E1[Enclave 1] -->|"KEK加密私钥"| DB[(数据库)]
    DB -->|"加密的私钥"| E2[Enclave 2]

    E1 <-->|"KEK传输<br/>(需互相验证程序一致)"| E2
步骤说明
1用 KEK(密钥加密密钥)加密私钥,密文存入 DB
2KEK 在 Enclave 间直接传输
3发送方 Enclave 确认接收方运行相同程序
4接收方 Enclave 确认发送方运行相同程序

关键问题:双方必须互相确认对方运行相同程序,否则 KEK 可能被泄露。


八、TEE_ID 生成规则

TEE_ID = 0x + 小写hex(SHA256(toLower(EVM-Address) + "platform-TEE"))

示例

  • EVM Address: 0x3F8fcfbfb78c03b3f19c8679f0a50896146ac3b8
  • TEE_ID: 0x9b4066090c8d5382e88f499d3784aa33ec495128f51b78f78a8bf158bcea2522

特点

  • 助记词导入后跨设备 accountId 不同,但 TEE_ID 相同
  • 保证同一钱包在不同设备上能识别为同一 SA

九、前端关键功能

9.1 功能入口

入口说明
钱包首页 Banner展示 SA 状态,未升级可跳转激活
钱包管理页添加 SA 账户
钱包详情页查看 SA 状态
DEX 引导弹窗DEX 内引导开启 SA

9.2 SA 状态展示

状态颜色说明
TEE 开启(正常)🟢 绿色正常使用中
TEE 开启(即将过期 ≤7天)🟠 橙色提醒续期
TEE 关闭/过期⚪ 灰色需要重新激活
未开启 SA-展示升级引导

9.3 DEX 交互方法

javascript
// 检测 SA 状态
window.wallet.checkSmartAccountStatus()
// 返回: { teeId, needUpgrade, isActive, expiryTimeStamp, saChainList, supportedChainList }

// 管理 SA(激活/续期/升级)
window.wallet.manageSmartAccount({
    actionType: 'enable' | 'renew' | 'upgrade',
    upgradeChainList?: []
})

十、后端安全机制总结

graph TB
    subgraph "安全层次"
        L1[传输层安全]
        L2[身份验证]
        L3[计算安全]
        L4[数据安全]
    end

    L1 --> L1a[HPKE 端到端加密]
    L1 --> L1b[RSA 二次加密]
    L1 --> L1c[预埋公钥版本协商]

    L2 --> L2a[EVM 私钥签名验证]
    L2 --> L2b[TEE_ID 对比]
    L2 --> L2c[HMAC API 鉴权]

    L3 --> L3a[AWS Nitro Enclave]
    L3 --> L3b[私钥仅存于内存]
    L3 --> L3c[Attestation 远程证明]

    L4 --> L4a[KEK 加密同步]
    L4 --> L4b[自动过期清理]
    L4 --> L4c[KYS 交易检查]

总结

Smart Account 通过 TEE 机密计算实现了"服务端运行但非托管"的钱包方案,核心安全保证包括:

  1. HPKE + RSA 双重加密:私钥传输端到端安全
  2. AWS Nitro Enclave:私钥仅存于隔离内存,无持久化
  3. Attestation:用户可验证 Enclave 运行正确代码
  4. 用户意图签名:TEE 验证每笔交易与用户意图一致
  5. 自动过期机制:私钥有有效期,过期自动清理

这使用户在保持非托管安全性的同时,获得了自动化策略交易能力。