CN113886841A - 一种面向云数据操作行为的可信溯源方法 - Google Patents

Abstract

本发明公开一种面向云数据操作行为的可信溯源方法，包括以下步骤，在用户的资源对象和执行命令的关键路径设置hook点，采集云数据的操作事件信息，获得云数据的溯源日志；提取溯源日志的日志摘要和相关元数据，将日志摘要和所述相关元数据存储在区块链账本上，并提出基于默克尔山脉的链上数据存储机制，支撑对溯源日志的完整性的细粒度校验和批量校验；构建面向云数据的溯源模型，给出结合超级区块链账本与ELK Stack技术的溯源机制,在实现身份验证服务的同时，基于所述的Merkle山脉算法和溯源日志集保证溯源日志可信性，并基于此给出基于DAG的行为追责溯源方法。

Description

一种面向云数据操作行为的可信溯源方法

技术领域

本发明涉及大数据数据溯源领域，尤其是一种面向云数据操作行为的可信溯源方法。

背景技术

大数据时代，云计算的快速发展解决了用户的本地资源受限问题，越来越多的用户和企业选择将数据资产存储在云服务器上，以充分享受云服务商提供的即时的资源按需分配服务。在海量的数据被用户和企业从本地上传到公共云服务器上的同时，数据的安全问题成为了人们关注的焦点，特别在不可信的网络环境下，数据泄露、篡改与丢失的情况时有发生，导致数据的真实性与可靠性得不到保证，数据溯源是解决这些问题的有效方案之一。数据溯源是指对于数据处理流程的管理，解决回答数据为什么是该状态(why)、数据从哪里来(where)以及如何获得的问题(how)。为了确保数据的安全，研究者们提出通过访问日志记录、审计和溯源用户行为，保证安全事件的可问责性。但是现有的研究没有关注到溯源数据是否可信的问题，因为在现实的入侵行为中，“抹痕”是攻击者的重要隐匿手段，不诚实的云服务商或者黑客在获得用户***的控制权后，日志文件是其篡改的关键目标，因此如何实现可信的数据溯源是目前面临的重要挑战。

在云服务的场景下用户的数据频繁地在客户端和服务器主机之间流通，数据追根溯源技术面临着三个方面的挑战：1)数据的流通过程难以追溯。数据在被共享以及使用的过程中，往往需要多方参与，数据的流转环节复杂并且权属难以界定，导致信息泄露和篡改等安全事件不易察觉；2)中心化的数据溯源机制可信力不足。现有的溯源技术大多基于中心化架构实现，由统一的云服务商负责日志存储和分析，导致溯源过程中数据的所属者与服务商之间的信息不对等，存在着信任问题；3)溯源日志的安全性得不到保证。日志文件作为溯源取证的信息源，是入侵者的重点攻击目标，其在不可信的网络环境下存储与传输时面临着被恶意删除与篡改的风险，直接影响着数据溯源的结果。

区块链具有分布式、高容错、不可篡改的特点以及无需第三方背书的可信机制，在数据溯源领域有着巨大的应用潜力。区块链通过分布式区块链账本和共识机制能够确保溯源数据的完整性和不可篡改性，同时依靠交易事务的时间戳和背书签名，能够不可抵赖地记录用户的操作行为。但是目前区块链所提供的数据查询以及分析功能较为简单，大规模数据的检索较为低效，无法独立地支撑可信数据溯源。

发明内容

本发明目的是提出了一种高效的基于联盟链的可信云数据溯源机制CBCProv，旨在为用户提供安全可信的数据溯源服务，实现在不受控的云环境下的数据监管。联盟链是CBCProv背后的关键技术，作为区块链中的一个分支，联盟链具有准入机制，其网络中用户的业务权限与身份相绑定，因此也形容其为去中心化的权限受限环境(Decentralizedpermission environment)。本发明提出从溯源数据的获取、存储、重构三个环节出发，通过联盟链保证云数据溯源过程中的各类参与主体的可信性，实现在无需中央权威的情况下提供可信溯源服务。

为了实现上述目的，本发明提供了一种面向云数据操作行为的可信溯源方法，包括以下步骤：

基于用户的资源对象和执行命令的关键路径设置hook点，采集云数据的操作事件信息，获得云数据的溯源日志；

提取溯源日志的日志摘要和相关元数据，将日志摘要和相关元数据存储在区块链账本上，用于支撑对溯源日志集的完整性校验；

通过基于Merkle山脉的数据存储机制，在链上存储日志摘要，用于支撑对链下溯源日志完整性的细粒度校验和批量校验；

构建面向所述云数据的数据溯源模型，获得结合超级区块链账本与ELK Stack技术的溯源机制,用于在实现身份验证服务的同时，通过Merkle山脉的算法和溯源日志集保证所述溯源日志可信性，获得基于DAG的行为追责溯源方法。

可选的，基于所述hook点，提取***事件的***调用函数的参数和环境，获得所述溯源日志，通过服务器监听和存储开销，支撑基于所述溯源日志的事件重构，其中，所述hook点根据资源对象来划分而包括文件、进程和通信三类。

可选的，基于Linux安全模块的LSM***事件捕获机制和所述hook点，通过重点关注用户云存储数据、通信网络、区块链网络配置文件三类对象，构建所述溯源日志。

可选的，控制所述区块链账本进行交易，记录所述日志摘要和所述相关元数据，其中，所述区块链账本包括多个分布式区块链账本，基于HLF的通道机制获得所述多个分布式区块链账本，每个所述分布式区块链账本之间数据隔离。

可选的，基于Elasticsearch的DLD，存储所述溯源日志，用于在校验接收的日志文件的完整性时，通过相应通道内的DLD Client进行链上区块链账本数据的查询，并根据返回的结果确定链下的日志文件是否遭到篡改。

可选的，转换所述溯源日志的格式为JSON格式，获得溯源日志文件；

基于所述溯源日志的采集时间和递增序列号，获得组合序号字段；

基于所述溯源日志文件和所述组合序号字段，构建所述溯源日志集。

可选的，提取所述溯源日志集的上传时间、上传者标识码、上传者签名公钥、哈希值，构建上传信息；

基于所述上传时间和所述上传者标识码，调用链码和共识算法，生成交易区块，用于所述区块链账本与所述溯源日志的交易，其中，在调用链码和共识算法过程中，至少附加时间戳信息。

可选的，基于所述Merkle山脉算法的算法结构，聚合所述溯源日志集，构建溯源日志摘要存储模型；

基于所述Merkle山脉算法更新日志摘要数据、Merkle根数据、SPV证明集，构建证明验证模型；

基于所述溯源日志摘要存储模型，构建证明快照；基于所述溯源日志摘要存储模型、所述证明验证模型、所述证明快照，构建所述溯源日志校验模型。

可选的，遍历所述Merkle山脉算法，提取所述溯源日志摘要存储模型的叶子结点的结点坐标，获得所述叶子结点的左侧的第一子哈希树、所述叶子结点所在的第二子哈希树、所述叶子结点的右侧的第三子哈希树；

基于所述第一子哈希树、所述第二子哈希树、所述第三子哈希树，构建所述SPV证明集。

可选的，提取所述云数据的最早时序日志作为顶点数据；

初始化所述数据溯源模型和所述云数据；

将所述顶点数据添加到所述数据溯源模型，标记所述顶点数据为已访问；

提取所述云数据与所述数据溯源模型相连的流转事件，将所述流转事件对应的***日志标记为待添加日志，判断所述流转事件是否为所述顶点数据，基于判断结果与所述数据溯源模型，对所述云数据进行溯源。

本发明具有以下技术效果：

本发明提出的方法，为用户提供安全可信的数据溯源服务，实现在不受控的云环境下的数据监管。该机制结合超级区块链账本与ELK Stack技术,在实现身份验证服务的同时，实现了去中心化的溯源日志完整性校验功能。通过提出的基于默克尔山脉的链上数据存储机制，实现了对链下日志完整性的细粒度校验和批量校验。通过实验测试，证明了CBCProv能够在***可承载的负荷内实现对数据的高效可信溯源。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请所述的方法流程图；

图2是本申请所述的CBCProv***架构示意图；

图3是本申请所述的CBCProv业务流程示例示意图；

图4是本申请所述的基于LSM的***事件捕获机制示意图；

图5是本申请所述的链上链下相结合的日志存储与检索机制示意图；

图6是本申请所述的溯源日志上传流程示意图；

图7是本申请所述的基于Merkle树的日志摘要结构示意图；

图8是本申请所述的基于MMR的日志摘要结构示意图；

图9是本申请所述的以用户为对象的MMR结构示意图；

图10a是本申请所述的基于MMR的日志摘要更新算法示意图；

图10b是本申请所述的基于MMR的Merkle根生成算法示意图；

图10c是本申请所述的基于MMR的SPV证明集生成算法示意图；

图11是本申请所述的数据溯源图构建算法示意图；

图12是本申请所述的对Alice.txt泄露事件的溯源示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

结合图1-12所示，对本发明提供的技术方案进行详细的描述。参考图1所示，为本发明提供的一种面向云数据操作行为的可信溯源方法的流程图，其中，本发明公开了一种面向云数据操作行为的可信溯源方法，包括以下步骤：

基于用户的资源对象和执行命令的关键路径设置hook点，采集云数据的操作事件信息，获得云数据的溯源日志。

提取溯源日志的日志摘要和相关元数据，将日志摘要和相关元数据存储在区块链账本上，用于支撑对溯源日志集的完整性校验。

通过基于Merkle山脉的数据存储机制，在链上存储日志摘要，用于支撑对链下溯源日志完整性的细粒度校验和批量校验。

构建面向所述云数据的数据溯源模型，获得结合超级区块链账本与ELK Stack技术的溯源机制,用于在实现身份验证服务的同时，通过Merkle(默克尔)山脉的算法和溯源日志集保证所述溯源日志可信性，获得基于DAG的行为追责溯源方法。

需要说明的是，ELK是Elasticsearch、Logstash和Kibana三种软件产品的首字母缩写。在本发明提供的的一实施例中，基于hook点，提取***事件的***调用函数的参数和环境，获得溯源日志，通过较小的服务器监听和存储开销，支撑基于溯源日志的事件重构，其中，hook点根据资源对象来划分而包括文件、进程和通信三类。

在本发明提供的一实施例中，基于Linux安全模块的LSM***事件捕获机制和hook点，通过重点关注用户云存储数据、通信网络、区块链网络配置文件三类对象，构建溯源日志。

在本发明提供的一实施例中，控制区块链账本进行交易，记录日志摘要和相关元数据，其中，区块链账本包括多个分布式区块链账本，基于HLF的通道机制获得多个分布式区块链账本，每个分布式区块链账本之间数据隔离。

在本发明提供的一实施例中，基于Elasticsearch(ES，分布式全文检索)的DLD(分布式日志数据库)，存储溯源日志，用于在校验接收的日志文件的完整性时，通过相应通道内的DLD Client进行链上区块链账本数据的查询，并根据返回的结果确定链下的日志文件是否遭到篡改。

在本发明提供的一实施例中，转换溯源日志的格式为JSON(JavaScript ObjectNotation,JS对象简谱)格式，获得溯源日志文件；基于溯源日志的采集时间和递增序列号，获得组合序号字段；基于溯源日志文件和组合序号字段，构建溯源日志集。

在本发明提供的一实施例中，提取溯源日志集的上传时间、上传者标识码、上传者签名公钥、哈希值，构建上传信息；基于上传时间和上传者标识码，调用链码和共识算法，生成交易区块，用于区块链账本与溯源日志的交易，其中，在调用链码和共识算法过程中，至少附加时间戳信息。

在本发明提供的一实施例中，基于Merkle山脉算法的算法结构，聚合溯源日志集，构建溯源日志摘要存储模型；基于Merkle山脉算法更新日志摘要数据、Merkle根数据、SPV(Simplified Payment Verification，简单支付验证)证明集，构建证明验证模型；基于溯源日志摘要存储模型，构建证明快照；基于溯源日志摘要存储模型、证明验证模型、证明快照，构建溯源日志校验模型。

在本发明提供的一实施例中，遍历Merkle山脉算法，提取溯源日志摘要存储模型的叶子结点的结点坐标，获得叶子结点的左侧的第一子哈希树、叶子结点所在的第二子哈希树、叶子结点的右侧的第三子哈希树；基于第一子哈希树、第二子哈希树、第三子哈希树，构建SPV证明集。

在本发明提供的一实施例中，提取云数据的最早时序日志作为顶点数据；初始化数据溯源模型和云数据；将顶点数据添加到数据溯源模型，标记顶点数据为已访问；提取云数据与数据溯源模型相连的流转事件，将流转事件对应的***日志标记为待添加日志，判断流转事件是否为顶点数据，基于判断结果与数据溯源模型，对云数据进行溯源。

面向云数据的数据溯源机制：

日志审计作为各类信息***的追责溯源机制之一，能够分析发现***的安全问题并进行溯源取证。通过捕获并记录服务器和客户端上的操作事件，是掌握用户数据流通历史，分析用户行为特征的重要途经。特别是在关键数据出现篡改、丢失和泄露等安全事件时，通过历史日志进行溯源审计，是发现安全隐患、追溯攻击者、取证非法行为的重要手段。

本发明提出的CBCProv机制，将用户、云服务商、分布式日志数据库和溯源审计员四类主体接入到区块链网络，并分别在日志收集端、分布式数据库端和溯源审计端上部署Logstash、Elasticsearch和Kibana组件，搭建了一个主体身份可信、日志数据可信、溯源结果可信的数据溯源平台。CBCProv的架构如图2所示。

其中区块链部分可以被分为四层：

客户端层：在Fabric Client上用户使用基于Node.js的SDK(SoftwareDevelopment Kit，软件开发工具包)与区块链网络进行交互，实现在节点上安装链码、提交交易提案、查询区块链区块链账本等功能。根据客户端上主体身份的类别，可分为用户客户端、云服务商端、数据库端以及溯源审计端。在用户客户端和云服务商端(User and CSP)部署Logstash组件，负责分布式的日志收集(Event capture)和预处理工作(Local logtransfer)；在数据库端(Distributed Log Database)部署Elasticsearch组件，负责分布式存储的日志文件的检索功能；在溯源审计端(Provenance Auditor)部署Kibana组件，负责日志数据的分析(Analysis)以及可视化(Visualization)。

网络层(Blockchain network)：区块链的网络层反映了***主体间的拓扑关系，封装了***的组网方式、消息传播协议、数据同步验证协议等内容，是整个***的通信网。

区块链账本层(Blockchain ledger)：维护着CBCProv***的区块链账本信息，负责收集交易数据，生成数据区块，对交易提案进行合法性校验，以及将校验通过的交易排序添加到链上。

数据库层(JSON Database)：在数据库层，分布式区块链账本中的数据以JSON的格式存储在CouchDB状态数据库内，支持以键k为索引，通过部署的链码函数PutState(k,data)、GetState(k)、DelState(k)控制数据库内数据的更新、查询和删除。

CBCProv业务流程的示例如图3所示，其中，User and CSP为用户客户端和云服务商端；BN为区块链节点；DLD为数据库端，PA为溯源审计端。

基于LSM的溯源日志采集模块：

在云服务的场景下用户的数据频繁地在不同的终端和服务器主机之间流通，迫切需要安全可信的日志采集机制支撑对数据的操作和流转溯源。在Windows和Mac OS等用户端上环境相对私密，通过syslog等工具获取到的***日志足以满足溯源的需求。但在开放环境下的服务器端，用户数据的存储介质由云服务商实际控制，并且集中式的公共服务模式更容易成为攻击入侵的目标，因此保证服务器端的***日志的完整性和可信性至关重要。可信的溯源日志采集模块应当具备以下三点特征：

1)以数据为中心。以数据为中心指的是捕获到的事件日志都应当是与用户托管的数据直接或者间接关联的，换句话说就是对溯源审计有支撑价值的，这样的采集方式不仅可以减小服务器的监听和存储开销，也有利于基于溯源日志的事件重构。

2)实时采集。顾名思义，溯源日志的采集应当是实时的，其工作机制应当是以事件为触发。实时的采集机制具有更高的安全性，因为攻击者的抹痕行为也会被实时地记录。

3)难以篡改。保证溯源数据完整和不被篡改是获得正确的溯源结果的关键，即使攻击者的入侵行为无法避免，也要保证记录在磁盘上的监控日志受到保护。

根据上述需求，本发明提出了基于Linux安全模块(Linux security module,LSM)的***事件捕获机制，为CBCProv提供了可信的日志数据来源。LSM是在Linux内核中实现的一个轻量级通用访问控制框架，它通过向内核中关键的数据结构添加安全域字段，提供了管理内核中资源对象的hook函数接口。LSM通过全局静态结构体security_operations与预留的hook函数指针关联，在***执行对关键资源对象的访问之前将会先调用hook函数并执行，以实现用户制定的安全策略。目前LSM框架下代表性的安全***有SELinux，AppArmor等，其安全性也已被实践证明。

如图4所示，基于LSM的***事件捕获机制的底层原理，其核心思路是：对于任意一条可执行的***命令，它的执行路径和所需的资源对象是明确的，因此通过在用户敏感数据的关键执行路径上设置hook点，就能捕获到***调用函数时的参数和环境，并在实际地执行操作之前将这些溯源数据输出。LSM架构下预设了约160个hook点，覆盖了内核中的七类资源对象，因此监控其所有执行路径是不必要的。在以数据为中心的原则下，本发明设置的hook点如表1所示，针对不同的***函数返回不同的事件信息，以操作对象来划分可分为文件、进程和通信三类。

表1

本发明引入基于LSM的***事件捕获机制的目标是提供云环境下端到端的溯源支撑服务，重点关注三类对象：关键用户数据、通信网络、HLF网络配置文件。前两类对象记录了数据的操作行为和流通网路，对HLF网络配置文件的监控则记录了对区块链网络的攻击。具体来说，HLF的crypto-config目录下保存了当前网络组织成员结构、证书等信息，在攻击者获得用户账户的控制权后，可以通过修改配置文件导致区块链上的业务异常。因此通过在区块链配置文件路径上设置hook点，这种攻击行为也会被监控并记录。所有获得的溯源日志被保存在用户空间中的/var/log/messages.log文件中，并通过强制访问控制(MAC)禁止所有用户的写入和删除权限，这也是基于LSM实现的。

值得注意的是要保证内核中的日志采集模块不被篡改或覆盖，以及日志文件的访问控制权限不被篡改，就必须要保证内核的安全性。而内核的安全性又与root权限是紧密关联的，因为***内核只能在root权限下进行修改。但是考虑到云服务商的行为是不可控的，因此仍存在一定的安全隐患，这表现在两个方面：一是作为服务器的管理员，云服务商可能与攻击者串谋窃取用户的数据，并通过泄露root密码禁用日志采集模块实现恶意行为的掩盖；二是云服务商可能没有谨慎保护用户的root权限，导致管理员的身份被窃用。因此，用户***中的sudo命令也需要监控的对象。

溯源日志的存储与检索机制：

在获得溯源日志之后，如何保证日志文件在存储、传输以及溯源审计过程中的可信性成为需要考虑的问题，而区块链的可信存储为解决这个问题提供了一条可行的技术路径。区块链的存储可信性依赖于其分布式区块链账本的性质，即所有的节点通过共识算法共同维护一个交易区块链账本，保证数据不会丢失以及不被篡改，但是这也导致了区块链不具有存储的可伸缩性。现有的区块链技术与传统的分布式数据库相比仍存在较大的性能差距，吞吐量和响应速度无法应当大规模的数据存储需求，且不具备负载均衡机制。区块链网络中的所有节点必须无差异地维护同一个区块链账本，服务器节点的增多并不能提高数据的吞吐量，反而会增加数据状态同步的时间开销。在基于区块链的日志存储***中同样面临着这个问题，虽然区块链可以保证日志的完整性和可靠性，但是无法应用于动态增长、实时分析的日志管理***。针对这个问题，同时考虑到分布式的日志上传和检索需求，本发明提出链上链下相结合的日志存储与验证机制，通过将日志摘要和相关元数据以交易的方式上传到HLF上，保证对链下日志的完整性校验，而完整的日志文件则通过Logstash上传到基于Elasticsearch集群的分布式日志数据库(DLD)中，满足了日志文件的高效存储与检索需求。

如图5所示，本发明通过HLF的通道机制实现区块链账本的分割，其中每一条通道单独地维护着一个分布式区块链账本，通道之间的区块链账本数据隔离。日志摘要和相关元数据以交易的方式在HLF的区块链账本上保存，而完整的日志文件则存储在基于Elasticsearch的DLD中。当DLD的管理员想要校验接收的日志文件的完整性时，他通过相应通道内的DLD Client进行链上区块链账本数据的查询，并根据返回的结果确定链下的日志文件是否遭到篡改。这个机制具有两点优势：一是链上链下相铆钉的日志存储方式既保证了链下数据的完整性，又减轻了大规模数据存储和查询给区块链带来的性能负荷；二是通过通道分割区块链账本可以提高区块链的数据吞吐量，同时区块链账本的分散化也减少了日志摘要的查询延时。

通道机制保证了不同安全域下的区块链账本数据隔离，同时按照安全域对链上的区块链账本进行分片，提高了链上数据检索的效率。具体来说，同一安全域下的组织成员被划分到同一条通道，正常情况下用户数据的传播被限制在规定的安全边界内，因此通道内区块链账本上存储的日志摘要都是来自该域的。这能够提高链上数据的检索效率，因为正常情况下只需关注用户所属的安全域对应的区块链账本。而违反安全策略的跨域访问也会被发现，因为DLD中存储着全局的日志文件，其管理员拥有HLF所有通道的查询权限，因此能够实现全局的数据追踪。

在将日志数据存储在DLD之前，首先要对其进行预处理，需要将日志文件转换为JSON格式以方便构建索引。本发明通过Logstash设置了针对日志文件的探测器(prospector)和收割器(harvester)，prospector负责去检测配置中指定的日志目录并判断harvester的运行状态，harvester负责文件的打开和关闭，并以定时器的方式连续地读取日志内容并发送到处理进程，然后通过预定义的正则表达式来匹配日志中的字段，最终将日志记录解析成为JSON格式，并定义其为一条溯源日志，以l表示。

溯源日志集：定义溯源日志集为t时开始，时间段τ内发送的n条日志的集合，表示为PL_t,τ＝{l₁,l₂,…,l_n}。其中时间变量τ即为harvester的定时间隔，它以设定的频率1/τ生成日志集PL_t,τ。

PL_t,τ中的每条日志在转换为JSON格式时都被附加上序号s，{l₁,l₂,…,l_n}中的日志按照s的大小递增排列。本发明设计s为采集初始时间t与递增序列号的组合字段，在t更新时序列号也会重新计数，这保证了l的序号s以时间属性严格递增。表2展示了处理后的日志的部分字段。

表2

链上日志摘要存储方案：

如图6所示，在溯源日志集合PL被上传至DLD的同时，用户或者云服务商也在客户端上生成溯源日志上传事务(LUT)提案，并发送至HLF网络。LUT中包含了日志摘要、相关元数据以及需要调用的链码名称。图6展示了LUT的整个记账流程，图中的账本节点(LN)部分表示设定所有的LN同时担任committer和endorser，它们同时负责交易的提交和背书。以Csk和Cpk代表用户的签名私钥和公钥，则整个流程可由以下四个部分描述：

1)Fabric Client(客户端)生成LUT提案，图中步骤1。提案中的上传信息可以表示为(MD,H,S)，其中MD是包含了上传时间uptime、上传者标识码UID和签名公钥Cpk的交易元数据，H＝hash(PL)是通过哈希算法获得的PL的哈希值，S＝sign(Csk,H)是发布者使用私钥Csk对溯源日志的签名，该过程可以通过式(4)表示：

upload(uptime,UID,Cpk,hash(PL),sign(Csk,hash(PL))) (4)

2)区块链账本节点背书，图中步骤2(a)、2(b)、2(c)、3。区块链网络中的LN接收到提案后，验证发布者的签名，将

作为该条日志记录的键k(表示字符拼接)，同时调用GetState(k)确认的k唯一性，防止日志的重复上传。在验证无误后，LN为该提案背书，并调用链码，然后将执行结果附加在提案上。该验证过程可以通过式(5)表示：

3)排序节点生成交易区块，图中步骤4(a)、4(b)、4(c)、5、6。在提案获得半数以上的背书后，上传者核查链码执行结果，然后将确认的LUT提案递交至排序节点。排序节点之间通过共识算法进行排序，然后附上时间戳等信息后生成交易区块，并广播到区块链网络上。

4)区块链账本节点更新区块链账本和数据库，图中步骤7、8(a)、8(b)、8(c)、8(d)。区块链网络中的LN接收到LUT后，验证发布者的签名(已验证过的背书节点可以忽略)以及交易结构的完整性，在确认本地的区块链账本和数据库不是最新版本后，根据LUT更新本地数据。

其中排序服务的共识算法是可选的，根据ON的可信度分为支持崩溃容错(CFT)和拜占庭容错(BFT)两种情况。在CFT的情况下，认为ON可信度较高，它们只会存在崩溃宕机的可能，使用Raft算法能够保证在少于一半的ON失效的情况下***正常运行。在BFT的情况下，认为ON中存在作恶节点，它们的排序服务并不可靠，使用BFT-SMaRt算法能够容忍在少于1/3的ON的背叛。

基于MMR的日志完整性快速校验算法：

在链上日志摘要存储方案中，日志摘要是通过对日志集合PL进行哈希运算获得的，这作为最简便的做法，具有最快的处理效率，但是这种方法也存在一个缺陷：日志的完整性校验只能以日志集的粒度进行，在发现日志完整性遭到破坏时，无法定位到具体的日志l。将日志摘要逐条保存在区块链账本上是一种解决方案，但是这将导致对溯源日志的完整性校验只能通过逐条对比的方式进行，这增加了LN的查询工作量和HLF网络的通信负荷，因此设计一种细粒度的日志完整性快速校验算法是必要的。

借鉴比特币的思想，按照Merkle树的结构聚合日志摘要数据是一条可行的路径，但是这个方案也存在一个问题：Merkle(默克尔)树的结构不能很好地处理日志摘要的动态添加。如图7为例，从t₀至t₁的时间段内在LN上共收到了6条日志摘要(H₁至H₆)，并已经通过迭代计算获得Merkle根H₁₆，但在t₁收到最新的日志集PL_t1,τ后，LN在更新Merkle根的过程中H₁₆和H₅₆的值都需要被再次计算，这带来了额外的计算开销。此外，为了满足验证的实时性，HLF客户端应当根据收到的PL尽快发送LUT提案，但是PL内过少的日志条数将导致Merkle树高度h过低，这也会导致校验速度的降低。因为考虑到LN需要为每条LUT生成一棵Merkle树，其中的Merkle根是对2^h条日志完整性的约束承诺，在最糟的情况下，树的高度为1时Merkle根降级为单条日志的散列，日志的校验过程退化到逐条对比，导致校验速度的严重降低。因此，实现日志实时快速校验的问题可被归纳为：如何实现日志摘要的动态更新且不影响已经生成的Merkle树，从而提供全局的LUT包含证明。基于此，本发明提出了基于Merkle山脉(Merkle Mountain Range,MMR)【Peter Todd.Merkle mountain range.】的日志完整性快速校验算法。

如图8所示，Merkle山脉:定义Merkle山脉(Merkle Mountain Range，MMR)是由多棵哈希树组成，具有n个叶子节点的数据结构，其Merkle根是对所有子树根从右至左的哈希，表示为r，其某一实例为M，MMR结构具有以下三点属性：

MMR结构可被看作高度为

二叉哈希树。

当M的叶子节点数n＝2ⁱ，

时，M成为平衡二叉哈希树，即Merkle树。

将M的叶子节点数表示为n＝2ⁱ+j，当n＞1时，

则M可被划分为两部分：具有2ⁱ个叶子节点的左子树M.left和具有j个叶子节点的右侧子山脉M.right。

重新将日志摘要以MMR的结构聚合，按照日志集产生的时间段可分为三组：

和

要求Fabric Client上每次收到日志集就立刻生成LUT提案并上传。在LN上以图中数组的形式保存叶子节点和中间节点的哈希值，该数组表示为A。在

被上传并确认后，A⁰＝[H₁,H₂,H₁₂,H₃]将被LN记录，其中H₁、H₂和H₃是通过哈希算法生成的单条日志哈希值，

是通过快速哈希算法对其叶子节点的聚合。在PL_t1,τ被上传后，LN根据之前A⁰的值，将生成A¹＝[H₄,H₃₄,H₁₄,H₅,H₆,H₅₆]并保存。同样，当

被上传时，A²＝[H₇]将被保存，这就实现了在不改变原有数据的情况下实现日志摘要的动态更新，此时Merkle根可以表示为H(H₁₄||H(H₅₆||H₇))。

如图9所示，在满足日志摘要动态更新的前提下，本发明提出以用户为对象的MMR结构。具体来说，LN在收到打包好的区块后将逐个验证其中包含的LUT，在确认交易有效后，LN将根据交易上传者的信息，为每个用户维护一个全局的MMR。与传统的Merkle树相比，这个结构具有两点优势：一是有效地减小了用户的存储开销，因为用户不需要再保存所有区块头，只需要记录自己的MMR的根数值。二是能够实现批量的LUT存在性校验，因为用户可以根据自己发送的LUT提案，自行计算出MMR更新后正确的Merkle根r'，当其与区块链账本更新的Merkle根r相同时，就可以证明LUT中所有的日志摘要都已经保存在了区块链上。

本发明提出了基于MMR的证明/验证协议。协议的一方为HLF上的LN，它存储着整条区块链的交易区块链账本，维护着基于MMR的日志摘要数据，负责为查询者提供SPV证明集，称之为证明方；另一方为用户或者DLD的管理员，他记录着自己MMR的Merkle根，但是没有存储完整的交易区块链账本，因此需要索取SPV证明集确认日志摘要已经保存在链上，称之为验证方。

SPV证明集：SPV证明集Π^k是对MMR中索引为k(从0开始)的叶子节点的存在性证明，包含了从叶子节点到Merkle根r路径上的所有兄弟节点。

图10a给出了基于MMR的日志摘要更新算法，其核心思想是在进行***操作时根据节点高度和兄弟节点的高度是否相同，判定是否生成中间节点。具体来说，可以通过数组A表示代表MMR的任一实例，因为它映射着唯一的MMR结构，因此节点的更新操作都可以看作是对A的写入，图10a中的4至9行给出了写入方法的伪代码实现。

图10b给出了基于MMR的Merkle根生成算法。由定义3可知，Merkle根r是对所有子树根的哈希，它反映了所有叶子节点的完整性。对比图10a和图10b，注意到Merkle根生成算法与日志摘要更新算法的判定方法相似，但是它们的调用条件不同。LN在每次获得新的日志后就需要进行一次MMR更新，但是Merkle根却只在每次新的区块被确认时计算一次，作为对全局日志状态的记录。

图10c给出了基于MMR的SPV证明集生成算法。算法的核心思想是MMR，找到索引为k的叶子节点x的坐标，然后生成其SPV证明集Π^k。这个过程划分为三个部分：一是将x左侧的子哈希树的Merkle根从左至右加入Π^k，二是构造x所在哈希树的Merkle证明集Π'，三是获取x右侧所有子树的Merkle根。算法的3至18行展示了MMR从左至右的遍历过程，通过比较左侧最大子树的叶子节点数2ⁱ与k的大小，判定x是否属于该子树，在不属于的情况下将该子树的Merkle根加入Π^k，然后删掉该子树继续遍历。当属于时，则通过经典的基于Merkle树的证明集生成算法，生成该子树的Merkle证明集Π'并停止遍历。最后通过算法2 MMRGenRoot(A,n)获取x右侧所有子树的Merkle根。以图8为例，通过算法3获得节点H₅的SPV证明集Π⁴＝[H₁₄,H₆,H₇]。

基于上述算法，给出基于MMR的证明/验证协议如下：

证明方：

1)在接收到新的LUT时，通过MMR AppendLeaf(A,n,x)更新数组A；

2)在新的区块被确认后，通过MMR GenRoot(A,n)生成Merkle根r，并写入到HLF的状态数据库中；

3)接收验证方发送的日志l的完整性问询；

4)通过MMR GenProof(A,n,k)生成SPV证明集Π^k并发送到验证方。

验证方：

1)向证明方发送日志l的完整性问询；

3)接收证明方发送的SPV证明集Π^k；

4)将日志的哈希值***Π^k，通过迭代哈希计算验证值r'；

5)比较链上公开的Merkle根r与验证值r'是否相同；

6)验证无误，确认l的完整性。

通过SPV证明协议能够实现单条日志的完整性校验，下面给出批量日志完整性校验的证明/验证协议。

证明快照：证明快照是对日志存储某一时刻的状态记录，以Π_t表示t时刻的日志快照，通过计算t时刻用户MMR对应的Merkle根r获得。

通过MMR结构生成证明快照，可以实现任意时刻的全局日志校验。当LN节点收到验证请求时，将根据查询的时间节点t返回相应的Π_t，以图8为例，

验证方保存着链下的溯源日志集，日志的序号s是按照时间序列严格递增的，他在获得Π_t后，能够根据完整的日志集迭代计算获得Π_t'，并根据Π_t和Π_t'是否相等判断日志集的正确性。

基于上述算法，给出基于证明快照的证明/验证协议如下：

证明方：

1)在接收到新的LUT时，通过MMR AppendLeaf(A,n,x)生成MMR更新数组A'；

2)接收验证方发送的给定时间节点t的问询；

3)生成t时刻的证明快照Π_t并发送到验证方。

验证方：

1)根据日志的序号s确定其时间节点t，向证明方发送时间参数t的完整性问询；

2)接收证明方发送的证明快照Π_t；

3)由实际保存的日志集迭代计算获得Π_t'；

5)比较Π_t和Π_t'是否相同；

6)验证无误，确认时间节点t之前的日志已被正确上传至DLD。

基于DAG的数据溯源方法：

在溯源审计环节，溯源审计员PA拥有读取所有用户日志的权限，能够为用户提供网络上端到端的溯源审计服务。PA接受用户发起的溯源请求，搜索指定数据的相关日志，并通过溯源日志以深度优先搜索的策略构建数据溯源图，展现数据的流转与演变过程，将给定数据的追踪溯源问题转化为溯源图的连通性问题，最终形成溯源结果。

数据溯源图：数据溯源图G＝(V,E)为一个有向无环图，其中：

其中D是数据实体的集合，U是用户的集合，以图中的任一节点v₁∈V为例，v₁←(d×u)表示由用户u所控制的数据实体d。Vi表示输入数据的集合，Vo表示数据结果的集合，Op是操作类型的集合，假设e₁∈E，e₁←(vi×op×vo)表示顶点vi在操作op下演变为顶点vo，并称之为一个用户域内的操作事件；假设e₂∈E，e₂←(vs×tr×vr)表示顶点vs←(d×u₁)通过传输行为tr连接到顶点vr←(d×u₂)，并称之为一个用户域间的流转事件。

数据溯源图G的构建算法如图11所示(图11中Y表示是,N表示否)，PA接受用户发起的c的溯源请求，在DLD中查找时序最早的相关日志，然后以此为根节点，采用深度优先搜索的策略遍历。在遍历过程中忽略之前已经访问的节点，从而消除周期性的文件读写循环，保证溯源图是有向无环的。具体步骤如下：

1)在DLD中查找时序最早的相关日志；

2)初始化数据溯源图G和LS；

3)将表示目标数据的顶点v添加至图G，并将v标记为已访问；

4)在LS中获取与G相连的边e，若不存在则跳转至步骤7；

5)判断e代表的日志事件是否为流转事件，当检测到数据传输到新的用户域时，将该用户域的所有日志添加到LS；

6)获取v通过e相连的顶点v'，判断v'是否被访问，若未被访问则将v设置为v'，跳转至步骤3，若已被访问则检索下一条边；

7)返回数据溯源图G。

网络通信日志是通过LSM对socket接口的监控获得的，这类日志反映了目标数据的流转情况，当检测数据传输到新的用户域时，该用户域就拥有了对目标数据的操作权，可能进行编辑操作或者再次传输，因此该用户域中记录的所有日志也需要被检测，步骤5)描述的就是这个过程。

图12展示了基于DAG的数据溯源结果，设定的情景如下：adminA是云服务器的管理员并拥有用户***的root权限，他登录到了Alice的虚拟机中并访问了文件Alice.txt，之后他通过电子邮件将该文件发送到了另一台虚拟机上，在重命名文件为Bob.txt后，将其发送给了其他的虚拟机。PA以Alice.txt为目标数据，通过上述算法构建数据溯源图，可以看到管理员利用特权进行的恶意访问行为和数据泄露的完整路径都被重构，并且由于区块链对日志的完整性保护机制，这个溯源结果是不可抵赖的。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种面向云数据操作行为的可信溯源方法，其特征在于，包括以下步骤：

基于用户的资源对象和执行命令的关键路径设置hook点，采集云数据的操作事件信息，获得所述云数据的溯源日志；

提取所述溯源日志的日志摘要和相关元数据，将所述日志摘要和所述相关元数据存储在区块链账本上，用于支撑对溯源日志集的完整性校验；

通过基于Merkle山脉的数据存储机制，在链上存储所述日志摘要，用于支撑对链下溯源日志完整性的细粒度校验和批量校验；

构建面向所述云数据的数据溯源模型，获得结合超级区块链账本与ELK Stack技术的溯源机制,用于在实现身份验证服务的同时，通过所述Merkle山脉的算法和所述溯源日志集保证所述溯源日志可信性，获得基于DAG的行为追责溯源方法。

2.根据权利要求1所述一种面向云数据操作行为的可信溯源方法，其特征在于，

基于所述hook点，提取***事件的***调用函数的参数和环境，获得所述溯源日志，通过服务器监听和存储开销，支撑基于所述溯源日志的事件重构，其中，所述hook点根据资源对象来划分而包括文件、进程和通信三类。

3.根据权利要求2所述一种面向云数据操作行为的可信溯源方法，其特征在于，

基于Linux安全模块的LSM***事件捕获机制和所述hook点，通过重点关注用户云存储数据、通信网络、区块链网络配置文件三类对象，构建所述溯源日志。

4.根据权利要求1所述一种面向云数据操作行为的可信溯源方法，其特征在于，

控制所述区块链账本进行交易，记录所述日志摘要和所述相关元数据，其中，所述区块链账本包括多个分布式区块链账本，基于HLF的通道机制获得所述多个分布式区块链账本，每个所述分布式区块链账本之间数据隔离。

5.根据权利要求4所述一种面向云数据操作行为的可信溯源方法，其特征在于，

基于Elasticsearch的DLD，存储所述溯源日志，用于在校验接收的日志文件的完整性时，通过相应通道内的DLD Client进行链上区块链账本数据的查询，并根据返回的结果确定链下的日志文件是否遭到篡改。

6.根据权利要求4所述一种面向云数据操作行为的可信溯源方法，其特征在于，

转换所述溯源日志的格式为JSON格式，获得溯源日志文件；

基于所述溯源日志的采集时间和递增序列号，获得组合序号字段；

基于所述溯源日志文件和所述组合序号字段，构建所述溯源日志集。

7.根据权利要求6所述一种面向云数据操作行为的可信溯源方法，其特征在于，

提取所述溯源日志集的上传时间、上传者标识码、上传者签名公钥、哈希值，构建上传信息；

基于所述上传时间和所述上传者标识码，调用链码和共识算法，生成交易区块，用于所述区块链账本与所述溯源日志的交易，其中，在调用链码和共识算法过程中，至少附加时间戳信息。

8.根据权利要求7所述一种面向云数据操作行为的可信溯源方法，其特征在于，

基于所述Merkle山脉算法的算法结构，聚合所述溯源日志集，构建溯源日志摘要存储模型；

基于所述Merkle山脉算法更新日志摘要数据、Merkle根数据、SPV证明集，构建证明验证模型；

基于所述溯源日志摘要存储模型，构建证明快照；基于所述溯源日志摘要存储模型、所述证明验证模型、所述证明快照，构建所述溯源日志校验模型。

9.根据权利要求8所述一种面向云数据操作行为的可信溯源方法，其特征在于，

遍历所述Merkle山脉算法，提取所述溯源日志摘要存储模型的叶子结点的结点坐标，获得所述叶子结点的左侧的第一子哈希树、所述叶子结点所在的第二子哈希树、所述叶子结点的右侧的第三子哈希树；

基于所述第一子哈希树、所述第二子哈希树、所述第三子哈希树，构建所述SPV证明集。

10.根据权利要求1所述一种面向云数据操作行为的可信溯源方法，其特征在于：

提取所述云数据的最早时序日志作为顶点数据；

初始化所述数据溯源模型和所述云数据；

将所述顶点数据添加到所述数据溯源模型，标记所述顶点数据为已访问；

提取所述云数据与所述数据溯源模型相连的流转事件，将所述流转事件对应的***日志标记为待添加日志，判断所述流转事件是否为所述顶点数据，基于判断结果与所述数据溯源模型，对所述云数据进行溯源。

Images