跳到主要内容

概述



当我们考虑做一款 OnChain 钱包的时候，首先要清楚我们的用户是谁，我们要解决什么问题。区块链技术发展多年，尽管已获得一定程度的普及，但距离普通大众还很遥远，究其根本还是缺乏安全易用的钱包入口，方便大家随时随地进入web3.0 世界。



因此，回答以上两个问题：

Q: 我们的用户是谁？

A: 我们的目标用户是因缺少专业技能而被区块链门槛挡住的普通大众。

Q: 我们要解决什么问题？

A: 回答这个问题，必须清楚现在 OnChain 钱包的最大痛点，即私钥或助记词管理。在区块链世界，私钥控制着一切，一旦丢失或被盗，意味着资产的永久性损失，这对于普通大众是难以承受的。我们希望做一个无需担心私钥安全、去中心化、简单易用，像 web2.0 一样体验的产品。用户只需登录网站，即可畅玩区块链。



基于以上考虑，我们选择了 MPC (Secure Multi-Party Computation) 技术，它可以实现 TSS (Threshold Signature Scheme)，即分布式密钥生成和交易签名。



这样做有几个好处：

  1. 私钥无单点故障：每个参与者只拥有部分私钥碎片。从创建账户到签名交易，完整的私钥在整个生命周期都从未存在过，彻底消除私钥被盗风险。

  2. 更好的隐匿性：传统 OnChain 多重签名会损害隐私，因为有关签名者的信息也必须在区块链上传输。在 TSS 中，签名者信息被包含在普通交易中，降低成本的同时保持了机密性。

  3. 更低的复杂性：传统 OnChain 多重签名是特定于区块链的，必须为每个区块链重新实现，并且在某些情况下根本不支持。而 TSS 依赖于纯加密技术，完全屏蔽了不同链的异构设计。

  4. 更高的安全性：TSS 支持私钥轮换，无需更改区块链上相应的公钥和地址即可更新私钥碎片。这种结构为安全性增加了一个临时的维度，单点私钥丢失或泄露，可重置找回，而攻击者必须在私钥旋转前，同时攻破多个私钥设备。



接着是 TSS 体系结构的确定，即私钥拆分几个碎片，分别由谁保管。通常来讲，私钥拆分越多，安全性更高，但同时性能折损也越大。比如：5-8 结构，每次签名都需要 5 个参与方同时在线实时交互，易用性和性能大打折扣。而更少的拆分则会降低安全性，比如：2-2 结构，双方必须做好充足的备份，一旦丢失，仅凭另一方也无法重置找回。我们在安全和易用方面做了一个 trade-off，即 2-3 架构，私钥拆分 3 个碎片，签名只需其中 2 个参与方在线交互。



而私钥由谁保管，我们提供 2 个方案：

  1. 默认方案：用户、OpenBlock、可信第三方。对于普通大众来说，自己持有 1 个碎片， 配合 24 小时在线的 OpenBlock 服务，可以随时随地完成签名。而第 3 碎片由可信第三方冷库存储，我们会尽量选取有公信力的机构，它们只负责存储，无法解密。用户随时可以申请取回第 3 碎片，比如用户端私钥丢失需要重置的场景。以下图示是默认方案签名过程的简单展示，仅供参考。

  2. 升级方案：用户设备1、OpenBlock、用户设备2。对于专业用户，需要保持第三方的零信任，且具备一定的安全备份能力。那么，在自己多个设备分持 2 个碎片是更好的选择。（Coming soon..）




安全是根本，易用是体验。没有安全守护，一切都无从谈起。上述介绍了我们的私钥安全形态，下面介绍工程实现方面的一些安全考量。



基础设施安全​

  1. 我们选择 AWS 部署服务，他们的安全和数据隐私控制已定期获得合规性证明和验证，并在推动建立世界级安全基础设施方面不断创新，这在业界是众所周知的。另外，可靠性、可用性也是我们的主要考量，从容器服务到密钥管理服务，AWS 提供超过 99.9% 的正常运行时间，这是我们为客户提供稳定服务的基础。

  2. 网络环境隔离，我们在虚拟私有云 (VPC) 中部署服务。每个环境（dev、uat、prod）都有一个专用的 VPC，除了 VPN 的 VPC 之外，VPC 之间不允许通信。在 VPC 中，我们将网络分为公共子网和私有子网。公共子网中的服务可供全世界访问，而私有子网中的服务则不能。这使我们能够在专用网络中部署核心业务逻辑并保护这些服务免受 Internet 的影响。

  3. 实时入侵检测，我们分析我们所有的 VPC 日志、DNS 日志和服务日志，以检测威胁和任何未经授权的访问。我们会持续监控流量并在需要时采取行动。



通信安全​

传统互联网 API 交互，抓包即可拿到请求参数及响应数据。参数纂改、SQL 注入、重放攻击屡见不鲜，这在金融属性产品中是不可接受的。通信安全非常重要，特别是涉及用户隐私和私钥相关的信息，稍有不慎就会被不法分子盗用。在工程实践中，我们做了以下工作：

  1. 通信使用 https

  2. 请求签名，防止参数被篡改

  3. 身份确认机制，每次请求都要验证是否合法

  4. APP 中使用 ssl pinning 防止抓包操作

  5. 对所有请求和响应都进行加解密操作，详情参见「网关加密」章节




执行环境安全​

为了进一步提升安全级别，以及可能的内部作恶，我们的私钥生成、签名、重置、加密、解密等敏感操作全部在 TEE (Trusted Execution Environment) 中执行。TEE 是在芯片层面单独划分出来的一个隔离空间，建立与本地操作系统并行运行的隔离执行环境，保证加载到内部的代码和数据在机密性和完整性方面受到保护，保护敏感代码和数据免受来自本地操作系统潜在漏洞的特权攻击。更多细节请参见「可信计算环境」章节。