基于区块链的云数据完整性验证研究综述

2023-11-10吴黎兵张壮壮霍丽娟

小型微型计算机系统 2023年11期

杨潇,吴黎兵,张壮壮,霍丽娟

(武汉大学国家网络安全学院,武汉 430072)

1 引言

随着互联网的普及与发展,互联网用户的数量增加,用户数据种类也越加多样化,从简单的文本发展到图片、视频;随着物联网技术的发展,越来越多的终端设备例如汽车、智能穿戴设备等接入物联网.这些都导致了计算机数据呈爆炸性增长.IDC(International Data Corporation)预测,到2025年全球所产生的数据总量将达到163ZB[1].越来越多的数据成为了用户有限存储资源的负担,因此越来越多的用户选择将数据存储在提供云存储服务的云存储服务器上以节约本地资源[2].

在将数据存储到云服务器上之后,用户为了节约本地存储空间往往会将本地数据删除,然而存储在云上的数据并不安全,其完整性难以得到保证.2015年谷歌数据中心遭遇雷击,部分存储于磁盘的上的数据丢失,无法修复;2018年,国内某云服务商内部磁盘发生静默错误,致使一家公司平台数据及备份数据全部丢失;2021年,欧洲规模最大的云计算公司OVHcloud的一个数据中心遭受火灾,导致部分未购买异地备份和灾难恢复服务的用户的数据无法恢复.除了云服务商内部发生软硬件故障及自然灾害造成数据丢失,云服务器还会受到外部黑客的攻击,黑客可能会盗取数据,甚至恶意篡改和删除数据[3,4].云服务商发生事故后,可能会为了维护声誉而选择不公开事故,导致用户数据丢失而用户不知情;恶意的云服务商还会删除用户不常用的文件以节约存储空间.

为了保护云存储数据的完整性,Ateniese等[5-7]等提出了验证云存储数据完整性的方案,基于同态验证标签、抽样策略等方法实现了在不将数据块下载到本地的情况下以常数级别的通信开销实现对云存储数据完整性的验证.但是上述方案中完整性验证证据的验证由数据拥有者(Data Owner,DO)执行,会给DO带来较大的计算开销.Wang等[8-10]提出引入可信第三方审计者(Third Party Auditor,TPA),接受DO的委托对云服务提供商(Cloud Service Provider,CSP)进行挑战和完整性验证证据的验证,使DO免于验证阶段的计算开销.

引入TPA后虽然降低了DO的计算开销,但也带来了额外的安全问题.首先,在基于TPA的方案中,存在着TPA是完全可信的安全假设,然而在现实世界中,不存在完全可信的实体,TPA也可能做出违反云存储数据完整性验证协议的行为.一方面,不诚实的TPA可能会总是返回验证通过的验证结果以节省计算资源,另一方面TPA可能会接受CSP的贿赂,与CSP联合进行共谋攻击欺瞒用户,来掩盖数据受损情况.在基于TPA的方案中,往往还存在着DO是诚实的安全假设.在现实情况中,DO可能会在数据完好的情况下对CSP进行诬陷以寻求赔偿.

其次,在基于TPA的方案中,缺乏仲裁机制,在一方认定协议运行异常的时候,无法通过协议运行信息确定做出违反协议规定行为的一方.

最后,基于TPA的方案存在着中心化局限,整个协议运转依赖于TPA的正常运行,当TPA宕机或者被恶意入侵时,整个验证协议都将失效甚至危害用户的数据安全.

区块链是比特币[11]的底层核心技术,具有去中心化、不可篡改、公开透明、可追溯、可审计等优点[12].区块链本质是一个去中心化的分布式数据库,能够在没有可信中心节点的情况下实现大规模分布式网络中各个节点的数据共识,并能够与智能合约结合,实现可信的分布式计算.

区块链技术与云存储数据完整性验证相结合,利用区块链的去中心化特点可以降低协议中心化风险;利用区块链的不可篡改性、可追溯性可以实现对验证结果的审计,解决三方间的信任问题;利用区块链的公开透明特性,比特币、以太坊等比特币等公有链也可作为外部可信数据源,替代协议中的一些参数,提高协议的公平性与可信性.将区块链技术与云数据完整性验证相结合已经成为一种研究趋势,本文将研究区块链技术在云数据完整性验证领域的研究进展,梳理区块链与现有验证方案结合产生的新技术和新方法,形成图1所示的结构脉络.

图1 基于区块链的云数据完整性验证方法体系脉络Fig.1 Architecture of blockchain-based cloud data integrity verification

2 研究背景

本章将首先介绍云数据完整性验证的相关背景,包括系统模型、安全问题及功能目标.进而介绍区块链技术,包括其原理、特性、关键技术等内容.

2.1 云数据完整性验证

2.1.1 系统模型

通常云数据完整性验证协议的系统模型包含三方,分别是 DO、CSP以及TPA,如图2所示.

图2 系统模型Fig.2 System model

DO:可能是个人用户或者企业用户,拥有大量的数据,需要租用CSP的云存储服务来存储数据.

CSP:对外出租其足量的存储资源及计算资源来盈利.

TPA:具有一定的密码学计算能力,接受DO的委托代替其完成审计任务.

云存储数据完整性验证协议本质上是一个挑战-应答协议,其一般工作流程如下:

1)DO对其要外包的数据进行预处理,例如分块、加密、编码等,然后对每个数据块生成一个标签.

2)DO将数据块及对应的标签集合发送给CSP,并将审计任务委托给信任的TPA.

3)TPA定期生成挑战信息并发送给CSP.

4)CSP接收到挑战后,根据挑战内容生成完整性验证证据,返回给TPA.

5)TPA验证CSP返回的完整性验证证据,并及时将验证结果告知DO.

2.1.2 安全问题

在云存储数据完整性验证模型中,三方互不信任.一方面,当DO存储在CSP中的数据发生损坏,CSP会为了维护声誉或者意图逃避对DO的赔偿而不公开数据损坏的情况;CSP也会删除用户不常用数据以节省存储空间.另一方面DO可能会在数据完好的情况下诬陷CSP,以得到CSP的赔偿.最后,TPA可能欺骗用户,做出违反完整性验证协议的行为,例如,TPA可能会不执行挑战和验证的过程而总是返回验证通过的结果给DO,以节省资源;又或者TPA会与CSP合谋,故意绕过损坏的数据块而总是去挑战完整的数据块来欺瞒用户.总而言之,云数据完整验证协议可能会遇到以下攻击:

1)伪造攻击:CSP伪造完整性验证证据绕过TPA的验证来掩盖用户数据受损的情况.

2)替换攻击:CSP利用没有损坏的数据块及对应的标签来生成完整性验证证据绕过TPA的验证.

3)重放攻击:CSP利用之前生成的完整性验证证据来绕过当前的TPA挑战,这样便不需要保存DO的数据以及标签.

4)共谋攻击:CSP与TPA合谋,或通过精心设计挑战信息绕过损坏数据块,或返回虚假验证结果来欺瞒用户.

2.1.3 功能目标

2.1.3.1 支持动态数据

用户存在云上的文件除了音乐、视频等不会发生改动的静态数据之外,还会有一些会发生改动的文件即动态数据,例如云文档.然而Ateniese[5]提出的方案并不支持动态数据的完整性验证,若存储在云上的数据发生改动,需要重新计算大量的标签,带来极大的计算开销.支持动态数据的思路是维护一个数据结构,记录数据块间的位置关系以及数据块与其验证元数据间的映射关系.Liu等[13-16]引入默克尔哈希树来支持动态数据.Zhu等[17-21]使用线性表来支持动态数据.

2.1.3.2 支持隐私保护

在CSP返回给TPA的完整性验证证据中往往会含有被挑战数据块的线性组合[8],好奇的TPA可能会从中恢复出数据,导致用户的数据隐私发生泄漏.常用的方案是采用随机掩码的方式来解决验证过程中的隐私保护问题[22,23].在数据共享的场景下,还需要考虑保护共享用户的身份隐私问题[24,25].

2.1.3.3 批量审计

批量审计是指审计者TPA可以同时验证CSP返回的多个不同DO的完整性验证证据,而不是依次验证每个证据.批量审计可以在TPA接受了较多审计任务委托的时候极大的提高审计效率,降低TPA的计算开销,是云数据完整性验证协议中非常重要的功能特性.

2.1.3.4 无块验证

利用同态验证标签(Homomorphic Verification Tag,HVT),可以使验证者能够在不接触到数据块的情况下实现对云数据的完整性验证,避免用户数据块在网络上频繁传输的情况,有效地降低通信开销.

2.1.3.5 可追溯性

将验证元数据、挑战信息、完整性验证证据、验证结果等信息公开存储到区块链中,可供任意一方查看.

2.1.3.6 公共审计

由计算资源丰富的TPA或区块链网络接受DO的委托,对CSP进行挑战并验证CSP返回的完整性验证证据来确认云存储数据的完整性,节约DO的计算资源.

2.1.3.7 分布式审计

由区块链网络接受DO的委托执行审计任务,实现分布式审计.能够避免传统中心化TPA带来的单点故障问题,提高协议的可靠性.

2.1.3.8 争议仲裁

当协议运行状态异常的时候,任何一方可以提起仲裁,可以根据存储在区块链中的三方通信信息判断出做出违反协议规定行为的一方.

2.2 区块链

近些年,比特币、以太坊等加密货币得到了越来越多的关注,区块链作为加密货币的底层核心技术也迅速成为了国内外学者的研究热点.如今区块链已经超脱于比特币,代表了结合底层区块结构、P2P网络结构、共识机制、激励机制的一类技术.

区块链的底层即狭义上的区块链数据结构,基本单位称为区块,其中记录了区块链中所有的被确认过的交易.区块之间通过哈希指针逻辑上相连,形成链式结构.区块链结构在整个系统中扮演“账本”的角色,是区块链系统透明性、可追溯性的基础.区块链结构如图3所示.

图3 区块链结构Fig.3 Structure of blockchain

区块链系统通过P2P网络组织各个对等节点,区块链“账本”在P2P网络中的每个节点都保存了一份,单个节点发生故障不会影响系统的正常运作.P2P网络是区块链系统去自治性、中心化特性的基础.

在区块链分布式系统中,为了达到对记账权力、交易有效性的共识,需要有效的共识算法.常用且知名的共识算法有PBFT、PoW、PoS、DPoS等,可以根据网络通信的可信程度及系统的特性选取或设计适配的共识算法.共识机制是区块链系统不可篡改性、安全性的基础.

根据区块链的开放程度,区块链可以分为公有链、联盟链和私有链.公有链允许用户随时加入和退出,无需授权,没有任何限制.联盟链则是多个参与者共同管理的,这些参与者可以是不同的组织或实体.联盟链的参与者需要进行身份验证才能加入链中,链上的交易也需要获得参与者的共识才能被确认和记录.私有链是由一个组织或一个实体完全控制和管理的,只有特定的参与者可以加入链中进行交易和数据管理.随着区块链系统开放程度的降低,系统的共识算法效率高,交易速度更快,但系统的去中心化程度也越来越弱.

区块链具有公开透明、可审计、去中心化的特点,因此区块链与传统云存储安全协议结合会增强安全协议的可靠性,并增加额外的安全特性.目前已有很多研究将云存储安全协议与区块链结合,例如云存储访问控制[26,27]、云存储重复数据删除[28-30]、云数据溯源[31,32]等,本文将着重研究云数据完整性审计安全协议与区块链结合的研究进展.

3 基于区块链的云数据完整性验证

3.1 使用区块链生成挑战

在TPA不可信的场景下,TPA可能会与CSP联合实施共谋攻击欺瞒用户,一种可能的攻击方式是TPA操纵其生成的挑战信息,故意略过损坏的数据块而只挑战完好的数据块,这样每次验证都能通过但是用户数据实际上已经发生损坏.为了避免云数据完整性验证过程中发生上述的共谋攻击行为,挑战信息的生成不能由协议参与的任何一方决定,也不能由任意两方协商决定,因为存在两方共谋攻击其他一方的可能,因此一个可行的思路是使用外部随机源生成挑战信息即使用公有链上的信息作为随机采样函数的种子,使得挑战信息由公开、可验证的信息决定.

为了抵御上述的共谋攻击,Xue[33]提出根据用户指定的时间从比特币公链上取得相应块中的nonce字段来构造挑战信息.类似地,Armknecht[34]提出根据用户给出的时间来选取该时间比特币公链中对应最新块的哈希值作为外部随机源来生成挑战信息.其同时提出了审计TPA行为的思想,并给出了具体设计方案.

TPA除了会与CSP共谋欺骗用户外,可能还会恶意推迟审计时间,即审计者并不在委托期间定期进行完整性审计,而是选择在委托截至期快要到达时集中完成审计任务,这样便不能及时发现CSP上的数据损坏,DO容易遭受损失.为了及时发现恶意延迟审计者的行为,Zhang[35]提出可以通过以太坊的区块高度推算出区块生成时间,而区块中的每一笔交易的生成时间都不晚于区块的生成时间.因此方案提出TPA根据当前最新的12个区块生成挑战信息,生成挑战后生成一条日志记录,记录中包含最新区块的高度来作为日志的时间戳.同时生成一条给数据拥有着转账0以太币的交易,将日志的哈希值填入交易的data字段.后续数据拥有者可以根据日志和区块链中的交易信息判定审计者的审计时间是否符合要求,来防御恶意延迟审计者的攻击.

总而言之,Xue等[33-35]使用了公有链上不同的信息作为采样函数的参数生成挑战信息,Xue[33]使用了比特币上区块头的nonce字段,Armknecht[34]使用了比特币最新区块的哈希值,Zhang[35]使用了以太坊最新的12个区块的哈希值.因为TPA已经不再可信,所以仍需验证挑战信息是否按照协议规定根据公有链生成的,因此TPA需要在审计过程中生成相应的日志记录,例如包含审计时间、nonce值、区块hash值、完整性证据、验证结果等值,供DO检查,带来了额外的计算开销和存储开销,如表1所示.

表1 基于区块链生成挑战的方案对比分析Table 1 Comparative analysis of schemes generating challenge by blockchain

3.2 使用区块链存储验证元信息

区块链本质上是一个分布式去中心化的数据库,其去中心化的特性使其相较于传统的中心化数据库降低了集中控制的风险,消除了单点故障的威胁.而在云数据完整性验证协议中,私有验证模型需要DO在本地存储标签,公共验证模型需要TPA存储标签以及其他的一些验证元信息,因此区块链与云数据完整性验证的一个可能的结合方向是使用区块链存储验证元信息,用于后续的验证过程,避免验证元信息存储服务单点故障造成协议运行终止,提高了协议的稳定性与可靠性.

Wang[36]对基于区块链的私有可证明数据持有进行了形式化建模,给出了私有云数据验证模型在区块链存储验证元信息情况下的基本流程框架,即DO将分块后生成的标签存储在区块链上,在验证阶段分别从CSP处取得完整性验证证据、从区块链中取得验证元信息,最后进行密码学验证计算.类似地,Liu[37]提出了一个IOT场景下的基于区块链的云数据完整性验证方案,与Wang[36]提出的方案相比,Liu提出利用智能合约实现在区块链上对验证元数据的存取,且该方案考虑了云服务器支持密码学运算、不支持密码学计算以及采用P2P文件系统的情况,但未考虑批量验证和数据隐私保护操作等其他功能,且存在重放攻击的风险.基于区块链的云数据私有验证模型如图4所示.

图4 基于区块链的云数据私有验证模型Fig.4 Blockchain-based private validating model for cloud data

与上述私有审计方案不同,Zhao等[38-40]提出了基于区块链的公有审计方案.基于区块链的云数据公有验证框架根据DO是否参与验证流程分为在线验证框架以及离线验证框架两种,具体工作流程如图5所示.在在线验证框架中,DO在完成数据的预处理后会将验证元信息存储在区块链上.在验证阶段,挑战由参与验证过程的DO生成,并分别发送给TPA与CSP,TPA会从区块链上取得验证元信息以及完整性验证证据,并进行后续的验证计算.离线验证框架与离线验证框架不同,DO不会参与验证计算,而区块链又仅承担存储任务不承担计算任务,因此通常的解决方式是CSP会根据事先约定定期生成验证元数据并将验证元数据发送到区块链上,之后由TPA读取区块链取得完整性验证证据进行验证,从这样就免去的挑战生成的过程.

图5 基于区块链的云数据公有验证模型Fig.5 Blockchain-based public validating model for cloud data

在在线验证框架中,DO发起挑战传输给CSP后,CSP根据挑战信息生成完整性验证证据发送给区块链,完整性验证性证据经过打包和验证链接在区块链上后TPA才能从区块链中取得证据,带来了较大的时延.离线验证框架的主要问题是重放攻击问题,因为完整性验证证据的计算已经事先约定好,CSP可以一次性计算出所有的完整性验证证据后删除数据块,之后仅通过标签便可以通过完整性验证,这是因为重放攻击往往是通过每次挑战中利用不同的随机数来防御的.

Zhao[38]提出的方法需要TPA在审计的时候额外向CSP请求加密数据块,这样CSP若删除了数据块则无法通过验证,避免了重放攻击,但是显然方案的验证过程中存在数据块的传输,未能实现无块验证,通信开销较高.Yu[39]提出了适用于车联网环境下的基于区块链的完整性验证框架SC-BOCSA.Yu提出在车联网环境下车辆可能经常处于离线阶段,因此设计了一个离线验证模型以减少车辆在完整性验证过程中的参与程度,具体来说,在初始化阶段,DO和CSP会协商3个参数以确定若干个时间戳来规定CSP计算完整性验证证据的时间点,并根据时间戳来生成用于计算完整性验证的参数.显然可见CSP可以一次性生成后续所需的所有完整性验证证据,可以删除数据块仅用完整性验证证据通过验证,造成重放攻击.

Li[40]提出了一个在线公有验证模型,将加密数据块的哈希值广播到区块链网络中,在验证阶段要求CSP根据存储的数据块计算出默克尔哈希树的树根返回给DO,同时区块链中的其他节点可作为审计者,根据存储在区块链中的哈希值同样计算出默克尔哈希树的树根返回给DO,审计者比较两颗默克尔哈希树的树根值来验证完整性.因为仅仅比较默克尔哈希树的树根存在重放攻击的风险,因此仍需要结合基于双线性对的同态验证标签的验证,效率较低.

文献[36]与文献[37]中验证操作由DO执行,故属于私有审计.而在文献[38-40]中,TPA(文献[39]中由路侧单元RSU担任TPA进行完整性审计)从区块链中提取完整性验证证据后进行审计,故实现了公有审计的功能,此外文献[38,39]属于离线审计框架,挑战时间节点由三方事先约定好,无需DO或TPA发起审计,降低了DO的参与度.而文献[40]属于在线审计框架,需要DO生成挑战并发送给CSP与TPA.文献[39]设计了相应的交易信息结构,结合提出的证据链可以实现更快的地从区块链中提取信息,具有更高的效率和可用性.

3.3 验证流程合约化

随着区块链的发展,其不但可以提供去中心化的账本存储服务,还可以结合智能合约提供灵活的、图灵完备的脚本代码系统,以支持用户对链上数据进行处理,创建高级中心化应用.因此将区块链与云数据完整性验证结合的进一步思路是将验证流程合约化,进一步提高验证服务的去中心化程度,增强了协议的可靠性和功能性.

将验证流程合约化的模型结构通常如图6所示,DO进行数据初始化及生成标签后,会分别将数据外包到CSS.因为合约不能主动执行发起挑战,所以仍需DO发起挑战,并将挑战信息分别发送给区块链以及CSP.模型中一般需要设计两个智能合约:挑战接收智能合约(CRSC)与完整性验证智能合约(IVSC),CRSC 负责接收DO的挑战信息并将挑战信息传输给IVSC,IVSC负责接受来自CSP的完整性验证证明、来自CRSC的挑战信息,并从区块链中读取验证元信息后进行验证计算,判定数据的完整性情况.

图6 验证流程合约化模型Fig.6 Validating model using smart contract

Wang[41]额外设计了一个HVT存储智能合约(HSSC),用来接收数据拥有者生成的同态验证标签,并在验证阶段将相应的同态验证标签发送给IVSC.Yue[42]提出了边缘云存储场景下的数据完整验证方案,在IVSC合约中需要进行哈希运算,而Wang所提出的方案中需要在IVSC中需要进行双线对运算,需要更高的计算成本.与上述方案不同,Wang[43]使用智能合约来保证佣金与赔偿金的强制支付,确保当完整性验证通过时CSP能获得DO所支付的费用、完整性验证不通过时数据拥有着会得到CSP的赔偿.同时为了减少智能合约执行时的通信开销,Wang还引入了非交互式的PDP结构,即去掉了挑战阶段,由CSP定期将完整性验证证据发送给验证者.

总而言之,文献[41]和文献[42]通过设计了智能合约实现了在链上对验证元信息的存取,以及对验证元信息和完整性验证证据的验证计算.文献[43]实现了审计任务委托的合约化,使用智能合约监测验证结果,保证了数据完好时CSP能获取酬劳而数据损坏时用户获得赔偿.上述文献结合智能合约对验证流程实现了合约化,实现了去中心化验证,避免了中心化TPA验证带来的单点故障风险,同时结合智能合约自动强制执行的特性,赋予了完整性验证协议额外的功能特性.

3.4 区块链作为通信平台

区块链是一个去中心化的交易系统,所有的交易都以交易记录的形式被打包在区块中然后链接在区块链上,加之区块链不可篡改的特性,实现了对区块链系统中的每一笔交易的追溯.对于云数据完整性验证这一问题而言,一种可能场景是DO与CSP互不信任,CSP可能对数据损坏进行抵赖,而DO可能在数据完好的是情况下对CSP进行诬陷,这在传统的解决方案下是无法处理的.而结合区块链,可以对云数据完整性验证这一场景设计适配的交易信息结构,使得完整性协议中三方的通信可以在链上进行,或以智能合约的方式,将三方的通信以交易信息的形式公开透明地存储在了区块链上,可以实现由任意一可信实体进行审计,杜绝了共谋攻击、诬陷等其他违反协议规定的行为.

将云数据完整性验证三方的交易信息上链,本质上是将区块链作为一个通信平台.与其他方案中CSP从TPA或DO处取得挑战信息、TPA从CSP处取得完整性验证证据等三方直接通信交换信息不同,将区块链作为通信平台的验证方案要求DO或TPA先将挑战信息、CSP先将完整性验证证据发送到区块链、然后CSP再从区块链中取得挑战信息、TPA再从区块链中取得完整性验证证据,具体流程如图7所示.这样通过将协议中的挑战、证据生成、证据验证步骤都在链上进行,保证了验证过程的公开透明以及可追溯.

图7 区块链作为通信平台的验证方案Fig.7 Validating model using blockchain as communication platform

Lu[44]提出了一个基于联盟链的云数据完整性审计方案,在上述思路的基础上设计了一个TPA选择算法,根据用户对可靠性和响应时间的不同需求快速为用户推荐合适的TPA,通过维护一组TPA和TPA选择算法实现了TPA的动态选择,实现了去中心化审计,因此协议从另一个角度实现了对共谋攻击的防御.Chen[45]提出协议参与者节点间维护一个区块链,系统中的注册信息、挑战信息等会被矿工打包到区块链中,并通过押金机制规范各方行为并保证公平性.Huang[46]结合云数据完整性验证这一场景设计了与之相匹配的基于信用分数的共识算法以及激励机制.此外,方案还提出了辅助链表(ACT)来方便验证者从区块链中提取验证元信息,并支持数据的动态操作.

Xu等[47,48]在上述基础上结合智能合约实现了争议仲裁,即在DO提出数据发生损坏的情况下,利用区块链的可追溯特性,结合存储在区块链中的挑战、完整性验证证据等通信信息,通过调用智能合约实现争议仲裁,找出做出违反协议规定行为的一方,并按照事先约定对违规方进行处罚.通常需要设计两个合约来满足争议仲裁的需求.第1个合约负责实现CSP与DO对验证元信息的共识,当发现数据与验证元信息不匹配的时候终止合约,第2个合约负责追溯区块链中的交易数据来实现争议仲裁.

文献[44]利用Fabric联盟链特性实现了对用户身份信息的保护,但是联盟链并未为提供证据验证等计算服务,而在文献[45,46]中验证计算由区块链执行.文献[44-48]将验证元数据、挑战信息等其他通信信息都在链上进行,使协议运行更加公开透明.文献[47,48]在通信信息上链的基础上设计了具有争议仲裁功能的智能合约,能够防止用户在数据完好的情况下诬陷CSP以及在数据损坏的情况下CSP对数据损坏进行抵赖.

对上述文献以2.1.3节所述功能目标为依据的对比分析如表2所示.其中“-”表示其模型为私有验证模型无TPA,不存在共谋攻击问题.

表2 基于区块链的云数据完整性验证框架总结与对比分析Table 2 Summary and comparative analysis ofBlockchain-based integrity validating framework

4 未来研究方向

基于上述对文献的比较分析,本文认为未来基于区块链的云数据完整性验证方案的研究应集中于以下几点:

1)对数据恢复的支持.现有方案很少考虑对数据恢复的支持,然而在实际的云存储服务场景下,仅仅保证文件损坏能够被发现是不够的,还应该考虑数据损坏后如何进行数据恢复,因为DO在将文件上传到CSP后往往会将本地文件删除.传统方案采用纠错码或纠删码[49,50]对文件进行编码来解决数据可恢复证明(Proof of Retrievabilty,POR)问题,通过容错技术使得文件损坏后能被恢复.然而容错编码会导致文件的大小膨胀,如何利用区块链的特性来优化解决POR问题是一个值得研究的方向.

2)降低DO获得验证结果的时延.使用分布式区块链网络替代中心化TPA完成审计任务时,虽然能有效地避免单点故障的风险,但是只有在验证结果被写入到区块链时,甚至还需经过多个区块的验证后,用户才能得到可靠的验证结果.在用户需要及时了解数据状态的场景下,这种时延是不能接受的,甚至会错过数据恢复的时机.一方面可以通过根据云数据完整性验证的场景设计更加适配更加高效的共识算法来降低时延,另一方面可以通过综合考虑DO对可靠性和验证时延的需求,动态调整共识算法.

3)对数据动态操作的支持.现有的方案往往采用默克尔哈希树作为动态数据结构来支持数据的动态操作,但是基于默克尔哈希树的支持数据动态操作方案往往具有较大的通信与计算开销.一方面,默克尔哈希树由CSP维护,但是CSP是不可信的,每次动态操作后都需要验证CSP是否对哈希树做了相应的正确的修改,带来了额外的计算和通信开销.另一方面默克尔哈希树的调整和存储带来的计算和存储开销也会随着数据量的增加而增大.如果采用由TPA维护的线性表结构作为动态数据结构,如索引哈希表、信息链表等,由区块链来维护这些数据结构也会带来额外的问题.在数据发生动态操作后,线性表中的相应的行数据也要发生改变,然而区块链是一个仅允许添加操作的数据库,如何使用区块链维护一个时常发生变动的表结构并保证能够高效率地检索来支持高效的数据动态操作是一个较为重要的研究方向.

4)协议的攻击与防御.将区块链技术与云数据完整性验证相结合,可以将区块链的去中心化、可追溯等特性赋予给云数据完整性验证协议,但是影响区块链的一些安全问题,诸如双重花费攻击、分布式拒绝攻击、自私挖矿攻击、区块扣留攻击等,也会给协议带来额外的安全隐患.目前很少有对区块链的安全问题会如何影响云数据完整性验证的相关研究,因此对于如何通过攻击区块链来对云数据完整性验证协议进行攻击以及相关的防御措施是一个具有重要研究意义的研究方向.