SafeKeeper：使用可信执行环境保护Web密码

3490SafeKeeper：使用可信执行环境保护Web密码0KlaudiaKrawiecka，芬兰阿尔托大学，kkrawiecka@acm.org0ArsenyKurnikov，芬兰阿尔托大学，arseny.kurnikov@aalto.fi0AndrewPaverd，芬兰阿尔托大学，andrew.paverd@ieee.org0MohammadMannan，加拿大康考迪亚大学，m.mannan@concordia.ca0N.Asokan，芬兰阿尔托大学，asokan@acm.org0摘要0密码是迄今为止在Web上最广泛使用的用户认证机制，从可部署性（例如成本和兼容性）的角度来看，它们优于所有竞争解决方案。然而，钓鱼和密码数据库的盗窃是两个关键的安全问题。这些问题由用户在不同服务之间重复使用密码的倾向加剧。当前的解决方案通常只解决这两个问题中的一个，并且不能保护密码免受恶意服务器的攻击。此外，它们不向用户提供任何关于其（服务器端）采用的可验证证据，并且在终端用户易于使用和/或服务提供商成本方面面临部署挑战。我们提出了SafeKeeper，这是一种新颖而全面的解决方案，用于确保Web身份验证系统中密码的保密性。与以前的方法不同，SafeKeeper可以保护用户的密码免受非常强大的对手的攻击，包括外部钓鱼者和被损坏的（恶意的）服务器。由于（i）使用广泛可用的基于硬件的可信执行环境（如IntelSGX），（ii）仅需要对流行的Web平台（如WordPress）进行最小更改，并且（iii）对性能几乎没有影响，因此部署相对廉价。我们讨论了设计和实现这样一个系统时面临的几个挑战以及我们如何克服它们。通过86名参与者的用户研究，系统分析和实验，我们展示了SafeKeeper的可用性，安全性和部署能力，该系统可作为开源软件使用。0关键词0密码，钓鱼，Intel SGX，可信执行环境0ACM参考格式：Klaudia Krawiecka，Arseny Kurnikov，AndrewPaverd，Mohammad Mannan和N.Asokan。2018年。SafeKeeper：使用可信执行环境保护Web密码。在2018年WWW会议上，2018年4月23日至27日，法国里昂。ACM，纽约，美国，10页。https://doi.org/10.1145/3178876.31861010本文发表在知识共享署名4.0国际（CC BY4.0）许可下。作者保留在其个人和公司网站上传播作品的权利，并附有适当的归属。WWW 2018，2018年4月23日至27日，法国里昂。©2018IW3C2（国际万维网会议委员会），根据知识共享CC BY 4.0许可发布。ACM ISBN978-1-4503-5639-8/18/04。https://doi.org/10.1145/3178876.318610101 引言0密码是迄今为止在Web上最广泛使用的主要认证机制。尽管已经提出了许多替代方案，但没有一个能够挑战密码的主导地位。在Bonneau等人的认证机制评估框架中，密码具有最佳的整体可用性，因为它们易于理解，使用高效，并且不需要用户携带额外的设备/令牌。从可部署性的角度来看，它们也具有优势，因为它们与几乎所有服务器和Web浏览器兼容，每个用户的成本最低，并且易于访问，成熟且非专有。然而，从安全性的角度来看，密码目前是一个相对较差的选择。导致大量密码泄露的两个关键安全问题是：（i）从用户那里钓鱼密码，以及（ii）从服务器泄露密码数据库。钓鱼攻击在野外广泛存在（参见APWG [2]，Phish- Tank[33]），并且越来越多地使用来自浏览器可信CA的TLS证书（例如见[30]）。虽然存在先进的反钓鱼解决方案[11，29]，并且随着时间的推移将得到改进，但它们单独无法充分解决密码保密性问题，因为用户可能无意中或无意中向恶意服务器泄露密码。请注意，估计有43-51％的用户在不同服务之间重复使用密码[13，17，22，39]。密码数据库泄露越来越频繁：近年来已泄露了数亿个密码（例如[14，34]）。用户对此类泄露完全无能为力。要求用户快速重置密码是处理密码泄露的常见方法，但效果不佳[19]。广泛的密码重用使这些泄露问题超出了实际泄露发生的站点[22]。已经提出了几种最近的解决方案（例如[4，9，15，26]）来解决密码数据库泄露问题。其中一些（例如[4，9，26]）利用了服务器端的基于硬件的可信执行环境（TEEs），但没有一种可以保护密码保密性免受恶意服务器（即受损服务器或恶意服务器操作员）的攻击。设计有效的解决方案以保护密码免受恶意服务器的攻击在安全性（如何隐藏密码免受认证服务器本身的攻击？如何对服务器进行密码测试进行速率限制？）；可用性（如何最大程度地减轻用户负担？如何支持来自不同用户设备的登录？）；用户可验证性（如何在解决方案激活时通知用户？）；性能（如何在规模上实现？）；和部署能力（如何允许与流行的网站框架轻松/廉价集成？）。0主题：Web上的安全与隐私WWW 2018年4月23日至27日，法国里昂3500我们提出了SafeKeeper，一个全面保护Web密码机密性的系统。与所有先前的提案不同，SafeKeeper甚至在恶意服务器的情况下，都能防御钓鱼和密码数据库盗窃。SafeKeeper由一个服务器端密码保护服务组成，在将密码存储在数据库之前，对密码进行基于密码的消息认证码（CMAC）计算，正如NIST的数字身份指南（SP800-63B）[32]所规定的。为了保护CMAC密钥，此计算在服务器端的TEE内执行，与服务器上的所有其他软件隔离。SafeKeeper使用一种新颖的速率限制机制来限制恶意服务器的在线猜测攻击。SafeKeeper的客户端功能以Web浏览器插件的形式存在，使最终用户能够检测Web服务器是否在服务器端TEE内运行SafeKeeper密码保护服务，并直接与其建立安全通道。这样，用户就可以确保只有SafeKeeper密码保护服务在服务器上才能访问他们的密码。与其他客户端保证方法不同，SafeKeeper不需要用户正确识别服务器（例如检查URL或TLS证书）。只要用户正确识别浏览器插件中的SafeKeeper客户端信号，并且只将密码输入到启用了SafeKeeper的Web服务器中，他们的密码的机密性就得到保证，即使用户错误判断服务器的身份（钓鱼）或服务器是恶意/被入侵的（恶意服务器）。因此，SafeKeeper可能在避免钓鱼和密码保护方面产生重大变革。我们的设计将可部署性作为主要目标。我们通过使用Intel最新的软件保护扩展（SGX）开发SafeKeeper的完全功能实现，并将其与PHPass集成到WordPress，Joomla和Drupal等流行平台中的最小软件更改中，这些平台占Alexa排名前1000万的网站的34％以上。SafeKeeper的客户端功能不依赖于任何其他设备/硬件功能，因此可以在大多数用户设备/操作系统中实现，包括智能手机。我们的实现可作为开源软件使用[25]。我们的贡献是SafeKeeper，包括其：0• 设计：作为一种密码保护方案，具有以下特点 -使用现成的可信硬件来保护用户密码的服务器端密码保护服务（第4.1-4.3节），以及 -一种新颖的客户端保证机制，允许用户轻松确定在网页上输入密码是否安全（第4.4节）。我们的机制仅依靠验证服务器是否运行SafeKeeper，而无需验证服务器的身份或正确行为。• 实施和集成：使用IntelSGX的服务器端功能的完整开源实现，并将其集成到支持几种流行网络平台的PHPass中，以及作为GoogleChrome浏览器插件实现的客户端功能（第5节）。•分析和评估：对安全保证进行全面分析（第6.1节），对性能进行实验评估（第6.3节），在实际平台上进行部署性评估（第6.4节），并通过86名参与者的用户研究验证客户端保证机制的有效性（第6.2节）。02初步 2.1存储密码0一种广泛使用的存储密码的方法是服务器对密码进行单向函数（例如，加密哈希）计算，并仅将结果存储在数据库中。当用户登录时，将同样的函数应用于提供的密码，并将结果与数据库中的值进行比较。获得数据库的对手无法反转单向函数，但可以猜测候选密码并应用相同的单向函数来测试猜测。由于密码是弱密码（例如，与加密密钥相比），暴力猜测攻击通常是可行的。对手可以使用预先计算的哈希密码表来加快此攻击的速度。如果多个用户选择相同的密码，则单向函数的结果将相同。为了防止彩虹表攻击并避免泄露重复密码，通常使用盐 -一种与每个用户唯一相关的随机数，将其与密码连接后进行哈希处理。然而，由于盐值存储在数据库中，获得该数据库的对手仍然可以对特定用户进行暴力猜测攻击。最近（2017年6月），NIST在特殊出版物800-63B[32]中更新了其数字身份指南。其中的一项变更是强制使用带密钥的单向函数（例如CMAC）来保护存储的密码。02.2 Intel软件保护扩展0Intel的软件保护扩展（SGX）是最近在台式机和服务器CPU中可用的技术[21]。新的SGXCPU指令允许用户空间应用程序建立一个硬件强制执行的TEE，称为enclave。enclave在应用程序的虚拟地址空间中运行，但在初始化后，只允许enclave内部的代码访问enclave数据。应用程序可以通过明确定义的入口点调用enclave函数（称为ecalls）。enclave数据存储在内存的特殊区域中，称为Enclave PageCache（EPC），只能由CPU访问。当任何enclave数据离开CPU（例如写入DRAM）时，它会被加密和完整性保护，使用只能由CPU访问的密钥[16]。因此，enclave的数据受到特权软件（包括操作系统/虚拟机监视器）和硬件攻击（例如窃听内存总线）的保护。在enclave初始化期间，CPU会测量enclave的代码和配置，这构成了enclave的身份（即其MRENCLAVE值）。enclave可以通过使用只能从具有完全相同MRENCLAVE值的CPU上运行的enclave访问的CPU受保护密钥对数据进行加密。远程证明是一方（验证者）可以确定远程方（证明者）的精确硬件和软件配置的过程。目标是为验证者提供足够的信息，以便对证明者做出信任决策。SGX通过为验证者提供来自enclave的签名报告来支持远程证明，其中包括enclave的精确身份（MRENCLAVE值）和enclave的公钥[1]。验证者可以使用Intel AttestationService（IAS）验证此报告，然后可以直接与enclave建立端到端加密通道。SGX远程证明在我们的技术报告中有详细解释[24]。0Track: Web上的安全与隐私WWW 2018年4月23日至27日，法国里昂Track: Security and Privacy on the WebWWW 2018, April 23-27, 2018, Lyon, France35103 系统模型和要求 3.1 概述0我们使用术语“密码”来指代任何用户记忆的认证密钥。密码通常是弱密钥[7]，经常在多个服务中重复使用。图1是基于密码的认证系统的通用模型。借助客户端软件（例如Web浏览器）的帮助，用户通过安全通道（TLS）将其用户ID和密码发送到服务器，并基于此进行身份验证决策。尽管真实系统无疑更加复杂，但它们都可以在逻辑上表示为图1中的模型。因此，我们在本文中始终使用此模型和术语。0图1：基于密码的认证系统的通用模型。0用户密码的机密性可能以多种方式被破坏，包括：0•用户在错误的印象下直接将密码透露给对手，以为密码被发送到了目标服务（例如钓鱼攻击）。•密码信息或密码本身从服务器泄漏（例如被盗的密码数据库）。•服务器被入侵（例如Web服务器内存窥探）。0保护密码的任何综合解决方案必须防御所有这些不同的攻击途径。03.2 对手模型0我们对手（Adv）的目标是了解用户的明文密码。我们的对手模型比以前的解决方案更强大-我们允许Adv具有Web服务器本身的操作者（所有者/管理员）的能力。这包括被入侵的Web服务器以及恶意的服务器操作者（为了清楚起见，我们使用术语“流氓服务器”来指代这两者）。重复在多个服务中使用相同或相似的密码的普遍做法为Adv学习明文密码提供了动力，他们随后可以以不同的方式滥用这些密码，包括（i）冒充用户在不同的服务上，用户可能使用相同或相似的密码；（ii）访问由密码派生密钥加密的用户数据（例如，对于加密云存储服务，特别是在法律或非法强制情况下）；以及（iii）将用户密码出售/泄漏给其他恶意实体。具体而言，我们允许Adv具有以下能力，涵盖了流氓服务器和较弱的外部对手：访问密码数据库：Adv可以无限制地访问密码数据库。这模拟了流氓服务器和可能窃取密码数据库的较弱的外部对手。修改Web内容：Adv可以任意修改发送给用户的内容（包括客户端脚本等主动内容）。0这也模拟了能够使用跨站脚本（XSS）等攻击修改内容的较弱的外部对手。访问服务器-客户端通信：对手可以读取发送到Web服务器的所有内容，包括由TLS会话密钥加密的内容。对于流氓服务器，这种访问很容易获得。执行服务器端代码：对手完全了解服务器上运行的所有软件，并能够在服务器上执行任意软件。这捕捉到了一个强大的攻击者，他可以访问并提升服务器上的特权，或者是一个恶意的服务器操作员。发起网络钓鱼攻击：对手可以发起最先进的网络钓鱼攻击，包括定向攻击。我们假设对手无法破坏客户端软件，包括用户的操作系统和浏览器，但可以向客户端发送任何内容。尽管客户端安全很重要，但这是一个正交问题，并且通过其他方式解决（例如，客户端平台安全）。我们关注如何使基于密码的身份验证对抗强大的服务器端对手。我们假设对手在计算上是有限的，因此无法实质性地破坏正确实现的加密原语。我们还假设对手没有足够的资源通过直接物理攻击来破坏基于硬件的可信执行环境的安全保证。拒绝服务（DoS）攻击超出了范围，因为流氓服务器可以通过简单地拒绝响应请求来发动DoS攻击。03.3 需求和目标0鉴于我们强大的对手模型，完全服务器妥协无疑会造成重大损失（例如，用户信息的盗窃、丢失或修改）。我们的目标是确保即使发生这种妥协，也不会泄漏用户的密码。这是一个有价值的安全保证，因为密码经常在多个服务之间重复使用，或用于派生云存储加密密钥。然而，保证存储密码的机密性并不足以防御流氓服务器或网络钓鱼攻击。因此，我们还需要为用户提供一种简单有效的方法来确定何时输入密码是安全的。因此，我们为保护基于密码的身份验证系统的全面解决方案定义了以下两个要求：0R1密码保护：服务器必须通过满足以下所有标准来保护用户的密码：（i）除了猜测之外，强大的对手不能以任何其他方式获得用户的密码（例如，他不能在传输密码或在服务器上处理密码时观察密码）。（ii）无论密码的强度如何，离线密码猜测都必须是计算上不可行的。 （iii）无论对手的计算能力如何，在线密码猜测都必须受到限制。R2用户意识：当给定服务器提示用户输入密码时，终端用户必须能够轻松准确地确定是否安全输入密码（即间接确定服务器是否满足需求R1）。0请注意，需求R2不要求用户理解需求R1的精确技术安全保证，而是要求解决方案使用户能够确定哪些服务器满足此要求，并因此保护密码。3520为了有效，任何保护密码的解决方案都必须能够在实际系统中部署。因此，除了上述两个安全要求外，我们还定义了以下部署目标：最小的性能开销：解决方案不应明显降低基于密码的身份验证系统的性能，无论是延迟（完成单个身份验证尝试所需的时间）还是可扩展性（身份验证尝试的整体速率）。最小的软件更改：应该能够将解决方案集成到各种现有软件系统中，而不需要大量工作。易于升级：应该能够透明地升级现有的基于密码的身份验证系统（例如，无需要求用户重置密码）。更改/重置密码的现有机制也应保持不受影响。04 设计0如图2所示，SafeKeeper由一个服务器端密码保护服务组成，在将密码存储在数据库之前，对密码进行基于密码的消息认证码（CMAC）计算。攻击者必须获取CMAC密钥，才能对被盗的密码数据库进行离线猜测攻击。在SafeKeeper中，该密钥是随机生成的，并在服务器端的可信应用程序（TA）中进行保护，该应用程序在TEE内执行；详见第4.1节。通过直接访问密码保护服务，恶意服务器（即被入侵的服务器或恶意服务器操作员）也可以进行在线密码猜测攻击。在这种情况下，攻击者提供一个猜测的密码，密码保护服务返回处理结果，攻击者将其与存储的值进行比对。为了防止这种攻击，密码保护服务必须限制处理密码的速率。SafeKeeper通过在TEE中强制实施速率限制来实现这一点；详见第4.2节。此外，恶意服务器可能会尝试在将密码发送到密码保护服务之前观察密码。Web浏览器插件和服务器之间的安全通道（例如TLS连接）是不够的，因为这种连接的服务器端由服务器操作员控制。相反，SafeKeeper在浏览器和受TEE保护的密码保护服务之间建立了端到端的安全通道；详见第4.3节。最后，浏览器需要某种方式来确定哪些输入数据应通过此安全通道发送到密码保护服务（例如密码但不包括用户ID）。为了提高可用性，服务器操作员定义哪些输入字段将受到保护，然后SafeKeeper浏览器插件向用户显示此信息。因此，用户只需要验证密码字段是否受到保护；详见第4.4节。04.1 服务器端密码保护0SafeKeeper密码保护服务（SafeKeeperTA）旨在成为现有密码哈希算法的替代品。因此，它以密码和相应的盐值的串联作为输入，并输出一个CMAC，服务器将其存储在数据库中。为了保护CMAC密钥，SafeKeeper0图2：SafeKeeper设计概述0在服务器端的可信执行环境（TEE）内计算CMAC。TEE与服务器上的所有其他软件（包括操作系统/虚拟机监视器）进行强隔离（例如，硬件强制隔离），从而确保CMAC密钥仅对TA代码可用。即使攻击者获取了密码数据库，他也无法进行离线密码猜测攻击，因为他需要CMAC密钥来将猜测与数据库进行比对。由于离线攻击不再可能，SafeKeeper可以使用任何具有密码学安全性的单向函数，即特定设计的密码哈希函数（例如[5,6]）并非必需（但可以使用）。因此，攻击者被迫尝试在线猜测攻击，而SafeKeeper的速率限制机制可以减轻这种攻击。04.2 速率限制0理想情况下，密码保护服务应该对每个账户进行速率限制，以保护每个账户的密码，并避免因其他用户的操作而对用户进行速率限制。需要注意的是，为了作为现有身份验证框架的替代品，SafeKeeperTA仅计算CMAC，而不进行身份验证决策的制定或学习。换句话说，它无法区分以下两种情况：(i)用户账户遭受猜测攻击，(ii)合法用户在短时间内多次尝试登录（无论是否使用有效密码）。此外，由于CMAC不以用户ID作为输入，我们无法实现基于用户ID的速率限制。将函数更改为包括用户ID作为输入将需要对服务器软件进行非常规的更改，从而限制了SafeKeeper作为现有系统的替代品的使用。为了解决这个问题，我们使用每个账户的唯一盐值对每个账户进行速率限制，这些盐值作为常规操作的一部分提供给CMAC。对于每个账户（盐值），SafeKeeper根据量化的最大速率限制密码处理。简单地强制执行最大速率（例如，在密码尝试之间等待W分钟）会对用户体验产生负面影响，因为用户可能会输错密码。相反，量化的最大速率允许在预定义的时间间隔内进行固定数量的尝试，但不要求在这些尝试之间进行延迟。例如，每个用户0Track: 2018年4月23日至27日，法国里昂的Web上的安全与隐私3530可以允许N次尝试，每24小时内可以在任何时间使用。在用尽这些尝试之后，用户必须等待到下一个时间段，计数将被重置。通过校准N = 24×600W，这样可以达到在尝试之间等待W分钟的相同总体速率，但在需要快速连续多次尝试时显著提高了可用性。04.3 远程证明0为了安全地传输用户密码，SafeKeeper浏览器插件必须通过远程证明正确验证运行在TEE内的SafeKeeper密码保护服务（SafeKeeperTA）。此外，插件必须直接与TA建立安全通道。SafeKeeper使用远程证明来向插件保证服务器端TEE内运行的确切TA。为了验证正在与真实的SafeKeeperTA通信，插件验证引用，然后将二进制测量与已知的SafeKeeperTA白名单进行比对。由于同一个TA可以被许多网站使用，并且TA的功能不太可能发生变化，真实的SafeKeeperTA白名单将很短，并且可以内置到SafeKeeper插件中。证明协议包括密钥协商步骤，通过该步骤，浏览器和TA建立共享会话密钥。请注意，证明协议仅对SafeKeeperTA向客户端进行单向身份验证；即在证明期间，客户端软件或用户不进行身份验证。因此，任何人，包括对手，都可以建立连接并与TA进行交互。但是，由于密钥协商步骤与TA的远程证明在密码学上绑定在一起，对手在合法客户端与TA通信时无法执行中间人攻击。使用共享会话密钥，插件在提交页面之前对密码进行加密。加密的密码代替原始密码发送到服务器，并可以包装在其他加密层中（例如TLS）。在服务器上，加密的密码输入到TA中，TA使用共享密钥解密并执行CMAC。04.4 客户端保证机制0SafeKeeper的客户端保证机制可以添加到现有的Web浏览器中，例如通过安装浏览器插件。该插件执行远程证明协议并与TA建立安全通道。如果证明成功，插件会更改其外观（例如其图标），以向用户表示这一点。服务器在网页中指定哪些输入字段应该加密并发送到SafeKeeper密码保护TA。插件解析此信息并对输入到这些字段中的任何文本进行加密。然而，恶意服务器可能会指定保护一些非密码字段，而实际的密码字段则不受保护。为了防止这种情况，SafeKeeper插件通过将整个页面变灰，仅突出显示将加密的文本输入字段，并显示信息工具提示来向用户指示哪些输入字段受到保护。对手可能会尝试伪造SafeKeeper执行的突出显示（例如，突出显示实际上未受保护的字段）。为了减轻这种情况，我们使用类似于安全关注序列的原理，要求用户单击浏览器插件图标以激活突出显示。对手无法检测或阻止此点击（因为它在浏览器DOM之外）。0用户点击后，SafeKeeper图标再次更改，表示它处于高亮模式。这为向用户指示哪些输入字段将受到保护提供了一种抵御欺骗的机制。因此，用户确信无论网站的身份还是服务器的行为如何，输入到这样的输入字段中的密码都将始终由SafeKeeper保护。与许多其他客户端方法（例如密码管理器）不同，SafeKeeper浏览器插件是无状态且与用户无关的。这使得我们的客户端保证机制成为直接集成到Web浏览器中的良好候选。我们在附带的技术报告[24]中讨论了其他可能的机制。05 实现0我们已经实现了SafeKeeper的一个完全功能的开源原型[25]。在本节中，我们描述了具体的实现挑战和我们的解决方案。05.1 服务器端密码保护0我们实现的密码保护服务使用了英特尔最新的软件保护扩展（SGX）。然而，SafeKeeper可以使用任何提供隔离执行、密封存储和远程认证的等效可信执行环境（TEE）。我们选择SGX是因为它在服务器平台上的性能和普及度越来越高（例如，英特尔至强[20]）。我们的SGXenclave设计保持简洁，只包含四个ecall。当第一次启动enclave时，init()函数使用英特尔的硬件随机数生成器（RDRAND指令）生成一个新的强CMAC密钥。当稍后重新启动enclave时，此函数用于将先前密封的数据传递给enclave。process()函数计算密码的CMAC并返回结果。我们使用Rijndael-128CMAC函数，因为它满足我们的安全要求，并且可以使用AES-NI硬件扩展进行计算。我们将SafeKeeper的密码保护服务集成到了PHPass库[31]中，该库广泛用于流行的Web平台，包括WordPress、Joomla和Drupal的密码哈希。默认情况下，PHPass使用软件实现的MD5进行256次迭代。我们用PHP-CPP框架[28]将其替换为对enclave的单个调用。05.1.1速率限制。除了Web服务器的速率限制（例如，失败尝试后的验证码），我们在TEE保护的密码服务（第4.2节）中实现了一个速率限制机制。SafeKeeperTA在内存中维护一个将每个salt（i）与剩余尝试次数（attemptsi）关联起来的映射。为了最大限度地提高灵活性，我们的实现使用64位salt和32位整数attemptsi，尽管如果需要可以减少以减少内存消耗。当对salti调用process()函数时，此函数首先检查attemptsi的值；如果值为零，则仅返回一个错误；否则，attemptsi减一，并返回CMAC结果。enclave存储了treset，即将所有attempts值重置为预定义值attemptsmax的时间。reset_attempts()函数首先获取当前时间；然后，如果treset已过去，则将所有attempts值设置为attempts max，并将treset增加一个预定义值。尽管速率由enclave开发者设置，但用户通过浏览器插件进行验证，因此恶意开发者无法设置任意高的速率。0会议：2018年4月23日至27日，法国里昂举办的Web安全与隐私研讨会3540为了允许enclave重新启动（例如，如果服务器重新启动），shutdown()函数会安全地将状态信息存储在enclave之外。具体来说，enclave会密封CMAC密钥、salt和attempts值的映射以及treset。通过init()函数，可以将这些密封的数据恢复到enclave中。enclave使用硬件支持的单调计数器来防止回滚攻击，即对手试图恢复旧的密封数据。恶意服务器可能会在不首先密封其状态的情况下突然终止enclave以重置attempts值。然而，enclave会检测到这一点，因为密封数据中的计数器值将与当前硬件单调计数器的值不匹配。在这种情况下，enclave无法恢复先前的attempts值-数据已经不可逆地丢失了。因此，唯一安全的做法是将treset设置为未来的某个预定时间，并将所有attempts设置为零（即施加最大惩罚）。这捕捉了最坏情况，即对手已经对所有账户尝试了所有的猜测。请注意，在正常操作中，enclave崩溃应该很少见，并且通过适当的负载平衡，异常enclave崩溃的影响可以分摊。05.1.2 远程认证。远程认证用于向浏览器保证其正在与运行在SGXenclave内部的真实的 SafeKeeper密码保护服务进行通信。它通过从enclave获取引用并使用IntelAttestationService（IAS）进行验证来实现。引用包括在enclave内部执行的代码的不可伪造表示。如第2节所述，SGXSDK提供的远程认证协议涉及四个消息和两个往返，以实现验证者和enclave之间的相互认证。在 SafeKeeper中，浏览器插件无需对enclave进行身份验证。任何实体都可以从enclave请求引用，然后决定是否建立安全通道。我们为 SafeKeeper设计和实现了一种优化的认证协议。由于空间限制，我们将读者引用我们的技术报告[24]以获取此协议的完整细节。05.2 客户端保证机制0我们将 SafeKeeper 的客户端保证机制实现为GoogleChrome浏览器的插件（也可以为其他浏览器开发类似的实现）。我们假设用户可以安全地下载和安装此插件（例如使用Chrome WebStore），并在有更新时接收软件更新。请注意，浏览器供应商正在积极努力确保浏览器插件的安全性[27]。我们的浏览器插件是用JavaScript编写的，由两部分组成：（i）实现主要功能的后台脚本；和（ii）注入到每个网页中以与页面内容交互的内容脚本。因此，插件需要权限来访问标签数据，使用浏览器存储，并捕获和修改某些网络请求。05.2.1 检测密码保护服务。使用 SafeKeeper的Web服务器在具有受保护字段（例如登录表单）的网页的HTTP响应头中发送一个SGX引用。此引用由插件的后台脚本处理，该脚本验证服务的完整性和引用的有效性。具体来说，0插件从引用中提取表示enclave加载的唯一哈希（即 MRENCLAVE值），并检查是否包含在其可信值列表中。此列表可以以类似的方式更新浏览器。如果信任 enclave 的身份，则插件使用IntelAttestationService（IAS）验证引用；参见第5.1.2节。如果认证过程成功，后台脚本为网站生成一个新的DH密钥对，并使用enclave的公钥建立共享密钥。最后，后台脚本更改插件的图标，以指示网站支持SafeKeeper；参见图3。0图3：SafeKeeper 浏览器插件图标：（1）网站上不可用SafeKeeper，或认证协议失败；（2）支持 SafeKeeper并建立了安全通道；（3）SafeKeeper正在突出显示受保护的输入字段（参见第5.2.2节）。05.2.2高亮保护的输入字段。当页面加载时，注入的内容脚本会检查是否存在 SafeKeeper元标签。如果存在，该标签指定了哪些输入字段必须由 SafeKeeper加密。当用户点击浏览器插件图标时，会弹出一个窗口，提供有关当前网页的信息。点击插件图标还作为安全关注序列，如第4.4节所述，因为这不能被对手控制的网页脚本操纵。此操作会向内容脚本发送一条消息，该消息会修改网站的DOM元素，以突出显示受保护的输入字段，并附加一个信息工具提示，以告知用户为什么突出显示每个字段。当用户再次点击图标时，内容脚本会恢复页面的原始外观。当提交网页时，内容脚本会使用与 SafeKeeper密码服务达成的共享密钥加密受保护输入字段的所有值。05.2.3防御恶意客户端脚本。根据我们的对手模型（第3节）的定义，恶意服务器操作员有能力修改网页内容，包括添加客户端脚本。这带来了几个威胁。首先，恶意脚本可能会尝试在用户输入密码时读取密码。已经观察到在野外存在这种行为的客户端脚本用于读取其他类型的个人信息[18]。除了禁用恶意脚本外，使用当前的浏览器插件技术没有其他方法可以避免这种情况，因为脚本在与文本输入字段相同的域中执行。其次，恶意客户端脚本可以尝试伪造  SafeKeeper浏览器插件对输入字段的高亮显示。第三，尽管对手无法检测到  SafeKeeper高亮显示何时被激活，但他可以在恶意脚本中添加时间延迟，以便在用户点击SafeKeeper  图标后伪造  SafeKeeper  UI。目前，GoogleChrome没有直接禁用特定网站的客户端脚本的选项，因此对于  SafeKeeper0Track: Web上的安全与隐私 WWW 2018年4月23日至27日，法国里昂3550我们开发了一种替代方法来实现这一点，即使用内容安全策略（CSP）。使用  SafeKeeper弹出窗口上的切换开关，用户可以禁用单个网站的脚本。然后，SafeKeeper重新加载页面并将我们的自定义CSP元标记注入到标头中，这仍然允许我们注入的内容脚本运行，但阻止页面上的所有其他脚本。这种方法的局限性在于我们注入CSP的时间和其他脚本的加载之间存在竞争条件。然而，我们的实验评估显示，只有直接从本地主机加载的页面才足够快，以逃避我们的CSP。当禁用特定网站的脚本时，插件将此信息存储在Chrome的本地存储中，并在以后访问该网站时继续禁用脚本，直到用户重新启用。然而，禁用客户端脚本通常会对网页的可用性产生负面影响。因此，默认情况下，  SafeKeeper允许客户端脚本。谨慎的用户仍然可以在需要时手动关闭所有客户端脚本。在附带的技术报告[24]中，我们提出了其他方法，可以在不禁用客户端脚本的情况下确保相同级别的安全性。06 评估 6.1 安全分析0根据要求R1的定义，保护密码的综合解决方案必须（i）防止甚至最强大的对手（即恶意服务器）在传输过程中或在服务器上处理期间观察密码；（ii）防止离线密码猜测攻击；以及（iii）无论  A dv的计算能力如何，都可以限制在线密码猜测。在本节中，我们分析了SafeKeeper对每种攻击类型的安全保证。在我们的附带技术报告[24]中，我们进一步讨论了  SafeKeeper对其他类型攻击的抵抗能力，包括回滚攻击、运行时攻击和SGX侧信道攻击。06.1.1密码在传输和服务器上。基于浏览器插件和安全区之间的DH密钥协议的安全通道，确保了密码在网络传输过程中的机密性，以及在输入到安全区之前在服务器上进行处理时的机密性。由于该通道在密码保险库的远程证明报告中具有密码学绑定，客户端软件确保与正确的安全区进行通信。请注意，该通道的安全性独立于浏览器和Web服务器之间建立的任何其他层，例如TLS。因此，即使在TLS/HTTPS协议中存在缺陷（例如[3, 36]），密码的机密性也不会受到影响。06.1.2 离线猜测。在离线攻击中，对手（Adv）将尝试猜测密码并直接将其猜测结果与泄露的密码数据库进行测试，绕过Web服务器的任何在线猜测预防措施。因此，Adv不受速率限制的限制，可以以其可用硬件支持的最大速率执行猜测。然而，为了测试他的猜测，Adv还必须猜测CMAC密钥，因此即使对于非常弱的密码，离线攻击也是不可行的。06.1.3在线猜测。为了避免猜测CMAC密钥，恶意服务器操作员可以通过向SafeKeeper密码保护提交密码猜测来进行在线攻击。0服务在SGX信封中运行。然而，Adv的猜测速率受到SafeKeeper在第5.1.1节中描述的速率限制机制的约束。这增加了猜测密码的难度，增加了所需的时间。例如，如果平均强度的密码提供了大约20位的熵[7]，并且SafeKeeper的有效最大速率设置为N =144次身份验证尝试每天，那么猜测此密码所需的平均时间（即2^19次猜测）将近10年。请注意，这仍然无法保护非常弱的密码（例如短密码或出现在常用密码列表中的密码）。这是基于密码的身份验证的根本限制。尽管我们的速率限制是基于盐的，而盐受到Adv的控制，但Adv无法通过操纵盐的选择来增加他的猜测速率。例如，如果Adv为所有帐户选择相同的盐，他可以将他的猜测与数据库中的所有密码进行测试（例如，每天N次猜测，针对所有帐户进行测试）。然而，如果他选择唯一的盐，他可以对每个单独的帐户进行相同数量的猜测，并且可能在帐户之间变化猜测（例如，每天对每个帐户进行N次猜测）。此外，他可以尝试添加具有猜测密码的虚假帐户，以利用相同密码将导致相同的CMAC值的事实，如果使用全局盐。然而，由于新帐户的密码也必须由SafeKeeper密码保护服务处理，因此每天的猜测尝试次数不受影响。外部对手（即未妥协Web服务器的对手）也将受到诚实服务器操作员实施的任何在线猜测预防机制（例如Captcha）的限制。06.2 可用性评估0为了评估SafeKeeper对R2要求的满足程度，我们对客户端浏览器插件进行了用户研究。该研究的目标是：（i）量化参与者正确使用插件的能力；（ii）评估插件在停用一段时间后的记忆性；以及（iii）分析使用插件的难度。此用户研究按照我们机构的标准实践进行。由于参与者没有被要求使用/披露任何个人数据，因此没有出现数据保护问题。06.2.1参与者和方法。我们使用机构邮件列表和社交媒体招募了86名参与者。参与者被随机分成两组：主要研究组（64名参与者）和对照组（22名参与者）。我们为主要研究组收集了基本的人口统计信息：70％的参与者为男性，30％为女性；年龄在18至39岁之间；参与者的教育资格：2％博士，34％硕士，41％学士，9％高中文凭（14％未指定）。主要组：该组中的每个参与者最初都会看到SafeKeeper信息页面，其中包含了安装我们的浏览器插件时普通用户会看到的相同信息。然后，参与者会得到一组25个网站。这些网站是使用HTTrack[10]创建的受欢迎网站的克隆，并托管在内部机构服务器上。我们稍微修改了这些网站以进行实验；请参见表1。我们没有警告参与者有关欺骗的信息。这些网站对于所有参与者来说都是按相同顺序列出