文章目录
《Building web applications on top of encrypted data using Mylar》论文笔记
1. 论文概述
Web应用程序依赖于服务器来存储和处理机密信息。本文介绍了一种用于构建Web应用程序的平台Mylar，它可以保护数据机密性，防止攻击者完全访问服务器。Mylar在服务器上存储加密的敏感数据，并仅在用户的浏览器中解密该数据。
Mylar主要解决了三个难题：
①Mylar允许服务器对加密文档执行关键字搜索，即使文档是用不同的密钥加密的。
②Mylar允许用户在存在活跃对手的情况下安全地共享密钥和加密数据。
③最后，即使服务器是恶意的，Mylar也确保客户端应用程序的代码是真实的。
实验表明，在Meteor框架上构建Mylar原型的结果是很乐观的：移植6个应用程序平均只需要更改36行代码，并且性能开销是适度的，在聊天应用程序中发送消息时相当于17%的吞吐量损失和50ms的延迟增加。
2. 论文背景
要在Web应用程序上保护机密数据，就要要求用户信任服务器以保护数据免受未经授权的泄露。然而，这种信任通常是有风险的，因为有许多情况可以使机密数据从服务器泄漏。例如，攻击者可以利用服务器软件中的bug来入侵，好奇的管理员可以窥探服务器上的数据，或者服务器管理员可能会被法律强制泄露数据。
一种看似可行的方法是给每个用户分配各自的加密密钥，在Web浏览器中使用该用户的密钥加密用户的数据，并在服务器上仅存储加密的数据。这种模型确保攻击者无法读取服务器上的任何保密数据，因为他们缺乏相应的解密密钥。这种模型也已经被一些具有隐私保护功能的Web应用程序所采用，但是这种方法存在三个显著的缺陷：
①首先，在安全性方面，被入侵的服务器可以向浏览器提供恶意的客户端代码，并提取用户的密钥和数据。因为Web应用程序由许多文件组成，例如HTML页面、Javascript代码和CSS样式表，并且HTML页面通常是动态生成的，所以很难确保服务器没有篡改应用程序的代码。
②其次，在功能性方面，这种方法不能提供用户之间的数据共享，为了解决这个问题，可以考虑用单独的密钥加密共享文档，并将每个密钥分发给通过服务器共享文档的所有用户。然而，经由服务器分发密钥安全性也不能得到保障，因为受损的服务器可以向用户提供任意密钥，并且因此欺骗用户使用不正确的密钥。
③第三，在效率方面：这种方法要求所有应用程序逻辑都在用户的Web浏览器中运行，因为它可以解密用户的加密数据。但这往往是不切实际的，因为进行关键字搜索将需要将所有文档下载到浏览器。
于是本文介绍了Mylar，这是一种用于构建Web应用程序的新平台，它只在服务器上存储加密数据。作者也证明了Mylar适用于许多类别的应用程序，以保护机密数据免受受损服务器的攻击。它利用了Web应用程序框架的形式，即在客户端Javascript代码中实现逻辑，并通过网络发送数据，而不是HTML。这就保证了：
在数据共享方面：为了防止服务器在密钥分发过程中作弊，Mylar通过生成证书路径来证明公钥，并允许应用程序每次使用上下文时指定可以信任的证书路径。结合用户界面组件来显示相应的证书用户，这种技术可以确保服务器不能串通应用程序使用错误的密钥。
通过加密数据进行计算：Mylar提供了第一个加密方案，可以在用不同密钥加密的数据上有效地执行关键字搜索。客户端向服务器提供加密的单词，并且服务器可以返回包含该单词的所有文档，而无需学习该单词或文档的内容。
验证应用程序代码：有了Mylar，在Web浏览器中运行的代码可以访问用户的解密数据和密钥，但代码本身来自不受信任的服务器。为了确保此代码未被篡改，Mylar检查代码是否由网站所有者正确签名。这种检查是可行的，因为应用程序代码和数据在Mylar中是分开的，所以代码是静态的。Mylar使用两个源来简化Web应用程序的代码验证。主源仅托管应用程序的顶级HTML页面，其签名使用服务器的X.509证书中的公钥进行验证。所有其他文件都来自次要来源，因此如果它们作为顶级页面加载，则无法访问主要来源。Mylar根据顶级页面中包含的预期哈希值验证这些文件的哈希值。
3.Mylar的架构
在Mylar中有三个角色：用户、网站所有者和服务器操作员。Mylar的目标是帮助网站所有者在面对恶意或受损的服务器运营商时保护用户的机密数据。
Mylar的结构如图所示。Mylar由以下四个组件组成：
Browser extension：它负责验证从服务器加载的Web应用程序的客户端代码没有被篡改。
**Client-side library：**客户端库。它拦截发送到服务器和从服务器发送的数据，并对这些数据进行加密或解密。每个用户都有一个公私钥对。客户端库将用户的私钥存储在服务器上，并使用用户的密码进行加密。当用户登录时，客户端库获取并解密用户的私钥。对于共享数据，Mylar的客户端创建单独的密钥，这些密钥也以加密形式存储在服务器上。
**Server-side library：**它在服务器上对加密数据执行计算。
**Identity provider (IDP)：**对于某些应用程序，Mylar需要可信身份提供者服务（IDP）来验证给定的公钥是否属于特定的用户名。如果应用程序没有可信的方法来验证创建帐户的用户，并且应用程序允许用户选择与谁共享数据，则应用程序需要IDP。（注：IDP不存储每个应用程序的状态，并且Mylar仅在用户第一次在应用程序中创建帐户时才联系IDP，然后，应用服务器存储来自IDP的证书。）
Mylar在web应用程序上的部署如下：
首先，开发人员使用Mylar的身份验证库进行用户登录和帐户创建。如果应用程序允许用户选择与哪些其他用户共享数据，则开发人员还应指定受信任IDP的URL和公钥。
第二，开发人员指定应用程序中的哪些数据应该加密，以及谁应该有权访问这些数据。当事人对应于公钥/私钥对，并表示诸如用户、组或共享文档等应用层访问控制实体。在我们的原型中，所有数据都存储在MongoDB集合中，开发人员使用包含机密数据的字段集和应该访问该数据的主体的名称（也就是应该使用哪个密钥）。
第三，开发人员指定应用程序中的哪些主体可以访问哪些其他主体。例如，如果Alice想邀请Bob参加一个秘密聊天，应用程序必须调用Mylar客户端来授予Bob的主体对聊天室主体的访问权限。
第四，开发人员更改他们的服务器端代码，以便在执行关键字搜索时调用Mylar服务器端库。我们的原型的客户端库提供了常见操作的功能，例如在MongoDB集合中的特定字段上进行关键字搜索。
最后，作为安装Web应用程序的一部分，站点所有者生成公钥/私钥对，并使用Mylar的捆绑工具使用私钥对应用程序的文件进行签名。Web应用程序必须使用https托管，并且站点所有者的公钥必须存储在Web服务器的X.509证书中。这确保了即使服务器被破坏，Mylar的浏览器扩展也会知道站点所有者的公钥，并且在客户端代码被篡改时拒绝加载。
Mylar的实现流程：
①首先，它验证在浏览器中运行的应用程序代码，以便客户端代码可以安全地访问密钥和明文数据。
②然后，客户端代码在将标记为敏感的数据发送到服务器之前对其进行加密。由于用户需要共享数据，Mylar提供了一种机制，可以在用户之间安全地共享和查找密钥。
③最后，为了执行服务器端处理，Mylar引入了一种新的加密方案，可以对使用许多不同密钥加密的文档执行关键字搜索，而不会泄露加密文档的内容或正在搜索的单词。
下面将按照这样的流程进行展开：
4.用户之间共享数据
在Mylar的威胁模型中，应用程序不能信任服务器来执行共享策略，因为服务器被假设会受到攻击。因此，应用程序必须使用一个只有正确的用户才能访问的密钥来加密共享数据。
每个主体都具有应用程序选择的名称、用于加密该主体的数据的公钥以及用于解密该主体的数据的私钥。
除了允许应用程序创建主体并使用主体的密钥加密和解密数据外，Mylar还为应用程序提供了两个关键操作来管理主体：
①找到一个主体，以便应用程序可以使用相应的私钥解密数据。目的是确保只有授权用户才能访问相应的私钥。
②找到一个主体，以便应用程序可以使用相应的公钥来加密数据或与其他用户共享数据。目标是确保恶意服务器无法欺骗Mylar返回错误的公钥，这可能导致应用程序与对手共享机密数据。
Mylar通过在主体之上形成两个图来加密地实现上述目标：
①访问图（Access graph），它使用密钥链将共享主体的私钥分发给用户。
②一个认证图（Certification graph），它使用证书链来证明主体名称与其公钥之间的映射。
Access graph
打个比方，如果主体A可以访问主体B的私钥，那么我们说A可以访问B。如果B也可以访问C，那么A也可以访问C的私钥。要在访问图中表示应用程序的策略，应用程序必须创建对主体之间关系的适当访问权限。应用程序还可以创建中间主体来表示（比如说）所有用户都应该有权访问相同私钥的用户组。
在这里Mylar使用了和CryptDB一样的密钥链。
例如，在上图中，“party”聊天室的私钥在Alice的公钥下加密，并且也在Bob的公钥下单独加密。服务器存储这些被加密的密钥。Mylar可以通过图2中的API来为用户生成使用不同操作所需要的密钥。
Certification graph
Mylar应用程序在共享数据时必须查找主体的公钥，有两个主要目的：用该密钥加密数据，或者给予某个主体对该密钥的访问。在这两种情况下，如果遭遇攻击的服务器欺骗客户端应用程序使用敌手的公钥，对手将获得对机密数据的访问。例如，在聊天示例中，假设Bob想要向“work”聊天室发送机密消息。如果服务器为聊天室主体提供攻击者的公钥，并且在应用程序客户端使用它，则攻击者将能够解密消息。防止这类攻击很困难，因为所有加密后的密钥都存储在服务器上，而服务器可能是恶意的。
为了防止这种攻击，Mylar依赖于一个认证图，它允许一个主体为另一个主体的名称和公钥做担保。应用程序为主体创建证书链，以颁发机构主体为根源。例如，在聊天示例中，应用可以用创建聊天室的“user：boss”主体的密钥来对“chatroom：work”主体进行签名。使用证书图，应用程序可以通过指定它们要查找的主体的名称沿着它们希望查找的证书链来查找主体的公钥。
5.数据完整性
对于数据完整性，所有加密的数据都通过MAC进行验证。Mylar不保证数据的新鲜性或查询结果的正确性。例如，在聊天室应用程序中，每条消息都有几个字段，包括消息正文和（客户端生成的）时间戳。通过将这两个字段放入身份验证集中，开发人员可以确保攻击者无法将一条消息的主体与另一条消息的时间戳拼接在一起。攻击者可以在不被检测到的情况下将整个身份验证集回滚到较早的版本，但不能回滚身份验证集的子集。
6.加密数据的计算
Web应用程序通常有许多用户，导致数据使用许多不同的密钥加密。用于对加密数据进行计算的现有有效加密方案（诸如关键字搜索）假设所有数据都用单个密钥加密。在Mylar中使用这样的方案将需要一次计算一个密钥，这是低效的。Mylar引入了多键搜索方案解决这一问题。
如果用户想在服务器上的一组文档中搜索一个词，其中每个文档是使用不同的密钥加密的。用户端只需要向服务器提供该单词的单个搜索标记。反过来，服务器返回包含用户关键字的每个加密文档，只要用户可以访问该文档的密钥。
Mylar多密钥搜索的伪代码如下：
但是这种算法的一个效率问题是服务器必须扫描每个文档的每个单词来识别匹配项。 如果文档很大，这可能会很慢，但如果每个单词的加密都是用不同的r来随机化的，这又是不可避免的。
为了能够在可搜索文档中的单词上构造有效的索引，Mylar支持这种多密钥搜索方案的可索引版本。 具体的思路是是在不损害安全性的情况下消除随机性。 直观上，需要随机性来隐藏在同一密钥下加密的两个单词是否相等。 但是对于一个文档中的单词，Mylar可以在文档加密时删除重复的单词，因此同一个文档中不需要每个单词的随机性。
因此，要加密由单词w1，…，wn组成的文档，客户端删除重复项，选择一个随机值R，然后在使用enc（）加密每个单词时使用相同的R。
当在文档中搜索word w时，服务器像以前一样执行调整并获得atk。 然后，它使用文档的随机性r计算v←combine(r，atk)=<r,H2(r，atk)>。 如果文档中的一个单词是W，它的加密将等于V，因为它们使用相同的随机性R。 因此，服务器可以对加密的字执行直接的相等性检查。这意味着它可以在文档中的加密单词上建立索引（例如，哈希表），然后使用该索引和v在不扫描文档的情况下在恒定的时间内确定是否有匹配项。
一个限制是服务器必须对于每一个密钥使用唯一键的索引，而不是一个整体索引。
上述算法的流程如下：
①当创建主体P时，Mylar使用KeyGen生成密钥kp。 每当P接收到对某个新主体A的访问时，Mylar将KA包含在P的包装密钥中。
②有权访问p的用户第一次联机时，该用户浏览器中的Mylar客户机从包装的密钥中检索kA，计算δkp→kA←delta(kp,kA)，并将其存储在服务器中。 对于一对主体，这种delta计算只发生一次。
③为了对某个主体A加密文档，用户的浏览器使用ENC(kA，w)分别对文档中的每个单词w进行加密。 由于多密钥搜索方案不支持解密，Mylar对所有可搜索文档进行两次加密：一次使用多密钥搜索方案进行搜索，一次使用传统加密方案如AES进行解密。
④为了搜索具有主体P的单词w，用户的客户机使用TOKEN(kp，w)来计算令牌tk，并将其发送到服务器。为了搜索加密了主体A的数据，服务器获取δkp→kA，并使用adjust（tk,δkp→kA)将令牌从kp调整到kA，得到调整后的令牌atkA。然后，对于在随机性为r的kA下加密的每个文档，服务器计算v←combine(r，atkA)，并使用索引检查文档中是否存在v。 服务器对p有权访问的所有其他主体重复相同的过程。