immudb官方论文学习记录

immudb: A Lightweight, Performant Immutable Database

0 摘要

世界上越来越多的活动被数字服务记录下来,这导致数据存储的合规性和监管环境越来越严格,对该存储的攻击也越来越复杂和微妙。本文描述了immudb,一个仅附加的通用数据库,它与其他安全最佳实践相结合,提供篡改证据和不可否认的传输,同时保持适合大容量应用程序的性能。immudb使用Merkle哈希树(MHT)来创建表示整个数据库在任何给定时间的状态的摘要。与证明1)给定元素已成功插入数据库和2)数据库在两个时间点之间一致的密码证明一起,这些提供了关于数据库状态有效性的可靠保证。同时,immudb使用版本化的键值和插入顺序API提供数据读取访问,使immudb能够以广泛的容量提供服务,否则将使用不太安全的替代方案。

1 简介和动机

……(大概就是数据安全受到威胁),需要创建一种新的数据库类别,该类别通过设计具有可审计性、不可破坏性和防篡改性,而不是试图用额外的说明来改造现有的数据库解决方案。

图1  一个经典Merkle哈希树的例子

如图一,每个数据元素 x_{i} 被散列并放入叶节点 I_{i,0}=H(x_{i}) ,每个连续的内部树节点都由其子节点的值从左到右串联的散列组成,直到创建单个根节点 I_{0,d} 。……

2 背景

2.1Merkle哈希树

Ralph C.Merkle在1979年的论文和1987年的一篇论文中描述了后来被称为Merkle树或Merkle哈希树(MHT)的东西,如图1所示。这些树被认为是数字签名,并在公共共享文件中对一些底层数据进行验证。当时签名方案的主要动机是在某些情况下提供加密安全的签名,同时通过使用计算成本低廉的哈希函数来避免使用非对称密钥加密的计算费用(当时很重要)。对这些树的操作有一个暂时的理解如下:

1.一些n个数据元素x_{0}x_{n}被呈现用于签名。在Merkle最初的概念中,这些是消息比特组。为了简单起见,我们假设n mod 2=0。

2.这n个元素中的每一个都是使用哈希函数H来消化的,为了便于记法,我们将每个H(x_{i}),0≤i≤n称为X_{i}。这些X_{i}值构成MHT的叶子,每个X_{i}包含在叶节点I_{i,0} ,表示其索引i和叶层深度,。更一般地,对于每个节点I_{i,j},i是以I_{i,j}为根的子树中最左边元素的索引,并且j是在从叶层向上(即朝向根)的路径遍历中测量的节点的深度。(ps:这边第二层最右边是不是应该是I_{n-1,1})

3.假设是一个二叉树,叶层的每对散列都被连接和散列,因此I_{0,1}=H(I_{0,0}\left | \right |I_{1,0})。因此,我们将I_{0,1},I_{2,1}……I_{n-1,1}装进\frac{n}{2}棵树,每棵树都是两个原始元素的散列的级联散列。我们重复这个过程,依此类推,直到我们创建一个具有根节点I_{0,log_{2}n}的树。

结果树有几个重要的财产。首先,根节点I_{0,log_{2}n}是整个树的摘要,包括所有原始数据元素x_{0}x_{n};因此,任何数据元素的改变都将改变包含该值的任何子树的根处的值,包括整个树。其次,从根到任何给定叶I_{i,0}的路径是唯一的。第三,给定数据元素x_{i}和树根值,可以使用一系列内部节点值构造x_{i}在树中的证明。

 图2

如图2:具有根I_{0,2}和数据元素x_{i}的某些树的包含证明。虚线圆圈表示可导出的值;粗圆圈是必须提供的值,以证明x_{i}用于树的构造(特别是作为第i个元素)。

2.2 包容性证明

图2说明了生成包含证明的过程。MHT根的值是其子值从左到右的2个串联的散列,其每个子值都是其子的从左到右侧的串联,依此类推。在深度为3和4的数据元素的完整二叉树的情况下,如果我们希望证明包含x_{1},我们需要提供缺失的信息,以允许某人在给定x_{1}的情况下生成I_{0,2}

PS(Hash函数H将可变长度的数据块M作为输入,产生固定长度的Hash值:h = H(M)。其中h是定长的散列值,H是哈希函数,M是一个变长消息。Hash函数在数字签名和消息完整性检测等方面有着广泛的应用。Hash函数同时是一种具有压缩特性的单向函数,其像通常称为数字指纹,消息摘要或散列值。)

因此,显示I_{0,1}(以及扩展为x_{1})在其指示位置被用于生成以I_{0,2}为根的树所需的元素是兄弟I_{0,1}、其父的兄弟I_{2,1}和根。包含证明是集合{I_{0,1}I_{2,1}I_{0,0}}。更一般地说,对于给定的x_{i},包含证明集是其同级,并且每个父级的同级都向根移动,这足以从x_{i}计算根。验证仅仅是对上述等式1的模拟计算。这证明了树包含证明的另一个重要特性——不需要包含任何数据元素,从而保护了这些数据的隐私。

2.3 可变Merkle哈希树

Merkle最初对MHT的描述是作为签名方案的一部分使用的,带外双方同意静态消息。Crosby和Wallach以及Laurie等人分别提出了扩展MHT的程序,以仅附加主要包含MHT所需安全不变量的数据结构。在这些系统中,当一些元素x_{n}被添加到一个由n个元素组成的树中时,它被附加到树中,并向重新计算的根进行散列,如图3所示

图3

因此,不是完全重新计算树,而是在插入到大小为n的树时,只重新计算O(log2n)个散列,从而产生O(n)个散列。

 rosby和Laurie都对散列输入函数0x00(如果散列结果是叶)和0x01(如果它是内部节点)的字节指示符进行了修改。这有助于抵御第二次preimage攻击(PS:哈希函数的 preimage 是指能够生成同一个特定指纹的所有输入的合集。),在第二次攻击中,一个attacker可以呈现一棵树,其中某个深度>0的节点被呈现为叶子,它们的值是其实际子代的连接散列,产生与原始有效树相同的根值,但会使数据混乱。

2.4 一致性证明

增长MHT的引入还引入了一类新的增量一致性证明,证明了一些树根值Iq是从某个其他树的有效超集构建的树的摘要,该树的摘要是Ip。也就是说,Iq包含Ip和额外的数据元素。这样的证据包括

Ip中最接近根的内部值,也存在于Iq中,足以计算Ip,如图4所示

图4 

如图4:使用Crosby的方案,可以通过提供叶子和节点的最小集合来证明左边的一元树与右边的树是一致的,这证明了左边的树可以从右边计算(在这种情况下,I_{0,0},它可以用来计算I_{0,1}(这与I'_{0,1}不同))加上I_{1,0}(可用来计算I'_{0,1})和I_{2,1},使用计算的I'_{0,1},可以用来计算右树的根。必要的节点在重圆圈中。

2.5根签名

上述MHT制度假设客户端/服务器/审计员模型,其中一个或多个客户端将其数据提交给持有可变MHT的权威副本的服务器,并可选地请求其数据被成功插入的证据。一个或多个审计员定期通过要求提供证据来测试MHT的一致性。如果客户端或审计员(统称为“代理”)收到的证据没有正确计算,它可以立即推测服务器行为不端。然而,上述代理人不一定能向任何其他代理人证明这种不当行为;根据另一个代理看到的更新和证据,服务器可以通过谎称服务器行为不端来声称报告代理行为不端通过提供伪造的证据。为了避免这种情况,Crosby和Wallach以及Laurie等人都规定,服务器应该对其广告的根值进行签名,并且这种签名的根应该广泛发布,以阻止否认。如果对根值进行了签名,则任何代理都可以证明服务器合法提供了任何证据。

2.6 变异Merkle树的安全性

鉴于上述组件,产生的可变MHT具有强大的安全性财产:

1.根摘要表示完整MHT的状态,如果任何底层数据元素发生变化,相关的哈希也会发生变化,从而使MHT明显被篡改。

2.树的仅追加结构意味着对数据元素的随意删除将对树造成显著的变化。因此,任何一致的MHT都保证了先前输入的数据在给定位置的不可否认性。

3.服务器及其底层数据不必是可信的;每个客户端都可以验证她的数据是否已插入,并随时审核MHT的当前状态是否仍包含该数据。签名根表示服务器的证明,可用于向其他代理证明不当行为。

 2.7 可变异Merkle树的渐近性能

除了它们的安全性财产之外,可变二进制MHT在空间和时间上的最坏情况性能方面还具有很好的财产。空间这样的MHT以O(n)的形式增长。具体来说,MHT用于存储n个项目的空间消耗为2n×32字节(节点数量×SHA-256哈希的大小),外加必要的特定于实现的开销。这不包括存储数据元素所需的空间,这将取决于这些数据的大小。深度MHT从给定的叶子到根的长度以O(log2n)的形式增长。插入时间将项目附加到MHT所花费的时间随着O(log2n)的增长而增长。查找时间在MHT中查找插入的某个项目所花费的时间随着O(log2n)的增长而增长。

3 immudb

 

图5 immudb体系结构概述

immudb是如上所述的可变MHT的扩展,它提供了一个由可变MHT支持的通用数据库,如图5所示。 

3.1 immudb服务器进程

 immudb服务器进程执行immudb的MHT的总体管理和相关数据的操作。服务器进程包含一个管理员线程,该线程不断地从底层数据中重新计算组成MHT值,以防止损坏。它还包含证明生成和根签名机制。服务器通过grpc公开一个API,客户端和审计员连接到该API,以进行身份验证、插入和获取数据、执行监控以及要求包含和一致性证明。grpc API可选择在传输层使用双向TLS进行保护。immudb分别使用FIPS认证的SHA-256和ECDSA进行MHT哈希和根签名。服务器进程连接到存储层,该存储层管理插入数据的物理持久性和相关的可变MHT。

3.2 immudb的存储层 

 immudb的存储层包括一个或多个应用程序数据库以及存储服务器自己的元数据的特殊sysdb数据库和MHT。每个数据库都由存储区(包含各种数据元素xi)和支持MHT组成,MHT保护存储区免受未检测到的泄漏。immudb的存储层设计为键值存储,其中每个键值对(k,v)都存储为数据元素xi。MHT中对这对数据进行散列,而不仅仅是值。存储层维护索引以帮助访问数据:

插入顺序索引i→ xi以按插入顺序提供随机访问。服务器的证据生成任务和腐败管理员也使用此索引。该索引改进了从基本二进制MHT的O(log2n)到O(1)的数据元素的查找。

密钥索引k→ {vx,vy,…}被维护以提供对给定密钥k的当前和历史值的访问。由于immudb是一个仅附加的数据库,对与给定密钥相关联的值的更新被建模为该密钥的新值的插入。客户端可以检索最新的值或历史值列表。该索引通过使用以上索引到O(|{v|k→ v} |),即随着键k映射到的值v的数量而增长。

MHT节点索引i,j→ Ii,j提供对MHT树节点和叶子的方便访问,索引通过消除树遍历操作,收紧了各种O(log2n)树算法运行时的常数因子,包括插入时间、证明生成和验证。

目前,immudb存储层使用Badger作为其存储引擎,但immudb服务器和存储层可以被认为是引擎不可知的。目前正在开发一个更轻的引擎,它除了提高性能外,没有改变immudb的财产。

3.3 The immudb API

immudb API提供了各种设置和获取数据的方法。核心方法包括:

get(Key k)返回与密钥k关联的最新键值对(k,v)

safeGet(Key k,int i)如上所述,但还需要(k,v)的包含证明以及服务器已知的最新MHT与插入xi后出现的树之间的一致性证明

getByIndex(int i)返回插入的第i个键值对(k,v)

history(Key k)返回与k关联的所有键值对(k,v)的列表

safeSet(Key k,Value v,int i)如上所述,但还要求提供(k,v)的包含证明以及插入请求元素后MHT与插入xi后出现的树之间的一致性证明

当将immudb集成到新的或遗留的应用程序中时,这些API调用提供了灵活性。存储键值对的软件无需进一步努力即可工作。使用时间序列数据的应用程序,例如tick数据,可以通过“覆盖”键来存储这些数据,然后可以使用history()检索tick流。面向文档的数据操作可以将文档存储为(k,v)对中的值v,尽管目前必须在应用层对存储中的文档进行过滤和操作。immudb还支持进一步的方法来支持证明:

consistencyProof(int i)返回插入xi后MHT版本与当前树之间的一致性证明

inclusionProof(int i)返回元素xi的包含证明

图6  safeGet()获取密钥值数据以及加密证明

图6提供了客户端使用safeGet()的示例。客户端调用safeGet(k),这是safeGet的语法糖(k,r),其中r是客户端已知的最近更新的根。然后,服务器返回密钥、值、包含性和一致性证明。客户端检查包含性和一致性证明,如果证明计算正确,则客户端使用证明更新其最后验证的MHT根。每个审计员和客户端负责维护其看到的最后一个有效MHT状态的自己的副本,并根据自己的状态定期验证服务器的MHT,并相应地更新其内部状态或宣布故障。包含性和一致性证明具有所需的特性,即所述证明不包括数据库中的数据元素,而只包括它们的散列。因此,尽管多个用户可以使用同一数据库,但在适当的访问控制制度下,不会向任何用户发送她无法访问的数据。

3.4免疫纵深防御

 与任何服务一样,为了确保安全操作,安全最佳实践是必要的。虽然本文中描述的可变MHT对无声篡改是鲁棒的,但除了标准数据库之外,它们在数据破坏、损坏或窃取方面没有提供任何保证,而这些数据破坏、破坏或窃取并不意味着秘密。

应该实践适当的网络分割和访问控制。此外,强烈建议immudb服务器在与任何客户端分离的计算机(物理或虚拟)上运行,以确保客户端与服务器或其数据的唯一交互是通过公开的grpc API.

根签名为不可否认性提供了更强的保证,但仅在代理可能被假设为对抗性工作的应用程序中有用。由于ECDSA签名的计算成本很高,在检测到数据库中存在故障的客户端可能会信以为真的情况下,使用不带签名根的immudb可能会提供更大的吞吐量。第5节展望了正在开发的机制,这些机制可能会进一步加强immudb和与其接口的应用程序以抵御攻击。

4 应用immudb

第1节中的例子可能显得微不足道,是小型媒体运营商安全性差的结果。然而,数据操纵的威胁是巨大的,通常是导致重大损失的长期违规行为的一部分。FireEye在2018年10月报道了一场将数据操纵作为攻击关键路径的活动。至少自2014年以来,根据公开报告,朝鲜国家支持的APT38威胁集团[2]利用SWIFT全球金融交易网络从多家银行窃取了约11亿美元[19]。在一系列精心策划的攻击中,APT38将鱼叉捕鱼和其他社会工程攻击、恶意软件以及滥用各种安全漏洞相结合,进入金融机构网络。一旦进入,APT38将花费大量时间(平均155天,每个FireEye最多678天)收集有关网络和计算环境的情报,然后将大型交易插入SWIFT网络,这些交易将用于APT38控制下的其他国家银行的账户,这些银行的财政监督较差。作为在资金交付之前逃避检测的稳健策略的一部分,APT38部署的DYEPACK恶意软件工具包将直接在支持SWIFT交易服务器的Oracle数据库上执行SQL命令,并删除或修改所进行的欺诈交易,这一点通过对恶意软件活拷贝的法医分析得到了验证[19,21,22]。这个简单的步骤阻止了对即将发出的SWIFT交易的检查,这些交易本可以立即标记该活动以供审查。

在这样的系统中,immudb可以通过两种方式之一进行部署。首先,immudb客户端监听Oracle数据库的变更数据捕获(CDC)功能[1]以记录所有数据库活动,该客户端可以将CDC输出通过管道传输到immudb服务器,该服务器本身可以防止分布在整个网络中的多个审计员的破坏。然后,immudb数据库将有一个不可否认和篡改的DYEPACK更新和删除记录,可以采取行动。然而,尽管这种解决方案在遗留应用程序的多种场景中都是必要的,但它远非理想。在DYEPACK攻击SWIFT服务器的特定情况下,DYEPACK可以简单地从Oracle数据库中删除相关的CDC表,完全禁用CDC,然后在删除和编辑完成后重新创建它们。如果工作量更大,那么用immudb替换Oracle实例就更安全。immudb不提供用于修改和删除的API,因此无法像使用Oracle那样从命令行界面删除记录。可以直接修改磁盘上的数据,但这种修改会被持续运行的服务器损坏管理员以及部署的审计员快速检测到。下一节中描述的工作将有助于在这种情况下加强immudb部署,并减轻应用程序开发的负担。

5 未来工作

如今,immudb代表着在不可伪造、不可篡改、可审计的数据存储方面的重大飞跃。为使immudb更具可用性、实用性和性能而计划或正在开发的其他功能包括但不限于:

驱动程序--为最常用的语言编写的驱动程序,允许更多新的和遗留的应用程序本地使用immudb

类SQL查询--支持类SQL查询语言,允许更复杂的服务器端结果获取,并更容易地从不太安全的遗留数据存储转换到immudb

改进的存储引擎--创建一个专门设计用于有效支持immudb底层数据结构的引擎

缓存--支持基于应用程序需求的可配置缓存。由于在immudb中,冻结子树中过去的条目和散列在功能上是不可变的,因此这些条目和散列有助于成熟的静态数据复制和缓存技术

高可用性和分片--支持可配置的复制和分片,以支持负载平衡、容错和可用性。immudb使用的SHA-256哈希的一致随机输出特别使基于哈希前缀范围的自动分片变得简单且可能负载平衡

外部安全密钥--支持包含加密密钥的硬件设备,例如Nitrokey或Yubico的通用第二因子(U2F)设备

静止时加密--继immudb特定存储引擎之后,在数据库服务器级别支持静止时的数据加密,以补充immudb在传输中的双向TLS加密。

八卦协议--支持审计员和客户之间的八卦协议,以透明、持续地检测和标记可疑篡改。

GPU加速--支持使用商品GPU硬件加速immudb的SHA-256哈希和ECDSA签名。与CPU相比,加密原语的加速利用了GPU的宽数据总线,并且在触发大量同时哈希计算或签名的事务的情况下,可以显著提高吞吐量。

GDPR和CCPA合规性--遵守欧盟《通用数据保护条例》和《加州消费者隐私法》。GDPR规定在某些情况下必须删除数据。虽然这对于诸如immudb之类的仅附加数据库来说可能具有挑战性,因为底层MHT的一致性取决于给定值的散列而不是值本身,基础数据本身可以在适当审计数据和记录的制度下删除(例如,在不受删除或编辑规定约束的配套immudb元数据库中),哪些条目是在什么权限下删除的。

6 结论

在本文中,我们描述了immudb的设计和实现,immudb是一种高性能的仅附加的通用数据库,它提供了强大的篡改证据和插入数据的不可否认性。从Merkle Hash Trees和Crosby和Wallach的后续工作以及Laurie等人的证书透明度标准提案开始,我们通过对通用数据库使用比喻的新颖扩展提供了一个实用的实现,从而扩展了新定义的现有技术。immudb结合标准网络和应用程序安全最佳实践进行了正确部署,可防止敏感数据的未检测插入、突变或删除。数据库状态的加密摘要允许定期和连续的审计,而无需连续扫描数据库状态的计算费用,并且这些摘要的可选服务器端签名允许审计人员权威地证明服务器的数据何时被篡改。

immudb的财产使其适用于各种行业,在这些行业中,数据的正确性和对未检测到的事后修改的抵抗至关重要。用例的范围很广,包括财务分类账合规性、电子健康记录、护照和文件控制系统、科学数据记录、源代码验证等等。我们相信,immudb的大规模应用有可能改变整个安全格局。

7 致谢

其他相关资料

immudb是Apache 2.0许可证下的开源软件,可以在以下位置找到:GitHub - codenotary/immudb: immudb - immutable database based on zero trust, SQL and Key-Value, tamperproof, data change history

有关immudb的更多信息,请访问:immudb - immutable database based on zero trust, SQL and Key-Value

immudb 的视频介绍:https://fosdem.org/2022/schedule/event/safety_dont_trust_us_trust_the_math_behind_immudb/

immdub 的论文:https://links.jianshu.com/go?to=https%3A%2F%2Fcodenotary.s3.amazonaws.com%2FResearch-Paper-immudb-CodeNotary_v3.0.pdf

 未完待续……欢迎点赞收藏!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值