一文了解Dfinity互联网计算机的加密网络认证和身份验证

互联网计算机用一种更先进安全的加密认证方法取代了用户名和密码。

要理解身份和认证在互联网计算机的背景下意味着什么，我们必须首先其在当今的网络中是如何使用的。

当登录一个网站时，用户名通常是电子邮件地址或一串字母和数字，它是你唯一的标识符，可以将服务器上的相关数据与你的身份联系起来。密码则是认证手段，从理论上讲，只有你自己才知道密码，而服务器则将你的密码解释为其与你交流的证明。然而事实是，密码实际上并不是一个好的远程认证机制。

当你在一个网站上输入密码时，你的电脑会将密码发送到服务器上，并与密码数据库进行核对。不幸的是，黑客可以获得这些密码数据库的访问权。在最恶劣的情况下，密码是以明文形式存储在服务器上的，非常不安全。即使密码是加密的，破解它们也只是黑客是否愿意为了获得访问权而投入计算和金钱资源的问题。

互联网计算机是一个以网络速度运行的区块链计算网络，可以无限制地增加其容量。其设计是通过在多个数据中心之间**数据和计算来提供安全，以防止个别计算供应商的恶意行为。要注意的是，**虽然可以保护数据的完整性，但并不能防止信息的泄漏；在互联网计算机上使用密码仍然会受到与传统网络上相同的安全问题的影响。因此，在互联网计算机上，我们用适当的加密认证取代了密码。

我们在互联网计算机上用于认证的主要加密机制是数字签名方案。数字签名是一个相当标准的概念，发明于20世纪70年代末，从90年代中期开始被广泛使用。

通常由以下三种算法组成：

• 密钥生成：密钥生成可以看作是选择密码。通常，密钥的产生会创造一对钥匙：1）一个是像密码一样必须保密的私钥，2）另一个是可以公开的从私钥衍生的公钥。
• 签名：签名需要信息和私钥产生。当我们使用数字签名进行用户认证时，该算法是在持有私钥的用户端运行的。
• 验证：算法接收信息、签名和公钥，并验证签名是否与信息和公钥相符。这里的关键属性是，与检查密码不同的是，密码需要存储在服务器上，而在这种情况下，签名的验证可以仅根据公共信息进行，因为服务器存储了公钥列表，每个用户都有一个，且公钥和签名都不需要保密。

互联网计算机上的应用是基于通过传递信息进行交互的容器（Canister）实现的。更详细地说，交互模是基于请求的，类似于远程过程调用。当容器 A调用容器 B时，容器 A便指定了目标容器，所要调用的函数的名称，以及该函数的参数。当指定的函数在容器 B上被评估时，该容器也知道该函数是由容器 A调用的。评估完成后，容器 A将获得该函数的返回值以作为响应。而当用户与容器互动时，同样的远程过程调用模也一样适用。当用户调用一个容器时，用户会向目标容器发送一个请求。这个请求也会指定一个带有参数的函数，用户也可以获得返回值以作为响应。在请求的变化过程中，容器也会了解到调用它的用户的身份。

注：在ICP平台上，Canister是最基本的组成元素，可以理解为容器，类似于以太坊等区块链公链平台上的智能合约。这些容器可以**、可以分叉，更方便自组织。

上图是用户发送请求的示意图。中间的浅灰色区域显示了核心请求，包括目标容器 ID，函数名称，参数，以及调用者的身份或主体。而深灰色区域显示的则是包含认证信息、签名和公钥的封套。如图左侧所示，调用者的主体是通过散列法从公钥中得出的。这种技术在区块链领域被广泛使用，例如比特币或以太坊地址就是如此。此外，图中右侧部分显示了作为数字签名方案中的消息的请求内容是如何通过签名与公钥绑定的。当互联网计算机收到这样的请求时，它既要检查签名在指定的公钥下是否有效，也要检查公钥和调用者主体之间的关系。

为了确保信息确实是由信息中指定的调用者发送的，容器不必理会这些技术细节。如果一切都检查完毕，互联网计算机会评估容器上的指定功能，但如果其中一项检查失败，请求就会被放弃。

以下是关于我们使用的身份格式的一些细节。我们从DER格式的公钥开始，用SHA-224对其进行散列，从而得到一个28字节的字符串。我们会添加一个字节，用于区分来自公钥的身份主体和我们在互联网计算机中其他地方使用的身份主体，例如容器。这29个字节是以用户委托书的内部二进制表示的。当把一个委托人转换为其文本表示时，我们首先要预加一个CRC-32错误检测码。然后，使用Base32编码产生的字符串，**建立每组5个字符的组，并用破折号隔开。我们选择这种格式是为了支持在有适当错误检测的情况下，可以轻松**粘贴，同时仍然允许ASCII表示法中的字符少于64个，以便与互联网协议（如DNS）兼容。

到目前为止，我们所看到的方案在结构上还是有点不灵活的。它们将用户的身份主体与单一的加密密钥进行绑定，但这种限制会使用户很难与来自不同设备的容器进行交互，因为需要在这些设备之间共享相同的加密密钥，既繁琐又不安全。相反，我们在不同的加密密钥之间使用了授权。如上图所示，你可以看到从黄色密钥到橙色密钥的委托。这种委托包括被委托的密钥，即橙色的钥匙；一些额外的参数，如过期或委托范围的限制；以及委托密钥的签名，即黄色密钥。

当用橙色密钥签署请求时，用户可以使用来自黄色密钥的委托，以便使用来自黄色密钥的身份。此外，委托的强大之处在于，可组合性。例如，橙色密钥可以将授权扩展到紫色密钥。这种结构与公钥基础设施和X.509非常类似，但这并不是巧合，我们向其进行了借鉴，并使用了更轻量级的数据结构。

委托的一个具体应用与网络认证有关。网络认证是万维网联盟（W3C）的一个**标准，主要针对网络应用的双因素认证。该标准的动机是，如前所述，密码有严重的安全缺陷。它们经常在钓鱼邮件、恶意软件以及黑客攻击发生时，成为网络犯罪分子的猎物。

双因素认证意味着除了密码之外，登录网络应用还需要一个额外的安全因素，通常是用户拥有的安全设备。在现实中，这可能是一个安全的U钥匙或是一个内置在用户终端设备中并通过生物识别技术激活的安全芯片，由安全芯片存储加密密钥。由于加密密钥从未离开过安全芯片，所以即使用户的电脑或手机被恶意软件感染，它们仍然是安全的。

当网络认证被用作网络应用中的第二因素时，协议流程如下：在用户通过提供用户名和密码启动登录过程后，网络服务器将生成一个随机挑战并将其发送给用户的浏览器。然后，浏览器将挑战发送给安全设备，安全设备在签署挑战之前需要与用户互动。然后，签署的挑战书被送回服务器，服务器根据用户注册的公钥验证挑战书上的签名。这确保了登录网络应用程序时，除了密码外还需要持有安全设备。

公认的事实是，网络认证是一个开放的标准，使用数字签名进行认证，且已经被广泛的设备所支持。然而，当把它改编为互联网计算机时，我们必须克服一些障碍。网络认证假定了传统网络中面向会话的客户服务器模，用户在登录应用程序时进行一次认证，并在同一会话中发送后续信息。相比之下，互联网计算机实现了一个模，且每个请求都是单独认证的。特别是，由于浏览器和互联网计算机之间不存在有状态的会话，所以没有服务器可以生成挑战，并由安全设备签署。然而，回顾一下，在典的网络认证流程中，安全设备需要对服务器发送的挑战提供数字签名。

为了使用相同的协议实现请求认证，我们需要使用请求本身作为挑战，并由安全设备签署，类似于我们的一般请求认证方案。我们必须克服的另一个问题是，网络认证需要用户对每个签名进行交互。在互联网计算机提供的典前端中，一个页面的加载可能对应着多个请求。由于我们不想要求用户明确确认每个请求，所以我们使用了上述的委托机制。当使用网络认证与一个容器进行交互时，我们会首先生成一个短期的会话密钥。然后，使用网络认证来签署一个面向该会话密钥的委托，这样，单个用户的互动就可以触发对互联网计算机的多个请求。

虽然网络认证对安全存储加密密钥很有帮助，但它不仅将这些密钥绑定在设备上，而且还将其绑定在了一个特定的容器上。其原因是浏览器的安全模，该模严格地将在同一网络浏览器中运行的不同应用程序所能访问的状态按其来源分开。在网络上，你可以认为一个原点大致上对应于一个网站。在互联网计算机上，每个原点则对应于一个容器。这种严格的状态分离对安全至关重要，但它也使得诸如密钥备份或支持从多个设备无缝访问同一容器的功能变得繁琐，因为所有这些操作都必须为每个容器单独执行。我们通过使用互联网身份服务来解决这个问题，即身份提供者，类似于你在网络上熟悉的 “用谷歌或Facebook登录 “功能。

当用户第一次加载一个特定容器的前端时，该前端会呈现一个 “用IC登录 “的按钮。当用户点击该按钮时，浏览器会打开一个弹出窗口，显示互联网身份服务，这是一个允许用户管理钥匙和身份的特定应用程序。然后，用户可以决定是否允许容器前端使用用户身份。如果用户同意，浏览器就会被重定向到容器前端，并能以用户的身份访问容器。这个机制将再次触发会话密钥和委托机制。届时，容器前端会生成一个会话密钥对，并将公钥传输给互联网身份认证。如果用户确认，互联网身份认证产生授权，并将其返回给信息库前端。作为通过大技术提供商签署的额外好处，身份提供商的完整认证流程发生在用户端，所以对用户私人行为的暴露要少得多，从而减少身份跟踪。(互联网身份服务常见问题)

谈到用户追踪，互联网身份认证将为用户登录的每一个容器前端提供一个不同的身份，这对安全和隐私非常有利。如果不是这样，互联网身份认证将允许每一个前端在用户的单一主体下登录。如果该用户与不相关的服务互动，例如留言板和购物网站，这些服务就可以在背后关联用户在这些网站上的行为。更糟糕的是，留言板的前端可以恶意调用购物网站的容器 ，并以用户的名义下订单。因此，互联网身份识别服务为用户登录的每一个前端生成一个不同的身份，并以主机名进行区分。这样一来，用户在不同服务上的行为就不那么容易被追踪了。虽然前端仍然能够使用用户的身份来调用互联网计算机上的任何容器，但它永远只是与执行调用的前端有关的身份。