Corda数据篡改问题 [英] Corda Data Tampering Issue

查看:70
本文介绍了Corda数据篡改问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

背景
我们了解到,corda不是防篡改的,而是显而易见的。因此,如果一个节点直接在数据库中操作了一个状态,则其他节点将能够检测到该状态并将其标记在后续事务中。但是,我们的测试结果不符合我们的预期。 Corda并未标记已被篡改的状态,实际上,它在所有参与者节点中记录了带有被篡改数据的新状态。

Background: We learned that corda is not tamper-proof but tamper-evident. So, if one of the node manipulated a state directly in the database, other nodes will be able to detect and flag it if that state was used in subsequent transactions. However, our test results were not as per our expectation. Corda did not flag the state that was tampered and in fact it recorded the new state with tampered data in all participant nodes.

先决条件
注释合同验证:我们注释了合同代码以检查是否在Corda中检测到数据篡改

要复制的步骤:


  1. 启动义务Cordapp。

  2. 在甲方和乙方之间建立3项义务(100泰铢,256泰铢和100泰铢)

  1. Start obligation Cordapp.
  2. Create 3 obligations between Party A and Party B (100 THB, 256 THB and 100 THB)

通过查看十六进制之间的差异来编辑乙方数据库中的VAULT_STATES表。

不同金额的债务在左边,而两个相同金额的债务在右边。在编辑器中,当它们的数量相同时,存在2个差异(可能与linear-id和时间戳相关),而当它们的数量不同时,则在左侧显示第三个差异。

Edit the VAULT_STATES table in the database of Party B, by looking at the differences between the hexs. Obligations with different amount is on the left and the two obligations with the same amount is on the right. From the editor when they are at same amount there are 2 differences (presumably linear-id & timestamp related) and when they are at different amount the 3rd discrepancy is showed on the left.

用较低的金额覆盖特定部分,使用SQL对乙方的保险库更新保险库:

Overwrite the specific portion with the lower value amount, update vault using SQL on Party B’s vault:


  1. 更新后,请检查乙方的保险库,并将这三项义务的金额更改为100泰铢。

  1. After this update, check Party B’s vault and the amounts are changed to 100 THB on all 3 obligations.

但是,甲方的保险库将显示原始金额(100、256、100)作为数据没有被甲方的保险库篡改。

However, Party A’s vault will show original amounts (100, 256, 100) as the data was not tampered in Party A’s vault.

将所有义务从乙方转移到丙方

Transfer ALL obligations from Party B to Party C

转移义务结果:乙方没有更多义务

Transfer obligations result: Party B have no more obligations

转移义务结果:丙方将获得乙方的所有义务(共100泰铢,即被篡改的数据已转移到新方)

Transfer obligations result: Party C will get all Party B’s Obligations (100 THB for all, i.e. tampered data was passed on to the new party)

转移义务的结果:甲方的保险库也将被篡改数据更新。它无法识别或标记被篡改的数据。

Transfer obligations result: Party A’s vault will also be updated with tampered data. It couldn’t identify or flag tampered data.

如何获取Corda参与者节点检测篡改状态?我在设置节点时错过了一些配置吗?

推荐答案

恐怕此讨论可能需要一段时间因为我们大多数人从今天下午开始放假。

I'm afraid this discussion may take a while because most of us are off on holiday from this afternoon.

我们将复制您在此处所做的工作。但是我不清楚这是一个错误。

We'll have a go at replicating what you did here. However it's not clear to me that this is a bug.

您说您已注释掉合同验证逻辑。听起来可能是这样:

You say you commented out the contract validation logic. It sounds like what may have happened is this:


  1. 编辑状态表以保存损坏的状态。

  2. 使用INPUT =指向先前正确状态的指针构建事务。 OUTPUT =(损坏的状态)+编辑以保留新的所有者字段。

  3. 此交易现已签名并转移。

此交易被认为是无效的,并在尝试转移至丙方时被拒绝,因为这是非法的状态转换:数字不平衡。但是您注释掉了检查该代码的代码!因此,在任何地方都没有什么说不准您随意改变义务的大小的。如果您注释掉包含此知识的代码,Corda不会暗含这一点。因此,从IOU应用程序的角度来看,在转移时更改大小现在是一件完全合法的事情。

This transaction would have been considered invalid and rejected when the transfer to Party C is attempted, because it'd be an illegal state transition: the numbers do not balance. But you commented out the code that checks for that! So nothing anywhere is saying you aren't allowed to simply change the size of an obligation whenever you like ... Corda doesn't know that implicitly if you comment out the code that contains this knowledge. Thus from the IOU app's perspective changing the size as you transfer it is now a perfectly legitimate thing to do.

这是问题-如果您不理会应用程序而不要修改其源代码,是否检测到篡改?如果答案仍然是否,那么我们还有更多调查要做。

Here's the question - if you leave the app alone and don't modify its source code, is the tampering detected? If the answer is still "no" then we have some more investigation to do.

这篇关于Corda数据篡改问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆