Internet Identity（II）的设计和实现：第一篇

本期概要

对于初学 IC 的开发者来说，Internet Identity（II）比较难以理解，所以我想写几篇文章尽可能简洁的介绍清楚 II 的设计和实现。

这篇文章先介绍一下 Internet Identity（II）整体上的一些设计，具体的实现放在下一篇。

II 的设计目标主要是：

1. 屏蔽掉私钥/公钥等技术概念，不让用户接触它们，且更安全

2. 用户登录不同的 DApp 有不同的身份，解决隐私问题

3. 用户登录 DApp 有过期时间，在一段时间内有效

另外，一个必须的基础是服务端永远不保存私钥。

第一个目标，II 是如何设计的呢？

主要是 Anchor、设备、助记词 这三个方面。

a. 关于 Anchor

Anchor 就是一个数字，也叫做 User Number。

Anchor 可以理解为 用户 的 ID，它在 II 智能合约中是一个索引，可以根据 Anchor 查出来用户的设备信息。

Anchor 是自增的。

b. 关于设备

II 抽象出来了「设备」的概念，即 Anchor → 设备 → 私钥/公钥，有了设备这一层，用户不需要去关注私钥/公钥，只要关注设备就足够了。

设备的特点如下：

1. 一个 Anchor 可以增加多个设备

2. 每个设备都有自己独立的 私钥/公钥，私钥保存在本地的设备，公钥保存在服务端

3. 每个设备都可以增加新的设备、删除其他的设备

一般要对 Anchor 增加多个设备，在任何一个设备都可以登录 IC 上的 DApp。

一个设备丢了，不会对使用造成影响，只需要在一台设备上删除丢失的设备，然后增加新的设备即可。

设备一般是电脑或者手机上的浏览器，在使用时需要刷脸或者指纹（基于 WebAuthn 实现），外人很难盗用，更加安全。

c. 关于助记词

在极端情况下，所有设备都丢了，怎么办？

这时候，还有助记词，用助记词增加一个新的设备，然后把其他所有设备都删除即可。

虽然助记词底层有一对私钥和公钥，但是用户可以把它看做是「恢复账户」的文本，不需要去理解私钥和公钥概念。

助记词的公钥也是保存在服务端，而私钥不会保存在本地，当恢复时，使用助记词生成私钥，然后和服务端的公钥做验证，验证通过即可恢复。

本质上，对于服务端来说，助记词也是个「设备」（类型为 seed_phrase，用途为 recovery）。

这里需要注意两点：

1. 设备和助记词 的「地位」其实是一样的

   i. 在一台设备上，可以删除和增加设备，也可以删除和新建一个助记词

   ii. 用助记词增加一台新设备后，可以做同样的事情

2. 要保证你的 Anchor 的设备和助记词 至少有一个存在，否则你的 Anchor 就无法恢复了，建议不要轻易修改助记词

第二个目标，II 是如何设计的呢？

这里主要是身份。

身份，即 Identity，是 IC 的一个特有抽象，其实在我看来，身份本质上是用户（Anchor）登录到不同 DApp 时的一个「分身」。

身份是基于公钥计算得来。

公钥的计算方式是：

|ii_canister_id| · ii_canister_id · seed

身份的计算方式是：

SHA-224(Public-Key) · 0x02

其中 seed 计算方式是：

seed = SHA-256(|salt| · salt · |user_number| · user_number · |frontend_host| · frontend_host)

注：|...| 表示 ... 的长度，user_number  就是 Anchor，frontend_host 是 DApp URL。

可以看到，身份的决定因素是 Anchor 和 frontend_host（II Canister ID 是不变的）。

这就保证了：

1. 当一个 Anchor 登陆不同 DApp 时，身份是不一样的

2. 在一个 Anchor 不同的设备上登陆 DApp，身份是一样的

但是，有个比较严重的问题，由于目前大部分 DApp URL 中包含 Canister ID，当 Canister ID 被删掉重建时，意味着 DApp 中的身份数据会发生变化！

第三个目标，II 设计了一套 Delegation 机制

Delegation 机制是 II 中非常重要的设计，它本质是权限委托，它的基本原理是：

1. 基于一对私钥和公钥（A）对另一对私钥和公钥（B）进行签名，签名之后， 后者可以代表前者的权限

2. 签名时可以带上 Scope 和 Expiration，Scope 是作用范围，也就是 frontend_host，Expiration 是过期时间，过期之后签名失效

Delegation 可以套娃，不断签下去，形成 Delegation Chain。

Delegation 机制

在 II 中，A 是任何一个设备的私钥和公钥，B 是 DApp 前端临时生成的私钥和公钥，B 的过期时间在 DAapp 前端设置。

签名之后，就表示 DApp 前端临时的私钥和公钥可以代表设备的私钥和公钥和 DApp 交互了，当然 DApp 前端也会获得和 DApp 绑定的用户的身份（Principal）。

另外：

1. 签名过程，首先要验证设备的私钥和公钥，然后对 临时的公钥 做签名，当然还会带上 Anchor、frontend_host、Expiration，签名结果会保存下来

2. 如果验证呢？在 DApp 前端向 IC 发送数据时，用临时的私钥加密，并且带上签名，IC 会验证签名的正确性，如果正确，就用临时的公钥解密，获取数据

另外，II 的这套签名机制有个叫法：Canister Signature，目前官方已经开放这个功能，不仅 II 可以使用，开发者开发 DApp 也可以使用了。

对 II 未来的展望

II 是 IC 生态 DApp 的单点登录系统（SSO），如果 IC 最终做成功了，II 则是整个互联网的单点登录系统。

而且，在未来，II 可以直接签发 Https 证书，也许会颠覆 Https 证书市场。

作者：tinywateer

原文链接：

https://mirror.xyz/0xFd007bb46C47D8600C139E34Df9DfceC86F0B319/47TgZKY1hqmpEESvtrbrzP0nNTtri5zE6fJxU0jkKjg

小助手微信号

入群请添加

联系我们

ICPL Twitter

https://twitter.com/icpleague_com

ICPL Medium

https://medium.com/icp-league

ICPL Telegram

 https://t.me/ICPL_en

ICPL 论坛

 https://icpleague.com