相关审计论文

相关标签

基于嵌套Merkle hash tree区块链的云数据动态审计模型

发布时间:2019-09-12 16:18

  摘要:云存储凭借高扩展性、高可靠性、低成本的数据管理优点得到用户青睐。然而,如何确保云数据完整性成为亟待解决的安全挑战。当前最成熟、高效的云数据完整性审计方案是基于半可信第三方来提供公共审计服务,基于半可信第三方审计方案存在单点失效、算力瓶颈和错误数据定位效率低等问题。为了解决上述问题,本文提出基于区块链的云数据动态审计模型。本文模型采用分布式网络、共识算法建立一个由众多审计实体组成的区块链审计网络来解决单点失效、算力瓶颈问题;引入变色龙哈希算法和嵌套 MHT 结构,在保证区块链数据可信度的前提下,实现云数据标签在区块链上的动态操作;借助嵌套 MHT 结构以及辅助路径信息,提高了在审计发生错误时对错误数据定位效率。实验结果表明, 与基于半可信第三方云数据动态审计方案相比,本文提出的模型显著提高审计效率、降低数据动态操作时间开销、提升错误数据定位效率。

  关键词: 区块链;云存储;动态操作;审计;变色龙哈希

  云计算是近几年的研究和应用的热点,云存储作为云计算的重要服务模式之一,其目地是利用云计算技术将大量低成本,低可靠性的设备协同起来,向用户提供高可靠、高弹

  2 计算机应用性、高性能、低成本的数据存储服务[1]。用户在享受便捷的云存储服务时,云存储也曝露出以下安全问题:(1)用户数据的所有权和控制权相互分离,云服务提供商(Cloud Service Porvider,CSP)可能出于经济目的故意删除用户不经常访问的数据或者冗余数据;(2)CSP 可能出现软件失效或硬件损坏,直接导致用户数据丢失或者损坏;(3)云数据可能遭到其他用户的恶意损坏。因此,为了验证用户云数据的完整性, 数据审计方案应运而生。其中,基于半可信第三方审计(Third Party Audit, TPA)文献[2-7]是最具有代表性的审计方案,但上述基于 TPA 方案存在以下缺点:(1)单点失效:所有用户的云数据都由唯一的 TPA 实体完成审计,因此一旦 TPA 实体功能失效,则整个审计系统瘫痪;(2)性能瓶颈:随着云用户和云数据规模增大,TPA 需要处理的数据规模也会增大导致审计时间会急剧加大,因此 TPA 的算力成为了整个审计系统的瓶颈;(3)错误数据定位:在云数据审计文献[2-5,7-15]方案中,均不支持用户错误数据定位,不能为后续数据修复工作提供参考,文献[6]方案中虽然支持错误数据的定位,但定位效率仍然不高。

  在充分研究了用户与 CSP 的信任矛盾和 TPA 审计模型的缺陷后,本文提出了基于去区块链的动态云数据审计模型。本文方案借助区块链去中心化、高扩展性、安全可信等特点, 将独立TPA实体的审计任务和用户数据标签一同转移到区块链上,采用分布式 TPA 实体来完成审计业务,利用区块链的分布式账本模型来存储用户的数据标签。 此外,本文在深入了解区块链系统和审计方案对用户动态数据的审计需求后, 在保证区块链分布式账本安全可信的基础上,结合已有的变色龙哈希算法和新提出的嵌套 MHT 结构实现对用户存储在区块链上数据标签的动态操作功能。

  1 相关工作

  数据完整性审计是数据拥有者检测远程云服务器中数据完整性的最佳途径和方法,本文主要研究的方向是数据持有性证明。

  2007 年,Anteniese 等人[12]首次提出了基于 RSA 签名的数据完整性验证方案(Proofs of Data Possession, PDP)。文献[12] 方案采用抽取数据样本的策略,利用 RSA 同态的特性,结合其首次提出的样本抽样策略,能够在相同可信度基础上,明显减少了验证数据的数量,有效减少了计算代价和通信开销。但文献[12]方案只支持静态云数据审计。在动态操作数据的情况下,插入或删除数据块,需要用户重新生成修改后数据块之后的全部前面,大大消耗用户的计算资源。同年,Anteniese 等人就文献[12]方案进行改进,提出了动态云数据审计方案(Dynamic Proofs of Data Possession, DPDP)方案[13],但文献[13] 方案只支持云数据的更新、删除和追加操作,不支持云数据插入操作,不能称得上完全的动态数据完整性验证方案。

  2009 年,Erway 等人[7] 采用基于排名的认证跳表动态数据结构和 RSA 签名机制来支持全动态数据操(Scable Dynamic Proofs of Data Possession, SPDP)方案。文献[7]方案是第一种支持全动态数据操作的 PDP 方案,但其存在寻找节点时间开销随着分块文件数量规模增大而快速增大,导致动态操作效率低下;此外,动态数据操作需要修改跳表中认证路径上所有节点的哈希值,需要计算大量辅助消息,存在计算代价和网络开销都比较大等缺点。

  2011 年,Wang 等人[5]提出了采用 MHT 和 BLS 签名机制的支持公开审计的动态数据完整性验证方案(Public Proofs of Data Possession, P-PDP)。文献[5]方案中采用 MHT 结构保证数据块在空间上的正确性,通过 BLS 签名的 PDP 机制来保证数据在内容上的完整性。该方案的优势在于:(1)借助 BLS 签名算法,用户可以将繁琐的审计任务转交给 TPA 来完成,从而实现公开审计;(2)相较于 RSA 签名机制,BLS签名机制具有更低的计算开销和通信开销;(3)借助 MHT结构,该方案认证路径长度更短。相较于文献[13]方案,文献

  [5]方案在节点查询、生成的认证路径速度更快。但该方案中,用户将云数据审计工作交给了 TPA 处理,随着用户数量、托管数据增加,最终会导致 TPA 承担繁重的计算开销,大大影响 TPA 性能;此外,该方案仍不支持审计发生错误时对错误数据的定位。

  2013 年,Kan Yang 等人[6]提出基于索引表结构和 BLS 签名算法,支持完全动态数据操作的 PDP 机制(Efficient Proofs of Data Possession, EPDP)。在该方案中,由于采用的索引表是通过连续的存储空间实现分块文件元数据存储,导致删除和插入操作会移动大量的数据。随着用户数据规模扩大、分块文件数量增多,删除和插入操作的时间开销会急剧增大,直接导致动态操作后的验证时间开销增大使得其审计效率低于文献[5]方案;此外,该方案同样采用基于 TPA 的审计模型,同样存在单点失效和算力瓶颈缺陷。

  2016 年,李勇、姚戈等人[8]在文献[5]方案研究的基础上, 针对构建 MHT 中认证路径过长问题,改进 MHT 结构为多路分支树结构(Large Branching Tree, LBT)结构,提出基于 LBT结构的PDP 审计模型(Large Branching Tree Proofs of Data Possession,LPDP)。LBT 采用多分枝路径结构,所需构造的 LBT 深度随着出度的增加而减少,进而减少数据完整性验证过程中的辅助信息,简化了数据动态更新过程,降低了系统中实体之间的计算开销。但该文献[8]方案依然采用文献[5]方案中基于 TPA 的审计模型,依然存在单点失效、算力瓶颈等问题。

  2017 年,Garg 等人[9]在文献[5]方案引入的 MHT 结构上附加了相关索引和时间戳, 提出了 RIST-MHT( Relative indexed and time stamped Merkle hash tree)结构,提出基于RIST-MH 结构的 PDP 审计模型(RRIST Proofs of Data Possession, RPDP)。文献[9]方案提出的 RIST-MHT 结构相较于 MHT 结构之上,一方面缩短了 MHT 中认证长度从而缩短了节点查询的时间开销,另一方面在标签中添加时间戳属性, 赋予标签数据新鲜度。但该方案依然没有解决文献[5]方案中存在的问题为了让用户对已有的数据持有性证明审计方案有客观的认识,本文从审计时间复杂度、动态操作支持、错误数据定位三个视角对文献方案进行分析对比分析,具体分析如表 1 所示。

  (n 是文件块数目、t 是审计过程中挑战的文件块数目、s 是文件块二级分块文件数目、M(Modify)是更新操作、I(Insert)是插入操作、D(Delete)是删除操作、EL(Error data Locate)是错误数据定位)从数据持有性证明方案的发展来看,最近 5 年来的主要研究方向主要是基于文献[5]方案中,对 MHT 认证路径缩短、隐私保护方向加以改善,就计算开销而言没有实际的改进。就审计计算量方面而言,文献[5]方案凭借其简洁的审计过程, 不需要额外的辅助数据,反而较文献[6][7][9]方案在计算量方面更小。就支持错误数据定位的动态云数据审计方案而言,只有文献[6]方案适合做对比实验。因此,本文在审计效率方面文献[5]方案做横向对比;在动态数据操作方面,由于只有文献[7]在支持支持动态数据操作的同时支持错误数据定位,故本文在错误数据定位方面本文主要与文献[6]方案进行比较。区块链系统的节点应当是可开放自由参与,身份平等,如此形成自治的系统[16]。为了更好适应区块链系统,大多数系统采用对等分布式网络来进行数据传播。为了使众多的节点能够在保证安全性的前提下完成网络中数据打包,则需要全网节点达成共识,共同完成任务[17-19]。

  区块链的共识算法主要分为证明类算法和选举类算法, 其中的的普遍应用的 PoW(Proof of Work)方案[20] 和 PoS(Proof of Stake)方案[21]是证明类共识算法,DPoS(Delegated Proof of Stake)方案[22]是选举类算法。其具体性能如表一所示,为了最大程度提升云数据的审计效率,本文采用 DPoS 共识算法。

  基于上文对共识算法的介绍,表 2 针对PoW、PoS、DPoS就性能、去中心化、确定性和资源消耗几个维度做对比。

  为了从根本上解决基于TPA的云数据审计方案的单点失效、算力瓶颈等问题。本文引入区块链技术弱化 TPA 在审计系统的地位,借助分布式网络提升审计系统的算力;此外, 本文通过一个创新的嵌入式 MHT 结构,在实现云数据动态操作的前提下,提高了审计错误时对错误数据定位的效率。

  2 背景知识

  定义 1 一个变色龙函数由四个算法组成 Cham_hash = (Setup, KeyGen, CHash, CForge)组成。

  1) Setup():输出公共参数 pp;

  2) KeyGen(pp):输入公共参数 pp,输出公私钥对(HK,CK),HK 公钥,CK 为私钥又称陷门;

  3) CHash(HK,m,r):输入公钥 HK,消息 m 和随机数r,输出变色龙哈希值 CH;

  4) CForge(CK,m,r,m’):输入私钥 CK,消息 m,随机数 r,消息 m’,输出另一个随机值 r’,满足 CH= CHash(HK,m,r)= CForge(CK,m,r,m’);

  变色龙哈希函数的安全性要求:

  1) 抗碰撞性(collision resistance):不存在一个有效算法在输入公钥 HK,可以得到(m1,r1)和(m2,r2),其中m1 1 m2,满足 CHash(HK,m1,r1)=CHash(HK,m2,r2) ;

  2) 陷门碰撞(trapdoor collisions):存在有效算法,在输入陷门 CK 后,对于任意的 m1,r1,给定 m2,可计算出 r2 满足 CHash(HK,m1,r1)=CHash(HK,m2,r2);

  3) 语义安全(semantic security):对于任意消息 m1, m2,CHash(HK,m1,r1) 与 CHash(HK,m2,r2)的概率分布是不可区分的;特别地,当r 为随机选择时,从Chash(HK,m,r)无法得到关于 m 的任何消息。

  3 本文工作

  3.1 系统框架和流程

  基于嵌套 MHT 区块链的云数据动态审计模型框架如图

  1 所示,下文主要介绍整个模型中涉及到的实体以及功能。

  2.1 BLS 签名

  BLS 签名方案使用双线性映射的性质进行验证和签名。

  1) KeyGen:选取一个随机整数 x,作为私钥 sk, g x作为公钥 pk;

  2) Sign:计算消息 h 的签名 sig =h x ;

  3) Verification:验证者知道 G,pk,h,sig' ,为了验证sig ' = hx ,即签名是拥有私钥 x 的人产生的, 验证者计算 e(gx , h) = e(g, sig ') ,若成立则消息的完整性得到证明。

  2.2 变色龙哈希

  哈希函数简单来讲就是能将任意长度的输入转换成一个固定长度的输出,这个固定长度的输出称为原数据的散列值或哈希值。通过原始输入消息能够很容易计算哈希值,通过输出(哈希值)则很难还原出原始输入。理想的哈希函数针对不同的输入产生不同的输出。如果两个不同的消息产生了相同的哈希值,则称为发生了碰撞[23]。

  与一般哈希函数不同,变色龙哈希函数(Chamelelon Hash)可以人为设下陷门秘钥,掌握了陷门秘钥就能轻松计算出不同数据指向相同的哈希碰撞[24]。对没有陷门秘钥的用户而言,变色龙哈希函数依然满足抗碰撞性 。

  普通用户(Common Owner, CO):该角色主要是持有大量的数据,同时将数据托管给云存储服务提供商,该角色可以是私人用户或者公司等需要保存数据的角色。

  授权用户(Delegate Owner,DO):该角色是通过 DPoS 共识,由分布式网络所有的 CO 投票产生,该角色在持有大量数据托管给云存储服务提供商,同时监测全网 CO 发送的元数据证据消息为全网用户的数据提供数据完整性验证服务。云存储服务提供商:该角色是提供云存储服务,拥有海量的存储空间、可靠的计算资源同时提供稳定服务。方案的大致过程如下:

  1) DPoS 共识:分布式网络中所有的 CO 执行该过程, 产生 DO 用户,约定区块生成的顺序和审计任务。

  2) 上传 UBlock:分布式网络中所有的用户将要保存在CSP 的文件经过处理后生成一个 UBlock 文件上传到 CSP 保存。

  3) 上传 Ublock* :分布式网络中所有的用户在上传UBlock 的时候,会生成一个不包含原始数据但包含元数据的 Ublock*发送给指定的 DO(激活)保存。

  4) 区块签署:当 DO(激活)生成一个区块文件之后, 向 CSP 发起一个区块签署挑战请求 CSP 返回一个签署证据响应。DO(激活)通过检查 CSP 返回的证据响应就可以确定 CSO 是否如约保存了分布式网络全体用户在该 DO(激活)工作时间内的托管的

  4 计算机应用件。

  5) 区块审计:DO 为了验证其存储的所有区块代表的用户数据的完整性,依照 DPOS 规定的时间表,周期性地向 CSP 发起区块审计挑战,验证 CSP 返回的证据的正确性。

  6) 动态操作:当分布式网络中的用户需要修改、删除、增加其已经托管在 CSP 的数据时,执行该操作。

  3.2 嵌套 MHT 数据结构

  传统的区块链应用模型中,用户的每一次交易的证据都双线性映射,gb 是 G 的生成元;Hb:{0,1}*→G 是将数据映射到 G 群的哈希函数;Hc: {0,1}*→Zp*是数据映射到 Zp*群的哈希函数,H: {0,1}*→Zr 是数据映射到 Zr 群的哈希函数 。输入公共参数 pp, 在乘法循环群 Zp*中随机选择指数 x,计算 h=gcx,最后得到私钥 CK=x,公钥 HK=h;随机选取私钥 SK = a←Zp,计算其相对应的公钥 PK=g a。

  3.3.2

  元数据和变色龙哈希生成阶段选取文件的唯一标识 v←{0,1}R,随机辅助变量 v←G, 对文件 F 进行分块:F = {b1,…,bn};将所有分块文件分别映保存在区块链上。交易数据较小且每次交易之间的数据没有关联性。但是,在审计过程中,用户文件比较大,为了减轻f = {s i }1£i£n,这里s i =Hb(mi)?umi 对每一个分块文件 mi,元数据的计算压力,文件一般会进行分块处理。如果直接引用传统区块链上的概念来存储数据,则会破坏分块数据之间的关联性。此外,传统的区块链应用模型中,是不允许对交易数据进行修改的。但是现今的审计往往要求针对动态数据的完整性验证,为了将区块链技术和动态云数据审计结合起来,必须要对区块链的底层数据结构作出相应修改。故本文专门引入变色龙哈希技术和嵌套 MHT 结构来适应区块链上验证动态数据的完整性。该结构中,顶层的 MHT 用来保证多个文件的完整性和空间位置的正确性,底层的 MHT 保证单个文件的分块数据在空间位置的正确性和数据的完整性, 其具体结构如图 2 所示。

  为了支持数据动态操作和数据安全,用户只能操作底层MHT 结构。通过变色龙哈希算法,假设底层 MHT 结构发生了改变也能保证上层 MHT 结构不变,从而解决了区块链不可变和云存储动态操作的矛盾。图 2 所示可知,顶层 MHT 的叶子结点保存都是某个用户存储在 CSP 的文件,其内部非叶子节点存储的都是经过变色龙哈希函数计算得到的哈希值。底层 MHT 的叶子结点保存都是某个用户托管于 CSP 文

  件的分块数据,其内部非叶子节点存储的都是经过变色龙哈希函数计算得到的哈希值,具体过程详见算法 3。

  生成一个随机数 ri←Zq*,输出变色龙哈希 CHmi=gcmi?hri mod p。  数据分发和区块生成阶段

  用户将文件 F 的每个分块文件 bi、mi、s i 和 CHmi 组合成 Unodei,后执行底层 MHT 构造算法(详情请看算法 1) 生成 UBF 发往CSP 存储,同理生成相应的证据 UBF*发往 DO

  (激活)存储。用户可以删除本地文件,只保留 UBF*数据以便以后修改数据之用。当 CSP 接收到 m 个用户发送的 UBF 之后,执行顶层 MHT 构造算法(详情请看算法 2)生成一个区块文件。同理 DO(激活)在收集到 m 个用户发送的 UBF* 之后,也生成一个未签署、未审计的区块文件。

  3.3.4 签署区块阶段

  当 DO 生成一个区块文件之后,直接读取头部文件中的ID 值,要求 CSP 就符合 ID 一致的区块返回其头部的U_ROOT 值。若 DO 本地区块的 U_ROOT 值和 CSP 返回的U_ROOT 值一致,则 CSP 可以证明其已经保存了该时间段内区块链网络中所有用户托管在 CSP 的数据,DO 发送签署消息到 CSP 完成区块签署。

  3.3.5 区块审计和错误数据定位阶段

  DO(激活)选择一个未审计的区块,这个区块内包含 m 个 UBF*文件。针对每个 UBF*文件随机抽取 C 个 UN*的索引为 UnodeIDi,并对每个索引选取一个相对应的随机数 vi← Zp/2。由此可以组成一个 UBF*挑战块t F ={Unodei, vi }(1≤i≤c),m 个 UBF* 挑战块组成了这个 区块文 件的 挑战 c h a=l t F{ , B l oic( £1k£Ii D发送到 CSP。CSP 接收到chal 挑战后,依据 BlockID 找到被挑战的区块 UBlock。依据t 找到被挑战的 UN 分块文件,通过UnodeIDi 得 到 每 个 被 挑 战 分 块 文 件 的 辅 助 消 ai =(UnodeIDi,LMi,dataHashi),将 c 个辅助消息合组成一

  3.3 模型关键流程

  本文的方案主要由密钥初始化阶段、元数据和变色龙哈

  3.3.1 秘钥初始化阶段

  选取公共参数 e 和安全参数 l ,构造满足安全参数 l 的大素数 p、q。其中p、q 满足p=k?q+1,选取乘法循环群 Zp* 阶为 q 的元素 gc,输出公共参数 pp=(p, q, gc);G×G→GT 是计算与其对应的jF 。CSP 计算完所有的jF ,将其整合成一个Res = {jF }1£i£m 返回给发出挑战的 DO。

  DO 接收到 CSP 返回的Res = {jF }1£i£m 消息之后,对其中的每一个j 依据公式 1 判断存储在CSP 的用户数据的完整性。若公式一输出 true,则说明该 UB 文件块数据内容完整;若公式一判断发生错误,则说明 DO 挑战的该 UB 中的分块文件发生错误,此时执行错误数据定位,具体流程详见算法 4。此时,DO 读取发生错误的 UB 的 b ,通过直接读取辅助消息 UnodeID,确定 DO 发出的挑战分块文件在 DO本地存储的 LM 消息和 dataHash 消息,通过比较 LM=LMi 和 dataHash=dataHashi 来定位错误数据的具体位置。

  Unode5 到内部节点 He 的联系,He 内部信息添加 Unode4 和Unode5 左右孩子结点位置信息。同理, DO 接收到Insert_to_DO 消息之后执行的过程和 CSP 一致,这里就不在赘述。

  支持数据动态操作是云存储数据的重要特性,本文模型结合变色龙哈希函数技术提供对云数据在修改、插入、删除等方面的支持,下文将对动态操作的安全性和细节进行阐述。

毕业论文:http://www.3lunwen.com/kj/sj/3774.html

上一篇:浅谈会计的确认、计量和披露研究

下一篇:有关企业内部审计隐患以及预防措施剖析

     移动版:基于嵌套Merkle hash tree区块链的云数据动态审计模型

本文标签:
最新论文