[区块链]一种基于区块链的防篡改技术设计下溯源应用系统-3-阿里云开发者社区

开发者社区> 安全> 正文
登录阅读全文

[区块链]一种基于区块链的防篡改技术设计下溯源应用系统-3

简介: 一种基于区块链的防篡改技术设计下溯源应用系统

3防篡改技术设计的溯源架构—TPAB架构

TPAB(基于区块链的防篡改架构)在我们设计的架构中,TPAB区块链注重保证数据的完整性、防篡改性和原始出处;与传统的区块链账本技术相比,TPAB区块链更加注重交易数据的一致性、共享性和智能合约方面。

3.1 TPAB整体架构

TPAB提供了由核心节点、聚合器和网关组成的安全基础设施,用于创建TPAB签名以实现数据完整性。

 

3.1.1网关层设施

第一层聚合服务器是收集和处理来自客户端的请求,然后将聚合请求发送到上游服务器的网关。网关是基础设施中面向客户端的部分,为客户端提供TPAB服务。

网络聚合哈希并分发签名。每个聚合服务器处理来自其下级服务器的请求,将其添加到哈希树中,并将本地根哈希发送给下一个更高级别的服务器。

 

3.1.2聚合层设施

聚合服务器层次结构为每一轮创建一个全局哈希树。认证网络(聚合网络的一部分)提供了广泛的目击者访问日历状态和访问认证解决方案中使用的根哈希历史。

 

3.1.3核心节点

核心集群位于聚合网络的顶端,运行分布式状态机,并管理日历。它每1秒(大约)计算一次顶级根哈希,使用分布式共识算法对其进行投票,并将顶级根哈希推荐给CHC.核心负责就每个聚合周期的顶级根哈希达成一致,然后将其存储在日历数据库中,结果返回给聚合网络。聚合和核心过程中使用的规则间隔周期(轮次)会产生一个精确的时间度量,该度量被嵌入到TPAB签名中。

3.2 TPAB中的算法模型

3.2.1 哈希函数、默克尔树

哈希函数(Hash function):又称散列函数,是一种从任意数据中创建“数据指纹”的方式,可将任意长度的输入值转换为固定长度的输出值,即哈希值,也称散列值,通常为数字与字母的组合。本系统中采用了SHA-256(Secure Hash Algorithm 256)算法作为系统运行过程中哈希值的计算方法。哈希函数能够给出数据的电子身份证明,简化数据规模,确保数据在传输、定位、检索等过程中的高效、准确,具有单向性、抗碰撞能力与防篡改的能力,具体表现为:

(1)单向性:哈希函数具有单向映射关系,即输入与输出值一一对应,但不可由输出值反推输入值的具体数据。在本区块链档案管理系统中,公有账本中仅记录了各表单相对应的哈希值,不可直接查看表单中的数据。

(2)抗碰撞能力:两个不同的输入经映射后形成同一个摘要的现象在密码学中称为碰撞,哈希函数具有极强的抗碰撞能力。在本系统中,抗碰撞能力表现为对任意表单、审批动作等相关信息,其转换后对应的哈希值均不相同。

(3)防篡改能力:哈希函数具有极强的敏感性,输入值的细微变化均可导致其输出的散列值的变化。以哈希函数SHA-256为例,有:

image.png

 

默克尔树(Merkle tree):又称哈希树(hash tree),是一种二叉树形数据结构,由一个根节点、一组中间节点一组叶节点组成,每个叶节点均以数据块的哈希作为标签,除了叶节点以外的节点则以其子节点标签的加密哈希作为标签。生成一个完整的默克尔树需要递归地对一组节点进行哈希操作,并将生成的哈希节点插入到默克尔树中,直到只剩一个哈希节点,该节点就是默克尔树的根,称为默克尔根(Merkle root),也称哈希根(Hash Root)。

 

3.2.2分布式哈希树

TPAB的服务包括一个全局分布式哈希树,其简化版本如下图所示。

image.png

哈希树每秒创建和销毁一次,树是由地理上独立的操作节点组成的层次结构,我们称之为聚合层,每个节点都以异步聚合的方式运行,都从其子树中接收哈希值,然后生成哈希树,再将哈希根值传送给多个父节点,聚合是无边界的,运行在虚拟机或专用硬件之上,在TPAB系统中,有4层聚合层次结构。系统可接受的理论极限是每秒2的64次方个签名。

3.2.3 聚合哈希链

聚合哈希链的目的是证明某个文档哈希(签名文档)是全局聚合树的一部分。聚合哈希链的组件是同级哈希,当按照给定的顺序从左或从右加入时,最终将产生聚合哈希树的根。

(1)AHC的多个实例

全局聚合树由若干个层次分明的聚合器组成。每个聚合器为该聚合器的子树提供链。当连接在一起时,这些来自每个聚合器的链 "碎片 "形成了一个从文档哈希到全局哈希树根的完整链。聚合后的链(碎片)的计算输出必须与下一个哈希链(碎片)的输入相匹配。

(2)聚合时间

聚合时间是文件签名时间,通常以秒为单位,从1970-01-01 00:00:00 UTC(即POSIX时间)开始表示,应该对应于日历块中注册的全局聚合树根哈希表示的时间。因此,它对所有通向根的AHC一起是相同的。这个特殊字段不受加密保护(由日历区块链提供),用于技术目的。例如,寻找用于签名扩展的正确日历区块链。

(3) 输入哈希

输入的哈希值是哈希链计算的起点。在签名中的 "最低 "聚合链的情况下,这就是签名文件的哈希值。输入的哈希值将连接到右边兄弟姐妹哈希值的左前角,结果将被哈希。后者将连接到下一个兄弟姐妹哈希层,直到计算出哈希链的最终输出。

(4)元数据

左边或右边的链接可以是元数据,不一定是同级哈希。这用于将特定信息嵌入到签名哈希链中,并对该信息进行加密保护。例如,每个聚合器(从Gateway开始)都会将客户端的身份嵌入到哈希树中。元数据有一个强制性属性--客户端ID,它只是一个UTF-8的字符串。从加密的角度来看,元数据与树中其他的哈希值是一样的。也就是说,计算出的哈希值的来源也存储在签名中,以后可以检索。

输出的是一系列的身份信息。比如下面的输出。

user1 :: gatewayX :: aggregatorY :: aggregatorZ。

意味着当使用SDK的应用向TPAB网关请求签名时,其用户ID为user1。当网关计算本地树并将请求发送到下一级聚合器时,它使用用户 ID gatewayX。

3.2.4 日历哈希链

TPAB签名中的日历散列链CHC的主要目的是证明某个签名的签名时间以及确保长期的完整性。日历哈希链将导致一个被广泛见证的事件。

CHC与AHC类似。由于日历块是由Core保存和维护的,所以TPAB签名的CHC组件只有一个从输入到公布值的哈希实例。签名中(最高的)AHC 的输出哈希必须与 CHC 的输入哈希相匹配。当首次获得 TPAB 签名时,其中的 CHC 是不完整的(或完全缺失),因为没有签名专用的释放。

释放的时间与CHC输出哈希的时间相对应。如果哈希链的结果是释放,则时间等于释放时间。如果释放时间不存在,或者签名没有延伸到释放时间,则释放时间只显示(不完整)CHC的输出哈希的时间。

左右链接的作用与AHC完全相同--它们用于计算输出哈希。

 

3.2.5 时间验证算法

TPAB签名的时间也以日历哈希链的形状编码。 这使得能够计算/验证来自日历哈希链的时间以及其导致的发布时间。 这种验证由TPAB SDK执行,作为内部验证策略的一部分。

3.2.5.1 构建日历哈希树

日历区块链(其中每个叶对应于一秒)的二叉树以一定的确定性方式构建。以下示例树用于说明构建过程:

image.png

样本树有13个叶子:

首先,采取8个最左边的叶子,因为8是最小的数字,是2的小于或等于13的幂。这允许我们构建最大的完美二进制子树(紫色)。

对剩余的叶子反复应用相同的程序。在样本树的情况下,下一个子树(蓝色)由4个叶子形成(因为4是2和小于或等于5的幂的最大数字)。剩下的绿叶形成第三个子树。

一旦形成了各个子树,就将它们结合成一棵树。这个过程从右起首先将绿色和蓝色树的根结合起来,然后结果与紫色树的根结合。

这意味着以下内容适用于树中的任何节点:

它的左子树总是一个完美的二叉树(叶数完全是2N)。

它的右子树遵循与整个树相同的结构,只有较少数量的树叶(例如其左子树再次是完美的,右树遵循与整个树相同的结构等)。

 

3.2.5.2 寻找叶子的位置

以这种方式构建树可以使用以下方式找到任何叶子的位置:

树中总叶数; 和

从根节点到所需叶的路径。

在上面的例子中,总数为13.如果我们想要查找或验证B1的位置,从根节点到它的路径将是RLLL(意味着从根部到达B1,我们将首先移动一次到右边 然后向左移动3次)。

用于查找位置的算法使用提供的路径从根节点遍历到所需的叶节点。 在遍历期间,在每个节点,很容易找到:

树中的树叶数,该节点是根节点; 和

左右子树中的叶数。

 

3.2.5.3 子树中的叶数

考虑到树的构建方式,我们知道左子树是一个完美的二叉树。 因此,它必须有2N个叶子,其中N是最大的整数,使得2N小于总叶数。 示例:

总叶数 N  2N (左子树中的叶必须小于总叶数)

13    3  8(<13)

16    3  8(<16)

18    4  16(<18)

在我们知道左子树中的叶子之后,找到右子树中的叶数是很容易的,因为我们知道叶子的总数 - 从先前的“迭代”,或者如果我们在根节点,这都是作为算法的输入。

3.2.5.4 路径搜索

知道左右子树中的叶数有助于缩小每个移动期望的叶节点的范围,如下所示:

当我们在根节点时,我们知道B1的(基于0的位置)为0 .. 12。

当我们向右移动时,将范围缩小到(0 + 8).. 12,因为左子树中有8个叶,而B1不是其中之一。

当我们向左移动时,将范围缩小到0 ..(12 - 5),因为右子树中有5个叶,而B1不是其中之一。

一般来说,这意味着移动右边会增加左边子树中的叶子数量的开始,左边移动的左边会将范围的结尾减少右边子树中的叶子数。

3.2.5.5 算法说明

以Python编写的以下递归函数findPosition找到由给定路径指定的叶的位置。 帮助函数getLeftLeafCount用于获取左子树中的叶数。 请注意,树中的叶数并没有明确地作为参数给出,因为这可以从posMin和posMax计算出来。

# Recursively finds the position of a leaf node, given the

# minimum, maximum leaf positions and the path from the root

# to the leaf node in question.

def findPosition(posMin, posMax, path):

    leafCountAtNode = posMax - posMin + 1

    leftLeafCount = getLeftLeafCount(leafCountAtNode)

    rightLeafCount = leafCountAtNode - leftLeafCount

 

    print "Total leaf count " + str(leafCountAtNode) +

    ", left subtree " + str(leftLeafCount) +

    ", right subtree " + str(rightLeafCount) + "; posMin " +

    str(posMin) + ", posMax " + str(posMax)

 

    # If no more moves left, posMin and posMax have to be equal

    if len(path) == 0:

        assert(posMin == posMax)

        return posMax

 

    move = path[0]

    if move == 'R':

        posMin += leftLeafCount

    elif move == 'L':

        posMax -= rightLeafCount

    else:

        raise ValueError('Invalid move ' + move)

    return findPosition(posMin, posMax, path[1:])

 

# Finds the number of leaves in the left subtree

# given the total number of leaves in the tree

def getLeftLeafCount(totalLeafCount):

    # The answer is the largest power of 2 that's

    # strictly less than the total number of leaves

 

    # Keep computing successive powers of 2 until

    # we reach or exceed the upper bound

    leftLeafCount = 1

    while leftLeafCount < totalLeafCount:

        leftLeafCount = leftLeafCount << 1

 

    # Now leftLeafCount >= totalLeafCount, so we have

    # come one step too far, so we take one step back

    leftLeafCount = leftLeafCount >> 1

    return leftLeafCount

使用具有13个叶子的样本树,并找到路径为RLLL的B1的0位置,得到以下结果:

>>> import tpabtime

>>> tpabtime.findPosition(0, 12, ['R','L','L','L'])

Total leaf count 13, left subtree 8, right subtree 5; posMin 0, posMax 12

Total leaf count 5, left subtree 4, right subtree 1; posMin 8, posMax 12

Total leaf count 4, left subtree 2, right subtree 2; posMin 8, posMax 11

Total leaf count 2, left subtree 1, right subtree 1; posMin 8, posMax 9

Total leaf count 1, left subtree 0, right subtree 1; posMin 8, posMax 8

8

3.2.5.5 时间验证

将上述算法放在TPAB签名和TPAB日历区块链的上下文中,我们可以使用以下方式验证TPAB签名的POSIX时间(自1970-01-01 00:00:00 UTC以来的秒数),POSIX出版时间P(假设TPAB签名已扩展到本发布)。

TPAB签名中的日历哈希链的形状,它是从时间P构建的树的根到对应于签名时间的叶的路径。由于最左边的叶对应于从1970-01-01 00:00:00 UTC开始的0秒,下一个叶对应于从1970-01-01 00:00:00 UTC开始的1秒),POSIX时间等于0 叶的位置。 因此,我们可以轻易地利用上面的findPosition函数来查找POSIX时间:

def findTime(P, path):

    # The leaves are numbered 0...P

    return findPosition(0, P, path)

运行该函数时,我们得到与findPosition相同的输出:

>>> tpabtime.findTime(12, ['R','L','L','L'])

Total leaf count 13, left subtree 8, right subtree 5; posMin 0, posMax 12

Total leaf count 5, left subtree 4, right subtree 1; posMin 8, posMax 12

Total leaf count 4, left subtree 2, right subtree 2; posMin 8, posMax 11

Total leaf count 2, left subtree 1, right subtree 1; posMin 8, posMax 9

Total leaf count 1, left subtree 0, right subtree 1; posMin 8, posMax 8

8

 

 

 

3.2.6 增强的共识算法

共识协议定义是使分布式系统中的节点快速有效地达成数据的一致性,即确保所有可靠节点以完全相同的顺序执行共识结论中交易,达成数据一致性,同时正确的客户端发送的有效交易请求最终会被处理和应答。

TPAB区块链平台的共识组件可集成多类共识算法实现共识机制。目前,TPAB区块链系统中已实现的共识算法包括 PBFT ,下一步将会支持业界多类优秀算法。

 

PBFT(Practical Byzantine Fault Tolerance)共识协议支持系统中不超过 1/3 的节点容错性。通过 PrePrepare、Prepare、Commit的三阶段提交协议来实现网络共识节点之间的交易数据的一致性。TPAB区块链提供的 PBFT 共识具有快速终止、恢复可靠、状态同步等多项特性。实用拜占庭容错系统(PBFT)降低了拜占庭协议的运行复杂度,从指数级别降低到多项式级别,使拜占庭协议在分布式系统中应用成为现实

 

核心节点需采用一定的共识机制算法对需要记录的数据进行同步。共识即共同的认识,共识机制算法即表示使参与各方实现一致意见的算法规则。在本系统中,共识机制算法采用PBFT(Practical Byzantine Fault Tolerance)实用拜占庭容错算法,其应用过程(公有链多采用POS权益证明机制,联盟链采用PFT共识机制)

image.png 

TPAB核心节点共识机制实现模式

 

3.2.7 国密算法支持、信创产业

兼容使用国家密码局审批的密码算法,随机数发生器采用国家密码局审批的物理噪声源真随机数发生器,系统整体安全可靠,性能优异,架构合理在TPAB项目中支持的摘要输入算法包含SHA-256、SHA-512、SM3等但不限于以上算法。

  摘要函数在密码学中具有重要的地位,被广泛应用在数字签名,消息认证,数据完整性检测等场景。摘要函数通常被认为需要满足三个基本特性:单向、不可逆、固定大小、雪崩效应

早期MD5算法和SHA-1算法存在碰撞攻击方法,MD5算法和SHA-1算法不再是安全可靠的算法。SM3密码摘要算法是中国国家密码管理局2010年公布的商用密码杂凑算法标准。SM3算法适用于商用密码应用中的数字签名和验证,是在SHA-256基础上改进实现的一种算法。SM3算法采用Merkle-Damgard结构,消息分组长度为512位,摘要值长度为256位。SM3算法的压缩函数与SHA-256的压缩函数具有相似的结构,但是SM3算法的设计更加复杂,比如压缩函数的每一轮都使用2个消息字。

简言之,其中SM3算法包含如下两个部分:

1、分组,将需要加密的文件转为2进制,然后分组为512*K+448(K为任意整数,不够用一个“1”和多个“0”补齐),再加上64位的文件长度信息构成512*(K+1)的分组

image.png

2、迭代运算,这里有一个参数(256位)参与运算,初始值V(0)(文档中叫做IV),迭代一次之后得到V(1),后面依次迭代得到V(1)、V(2)、V(3)……V(K)、V(K+1),V(K+1)也就是最终的杂凑值 

image.png

迭代运算

信息技术应用创新产业中,目前我们正在兼容国产操作系统(如麒麟OS、UOS、普华OS、中科方德)、国产数据库(如人大金仓、达梦、巨杉等)、服务器(如中国长城、联想、曙光、东华、海信等)和芯片(如鲲鹏、飞腾、龙芯、兆芯等),助力于更具有普遍适用性和广泛的兼容性。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章
最新文章
相关文章