DFCloud读后笔记

《DFCloud : A TPM-based Secure Data Access Control Method of Cloud Storage in Mobile Devices》读后笔记

DFCloud : A TPM-based Secure Data Access Control Method of Cloud Storage in Mobile Devices(link).

故事梗概

云存储由于给移动设备处理数据带来了灵活性和扩展性，因此被用的越来越多。但安全问题始终是需要被人们重视，尤其是在移动设备尝试去访问云端数据时。作为当今典型的云存储服务Dropbox，其提供了服务器端的加密手段，但是却仍有以下问题：

1. 所有的加密密钥由软件管理然而没有关于客户端软件完整性的证明；
2. 基于用户ID和Password的身份认证过于简单，容易被攻陷；
3. 企业环境中的数据共享由于用户之间不易共享加密密钥而受到了很大的限制；

文章针对典型云存储服务Dropbox中存在的这些问题，提出了一种云存储服务的安全数据访问控制方法DFCloud。我概括主要是客户端的安全性问题，即如何证明客户端是可信的。

1. DFCloud依靠可信平台模块(TPM) 来管理所有加密密钥；
2. DFCloud在合法用户之间定义密钥共享协议；
3. DFCloud框架定义了基于TPM的安全通道设置和密钥管理，以及远程客户端证明和跨多个用户/设备的安全密钥共享协议；

云存储的数据安全

在云存储中，数据是被云服务器存储以及管理，会面临数据泄露的安全问题。这一问题可分为两个方面：

• 客户端泄漏：
  • 如果用户丢失了连接到云存储服务的移动设备，则任何使用该设备的人都可以访问用户的安全敏感数据；
  • 如果用户使用不可信设备访问他或她的云存储，用户的凭据或安全敏感数据可能会被恶意程序拦截；
• 服务器端泄漏：
  • 利用商用虚拟机管理程序的漏洞可能会导致服务器端数据泄漏；

许多商业云存储服务通过引入基于客户端或基于服务器的数据加密来保护存储在服务器存储中的用户数据。

• 基于客户端的加密：
  • 确保用户的数据在传输到服务器之前被加密；
  • 所有与加密相关的组件，如加密过程、库和数据密钥，都由客户端程序托管；
  • 客户端程序为数据加密生成一次性对称密钥，该密钥将使用用户的非对称公钥加密，并与加密数据一起上传到服务器，当用户想要下载他或她的数据时，客户端程序请求这个加密的数据密钥以及数据，然后使用用户的私钥解密数据密钥，最后解密数据；

这种方式的问题在于：加密过程中涉及的密钥由软件方式管理。如果客户端的TCB损坏，攻击者将拦截密钥。

• 基于服务器的加密：
  • 在数据传输发生之前，在服务器和客户端之间建立安全的网络链接；
  • 用户数据被安全地传输到服务器，在服务器中加密，然后存储在服务器的存储器中；
  • 服务器密钥管理器维护唯一分配给每个客户端的数据加密密钥；

这种方式的问题在于：在加密过程之前，用户的数据在服务器中仍然保持为纯文本。因此，攻击者可以利用服务器的漏洞来获取用户数据。

Dropbox在服务器和客户端之间传输数据时，使用的是基于服务器的加密方式和SSL。其用户认证仅取决于用户ID和Password。如果用户使用有效的用户标识和密码对登录，他就可以访问云存储的每个内容。

而本文提出的方案在加密和访问认证方面都做了改进以增强系统安全性，具体如下：

1. DFCloud使用基于客户端的加密方法，保证服务器端数据不会泄露；
2. DFCloud依靠可信平台模块(TPM)功能来管理所有加密密钥，并在合法用户之间定义密钥共享协议；
3. 我们假设每个客户端都是使用ARM TrustZone技术的移动设备，并在信任区环境的安全世界中实现了安全模块，以支持基于硬件的密钥管理；
4. 在使用数据加密密钥之前，DFCloud对每个客户端执行远程证明，以防止客户端恶意程序导致的数据或凭据泄漏。只有当整个客户端系统处于“安全状态”时，才能使用该密钥；

故事设定（威胁模型假设）

• 每个客户端都是支持ARM信任区技术的移动设备，用于基于硬件的密钥管理；
• 由于恶意程序可以驻留在任何移动客户端上，我们假设客户端设备不受信任；
• 云提供商也是不可信的，可被攻击者(包括恶意内部人员)破坏，攻击者可利用服务提供商的漏洞，从而泄露用户数据；
• 我们主要关注客户端或服务器端的数据泄漏，但不关注完整性、一致性或提供商的可用性；

方案设计

总体框架如题所示。

先从左边开始看，在客户端是一个TrustZone enabled的移动设备，分为普通世界和安全世界。普通世界主要是File Explorer组件，它的作用是提供云端和本地的文件列表以及文件基础操作的接口（如执行、删除、复制、移动，这些是不知道密码也可以对密文文件进行的整体性操作），它还可以跟云端服务器进行交互来进行诸如索引、上传、下载密文文件（经它手的都是密文）。

文章中假设整个系统的度量可信根是客户端的安全世界（其实TPM中有三个可信根包括：度量可信根RTM（a root of trust for measurement）、报告可信根RTR(aroot of trust for reporting)、存储可信根RTS(a root of trustfor storage)）。客户端的安全世界里是模拟了一个TPM的运行环境来做Cloud Storage Service即云端存储服务功能（这是因为移动设备基本上都没有TPM，而这一点能成立是由安全世界跟普通世界有强隔离的特性保证的），放了三个子功能进去。

• 第一个子功能是File Handler（文件处理器），主要管理文件数据块的加密或解密；
• 第二个是 Attestation Component （证明组件），用于验证客户端是否处在预知的安全状态。
  • 在系统引导时测量普通世界OS的BootLoader和Kernel image的完整性，并将结果哈希值extend到TPM仿真器的平台配置寄存器(PCRs)；
  • Attestation Component测量完普通世界OS初始完整性后，系统即开始继续引导。在系统完成加载之后的运行时，通过IMA来验证每次加载时测量库和进程的完整性（计算哈希值然后extend进PCR中）。每次服务器端要求远程证明时，就会将PCR中的哈希值传给服务器；（这里内核修改哈希值的可能？修改哈希值需要内核被攻陷，保证完整性能否保证内核不会被攻陷？但是这样的方式（只记录哈希值而不验证，直到服务器远程证明时才进行验证），有可能内核先被攻陷了，坏内核再传递一个正常的哈希值给服务器。在TEE中存储每个模块的正确哈希值，在做完哈希以后就进行校验会将这个检验提前以更好的安全性。但是做哈希这个事是必须先于加载模块的，否则仍有模块拿到内核控制权后修改哈希值结果的问题）
• 第三个子功能是Key Mgmt Component（密钥管理组件），用于创建、管理数据加密密钥。

DFCloud服务器充当代理服务器，管理用户和第三方云存储服务。DFCloud服务器负责维护File Metadata Store，文件元数据存储。文件元数据由文件所有者信息和指向第三方云存储服务上的位置的每个数据块的地址组成。Cloud Service Manager 云服务管理器的具体功能有：

• 当客户端请求用户的文件列表时，云服务管理器将查找存储，组织结果消息并发送到客户端的云服务进程；
• 当客户端请求上传数据块时，云服务管理器会将数据块转发到第三方云存储服务，并将数据块的地址更新到文件元数据存储；
• 当客户端请求下载数据块时，云服务管理器发送数据块在第三方云存储服务中的位置信息。然后，客户端可以直接从第三方云存储服务访问所需的数据块；

整体流程

登录

基本思路：
在第一次使用时，用户应该输入其凭证，如用户ID和PassWord。如果凭证是有效的，那么用户只可以读取存储文件的列表:在获得数据加密密钥之后，可以检索实际的文件内容。为了获得密钥，要求客户端通过服务器的证明并获得证明值(如果客户端满足证明要求，服务器的证明服务将创建证明值，而证明服务将存储用户标识和证明值之间的映射信息以供以后使用)。
具体流程：
如图2中的第一个虚线框所示，流程包括验证用户的凭证、客户端的远程证明和保存证明结果。

1. 当用户发送登录请求时，两个组件交换一个新的随机数N，如果用户的凭据有效，则该随机数由服务器端证明服务创建。
2. 客户端证明组件使用该随机数N、TCB(客户端TPM仿真器中PCR值)和ML(测量日志)创建证明请求。
3. 当接收到来自客户端的证明请求消息时，服务器端证明服务通过与哈希存储的内容进行比较来验证客户端的环境。
4. 最后，客户端接收由证明值H和随机数N组成的响应消息。如果证明通过，客户端的证明组件将证明值H extend到PCR的一个寄存器(例如，PCR14)，否则，如果证明失败，客户端仅接收失败消息，这意味着拒绝服务。

当证明过程成功通过后，现在客户端就可以创建或使用数据加密密钥了。（随机数N的作用？用于防止重放攻击！）

密钥生成和管理

若用户没有预先的数据加密密钥，就开始Key Creation Protocol（图2中的第二个虚线框）。客户端证明组件向服务器发送密钥创建请求，服务器更新用户的状态，以显示用户在当前设备中创建了数据加密密钥。服务器对密钥创建的确认最终被转发到客户端的密钥管理组件，然后它开始创建用户的新数据加密密钥——客户端TPM仿真器创建对称密钥EKA，它将被云服务用于加密和解密过程。

当客户端不使用密钥EKA时（可能是退出程序或者设备关机），密钥以“Sealed Data”的形式存储在客户端的永久存储器中。密钥管理组件请求TPM仿真器使用包括证明值H的PCR（PCR14）的值来seal住密钥EKA。然后，当云服务请求密钥来加密或解密数据块的内容时，将进行证明过程（即验证到此时位置的执行流是否和seal时的一致–通过PCR中迭代得到的哈希值），并在unseal过程之后获取未密封的密钥EKA。如果证明过程失败，则客户端无法获得未密封的密钥；因此，没有人可以访问数据。关于这里的seal有更详细的解释(link1)(link2).

跨设备的密钥共享

一个用户可能会有多个设备，因此可能的应用场景是：用户用了设备A在DFCloud上注册了账户、创建了数据密钥EKA然后用EKA上传了文件X，如果他想要在设备B上访问文件X，他必须在设备B上获得EKA才能解密在DFCloud上加密存储的文件X。
因此本文提出了跨设备的密钥共享协议。主要分为两个阶段：

1. 设备B通过服务器的密钥分发器 Key Distributor将设备B的公钥KB传递给设备A。设备A收到KB后unseal EKA然后将EKA用KB加密后的({EKA}KB)发送给服务器，服务器将其存在自己的数据库中。
2. 对设备B进行身份验证（远程证明），若通过则将({EKA}KB)发给设备B，设备B再用自己的私钥去解密获得EKA，将其用当前PCR的值seal到自己的持久存储中以备下次使用。

数据上传与下载

在登录以后就可以对数据进行上传和下载了，其中数据的加密和解密都是安全世界中的File Handler来进行的，先说下载（即当用户将文件从文件资源管理器复制到本地存储时）：
之后，文件浏览器用文件名向云服务管理器发送下载请求。云服务管理器搜索文件元数据存储，确定存储实际用户数据的源后端云存储服务，并将数据的位置请求转发到该后端云存储。然后，源后端云存储服务将用户数据的位置传输到DFCloud服务器的云服务管理器，云服务管理器将该位置转发到客户端的文件浏览器。

1. 在NW中的File Explorer 和服务器的Cloud Service Manager之间建立下载会话
2. 然后NW中的File Explorer 用文件名向Cloud Service Manager发送下载请求
3. 服务器端的Cloud Service Manager搜索其File Metadata Store，找到实际存储用户加密数据的Backend Cloud Storage，并将数据的位置请求转发到该Backend Cloud Storage
4. Backend Cloud Storage服务会将用户数据的位置传输到DFCloud服务器的Cloud Service Manager
5. Cloud Service Manager将该位置转发到客户端的File Explorer
6. File Explorer可以根据服务器给它的地址在Backend Cloud Storage中下载加密文件
7. 为了解密文件，NW中File Explorer将加密文件发送给SW中的File Handler
8. File Handler将sealed的数据密钥使用当前PCR值和之前在登录时获得的远程证明值来unseal
9. SW中File Handler将数据解密，返回到NW中的File Explorer，由其进行存储到本地路径

相当于在用PCR值和远程证明值证明当前系统是按预期加载的之前，NW是拿不到明文文件的。
上传是下载反过来，先让SW中File Handler将数据加密，然后传给NW中File Explorer。由File Explorer向服务器端Cloud Service Manager发送上传请求和欲上传文件。之后服务器端的Cloud Service Manager会选择目标Backend Cloud Storage，将加密数据上传过去并且更新File Metadata Store。

实施与测评

实施环境

DFCloud是在Open Virtualization’ software for ARM TrustZone（TEE操作系统，类似于OP-TEE）上实现的，在ARM Fastmodel（ARM官网提供的一个固定虚拟平台）上模拟ARM Cortex-A15内核。我们通过修改IMA的源代码来调用TZAPI，而不是TPM_extend操作来将加载的进程和库的测量哈希值扩展的操作放到安全世界，Linux内核用的是2.6.38版本。DFCloud File Explorer是一个跑在NW上的应用，用TZAPI和SW中的组件进行交流。
目前，Open Virtualization实现的TEE OS支持执行数据加密和解密这样的简单安全任务。文章中对安全任务进行了修改，以实现Cloud Storage Service。当File Explorer发送文件加密或解密请求时，Cloud Storage Service使用用户的256位密钥和TEE OS当前支持的RC4加密算法来执行加密操作。
在服务器端，文章实现了在Linux上作为应用程序运行的DFCloud Server Manager，并维护用户信息、用户文件元数据存储和哈希值存储。我们使用Dropbox作为后端云存储服务，Cloud API Layer支持Dropbox API的包装功能。

性能评测

文章测量了DFCloud框架在下载和上传用户文件时的性能开销。设计了三个类别的实验来评估加密操作的开销和正常的世界切换开销：对于同一个文件，分别在没有加密操作、在正常世界中执行加密操作、在安全世界中执行加密操作，三种情况下进行文件下载。
当前的云存储服务支持大规模数据传输，但是由于正常世界和安全世界之间是通过TZAPI和secure monitor进行数据交换的，而这个是有消息大小限制的，因此当前的实现不支持大文件。所以，文章检查了小文件：512Byte、1KB、2KB、4KB四种文件大小来进行测试。结果如下：

目前SW的实现支持一次对最多512字节的数据进行加密或解密，因此使用安全世界进行加密，世界切换发生次数就是文件大小除以512字节向上取整；例如，对于2KB文件，世界上下文切换发生4次。
在SW加密和在NW加密的对比就是世界切换引起的开销；而在NW中进行加/解密和不加密是加/解密带来的开销。趋势也很明显，更多的世界切换或者加/解密更大的文件都会带来更大的开销，几乎是比例增长的。

在文章当前的实现中没有任何性能优化，不过提了两个点：

1. 在SW和NW之间使用共享内存(解除文件传递时512Byte的限制)
2. 在每个世界使用指定的处理器内核(减少世界切换带来的开销)

安全性分析

本文主要关注可能发生在客户端或服务器端的数据泄漏。DFCloud利用客户端加密技术来减轻服务器端数据泄漏，如恶意内部攻击或利用服务器平台的漏洞。DFCloud的移动客户端通过使用ARM TrustZone和在SW上运行TPM仿真器来支持基于硬件的密钥管理。由于每个加密函数都只在安全世界中处理，因此任何恶意程序都无法访问数据密钥。验证客户端的远程证明协议能够确保恶意行为不会在NW中发生。因此，用户可以在安全的移动环境中访问云存储的内容，并使用安全创建和管理的数据加密密钥以加密形式将用户数据存储到远程服务器。