APP下载

基于Intel SGX 的安全数据去重方法*

2022-05-09张新宇咸鹤群田呈亮

密码学报 2022年2期
关键词:哈希密钥客户端

张新宇, 咸鹤群, 卢 倩, 田呈亮

1. 青岛大学计算机科学技术学院, 青岛 266071

2. 中国科学院信息工程研究所信息安全国家重点实验室, 北京 100093

1 引言

云存储作为一项能够为用户提供强大的数据管理和存储能力的云服务, 现已成为企业单位以及个人存储和管理数据的主要手段. 随着云存储规模的不断增长, 越来越多重复的数据被存储到云服务器上, 这将造成云存储资源的极大浪费. 为了解决这一问题, 云服务提供商通常会采用数据去重技术来删除云服务器上的冗余数据, 而只保留对应文件的一份副本.

用户将个人数据外包给云服务器, 就意味着必须无条件地信任云服务提供商, 那么用户便会担心个人数据的机密性是否会受到损害. 将数据先加密再上传至云服务器便成为解决这一问题的有效方法. 传统的加密方案会因为用户密钥的不同而使相同的明文产生不同的密文, 这给数据去重带来了困难.

Douceur 等人提出了收敛加密(convergent encryption, CE)[1]. CE 使用明文的哈希散列值作为密钥, 相同的明文经CE 后会得到相同的密文, 在数据的机密性得到保护的同时, 数据去重效率也得到了保障. 尽管CE 简易高效, 但当数据熵较低时, 容易受到字典攻击或者离线穷举攻击的威胁, 并且CE 无法达到语义安全的要求[2]. Bellare 等人提出了消息锁定加密(message-locked encryption, MLE)[3,4]. 在此基础上进行加解密的密钥来自于消息本身, 但仍未从根本上实现语义安全的加密.

有些研究者提出可信第三方服务器(trusted third party, TTP) 可以协助云服务器实现安全的数据去重[5–9]. 首先, TTP 的引入会降低数据去重的效率, 其次, TTP 在现实场景中极难部署, 因此实用价值不高. 现阶段, 寻求一种能够摆脱TTP 的安全加密数据去重方法便成为了热点问题.

2015 年, Liu 等人首次提出了一种无需TTP 的数据去重方案[10], 每一个用户在上传文件之前, 首先运行口令认证密钥交换(password authenticated key exchange, PAKE) 协议与其他用户交互以获取文件加密密钥, 但这需要建立在用户实时在线的前提下. Stanek 等人提出数据流行度(popularity) 概念[11],将数据划分为非流行数据与流行数据. 非流行数据的机密程度较高, 因此采用语义安全的加密算法进行保护. 而流行数据的机密程度较低, 采用高效的CE 即可. 划分数据流行度在一定程度上提高了数据去重的效率, 但针对非流行数据的去重仍然是一个较难解决的问题. 2018 年, Stanek 等人在现有方案的基础上进行了拓展, 提出了新的门限数据去重方案[12], 设计了一套门限密码系统, 提高了非流行数据的安全性, 但是需要借助TTP 作索引服务. 张曙光等人提出一种无需TTP 的安全数据去重方法[13], 采用PAKE 和双线性映射生成冗余性辨识算法, 并运用同态加密算法, 使得初始上传者能够将密钥安全地传递给后续上传者, 然而执行PAKE 协议会产生额外的通信开销. Liu 等人利用CE 和基于身份的广播加密技术相结合设计出一种客户端数据去重方案KeyD[14], 通过数据所有者与云服务提供商之间的交互即可实现安全的数据去重, 但数据所有者的身份隐私存在威胁. Tian 等人提出了一种随机的客户端数据去重方案[15], 该方案使用随机的数据去重方法来防止外部敌手发起的合谋攻击和离线穷举攻击, 并根据两个文件标签存储每个数据以抵抗重复伪造攻击. 此外, 方案借助于动态密钥加密密钥树, 实现了更有效的所有权管理和数据共享. 范永开团队提出了一种基于可信执行环境(trusted execution environment, TEE) 的安全数据去重方案[16]. TEE 被认为是一种基于硬件安全的用户安全执行环境. 在TEE 中运行的程序受到保护, 而多媒体执行环境(rich execution environment, REE) 中的应用程序不能访问TEE 中的程序. 由于TEE的特殊性, 标签生成、密钥管理等敏感操作都限制在TEE 中执行, 从而摆脱了对TTP 的依赖.

2013 年,Intel 推出一种新的硬件安全技术英特尔软件防护扩展(Intel software guard extension,Intel SGX)[17]. Intel SGX 是Intel 架构新的扩展, 这些扩展允许应用程序实现一个被称为飞地(Enclave) 的安全容器, 在应用程序的地址空间中划分出一块被保护的区域, 为容器内的代码和数据提供机密性和完整性的保护, 免受拥有特殊权限的恶意软件的破坏[18]. Dang 等人在Intel SGX 架构上提出了一种安全的服务器端数据去重方案[19], 研究了一个三层体系结构, 不仅减少了服务器端数据去重方案带来的带宽开销, 还在保护数据机密性的基础上保护了所有权和平等信息, 但是由于采用了三层体系结构, 需要额外借助企业/集团级的服务器作为中间辅助, 造成了额外的通信和存储开销. Ren 等人通过引入Intel SGX 设计了一种改进的数据去重方案[20], 避免了传统MLE 方案中加密原语带来的昂贵计算开销, 提高了数据去重效率, 实现了效率和安全性的共同提升. 但其仍然借助了密钥服务器作为TTP.

本文基于Intel SGX 提出了一种安全数据去重方案, 在客户端使用Enclave 安全容器实现了TTP 的功能, 借助Intel SGX 提供的远程认证和数据密封[21]提高了方案的安全性.

本文的主要贡献表现在以下三个方面:

(1) 提出了一种基于Intel SGX 的安全数据去重方案. 利用Intel SGX 提供的Enclave 安全容器作为可信执行环境, 执行敏感操作, 克服了传统方案对TTP 的依赖, 实现无任何TTP 的安全去重.

(2) 首次设计了云服务器与客户端之间的具体安全通信机制. 借助Intel SGX 提供的远程认证机制,构建了云服务器到客户端Enclave 之间端到端的安全通信信道, 提高了数据通信的安全性.

(3) 设计了客户端敏感信息的安全存储方法. 基于Intel SGX 的数据密封机制, 使用与硬件相关信息绑定的安全密钥, 实现本地设备上的隐私信息的安全存储, 能够有效抵抗外部敌手.

2 预备知识

2.1 Intel SGX

Intel SGX 提供了两个安全功能: 认证和密封[21]. Intel SGX 利用基于硬件的认证机制, 使挑战者能够检查特定软件是否已通过加密安全地加载Enclave. 通过认证机制, 挑战者可以与Enclave 建立一个端到端的安全信道, 以传输敏感数据. 数据密封机制可以用来保护存储在Enclave 之外的数据, Intel SGX利用基于硬件信息生成的加密密钥来安全地加密和存储敏感数据, 确保只有在恢复受信任的环境时才能恢复数据.

在Intel SGX 中, 通过认证机制, 挑战者可以确信正确的软件已经在已启用Intel SGX 的平台上的Enclave 内安全运行. 认证机制包括在同一平台上的两个Enclave 之间创建认证(本地认证), 以及扩展本地认证以向平台外的第三方提供认证(远程认证).

在实例化Enclave 时, 硬件提供对其中数据机密性和完整性的保护, 这些数据是在Enclave 内维护的.但是, 当Enclave 进程退出时, Enclave 将被销毁, 并且Enclave 内的全部数据将会丢失. 如果要在以后重用数据, 则Enclave 必须作出特殊处理, 以便安全地将数据存储在Enclave 之外. Intel SGX 提供了数据密封机制, 用户可以请求特殊的密钥, 这个密钥能够结合Enclave 信息和硬件信息做到独一无二, 用来保护存储在Enclave 之外的数据.

2.2 收敛加密

收敛加密[1]是解决云服务器端加密数据去重的有效途径. 对于外包数据M, CE 计算它的哈希散列值K=H(M) 作为密钥, 并使用K对M进行对称加密得到密文C= Enc(K,M), 其中Enc 为确定的对称加密函数. 然后CE 计算T=H(C) 作为M的标签用作去重检查的依据. CE 简易高效, 有效地解决了由于用户密钥不同而导致相同明文被加密为不同密文, 从而引起去重效率降低的难题. 但是, 当数据熵较低时, CE 很容易遭受离线穷举攻击. 即攻击者通过穷举M′的内容, 并通过计算其哈希散列值作为密钥加密M′, 进一步加密计算得到密文C′及标签T′, 通过比较C′=C,T′=T, 如果等式成立, 那么原数据M的内容便遭到了泄露. 尽管CE 存在一定的问题, 它仍然是加密数据安全去重方向的一个经典思路, 近年来的绝大多数优秀方案都是基于CE 改进而来的.

2.3 所有权证明

所有权证明(PoW) 的目的是让云服务器能够验证一个客户端用户是否真正拥有某份文件, 这样就避免了恶意客户端在知晓部分文件内容的情况下成功地欺骗云服务器的威胁. Halevi 等人最早提出了PoW的概念并实现了一种基于默克尔哈希树(merkle hash tree, MHT) 的PoW 方案[22]. 云服务器为每份文件创建一棵独立的MHT, 并只保留其根结点的数据. 通过PoW 发起挑战, 客户端根据挑战内容计算并返回有效的兄弟结点路径. 云服务器使用客户端返回的信息重新构建MHT′, 当root(MHT′)=root(MHT)时, PoW 验证成功.

3 系统与攻击者模型

3.1 系统模型

在本文的方案中, 系统模型包含两类主体, 如图1 所示.

图1 系统模型Figure 1 System model

(1) 客户端用户U: 客户端用户U通过购买或者租赁的方式获得云服务器的存储空间, 然后合法地将数据存储至云服务器, 并在需要的时候能够请求下载自己的数据.

(2) 云服务器S: 云服务器S即云存储服务的提供者, 不仅为用户提供巨大的云存储空间, 还拥有强大的计算能力. 由于用户规模庞大,S通常使用数据去重来提高云存储资源的利用率.

3.2 攻击者模型

在本文的方案中, 考虑两种可能的攻击者: 内部攻击者和外部攻击者.

(1) 内部攻击者: 由于云服务器S是诚实但是好奇的, 因此它能够在用户不知晓的情况下, 访问用户上传的隐私数据. 云服务器这种攻击行为体现的意志可能来自云存储服务提供商或其员工. 他们拥有云服务器强大的计算能力并且掌握着用户数据的密文以及相当多的相关信息, 因此可能通过离线穷举攻击等方式尝试破解密文.

(2) 外部攻击者: 外部攻击者通常被认为是一个试图非法获取其他用户隐私数据的恶意用户, 一方面,该类攻击者可能通过远程攻击客户端本地设备来获取隐私数据的相关信息; 另一方面, 他可以截获其他用户与云服务器之间的通信. 除此之外, 他还可能试图通过伪造身份验证信息来欺骗云服务器.

4 方案设计

4.1 方案概述

本文设计实现了一种基于Intel SGX 的安全数据去重方案, 其中去重检查所使用的依据信息, 加密文件所使用的收敛密钥以及所有权证明所使用的验证信息都是基于合法客户端用户掌握的隐私集合生成的.Intel SGX 的Enclave 安全容器作为可信执行环境执行敏感操作, 克服了传统方案对TTP 的依赖. 远程认证机制能够构建云服务器到客户端Enclave 之间端到端的安全通信信道, 以便云服务器安全地向客户端Enclave 传输敏感信息. 数据密封机制能够通过结合硬件信息生成的密封密钥, 将隐私集合安全地存储在用户本地设备上, 有效抵御外部敌手的攻击.

4.2 方案实现

4.2.1 初始设置

假设每一个合法客户端用户U都被分配了一个公共隐私集合Aα={a1,a2,··· ,am},|Aα| =m, 并且Aα被U使用Intel SGX 的数据密封机制安全地存储在客户端中. 在云服务器S上需要初始化一个记录表R用来支持数据去重. 除此之外, 需要完成客户端创建的EnclaveE与S之间的远程认证, 以构建安全的通信信道, 进而保护后续操作中S向客户端E中传递信息的机密性.

4.2.2 数据上传

当U想要向S上传一份文件F*时,U首先计算F*的哈希值标签hF=H(F*), 然后将hF发送到E中, 在E中基于隐私集合Aα生成一个隐私密钥kα=G(a1||a2||···||am,tdm),ai ∈Aα. 其中, tdm作为单向陷门函数G的陷门. 接着计算出一个身份验证信息ξF= HMACkα(hF), 然后将ξF发送给S.上述操作流程如图2 所示.

图2 身份验证信息生成过程Figure 2 Authentication information generation process

当S接收到ξF后, 它首先检查ξF是否已经存储在R中, 因此ξF便成为了数据去重检查的依据.如果在R中没有存储ξF, 即ξF对应的文件没有存储在S上,U便被视为对应文件的初始上传者. 否则,U便被视作相应文件的一位后续上传者.

(1) 初始上传者情况

S生成一个验证参数s并将其存储到R中, 之后通过安全信道将s发送回E中. 当E接收到验证参数s后, 它首先计算出一个收敛密钥kc=E(hF,HMACkα(s)), 然后U在密钥kc下使用确定性的加密方案加密文件F*得到密文CF.

与此同时, 在客户端E中使用隐私集合Aα以及hF生成一个所有权证明初始值Am=⊕mi=1Ai, 其中Ai= HMAChF(ai). 随后,E在本地删除收敛密钥kc, 然后将密文CF以及Am发送给S,S将Am以及代表密文CF存储路径的loc(CF) 一并存储到R中. 至此, 初始上传者的文件上传操作已经完成. 上述操作流程如图3 所示.

图3 文件上传过程Figure 3 File upload process

(2) 后续上传者情况

如果U被视为相应文件的一位后续上传者, 那么S需要通过执行PoW 验证U对文件的所有权, 关于PoW 阶段的操作流程如图4 所示.

图4 所有权证明过程Figure 4 PoW process

4.2.3 数据恢复

当合法客户端U想要下载曾上传到S上的文件时,U向S发送一个文件下载请求.S接收到下载请求后, 验证U是否拥有访问该文件的权限. 有关权限验证的方法超出了我们方案的研究范围, 因此在这里没有具体讨论. 文件下载恢复过程如图5 所示. 如果U拥有文件的访问权限,S将密文CF以及验证参数s发送给U.U使用文件的哈希值标签hF在客户端E内计算生成文件的收敛密钥kc=E(hF,HMACkα(s)), 并利用kc解密CF获取原始文件内容. 否则,S便会拒绝U的下载请求并返回错误信号.

图5 文件下载过程Figure 5 File download process

5 安全性分析

本文从身份验证信息的安全性、密钥的安全性、抵抗穷举攻击以及PoW 的安全性四个方面来分析验证方案的安全性.

5.1 身份验证信息的安全性

在本文方案中我们使用身份验证信息ξF作为数据去重的检查依据,ξF通过隐私集合Aα以及文件哈希值标签hF计算生成, 其作用是防止没有权限的恶意用户访问文件.ξF的安全性可以从以下两个方面来证明.

5.1.1 文件哈希值标签的唯一性

对于一个安全的哈希函数H, 它应该具有三个基本特性:

(1) 单向性: 对于任一给定的消息M, 哈希函数H可以很容易地计算出对应的散列值HM. 然而给定散列值HM′, 找到消息M′使得H(M′)=HM′在计算上是不可行的.

(2) 抗弱碰撞性: 对于任一给定的消息M1, 试图寻找一个消息M2使得H(M1)=H(M2) 在计算上是不可行的.

(3) 抗强碰撞性: 试图寻找一对不同的消息M1和M2, 使得H(M1)=H(M2) 在计算上是不可行的.基于上述的三个性质, 可以认定文件F的哈希值标签hF是唯一的.

5.1.2 隐私密钥的安全性

本文方案中, 隐私密钥kα=G(a1||a2||···||am,tdm),ai ∈Aα, 其中G是一个单向陷门函数,G具有两个性质:

(1) 对于任一给定的函数G定义域内的x, 可以很容易地计算出y=G(x).

(2) 对于任一函数G值域内的y, 除非掌握陷门z, 否则试图计算出x使得G(x)=y是不可行的.

G是一个单向陷门函数, 类似于密码学中的非对称加密, 已知x可以很容易地计算出y=G(x), 但除非掌握陷门值z, 否则在已知y的情况下想要求解x=G-1(y) 在计算上是不可行的, 这里的陷门值z可以看做非对称加密中的私钥. 如4.2.2 节所述, 身份验证信息ξF= HMACkα(hF),ξF的生成需要两个关键参数, 一个是隐私密钥kα, 另一个是文件哈希值标签hF. 因此, 如果不能够同时掌握kα和hF, 就不能通过身份验证信息的检查, 也就无法继续进行后续的恶意访问.

5.2 密钥的安全性

本文方案中包含了两种密钥, 隐私密钥kα和收敛密钥kc. 在上节中我们已经证明了隐私密钥kα的安全性, 接下来我们对收敛密钥kc的安全性给出证明.

在4.2.2 节中我们描述了kc的生成过程kc=E(hF,HMACkα(s)). 计算生成kc需要三个参数: 哈希值标签hF、验证参数s、隐私密钥kα. 已经证明了hF和kα的安全性, 验证参数s是由云服务器生成的, 并通过Intel SGX 创建的安全信道加密传输至客户端Enclave, 外部敌手无法通过任何手段获取到s.

假设存在一个外部敌手A1,A1能够通过远程损害客户端机器来窃取用户的隐私信息, 那么如果将密钥存储在本地环境中, 显然A1可以轻易地得到. 为了防止这种情况的发生, 本文借助于Intel SGX的Enclave 安全容器来进行密钥管理, 因而A1无法获取到Enclave 中的密钥. 同时,A1也无法知晓在Enclave 中使用的加密算法. 因此, 即使敌手A1窥探到存储进Enclave 容器中的数据, 也无法从中获取任何有效信息.

5.3 抵抗穷举攻击

假设存在一个外部攻击者A2,A2能够对存储在云服务器中的密文信息发动蛮力穷举攻击.A2发动蛮力穷举攻击的过程包括三个部分:

(1) 穷举文件F的内容获取文件哈希值标签hF, 使用CarF表示文件域基数, 其大小与文件内容大小成正比, 与文件的数据熵成正比, 计算分析可知A2穷举文件内容的过程的时间复杂度为O(2CarF), 即穷举成功概率为1/2CarF;

(2) 穷举隐私集合Aα内容获取隐私密钥kα, 其中|Aα| =m, 那么A2成功穷举得到隐私集合的概率为1/2m;

(3) 计算ξF=HMACkα(hF) 获取身份验证信息进行验证.

本文提出的安全数据去重方案能够有效地抵抗蛮力攻击, 即敌手已知存储在云服务器上的密文, 通过蛮力穷举的方式猜测出原始数据信息, 成功的概率是可忽略的. 即

根据上述分析,A2能够通过穷举攻击成功的概率为(1/2CarF)×(1/2m). 因此可以认定, 当需要存储的文件体积较大, 并且文件的数据熵较高时, 在计算上是不可行的. 并且, 可以通过调整m的值来满足上述要求. 因此, 本文方案可以有效地抵抗蛮力穷举攻击.

5.4 PoW 的安全性

在本文方案中, 当U被认为是一个后续上传者, 那么S便会通过PoW 验证U对文件的所有权. 所有权证明过程分为三个部分: 发起挑战、生成证明、验证结果.

上述等式证明了PoW 过程中S对U生成的证明的验证结果. PoW 需要使用两部分信息, 一个是S随机选择的隐私集合的m/2 元子集Y, 另一个是文件哈希值标签hF.hF的唯一性已经证明, 下面就集合Y的安全性开始讨论. 在每次S发起挑战时,S会随机的从Z={1,2,··· ,m}中产生出一个m/2 元子集, 意味着每次执行PoW 过程的挑战与证明内容都是不相同的. 假设存在一个外部敌手A3, 他能够窃听用户与云服务器之间的通信内容, 从而获取相关信息试图攻击加密数据. 在发起挑战阶段,S生成的挑战是通过Intel SGX 创建的安全信道传输至客户端的,A3无法获取挑战信息的内容.U通过挑战信息生成证明, 并将其返回给S. 在这一阶段, 即使A3通过窃听手段获取到证明内容, 也无法通过[Ym,Xm] 获取到有关文件内容的相关信息, 因而恶意敌手A3无法威胁PoW 的安全性.

6 性能评估

本方案采用C++ 语言, 利用OpenSSL[23]函数库进行算法实现. 实验环境使用具有2.10 GHz 的6 核Intel(R) Core(TM) i5-8500T 处理器的DELL 台式机模拟客户端, 运行的操作系统是Windows 10,并使用具有2.10 GHz 的4 核Intel Core Processor 处理器模拟云服务器, 运行的操作系统是Windows Server 2012 R2.

在实验中, 本文采用SHA-1 作为Hash 函数, 利用HMAC-SHA-1 算法计算身份验证信息, 基于AES-256 对称加密算法对文件进行加解密.

实验分为3 个部分:

(1) 性能分析. 从通信开销和存储开销两个方面分析本方案的性能, 并与其他优秀方案进行比较.

(2) 计算开销. 测试本方案在文件上传过程中各阶段所需的计算开销. 然后, 测试本方案进行所有权证明所需的计算开销. 最后, 测试本方案的总体计算开销, 并与其他优秀方案进行对比.

(3) 方案特点. 分析本方案的特点, 并与其他优秀方案进行比较.

6.1 性能分析

本文从理论上对方案进行性能分析, 包括通信开销与存储开销两大方面, 并与当前优秀方案进行对比.对于一份需要外包的数据M, 采用SC表示密文规模,ST表示标签规模,Ss表示验证参数规模,SξF表示身份验证信息规模,SAm表示所有权证明初始值规模,Sh表示哈希规模,Ssk表示私钥规模,Sk表示加密密钥规模,St表示默克尔树规模,SAα表示隐私集合规模,Std表示陷门规模,Sbm表示双线性配对元素规模,SID表示用户表示规模,Sblind表示盲签名规模.

分析文件上传过程所消耗的通信开销并与Key-sharing[7]、stanek[12]与Dang[19]进行比较, 结果如表1 所示. 由于本方案无需TTP 的支持, 节省了大量的通信开销.

表1 通信开销比较Table 1 Communication overhead comparison

存储开销分析包含对云服务器端, 客户端以及TTP 端的存储开销的分析, 由于本方案无需使用TTP,因此不需要额外的存储开销. 结果如表2 所示.

表2 存储开销比较Table 2 Storage overhead comparison

6.2 计算开销

本文对方案的计算开销进行了测试. 为了测试不同大小的文件在文件上传过程中的计算开销, 我们选取了5 组文件, 大小分别为16 MB、32 MB、64 MB、128 MB、256 MB, 分别测试每组文件在文件上传过程各阶段的计算开销. 实验数据均取10 次测试结果平均值进行记录. 结果如图6 所示.

图6 不同大小文件的计算开销Figure 6 Computation overhead for different file size

可以看出, 文件哈希标签生成阶段、文件对称加密阶段以及文件上传阶段的平均计算开销都随着文件大小的增大而呈线性增长. 身份验证信息生成阶段的平均计算开销比较短暂, 几乎可以忽略不计. 除此之外, 在整个过程中, 文件对称加密阶段和文件上传阶段的平均计算开销占比最高.

另外, 我们以上传32 MB 大小文件为例, 测试了所有权证明所需要的计算开销, 结果如图7 所示.

图7 所有权证明计算开销Figure 7 Computation overhead for PoW

所有权证明过程分为三个阶段: 初始化阶段、证明阶段以及验证阶段. 可以看出, 在所有权证明过程中, 计算开销占比最大的是生成证明阶段. 生成证明阶段是在客户端进行的, 而计算开销较小的初始化阶段以及验证阶段则是在云服务器端执行.

为了评估性能, 将本方案与ClouDedup[5]、Key-sharing[7]与Dang[19]进行了对比. 其中ClouDedup[5]与Key-sharing[7]分别是需要借助TTP 来实现安全去重的先进方案; 而Dang[19]是摆脱了TTP 使用Intel SGX 的Enclave 作为安全执行环境的安全去重方案. 我们测试了各方案的总体计算开销并与本方案进行比较, 结果如图8 所示. 实验表明本方案的总体计算开销相较于其他方案有着较好的表现.

图8 计算开销比较Figure 8 Computation overhead comparison

6.3 方案特点

将本方案与一些代表性方案进行了比较, 结果如表3 所示.

表3 方案特点比较Table 3 Characteristic comparison

本文通过对能否摆脱TTP、是否改进收敛加密、是否考虑安全通信以及是否实现所有权证明四个方面对比了本方案与其他几个方案的特点. 在ClouDedup[5]方案中, 需要借助TTP 来实现对用户的身份验证, 对数据块签名执行访问控制以及数据加解密. 在Key-sharing[7]方案中, 同样需要借助TTP 来实现数据去重检查、所有权证明以及密钥管理等. TTP 的使用对方案的整体实用性产生了一定的限制.TEE[16]方案借助TEE 安全执行环境实现了TTP 的功能, 虽然成功摆脱了TTP 的限制, 但本方案与之相比较, 还考虑了服务器与客户端之间的安全通信问题, 进一步提高了安全性. SGXDedup[20]引入Intel SGX 卸载了传统MLE 加密方案昂贵的计算开销, 基于Intel SGX 的特性维护其安全性, 提高了数据去重效率, 但并未摆脱TTP. 通过上述比较可以看出, 本方案具有综合优势.

7 结论

本文提出一种基于Intel SGX 的安全数据去重方案, 利用Enclave 安全容器作为安全执行环境实现了TTP 的功能, 摆脱了TTP 的限制. 首次设计了云服务器与客户端之间的具体安全通信机制, 利用Intel SGX 提供的远程认证机制构建云服务器与客户端Enclave 之间端到端的安全信道, 使得云服务器能够安全地向客户端传递敏感数据信息. 借助Intel SGX 提供的数据密封机制, 使用与硬件信息相结合生成的安全密钥, 实现了本地设备上的隐私信息的安全存储. 安全性分析与性能评估证实了本方案拥有较高的安全性以及实用价值.

猜你喜欢

哈希密钥客户端
你的手机安装了多少个客户端
“人民网+客户端”推出数据新闻
——稳就业、惠民生,“数”读十年成绩单
幻中邂逅之金色密钥
幻中邂逅之金色密钥
哈希值处理 功能全面更易用
Windows哈希值处理不犯难
文件哈希值处理一条龙
Android密钥库简析
虚拟专用网络访问保护机制研究
巧用哈希数值传递文件