互联网计算机上的Web身份验证和身份

要了解身份和身份验证在互联网计算机（一个以网络速度运行并可以无限制地增加其容量）的区块链计算网络的上下文中的含义，我们必须首先考虑当今如何将身份和身份验证与网络一起使用。

登录网站时，您的用户名通常是您的电子邮件地址或一串字母和数字，它们是您的唯一标识符，该标识符将服务器上的相关数据与您的身份相关联。您的密码是身份验证的手段。

因为从理论上讲，只有您应该知道密码，所以服务器会将您的密码解释为与您进行通信的证据。但是事实证明，密码实际上并不是远程身份验证的良好机制。

当您在网站上输入密码时，计算机会将密码发送到服务器，然后根据密码数据库对其进行检查。不幸的是，黑客可以访问这些密码数据库。在最极端的情况下，密码以明文形式存储在服务器上，这不是建议的安全做法。

但是，即使密码已加密，恢复密码也仅是黑客为了获得访问权限而愿意投入的计算和金钱资源的问题。

互联网计算机旨在通过在多个数据中心之间复制数据和计算来提供针对单个计算提供者的恶意行为的安全性。复制在保护数据完整性的同时，并不能防止信息泄漏。

在互联网计算机上使用密码仍然会受到与传统Web上相同的安全性问题的困扰。因此，使用互联网计算机，我们已使用适当的加密认证替换了密码。

我们在互联网计算机上用于身份验证的主要加密机制是数字签名方案，数字签名是一个非常标准的概念，它们是在1970年代后期发明的，至少从1990年代中期开始就被广泛使用。

通常认为它们由三种算法组成：

• 密钥生成，您可以将其视为选择密码的模拟。密钥生成会创建一对密钥：1）必须像密码一样将密钥保密；以及2）从私有密钥派生但可以公开的公共密钥。

• 签名，它接收消息和私钥并产生签名。当我们使用数字签名进行用户身份验证时，该算法在持有私钥的用户侧运行。

• 验证，它接收消息、签名和公共密钥，并验证签名与消息和公共密钥匹配。这里的关键特性是，与检查密码（要求将密码存储在服务器上）不同，在这种情况下，仅基于公共信息即可执行签名验证。服务器存储一列公用密钥，每个用户一个，并且公用密钥和签名都不必保持秘密。

互联网计算机上的应用程序是基于通过传递消息进行交互的容器来实现的。更详细地说，交互模型基于请求，这很像远程过程调用。当容器A调用容器B时，容器A指定目标容器（即容器B），它要调用的函数的名称以及该函数的参数。在容器B上评估了指定的函数时，该容器还知道该函数已被容器A调用。

评估完成后，容器A获得该函数的返回值作为响应。用户与容器交互时，将应用相同的远程过程调用模型。当用户调用容器时，用户会将请求发送到目标容器。该请求还指定了带有参数的函数，并且用户获得了返回值作为响应。在更改请求期间，容器还可以了解调用它的用户的身份。

上图显示了从用户发送的请求的示意图。中间的浅灰色区域显示核心请求：目标容器ID、函数名称、参数以及调用者的身份或主体。较深的灰色区域显示了包含身份验证信息、签名和公钥的信封。如左侧所示，调用者的主体是通过从公钥中散列而得出的。

这项技术广泛用于区块链领域，例如比特币或以太坊地址。右侧显示了数字签名方案中作为消息的请求内容如何通过签名绑定到公钥。当互联网计算机收到这样的请求时，它会检查在指定的公共密钥下签名是否有效，以及公钥和呼叫者主体之间的关系。

为确保消息确实是由消息中指定的呼叫者发送的，容器不必打扰这些技术细节。如果一切都检查完了，则互联网计算机会评估容器上的指定功能。如果其中一项检查失败，则仅丢弃该请求。

我想提一些有关我们使用的委托人格式的细节。我们以DER格式的公钥开始，并使用SHA-224对其进行散列，从而得到28字节的字符串。我们附加了一个字节，该字节仅用于区分从公钥派生的主体与我们在互联网计算机的其他地方（例如容器）使用的主体。

这29个字节是用户主体的内部二进制表示形式。在将主体转换为其文本表示形式时，我们首先要添加CRC-32错误检测代码。然后，我们在Base32中对结果字符串进行编码，最后构建每个由五个字符组成的组，并用破折号分隔。

选择该格式以支持通过适当的错误检测轻松进行复制粘贴，同时仍允许ASCII表示的字符数少于64个，以与DNS类似的互联网协议兼容。

到目前为止，我们所看到的方案在构造上仍然有些僵化，它将用户的委托人绑定到单个加密密钥。这种限制使用户难以与来自不同设备的容器进行交互，因为这将需要在这些设备之间共享相同的加密密钥，从安全角度来看，这既乏味又不鼓励。

相反，我们在不同的加密密钥之间使用委托。在上图中，您看到了从黄色键到橙色键的委托。这样的委派由委派的密钥（橙色的）组成，一些其他参数，例如授权范围的到期或限制，以及授权密钥的签名（黄色）。

现在，使用橙色键签署请求时，用户可以包括来自黄色键的委派，以便使用从黄色键派生的身份。委托的特别强大之处在于可以组合。例如，橙色键可以将委托扩展到紫色键。如果从公钥基础结构和X.509看来，这一切都不是巧合-我们只是在使用更轻量级的数据结构。

委托的一种特定应用与Web身份验证有关。Web认证是一种最新的标准中的万维网联盟（W3C） ，并主要针对双因素身份验证的Web应用程序。如前所述，该标准的动机是密码具有严重的安全缺陷。

无论是通过网络钓鱼电子邮件和安装在用户设备上的恶意软件，还是当服务被黑客入侵时，它们经常成为网络罪犯的猎物。

两重身份验证意味着，除了密码之外，登录Web应用程序还需要附加的安全因素，通常是用户拥有的安全设备。

实际上，它可以是安全的USB密钥或内置在用户终端设备中并通过生物识别技术激活的安全芯片，安全芯片存储加密密钥。由于加密密钥永远不会离开安全芯片，因此即使用户的计算机或电话感染了恶意软件，它们也保持安全性。

当将Web身份验证用作Web应用程序的第二因素时，协议流程如下：用户通过提供用户名和密码启动登录过程后，Web服务器将生成随机询问并将其发送给用户的浏览器。

接下来，浏览器将质询发送到安全设备，安全设备需要用户交互才能签署质询。然后将已签名的质询发送回服务器，服务器会根据用户注册的公共密钥验证质询上的签名。这样可以确保登录Web应用程序除了需要密码之外还需要保存安全设备。

我们基于以下事实：Web身份验证是使用数字签名进行身份验证的开放标准，并且已经在各种设备上得到支持。但是，在将其用于互联网计算机时，我们必须克服一些障碍。

Web身份验证采用传统Web的面向会话的客户端服务器模型，在该模型中，用户使用应用程序登录时进行一次身份验证，并在同一会话中发送后续消息。相反，互联网计算机实现了一个模型，其中每个请求都单独进行了身份验证。

特别是，由于浏览器和互联网计算机之间没有状态会话，因此没有服务器可以生成将由安全设备签名的质询。但是请回想一下，在典型的Web身份验证流程中，安全设备会针对服务器发送的质询提供数字签名。

为了使用相同的协议实现请求认证，我们将请求本身用作质询，并由安全设备对其进行签名，这类似于我们的一般请求认证方案。我们必须克服的另一个问题是，Web身份验证要求每个签名都需要用户交互。

在互联网计算机提供服务的典型前端中，单个页面加载可以对应于多个请求。由于我们不想要求用户明确确认每个请求，因此我们使用上述委托机制。使用网络身份验证与容器进行交互时，我们首先会生成一个短期会话密钥。

然后，我们使用Web身份验证对指向该会话密钥的委派进行签名，以便单个用户交互可以触发对互联网计算机的多个请求。

虽然Web身份验证非常适合安全地存储加密密钥，但它不仅将这些密钥绑定到设备，而且还绑定到特定的容器。原因是浏览器安全模型，该模型严格按照来源来区分在同一Web浏览器中运行的不同应用程序可访问的状态。

在网络上，您可以将来源视为大致对应于一个网站。在互联网计算机上，每个来源都对应一个容器。这种严格的状态分离对于安全性至关重要，但是它也使诸如密钥备份或支持从多个设备无缝访问同一容器的功能变得乏味，因为必须对每个容器单独执行所有这些操作。

我们通过使用互联网身份服务解决了此问题，一种身份提供者，类似于您在网络上熟悉的“使用Google或Facebook登录”功能。

当用户第一次加载给定容器的前端时，该前端可以显示“使用IC登录”按钮。当用户单击该按钮时，浏览器将打开一个弹出窗口，其中包含Internet Identity互联网身份服务，该服务是允许用户管理密钥和身份的特定应用程序。

然后，用户可以在那里决定是否允许容器前端使用用户的身份。如果用户批准，浏览器将重定向到容器前端，并可以用户身份访问容器。该机制再次使用会话密钥和委托机制。容器前端生成一个会话密钥对，并将公共密钥传输到互联网身份。

如果用户确认，则互联网身份将生成委托，并将其返回到容器前端。与通过大型技术提供商进行登录相比，另一个好处是，身份提供程序中的完整身份验证流程在用户端进行，因此，私人用户操作的暴露度大大降低，因此跟踪也大大减少。

说到用户跟踪，互联网身份将为用户提供不同的体验他们登录的每个容器前端的身份，这对于安全性和隐私性来说非常有用。如果不是这样，互联网身份将允许每个前端使用用户的单一主体登录。

如果该用户与不相关的服务（例如，留言板和购物网站）进行交互，则这些背后的内容可能会与用户在这些网站上的行为相关联。更糟糕的是，留言板的前端可能恶意呼叫购物站点的容器，并以用户的名义下订单。

因此，互联网身份服务会为用户登录的每个前端生成一个不同的身份，前端根据其主机名进行区分。这样，就不容易跟踪用户对不同服务的操作。

我们在最近发布的《互联网计算机接口规范》中详细说明了上述机制以及在互联网身份标识中使用的机制-我们期待着开发人员社区还将以此为基础。

请继续关注更多发布，详细介绍互联网计算机背后的技术。

开始在sdk.dfinity.org上构建并加入我们的开发者社区forum.dfinity.org。

作者：DFINITY研究团队主管Björn Tackmann

翻译：Catherine

进DFINITY交流社群，请添加小助手微信：

comiocn

长按关注

DFINITY微信公众号

给你第一手资讯和项目信息

更可随时答疑解惑