私钥重置

---

上图所示是我们 2-3 默认方案的私钥重置时序图，需要 3 个参与方，分别为：User、Hot Server、Cold Server。整个 Resharing 生命周期携带唯一的 Session ID 标识单轮次信息。消息传递通过消息队列，采用了端到端加密，且通过 Token 鉴权确保了各方只能获取自己 Channel 的消息。Hot Server、Cold Server 是常驻服务，通过消息订阅可以随时接收信息。

Resharing 具体步骤如下：

1. 用户向服务端用户中心发起 Resharing 请求。
2. 服务端将用户账户设置为「重置中」状态，冻结所有设备的私钥操作，并返回成功响应。
3. 用户需要等待七天，以防恶意重置的发生。如非本人操作，可取消重置，并修改账户密码。
4. 七天等待期之后，用户中心通过特殊的安全渠道，携带用户登录邮箱、安全邮箱信息，向第三方冷库申请取回私钥。
5. 第三方冷库校验请求的合法性后，返回响应，并异步启动取回私钥的流程。经过TEE解密之后，将私钥拆分两部分，加密压缩之后，分别发送到用户的登录邮箱和安全邮箱。
6. 用户从登录邮箱和安全邮箱解压取出两部分私钥碎片，在重置页面上传，正式启动Resharing 流程。
7. 用户向服务端用户中心发起 Resharing 请求，获取 Session ID。
8. 服务端响应请求，生成 Resharing Session ID 并返回给用户。
9. 用户端向消息队列发送 Resharing 启动的广播消息，并携带 SessionID。同时，本地异步启动 Resharing 流程。
10. 消息队列收到发送消息请求，解析用户Token，并到用户中心鉴权是否合法。
11. 如果鉴权通过，说明是正常用户请求，反之是直接拒绝返回。
12. 消息队列将 Resharing 启动的消息广播到 Hot Server、Cold Server 订阅的 Channel，它们收到消息的同时，也相继异步启动 Resharing 流程。
13. 消息队列返回广播成功的响应，用户端启动 MPC 协议交互流程。反之，Resharing 异常。
14. 通过消息队列，User、Hot Server、Cold Server 进行多次 MPC信息交换。最后 Hot Server 将生成的私钥碎片 TEE 加密之后存入 DB，标记旧私钥失效。Cold Server 则 TEE 加密之后转交可信第三方冷库存储。Hot Server、Cold Server 分别广播 Resharing 结束信号。
15. 用户端需要确保收到 Hot Server、Cold Server 的结束信号，并且本地私钥也重置生成完毕。
16. 用户端采用 AES-256 将私钥碎片加密存储在本地。
17. 用户端将私钥重置结果以及新的私钥版本信息告诉服务端用户中心。
18. 服务端记录用户相应设备的私钥版本号，将账户设置为生效状态，返回成功响应，整个 Resharing 流程结束。